A PM spends a week researching a problem. Talks to customers. Analyzes data. Builds a clear picture of what needs to happen and why. Then they write it up in a document and hand it to engineering.
Engineering reads it. Asks a few questions. Starts building. Two sprints later, the PM reviews the work and says "that's not what I meant."
Both sides did their job. The handoff killed the intent.
Where context dies
Every handoff is a lossy compression. The PM knows why a decision was made. The nuance behind the priority. The customer conversation that shaped the requirement. The thing they explicitly decided not to build and why.
The spec captures maybe 60% of that. The rest lives in the PM's head. By the time engineering is building, they're working from an incomplete picture and filling in the gaps with assumptions.
The telephone game
It gets worse when there are more handoffs. PM to designer to engineer to QA. Each step loses more signal. By the time QA is testing, they're verifying against a spec that's two translations removed from the original insight.
Nobody is wrong. Everyone is working from a slightly different understanding of the same thing.
Why documents don't fix this
More documentation isn't the answer. Nobody reads a 20-page spec word for word. And even perfect documentation can't capture the judgment calls and tradeoffs that shaped the decision.
The problem isn't that teams don't write things down. It's that context is experiential. You had to be in the room. You had to hear the customer say it.
What works
Shorten the chain. The person closest to the insight should be in the room when the work is being shaped. Not through a document. In the conversation. If the PM heard the customer say it, the PM should be pairing with the engineer when it's being built.
Handoffs are inevitable. Context loss isn't.
Tom Pinder