What is Customer Engineering?
April 2, 2026
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 needs1. 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.
It’s common for 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 as has definitely disappeared by the time we’ve hit 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.
Previously, customer obsession never scaled well before because customer support is overwhelmingly treated as a cost center, with the exception of a 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 about through the lens of reactive and proactive customer communications.
Reactive
Reactive support means responding to inbound requests, incident communication.
Since AI agents, you don’t get the typical FAQ-level questions anymore: everyone is asking their agents, long before asking you. The questions I get are most 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. The line between customer and product code is blurrier than ever, as agents are the interface to both code bases and the two humans are only auditors on the communications and changes.
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.
Proactive
Proactive communications mean looking at customer “health” (usually usage) and developing theories around what they could be paying us. 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.
For enterprise, it means scheduling a monthly or quarterly check-in. Another Zoom call, not entirely unpleasant, but more a hassle than a service.
What if support had product placement? Every inbound support request is a chance upsell your 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’re opening a pull request”.
Support is uniquely empowered to shepherd the customer base forward. If a customer is emailing you, they’re activated because when things are broken, customers are most ready to change. 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 business 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. Reactively, that means answering questions and helping debug issues with using Kernel. Proactively, that means proactively reaching out to customers about relevant features.
Failure
Churn is an incident, not a failure. Failure is customer disappointment.
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.
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 switching 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 exist 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 provide the context necessary for product engineering to triage and immediate begin work on issues. For feature requests, deliver a concrete customer use case. For bug fixes, a repro case. For both, a discrete list of customers that will 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 support
We want to compete with product for customer love. And we have an unfair advantage.