The same ask arrives for the third time, and it sounds different every time. One customer calls it an export. One calls it an interface. One calls it “the Excel thing”. Three tickets, three phrasings, one need.
All three sit in different projects, and every one of them was handled properly. The first shipped four months ago as a one-off, inside the project that asked for it. The second is in a sprint right now, cut slightly wider because the developer suspected more was coming. The third is in a backlog with the note “check this”. Three lots of effort, three rounds of clarification, and at the end three solutions that resemble each other and still have to be maintained one by one.
And every time it was the right call. That is what makes this kind of mistake so stubborn: there is no moment where somebody could have stepped in without looking obstructive. There is only the day the third invoice goes out for the same piece of work.
Nobody did anything wrong here. It is only that at no point did anyone get to say: that is the same sentence three times, wearing different clothes. Most organisations have nowhere for that sentence to be said — not because nobody is paying attention, but because the three asks never sit next to each other.
Two layers, two languages
The customer says “export”. What your product actually has to do turns out to be “extract to CSV, selectable column set, on demand or on a schedule”. Both of those are requirements. They do not belong in the same field, and forcing them into the same field is how most requirements lists end up as documents nobody opens.
HOW IT ARRIVES
"The invoicing module needs to be more flexible."
HOW IT BECOMES BUILDABLE
"Accounting issues one consolidated invoice per quarter for a customer with several projects, itemised by project."
The usual escape is to pick one of the two layers, and both escapes cost you something. Keep only the customer sentences and one capability turns into seven entries that start contradicting each other the moment the seventh customer wants one detail differently. Keep only the product capabilities and you get a tidy list with the origin scrubbed out of it: the capability is there, and in the next prioritisation meeting nobody can say who it was promised to, or what happens if it slips a quarter.
So: two layers, and between them not a memory but a link that somebody deliberately made. The customer requirement stays worded the way the customer worded it, in the project where it was raised. The product requirement is written in your language, belongs to the product, and gets built once. The link is a statement: this capability satisfies that ask — fully, partly, or at the edges.
The degree looks like bookkeeping and is in fact the most useful question in the whole model. “Full” is quick to say. “Partial” forces the next question: what is missing from the rest? Answer that and you have just found the second product requirement — four months before the customer finds it in an acceptance meeting. The difference costs two minutes at the right moment.
When the same need arrives from three projects
Back to the three tickets. Once all three are linked to one product requirement, three separate items have become one need — and not a single customer sentence had to be rewritten to get there. Each one still sits in its own project, with its own priority and its own date. What changed is that the capability now has three senders instead of one, and that is the first number in this article that can carry a decision.
What gets counted matters. Breadth counts projects, not customers. Five customers inside a single project give a breadth of one, and that is deliberate: otherwise one large programme tilts every ranking simply by containing the same ask five times over. Three projects asking independently for the same thing is a different signal from one project asking loudly.
The rest of the arithmetic is unremarkable and open to inspection. Priority carries weight: critical 8, high 5, medium 3, low 1. Every customer requirement confirmed against the capability counts only for the share of it that is not covered today — something already covered contributes nothing, however loud it once was. The total grows with breadth, but damped rather than linearly. So one critical ask from one project comes to 8 points, and three high asks from three projects come to just under 39. Points: not hours, not money, not votes.
And then the number stops. It offers an order of work; it does not decide one. It knows nothing about your sales pressure, or the account up for renewal next year, or the two weeks of rework hiding behind that one capability. A signal that pretends to know those things gets ignored after the third bad call. A signal that can show what it is made of gets used.
That separation is not caution for its own sake. It is the reason the numbers are worth anything later. Coverage that also counts proposals tells you nothing in a customer meeting, because you cannot tell whether a person ever stood behind it. Coverage built only from confirmed links is something you are allowed to read out loud.
You can feel that restraint in the tool, and it is deliberate. A number that presumes to know what matters gets dismissed the first time it contradicts the room, and is never looked at again.
Two layers, two kinds of gap
Run both layers and you are handed two questions that nobody could previously answer without losing half a day to it.
The most expensive requirement is the one you build twice — once per customer.
The first question faces outward: which customer requirement has no confirmed link at all? That is a promise with nothing currently behind it. Not necessarily a failure — perhaps the capability simply has not been written down yet — but always something you want to know before the customer does, rather than at the same time as them.
The second question faces inward, and it usually gets told wrong. It is not “what did we build that nobody asked for?”. It is: which of our product requirements are settled and still not built? This layer compares a product against itself — the capabilities you committed to, against how far they have actually got. That is a backlog, not waste. And it is exactly as honest as you keep it: a product requirement whose implementation status was never set shows up there as planned. Never triage, and you will read a very generous list.
| Requirement | Status | Coverage |
|---|---|---|
| Consolidated quarterly invoice | PARTIAL | |
| Dunning escalation levels | GAP | |
| DATEV document export | COVERED | |
| Customer portal login | UNASSESSED |
That is the whole difference between a list and a model. A list tells you what somebody last typed into it. A model tells you what follows from that — at the moment you ask, rather than at the moment somebody last had time for housekeeping.
What to do with this on Monday
Take the three tickets from the top of this article, the ones you could already name in your own organisation. Leave all three exactly as they are worded — they are evidence, not raw material. Write one sentence next to them describing the capability that would satisfy all three, in your language and with no customer names in it. Then link the three to that sentence and record how far it carries in each case: fully, partly, at the edges.
You have deleted nothing, rewritten nothing and taken nothing away from anybody. You have only written down what was already true — and for the first time in a place where the next person finds it without asking you.
It is a small act, and at first it feels like nothing. The difference shows the next time the same ask arrives from a fourth project: you do not go looking. You attach it.
Why that one sentence never gets written in so many organisations is the subject of Why requirements fail: three filing places, three truths, and the review where all of them turn up at once. And if you want to see how the same link reads one level up — as portfolio, dates and progress, with nobody assembling numbers on a Friday — then The overview leadership needs is the next one to read.