I’ve done engineering (Snowflake), sales & marketing (Numeracy), and a “hybrid” growth engineer (Sentry). At Kernel, I’m a customer engineer, a title I find myself often explaining, internal and external. So, time to write it down.

You can define a function in three parts:

• What is its purpose?
• What is success/failure?
• How does it work with other functions?

What is the purpose?

Customer engineering scales customer obsession.

Customer obsession means listening to and delivering on customers’ needs¹. Customers are the ground truth. They are how we touch grass. While no individual customer is “always right”, customer obsession course-corrects our product instincts.

Founding teams are customer obsessed in the early days, but as the number of customers grows exponentially, customer obsession breaks down. Time for customers declines linearly as focus is split on recruiting, fundraising, partnerships, product roadmaps, and internal management. A founder’s ability to focus on specific customers, not just the broad customer base, declines, and has definitely disappeared by the Dunbar number (150) of customers.

The last decade of product-led growth means self-serve customer bases scale faster, earlier. A decade ago, a public SaaS company might have a thousand customers. Now, you’ll get to a thousand before Series B, and that thousand might have all signed up in the last year. This volume creates the problem of scaling customer obsession very early on.

Why not scale using the product?

When customer obsession scaling breaks down, many companies shift to product obsession, because software scales (mostly). The dream is the product is self-documenting, customers are self-onboarding, and all your charts are up and to the right. You build a feature, update docs, and add it to onboarding. But most users are skipping the product onboarding or have trouble understanding the docs. They’re busy and they just want to create a browser and move on.

Product obsession is right for the product team, but it’s not enough for the business as a whole. You’re asking customers to meet you at your product, instead of you meeting them where they are. Your early adopters will soak up everything you ship, but as your customer base expands and matures, you increasingly need to meet them.

Scaling customer obsession

Trite as it is, AI unlocks the ability to scale customer operations from an engineering perspective, instead of a business COGS problem.

Customer obsession never scaled well before because customer support is overwhelmingly treated as a cost center, with the exception of companies like Zappos or Hilton, where it’s their brand. But those are fundamentally service companies with little to no core product of their own. At product companies, it’s hard to imagine customer support or even account managers ever getting paid more than the engineers.

AI changes this. Not just because AI can reply to emails. The entire nature of customer communication has changed. Let’s talk through the lens of reactive & proactive, fixes & features.

Reactive

Reactive means responding to inbound: bug reports and feature requests.

Bug fixes are the most straightforward quadrant. Either the customer misconfigured their code or our code’s behavior is incorrect. Since AI agents arrived, you don’t get the typical FAQ-level questions anymore: everyone is asking their agents, long before asking you. The questions I get are about bugs — “something unexpected happened, my agent can’t fix it. Can you see something I can’t?” And a lot of conversations turn into back and forth Claude screenshots. It’s not about having AI automate replies. The next step is letting customer and company AI’s have supervised conversations to solve not only customer problems, but diagnose and solve product gaps.

In doing so, customer support blurs the line between COGS and R&D.

For instance, when addressing issues, I no longer send just messages: I send code artifacts. AI enables “show don’t tell” at a support ticket level because writing sample apps or repro cases cost pennies instead of hours.

Feature requests are the more interesting reactive quadrant. We collect them, bagged and tagged, until we’re confident this is the right direction for the product roadmap. Most times, these issues (with customer requests attached) should clearly aggregate customer pain, not propose product solutions.

The fascinating part is validation: after release, we follow up with customers on whether this solved their problem. Founding teams do this naturally — every feature ships with a mental list of who asked for it and a Slack message checking in. But as the organization scales, validation gets lost. Historically, infrastructure customers were sticky, so even when they don’t adopt your latest features, they don’t churn. But that’s no longer the case. Swapping providers is one prompt away. Customer value is the only churn mitigation. Validating that features solve their case is just as essential as bug fixes.

Proactive

Companies love doing proactive comms, but how many of us truly enjoy them? For self-serve, you’d serve them a steady drip-drip of email campaigns and in-product tours. Except I don’t remember the last drip campaign I liked. I don’t remember the last product tour I didn’t mash the Escape button on. At the enterprise tier, you end up scheduling a monthly or quarterly check-in: often valuable but often slow-moving and difficult to scale.

Proactive communications break down into two types: health checks for fixes and feature recs. Because proactive comms aren’t requested by the customer, they must be managed more carefully. To ensure you’re not just creating spam, each communication must be centered on customer value, which comes from two things: working products and working relationships. Working products means following up on all the dozens of little issues, making sure nothing gets dropped. Working relationships means human-coherent milestones: What is the customer trying to accomplish? What’s the champion’s career timeline? What are the blockers to each?

Health checks are bug and performance audits. Look at a customer’s usage, spot misconfigurations or silent failures, and reach out before they notice. Same work as reactive bug fixing: conversations should result in fixes on both sides, not just the customer.

Feature recs are more interesting. When you ship a new feature, there should be a follow-up per customer: Open → In conversation → Evaluating → Adopting → Done, with Deferred or Declined as exits. These are customer engineering’s issue statuses, but for adoption.

