The Engineer Customer Conversation: Patterns That Yield Insight
Engineers who talk to customers bring a different quality of attention to the conversation than product managers or salespeople do. They notice the workflow details that reveal where the product is creating friction. They hear the technical constraints the customer is working around. They ask questions that surface the 'how' behind the 'what.' These conversations produce different product insight than the conversations that product managers typically have.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- Engineers hear different things in customer conversations than product managers do. Use that perspective.
- The most valuable moment in a customer conversation is when the customer describes what they do instead of what they want.
- Workarounds reveal product gaps better than feature requests do. A customer who built a spreadsheet to compensate for a missing feature is describing an architecture problem.
- Never ask a customer to design the solution. Ask them to describe the problem, the workflow, and the outcome they need.
- One conversation is an anecdote. Five conversations with the same pattern are a product decision.
| Conversation Pattern | What It Reveals | How to Elicit It |
|---|---|---|
| Workaround description | Product gap the customer solved manually | "What do you do when this doesn't work?" |
| Tool comparison | Where competitors are stronger | "What does [competitor] do differently here?" |
| Downstream workflow | How the feature connects to the customer's process | "What happens after you export this?" |
| Failure description | How the product breaks in real use | "When was the last time this caused a problem?" |
| Success definition | What good actually looks like to this customer | "If this worked perfectly, what would change for you?" |
The core argument
Most customer conversations happen between non-engineers and customers, and this works well for understanding buying decisions, satisfaction levels, and feature preferences. But it misses a category of insight that is only visible to engineers: the technical constraints, the integration patterns, and the workflow details that explain why a feature that seems straightforward in the product is actually broken in the customer's specific context.
An engineer who talks to a customer who reports that the API is slow discovers, through follow-up questions, that the customer is calling the API in a tight loop 1,000 times per request because the batch endpoint was too inflexible for their use case. A non-engineer hears "the API is slow" and writes a ticket for performance optimization. The engineer hears "the API is slow" and asks "how are you calling it?" and discovers that the fix is a better batch endpoint, not a faster implementation.
This technical listening is underutilized because engineers are often insulated from customer conversations by product managers who synthesize and translate. The synthesis is useful for keeping engineers focused. It also removes the engineers from the raw signal that would change how they think about what they are building.
The conversation structure that generates insight
The most productive engineer-customer conversations follow a pattern that is different from a standard product interview.
Start with the workflow, not the product. Ask the customer to describe the business process that the product is part of. Not "how do you use the export feature" but "walk me through what happens from when a customer places an order to when the accounting team records it." This workflow description reveals where the product fits, where the handoffs happen, and where the product creates friction that the customer has learned to live with.
Follow the workarounds. Every customer has workarounds: spreadsheets they maintain because the reporting is insufficient, manual steps they added because the automation failed, third-party tools they use because the product cannot do something they need. Ask specifically about these. "Do you do anything outside the product to make this work?" The workarounds are the product roadmap.
Understand the downstream impact. When a feature does not work well, what does the customer do? What takes longer? What does not happen that should? The downstream impact is the real cost of the product problem, and it is often much larger than the product problem itself. A slow export is an annoyance. A slow export that delays the monthly board report is a firing offense for the customer's analyst.
Ask about the definition of success. "If this worked exactly as you needed it to, what would you be able to do?" The answer to this question often reveals requirements that the original feature request did not specify. The customer who asks for faster export actually needs to run a report before 9am on the first of the month. The solution is scheduled report generation, not faster export.
How to get into customer conversations as an engineer
The path is simpler than most engineers assume. Express genuine interest to the person who runs customer conversations. "I want to understand what customers are struggling with technically. Can I join a call?" Almost everyone says yes to this request because it demonstrates the kind of customer awareness that product teams value in engineers.
Once in the conversation, the role is listening with specific technical curiosity. Not pitching the roadmap. Not defending the product's choices. Not immediately offering solutions. Listening for the workflow details that reveal where the architecture is creating friction.
After the conversation, write down the specific technical observations: the workaround that was described, the integration pattern that would be required for the customer's use case, the downstream system that the product should be aware of. This technical analysis is the contribution that only engineers can make.
Common mistakes engineers make in customer conversations
- Answering technical questions rather than asking them. The customer asks "can the API support webhooks?" and the engineer explains the current webhook implementation. The useful question is "what event would trigger the webhook and what would you do with it?"
- Defending design decisions. When the customer describes a frustration with the product, the instinct is to explain why the product works that way. This closes the conversation. "That makes sense as a frustration. Tell me more about the workflow where this gets in the way" keeps it open.
- Taking notes on features instead of workflows. "Customer wants faster export" is a feature note. "Customer exports a CSV at 8:45am and imports it into their accounting system by 9am on the first of each month" is a workflow note. The workflow note is actionable.
- Not following up on unexpected answers. When a customer says something that reveals a use case the engineer did not expect, the instinct is to move on to the next question. The unexpected answer deserves follow-up: "That's interesting. Tell me more about how that works."
- Joining one customer conversation and concluding they understand the market. One conversation is an introduction. The insight comes from patterns across five to ten conversations.
Where to start: a 3-step customer conversation plan for engineers
Step 1: Ask to join one customer call this month. The first step is just being in the room. Observe how the customer describes the product and their use of it. You do not need to lead the conversation.
Step 2: After the call, write the technical observations. What workarounds did the customer describe? What downstream systems did they mention? What technical constraints came up? This document is the engineer's specific contribution from the conversation.
Step 3: Run five conversations over the next quarter and look for patterns. After five conversations, identify the common workarounds, common integration patterns, and common technical frustrations. These patterns are the product decisions that engineering input should drive.
The Perspective That Comes From Doing Both
Yashveer Singh. Founder of Yashveer Labs. I build products and I talk to the customers those products serve. The combination changes what I build. The customer conversation patterns I describe in this post are ones I practice. If you need an engineer who ships and listens in the same week, that is the combination I bring.
Related reading
Frequently asked
About the author and why it matters
Yashveer Singh wrote this. I run Yashveer Labs out of New Delhi. The work I take on tends to come from founders who have been burned by an agency, a freelancer, or their own ambition. I do not promise miracles. I promise that the system will be online, the code will be readable, and the next engineer who touches it will not curse me. That is rarer than it should be.
Posts that line up with this one.
- Startup Technical Strategy
Engineering Driven Customer Discovery
Customer discovery is too important to delegate to product alone. The engineers who talk to customers build better products. Here is the pattern that makes engineering driven discovery work.
- Startup Technical Strategy
The Build Measure Learn Loop for Engineers
How engineers apply the build-measure-learn loop in practice: what to instrument, how to define the experiment, and when to iterate versus when to pivot.
- Startup Technical Strategy
The Engineering Brand: Why It Matters More Than You Think
How the engineering team's reputation affects recruiting, product credibility, and the company's ability to attract the right technical partners.
- Startup Technical Strategy
The Engineering Hiring Bar: How to Set and Hold It
How to define what good looks like for your engineering team, evaluate candidates against that standard, and avoid the most common failure modes.