The Customer Translation Gap
Engineers build what they think was asked for, sales promises what they think can be built, and the customer ends up with a product that solves none of their actual problems.
Action
Hit the Pause Button If you hear the team debating what a customer 'meant' or arguing over conflicting interpretations of a feature request, stop the conversation immediately. Say this out loud: "Let's pause for a second. I am hearing a lot of different interpretations of what the customer actually needs here, and we are starting to design solutions based on assumptions. Let's step back before we commit to any direction or write any code."
Action
Trace the Source Establish the lineage of the information. You need to know how many hands this feedback has passed through. Say this to the room: "Who spoke directly to the customer about this? Do we have raw notes, a call recording, or an exact quote? Or are we working off a digested summary?" If it is a digested summary, acknowledge the gap: "Okay, we are playing a game of telephone. Let's treat everything we are saying right now as a hypothesis, not a fact, until we verify it."
Action
Pivot to the 'Why' Stop talking about how to build the feature and focus on why the user needs it. Use a basic Jobs-to-be-Done approach. Say this: "Let's forget about the feature request for a minute. What is the customer trying to accomplish when they open this screen? What is the pain, frustration, or inefficiency they are experiencing in their day-to-day work? Let's try to complete this sentence: 'As a user, I want to [action] so that I can [value/outcome].'"
Action
Map the Assumptions Draw a clear line between what you know and what you are guessing. Draw a simple T-chart on your shared screen. Label one side 'Facts (Direct Quotes/Data)' and the other 'Assumptions (Our Interpretation)'. Say this: "Let's list our assumptions. We are assuming they want a PDF export, but the fact is they just need to share this data with their manager. Could they do that with a shared link instead? Let's write down everything we are guessing so we can test it."
Action
Assign an Immediate Verification Action Do not let the meeting end with a decision to build based on assumptions. Assign someone to get clarity directly. Say this: "We cannot build this on assumptions. [Name], can you reach out to the customer or the account manager today? We need the answer to this specific question: 'What is the manual workaround you are using today to solve this?' Let's schedule a 15-minute sync tomorrow once we have that raw feedback."
Action
- Team members arguing about 'what the customer wants' without any actual customer data or quotes to back it up.
- Features are fully built and delivered, only for the customer to say, 'This isn't what we meant.'
- Requirement documents that are filled with technical jargon but lack user personas or real-world use cases.
- A developer asking, 'Why are we building this?' and receiving the answer, 'Because product/sales said so.'
- Frequent, late-stage scope changes because a customer review of a demo reveals a fundamental misunderstanding.
- The sales team translating customer feedback into specific feature requests rather than sharing the raw pain point.
- High frustration levels between product, engineering, and sales teams, with finger-pointing when a release flops.
- Meeting notes that summarize 'agreed actions' but omit the context of the user problem being solved.
- The 'Telephone Game' effect: Customer feedback passes through sales, account management, and product owners before reaching developers.
- Solution-oriented bias: Teams jump straight to designing solutions before fully understanding the underlying customer problem.
- Lack of direct customer exposure: Engineering and design teams are shielded from direct customer contact, relying on second-hand summaries.
- Conflicting incentives: Sales is incentivized to close deals quickly (leading to feature promises), while engineering is incentivized to ship on time.
- Vague or buzzword-heavy customer language ('make it seamless', 'robust reporting') is taken literally instead of being unpacked.
- Confirmation bias: Team members interpret vague customer feedback as validation for the features they already wanted to build.
- Absence of a standardized framework (like Jobs-to-be-Done or User Stories) to document and communicate user needs.
- Low psychological safety preventing team members from questioning assumptions or asking 'why' multiple times.