The PRD said users can cancel an order. Engineering built it. There's a cancel button, it works, QA signed off, the ticket closed.
Six weeks later a cancelled order arrives at a customer's door.
Nobody wrote the wrong thing. The doc said what it said, and what it said got built. The problem is what the doc could not say. It described a button. It did not describe what happens when a cancel arrives eleven seconds after the pick ticket prints. It did not say who wins when support and the warehouse both act on the same order in the same second. It did not say whether cancel is still a legal move once a box is on a truck.
None of those questions came up, because the document was organized around a feature. The failure lives in a process.
Features are slices. Processes are the thing.
A PRD is a list of features. That is a useful shape for planning work and a terrible shape for describing a business.
Businesses do not run features. They fulfill orders. They adjudicate claims. They onboard customers, approve expenses, escalate tickets, close loans. Each of those is a process: something that starts, moves through defined steps, passes between several actors, and ends in one of a small number of ways.
Features are cross-sections of those processes. "Cancel order" is one move inside order fulfillment. So is ship. So is refund, pack, restock, partially refund. Cut them into separate tickets across separate sprints and the process itself is never anyone's document. It exists only as the sum of the features, which is precisely the form in which no human being can read it.
Ask five people at a company to describe how an order actually gets fulfilled and you will get five different answers, all of them partly right. That is not a communication problem. It is a missing artifact.
What a process says that a PRD can't
A PRD answers one question: what should this let people do?
A process answers a harder set. What can happen to this thing? In what order? Triggered by whom? What is not allowed, and what happens when someone tries it anyway? Where does the work leave our system, go sit inside a payment provider or a carrier, and come back? What are the ways this ends badly, and what do we do in each case?
The second set is where the money and the risk are. It is also the set that prose is bad at holding. You can write four paragraphs about cancellation policy and still not have said whether cancel-after-ship is possible, forbidden, or forbidden-but-technically-reachable. A process forces the answer, because the answer is either a line on the diagram or it isn't.
Why this suddenly matters more than it used to
Every spec has always been incomplete. That was survivable, because a person closed the gap.
An engineer read the doc, noticed something unspecified, and either knew the answer from four years at the company or walked over and asked. That resolution happened in hallways and Slack threads and code review comments, and it almost never made it back into the document. Which is the real reason the PRD was never the source of truth. The code was. The doc was a pitch that got the code funded.
That loop is closing. Ambiguity now gets resolved by a model, in seconds, at volume, without anyone in the room who knows that cancel-after-ship destroyed a quarter in 2019. And it resolves ambiguity plausibly, which is the dangerous part. Plausible is not the same as correct, and the gap between them does not surface as an error. It surfaces as a system that demos beautifully and is quietly wrong about your business until an actual customer finds the seam.
Generated implementations are downstream of the spec in a much more literal way than hand-written ones ever were. Whatever the spec fails to say, nothing further down the line will catch.
A process can be tested before it exists
This is the argument that lands with people who are tired of methodology.
Take a real case. A customer paid, then cancelled while the box was being packed. Put your finger on the process diagram and trace it. Either there is a path for that case or there isn't. If there isn't, you just found a hole in an afternoon, on a whiteboard, for free.
Now try the same exercise against a PRD. You can't trace prose. You can only read it again and come away feeling like it's probably fine.
Run twenty real cases through a process, including the ugly ones, and you learn more about what you are actually building than any amount of review. The cases you cannot trace are your spec. That is the entire methodology.
The process outlives the code
Code used to be expensive, which made it feel permanent. It isn't anymore. Implementations get regenerated, refactored, ported, and thrown away faster every quarter, and that rate is going one direction.
What survives is the process. The states an order can be in, and the moves allowed between them, do not change when you change frameworks or models or vendors. They change when the business changes, which is far less often and for reasons someone can name.
That makes the process the most stable thing you own, and the only sane candidate for source of truth. It is also the only level at which governance means anything. Nobody can audit "added a cancel button." You audit a process: who is permitted to move this record from here to there, under what conditions, and what evidence gets recorded when they do.
Where this goes
Write a process down honestly and you will notice it has a shape. A set of states something can be in. A set of moves between them. A much larger set of moves that must never be possible.
That is a state machine. You are running one right now, in whatever app you inherited, whether or not anyone drew it. Usually it is hiding in a handful of boolean columns and a dozen endpoints that each flip one and trust the others behaved.
That is the next thing worth pulling on. For now the useful shift is smaller and comes first: stop starting with a list of features, and start with the process the features are slices of. The diagram is not a picture of the spec. It is the spec.
