Three months after kickoff, your team sits in the review and three people remember three different readings of the same requirement. Nobody is lying. Everyone is right — measured against the last state they saw.
You know the silence that follows. Three seconds in which nobody says anything, because everyone has just realised they were working from something else. Then somebody moves the meeting along, and it runs straight over the crack.
One of them is going by the workshop notes, handwritten, with an arrow in the margin. The second has the spreadsheet open, column F, filtered to “open”. The third is reading a Jira ticket created in May and reworded in June, because the customer said something different on the phone. Three sources, three truths. The only thing that can reconcile them is the memory of the people in the room.
This is how requirements fail. Not loudly, not in an escalation meeting. They fail quietly, at exactly the point where nobody can say any more which sentence is the one that counts.
Requirements don't die at the start
At the start, everything is clear. A customer describes what they need, somebody writes it down, everyone nods. The trouble starts at the first handoff. The notes become a row in a list. The row becomes a ticket. The ticket becomes a paragraph in an email to whichever team has capacity. Every one of those handoffs is a copy — and every copy is a fork nobody notices.
Copies are harmless as long as they are dead. They get dangerous when they keep living: when somebody edits the spreadsheet because the customer corrected a number in the weekly call, and the ticket stays exactly as it was. From that moment you have two requirements carrying the same number and asking for different things. You will find out in testing at the earliest. More likely in front of the customer.
Do the arithmetic. Five projects, forty requirements each, three places to keep them: spreadsheet, tracker, inbox. That is six hundred places a sentence can sit, and not one place that says which of them counts. No team is sloppy for losing control of that. It is just what people do.
The bill never shows up as a line item. Nobody writes “built it twice” into a project retro. It hides in follow-up questions, in a sprint that gets replanned, in a customer meeting that opens with a clarification instead of a demo. That is why the situation survives for years: a cost you cannot put a number on is a cost nobody removes.
Who actually pays it is not written down either. It is the developer asking a third time what was meant, starting to suspect they are the slow one. It is the project lead explaining a result to a customer that they are seeing in that form for the first time themselves. Both are good at their job. They are simply working against a filing system that leaves them on their own.
The second place requirements die is the translation into the product. A customer says “we need consolidated invoices”. What your product actually has to do about it — batch run, cancellation, export — is written nowhere near the customer's sentence. It lives in the head of the person who understood the deal. When that person moves to another project, the requirement stays and the reasoning leaves. Three months later somebody in the review asks: “Why are we building this again?” And nobody can answer without searching their inbox.
A lifecycle is not process theatre
The usual answer to this problem is process, and the usual response to process is avoidance. Anyone who has ever filled in an approval form nobody reads knows why. A lifecycle that only counts states is theatre. It produces work, not clarity.
A lifecycle worth having does exactly one thing: it forces a conversation at the moment when that conversation is still cheap. Draft, in review, approved, in progress, delivered — the names are interchangeable. What matters is the gates between them. A gate is not a permission slip. It is a question that has to be answered before the next step is available.
The questions are unremarkable, which is precisely why they work. Who asked for this? Does the text say enough for somebody else to read it without coming back to ask? Does it contradict something we have already promised? Answer those three in the draft and you spend ten minutes. Answer them in delivery and you spend a sprint.
A real example. “The import should handle large files too.” It looks like a requirement, but it is a wish with a hole in the middle. It gets stopped at the gate, and then somebody asks: how large is large? How will we know it was handled? Two questions back to the customer, five minutes on the phone, and the sentence becomes “up to 5,000 rows, no timeout, with a per-row error log”. The same question asked during delivery does not cost five minutes. It costs two days, because by then somebody has guessed.
Telling a gate from bureaucracy is easy. A gate that cannot tell you why it is shut is bureaucracy. A gate that tells you which sentence is missing is a colleague.
Traceability beats memory
The review at the top of this article cannot be fixed with better memory. It can only be fixed by having something that remembers better than the people in the room. Not one more place to file things next to the three you already have, but a place the other three refer to: a ledger where a requirement is written once, from the customer's words through to the implementation.
A requirement that lives in two places is two requirements.
Traceability sounds like a documentation duty. It means something far more practical: the chain from a customer's sentence to the capability that satisfies it, readable in both directions at any time. Read forwards, it answers “what happened to my request?”. Read backwards, it answers “who are we building this for, and what breaks if we don't?”. Both questions turn up in every project. Rarely at a moment when they are still comfortable.
For that chain to hold, it needs two ends. The customer's sentence is one requirement: what this customer, in this project, is asking for, in their words. Your product's capability is the other: what you build once and deliver many times. Between them sits an explicit link — and the entire benefit is in the word explicit. As long as the link only exists in somebody's head, it leaves with the next person who changes teams.
“One place” does not mean everything moves in. Development keeps working in Jira, documentation stays in Confluence, and customers will keep sending spreadsheets — none of that is going to change, and none of it needs to. What changes is the point of reference. The requirement is written once, and it keeps the key of the ticket that came out of it instead of dissolving into it. The difference between a copy and a reference is the whole difference between this article and your last review.
Those gaps sit on two layers, and both are uncomfortable. The first asks: what has a customer asked for that no product requirement carries? The second asks: what is settled as a product requirement and still not built? The first gap costs you trust, the second costs you dates. Neither one catches anybody's eye in passing.
| Requirement | Status | Coverage |
|---|---|---|
| Consolidated quarterly invoice | PARTIAL | |
| Dunning escalation levels | GAP | |
| DATEV document export | COVERED | |
| Customer portal login | UNASSESSED |
How to tell by tomorrow morning whether this is you
No maturity model, no score. Five sentences that either describe you or don't.
- Your most current requirements list is an email attachment, and the filename ends in “_final_v2”.
- “Who asked for this?” is answered by searching your inbox, not by a click.
- Two projects are building the same capability, and you found out in testing rather than in planning.
- Before every customer meeting, somebody assembles a status overview by hand — the same one as four weeks ago, with different numbers.
- You cannot say in under a minute which promises from your last proposal are covered by nothing today.
One tick is ordinary. Three is a pattern. Five is not a team problem, it is a filing problem: your requirements have no home, they have whereabouts.
Where to start
Not with a tool. Start with one requirement that currently hurts, and write two sentences: what the customer asked for, and what your product has to be able to do about it. If the second sentence is hard to write, you have found the cause — and that is good news, because a sentence can be written. Three people's memories cannot be repaired.
The first sentence that finally sits where everyone can find it feels unremarkable. You notice the difference at the next review: the question “what did we mean by that again?” simply does not come. Nobody celebrates it. It is still the moment your project stopped running on memory.
The next step is the link between those two sentences, which is what From customer voice to product requirement is about: how the same need, arriving from three projects in three different phrasings, becomes one product requirement without the customer sentences losing their origin. If you would rather see how this feels in a working week than read it as a method, A day as a Product Owner walks through an ordinary Tuesday, hour by hour, from the inbox in the morning to the status question in the afternoon that answers itself.