How can you be proactive at scale, aka self-serve? Let me start with this: don’t drip. You need to stop thinking about support as tickets and more as ongoing conversations. In a world where every shopping site has product recs and media is full of product placement, what if support had personalized feature recs? Every inbound support request is a natural transition to talk about your other product features, to drive adoption, to demonstrate and solve a problem proactively. Using Kernel Profiles and experiencing a bug? Let me fix that for you and also remind you that Managed Auth actually solves the problem for you. “While I have you on the line” becomes “while you have that kernel.js file open”.

And these recs can be personalized not just to the customer’s use case, but to their language, stack, and toolset. A Python shop gets Python examples. A team on Terraform gets Terraform modules. What if you could send a prompt good enough to one-shot the adoption? Not a generic migration guide, but a concrete, ready-to-apply change tailored to their codebase.

Support is uniquely empowered to shepherd the customer base forward. When things are broken, customers are most ready to change — they’re activated. Products inevitably have bugs, but responsive support and timely resolution builds trust in the service. And once that trust in the service is earned, you can use that same relationship to drive customers to adopt new features or even new products.

What is success & failure?

Infrastructure businesses are power-law. Stripe had Lyft, Shopify; Twilio had Uber, Airbnb. And yet a customer that is 20% of total revenue can produce the same amount of support load as a free customer. But also that same free user could test out a tool on weekend project and then bring it to work and end up as a massive account.

PLG means self-serve doesn’t need to convert to be valuable. Marketing your product is expensive and the highest quality marketing is always word-of-mouth.

Success

Success is a customer fully utilizing the product. Whether or not a given customer has volume isn’t up to you. Whether a customer understands and adopts all the applicable features is.

Metrics map back to the grid. Reactive fixes: response times and resolution rates. Reactive features: quality of the issue delivered to product engineering. Proactive fixes (health checks): customer happiness (easily judged by agents, not CSAT scores). Proactive features (recommendations): feature adoption.

I trust that with each new feature or fix, we’re building something customers want. And by delivering that to the customers, the revenue will follow. Customer value and education have a long-term payoff, well beyond financial reporting cycles. The young couple spending a single night at your hotel deserves just as much attention as the traveling salesman, even if they spend a fraction. The value of a person today is a poor predictor for their future value, because great engineers curate the best tools and bring them wherever they go.

Failure

Churn is an incident, not a failure. Just like product engineering incidents, customer churn can be caused by our own bugs, competitive landscape, or even just customer fundraising cycles. We often see our Hobbyist churning because they don’t have enough usage. Customer engineering delivers churn postmortems, where each churn event, self-serve or enterprise, is understood as either a company failure or a customer journey (product or company shut down).

Failure is customer disappointment. And we measure that in failed conversations and failed relationships. And that doesn’t just include support tickets that don’t resolve, but in all customer conversations, like proactive outreach, that result in customers getting frustrated with and losing trust in us, the customer team at Kernel.

How does it work with other functions?

There are two major functions that intersect heavily with customer engineering: sales and product engineering.

Sales

Customer engineering should not be making sales. Customer engineering is focused on delivering overwhelming value to the customer, regardless of whether they upgrade. Your greatest advocate is the engineer who switches companies (or starts their own) and brings their tools with them. And sales much prefers when customers are already sold on the product and they just need to close the deal (focusing on legal, compliance, finance roadblocks).

Customer engineering should be handing off insanely qualified leads by driving customer success first and letting sales harvest the revenue later.

Product Engineering

The relationship between product and customer engineering is a question of context management. At any moment, all products have dozens of feature requests and hundreds of bugs. Trust me, I worked at Sentry. Building any individual feature or fixing any bugs doesn’t matter. Fixing bugs hit by hundreds or thousands of users doesn’t matter. Addressing user pain matters and that requires talking to users.

The primary responsibility of customer engineering is to give product engineering enough context to start immediately. For feature requests, deliver a concrete customer use case. For bug fixes, a repro case. For both, a discrete list of customers that are or will be impacted.

The threshold is context. Product engineering has the product context: stability, uptime, technical debt, design, etc. Customer engineering has customer context: for each customer, what are they using the product for, what features are they using, what is the state of the relationship, etc.

When the fix does not require product context but requires a lot of customer context, customer engineering should address it. This happens most often with bugs, where documenting a corner case requires more effort than prompting a fix.

When the fix requires understanding the product system as a whole, it’s always better to let product engineering’s code owner triage it. Most changes should end up in product engineering’s side, but the rapid turnaround enabled by customer engineering can save a customer relationship.

I recently fixed a Live View Safari bug. At first, I thought it was a minor bug: our live view seemed flaky at accepting user input for the first few seconds. But for this user, it was the difference between using Kernel or not because a significant portion of his audience (11%) uses Safari.

On the other hand, our Live View VP8 was causing major CPU load on safari on Macs and iPads because they do not support hardware-level VP8 decoding. I completely lack the context on VP9 encoding. In this situation, customer engineering’s job is to gather, aggregate, reproduce and triage customer feedback to hand-off to the part of product engineering with sufficient context.

Come for the product, stay for the service.