The Translation Layer

Same story, different rooms, completely different translations

3 minute read

Most product teams tell the same story to every room and wonder why alignment breaks down somewhere between the design review and the planning meeting. The problem isn’t the story. It’s that each room has a different filter, and we rarely adjust for it.

In any organization with more than a couple of decision-making layers, that adjustment isn’t optional. It’s part of the job.

One Story, Many Translations

The engineers are listening for constraints and what done looks like in practice. Designers are listening for the person experiencing the friction and what success feels like from their side of the screen. Product is listening for the bet and the signal that would confirm or deny it. Executives are listening for outcomes and the cost of waiting another quarter.

Tell engineers about retention metrics and they’ll nod and ask what the acceptance criteria are. Tell executives about a state management refactor and attention quietly exits the room. Neither audience was wrong. Neither story was wrong. They just weren’t aligned to what each room needs in order to move.

The failure isn’t telling the wrong story. It’s telling everyone the same version of a good story. “Good” almost always means the version that resonated most with the person telling it — the framing that landed in the room where the work got approved, with that specific group of people carrying their specific context. That room was the filter. Every room after it is a different one.

 
The harder version of this failure is less visible. When the underlying thinking isn’t fully resolved, different groups hear genuinely different stories. Design hears user empathy while engineering hears a technical opportunity. Leadership supplies the competitive framing it was already carrying. Each version feels true. None of them connect. That gap rarely surfaces until a sprint review or a cross-functional planning session, and by then it’s already shaping competing priorities.

The Anchor

What tends to work is writing the anchor before any of those conversations. Not a full brief — just the customer problem connected to the business reason it matters, specific enough that anyone reading it could explain it to a colleague.

ANCHOR BRIEFCUSTOMER PROBLEMTeachers spend 30–40 min/week reformatting the same data for different audiences.BUSINESS REASON IT MATTERSCited in 3 of our last 8 churn conversations. Competitors are actively moving into this space.ASSUMPTION BEING TESTEDA one-click format switcher removes enough friction to change behavior.SIGNAL THAT CONFIRMS OR DENIES ITUsed by 40% of active teachers at least once per report cycle within 60 days of launch.Write this before any stakeholder conversations. If the signal row is empty, the work isn't ready.

If writing the anchor brief surfaces contradictions between the business reason and the customer problem, or leaves the signal row empty, then those gaps were already there. Better to find them in a document than in a budget conversation.

With that anchor solid, translations become adjustments in emphasis rather than wholesale rewrites. The story doesn’t change. What you lead with does.

 
The translation isn’t just about language. It’s about sequence. Leading with what each room needs to act on first signals that you understand their context — which is usually the precondition for getting their real engagement.

The anchor also handles the upstream failure I wrote about in Discovery Debt. When teams skip customer understanding, there’s nothing credible to anchor to, and each room fills the gap with whatever narrative it was already carrying.

Before the next cross-functional conversation, the question worth asking is whether the underlying story is solid enough to survive translation. If it isn’t, what looks like a communication problem is probably still a clarity problem.

Those require different fixes, and they don’t have the same urgency.