Everyone Is Speaking a Different Language About the Same Product
Support, product, engineering and finance describe one fact in four vocabularies with no shared object connecting them. Every handoff is a translation, and 64% of defects originate there.
A booking fails on Friday afternoons. Here is how that one fact travels through a company.
Support files it as: customers can't book on Fridays, three tickets this week. Product rewrites it as: availability is broken for end-of-week slots. Engineering translates it as: the availability window calculation excludes the last business day when the timezone offset is negative. Finance eventually sees it as: Q3 churn in the SMB segment, unexplained.
Four departments. Four vocabularies. One fact. And no shared object anywhere in the company that says these are the same thing.
Every handoff in that chain is a translation, every translation loses something, and the losses accumulate in one direction — away from the person who could have fixed it cheaply and toward the quarterly review where somebody asks why churn is up.
This is not a communication problem in the soft sense. It is the most expensive structural feature of modern software companies, and it is measurable.
The cost has a number
Deloitte's analysis attributes 64% of software defects to the requirements and design phases rather than to coding. Not typos. Not bad algorithms. Misunderstandings about what was supposed to happen — which is to say, translation failures between people who each understood their own half perfectly.
Then there is the escalator. The IBM System Science Institute's long-cited figures put the cost of fixing a defect during testing at roughly 15× what it costs at design, and during maintenance at around 100×. Some analyses frame it more starkly: a hundred-dollar problem at design is a ten-thousand-dollar problem in production.
And the aggregate: the Standish CHAOS data has long placed around 68% of projects in the challenged-or-cancelled column, with roughly a third delivered on time and on budget. Poor requirement quality is a consistent contributor.
Put those three together and a specific picture emerges. Most failures originate before anybody writes code. They originate in the gap between vocabularies. And their cost rises by an order of magnitude at each boundary they cross undetected.
Why documentation never solved it
Every company has tried the obvious fix. A wiki. A glossary. A ubiquitous language workshop. An architecture decision record repository. A Notion space with a page per domain.
They decay, and they decay for a reason that is not laziness.
Documentation is a snapshot of an understanding at a moment, maintained by hand, competing against shipping. The system it describes changes daily; the document changes when someone remembers. Within a quarter it is describing a product that no longer exists, and the moment a team discovers one stale page, they stop trusting the rest — correctly, because they cannot tell which pages are current.
There is a deeper problem. Documentation is written in one vocabulary, usually the author's. An engineer's architecture doc does not answer the product manager's question. A PRD does not answer the engineer's. So each function writes its own, and now you have four decaying documents describing one system in four languages, which is worse than one.
The failure mode is structural. Any solution that requires a human to manually keep a translation current will lose to the rate of change.
What the AI wave did to this
You might expect AI assistants to help here. In a narrow sense they do — they will happily explain a function to a non-engineer.
But look at what the tools actually see. Almost all of them read code. Which means they are fluent in exactly one of the four vocabularies in our Friday booking example — the engineer's — and mute in the other three.
Ask a code-reading assistant "why are customers churning in the SMB segment" and it has nothing. Ask it "what does the availability window calculation do" and it will tell you precisely. The tool is excellent at the layer where the problem is cheapest and silent at the layer where the money is.
And the volume of material to translate is going up. DORA finds that 90% of technology professionals now use AI at work, with copy-paste rates rising from 8.3% in 2021 to 12.3% in 2024 and refactoring collapsing from roughly 24% to under 10%. More code is being produced, and less of it is being consolidated. Every additional line is another line somebody outside engineering will eventually need explained.
Meanwhile 96% of developers say they do not fully trust AI-generated code to be functionally correct. So the code is growing faster, being consolidated less, and trusted less — while the number of people who need to understand it stays the same.
The tax nobody books
Here is where it lands on a P&L, in four line items no accounting system separates.
Senior time spent as a search index. The two people who hold the system in their heads spend their week answering questions with answers that exist in the code. Their calendars are the real constraint on the team's speed, and none of that time appears as a cost.
Meetings that exist to reconcile vocabularies. The cross-functional sync where four people establish that they were talking about the same thing. Every recurring meeting on your calendar with three or more functions in the room is, in part, a translation cost.
Rework after the first version. Built correctly against a misunderstanding. Deloitte's 64% lives here.
Decisions made without evidence. "Is this risky?" answered from memory by whoever has been here longest. Sometimes right, never checkable, and completely dependent on that person's continued employment.
The last one is the largest and the least discussed, because it never produces an incident report. It produces a slightly worse decision, quietly, hundreds of times a year.
What actually helps
The pattern that works is not a better document. It is a single description of what the product does, kept current automatically, that each role can question in their own language.
The distinction matters. A shared document forces everyone into one vocabulary, which means it serves one function well and the rest badly. A shared source that answers questions lets the support lead ask about Friday bookings, the engineer ask about the availability calculation, and the CFO ask what changed in Q3 — and get answers that are consistent with each other because they came from the same underlying reality.
Three properties make the difference between that and another wiki:
It updates itself. If keeping it current is a human task competing with shipping, it will lose. This is the property that killed every previous attempt.
It answers in the asker's terms. Not one canonical vocabulary that everyone must learn, but answers phrased for the question that was asked.
Every answer carries its evidence. A claim that traces back to the source can be checked in seconds. A claim that cannot is a second opinion from a source with no accountability — and organisations quite reasonably do not act on those.
The question worth asking your own company
Take the last significant incident or missed deadline. Trace it backwards. Not to the commit — to the moment where two people were confident they had agreed and were describing different things.
You will usually find it. And you will usually find that the moment was weeks or months before anything visibly went wrong, that it cost nothing to fix at the time, and that nobody could have spotted it because no two people in the chain shared a vocabulary precise enough to notice the mismatch.
That gap is where your engineering budget actually goes. Not to typing. To the cost of four departments describing one product in four languages and hoping the translations hold.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
Why do so many software defects originate before any code is written?
Because most of them are translation failures rather than technical mistakes. Deloitte attributes 64% of defects to the requirements and design phases — situations where each participant understood their own half correctly but the handoff between vocabularies lost something. The code is then built correctly against a misunderstanding.
How much more does it cost to fix a problem later?
The IBM System Science Institute's figures put a defect fixed during testing at roughly 15× its cost at design, and during maintenance at around 100×. The practical framing is that a hundred-dollar problem at design becomes a ten-thousand-dollar problem in production, with the multiplier applied at each boundary it crosses undetected.
Why does internal documentation always go stale?
Because it is a manual snapshot competing against shipping. The system changes daily and the document changes when someone remembers. Once a team finds one stale page they stop trusting the rest — correctly, since they cannot tell which pages are current. Any fix that depends on humans maintaining a translation loses to the rate of change.
Can AI coding assistants solve cross-team misunderstanding?
Not on their own, because most of them read only code. That makes them fluent in the engineer's vocabulary and mute in the vocabularies of support, product and finance — which is where the expensive misunderstandings live. They help most at the layer where problems are cheapest to fix.
What should a shared source of product understanding actually do?
Three things. Update itself, because manual maintenance always loses to shipping. Answer in the vocabulary the question was asked in, rather than forcing everyone into one canonical language. And attach evidence to every claim, so an answer can be checked in seconds instead of taken on trust.
Related articles
MCP, Explained for Engineering Teams
What the Model Context Protocol actually is, why it turns an N×M integration problem into N+M, and the question to ask a vendor that 'we support MCP' does not answer.
The 19% Problem: What a Controlled Trial Revealed About AI and Developers
A randomised controlled trial found experienced developers were 19% slower with AI — while estimating they were 20% faster. The detail everyone skips explains why.
The Comprehension Economy
Developers spend 58% to 70% of their time understanding code, not writing it. The industry spent three years optimising the smaller half — and increased the load on the constraint.