Stop arguing about PRDs. Start matching the artifact to the risk.

Every few years the product world relitigates the same fight. One camp says you need a real written spec before you build anything. The other says specs are waste, just write a user story and start shipping. Right now there’s a third voice getting loud, arguing that AI has made written specs obsolete because you can just prototype your way to the answer. I’ve worked through every one of these models across about two decades, and I’ve come to think the entire debate is framed wrong.

The question was never “which artifact is correct.” It’s “how much certainty does this decision require, and what’s the cost of being wrong.” The artifact should follow from that answer. When it doesn’t, you get the two classic failures: heavy specs written for throwaway experiments, and zero documentation on decisions that will be expensive and permanent.

It’s worth remembering how much of software pain traces back to unclear requirements specifically. The Standish Group’s long-running CHAOS research, for all the healthy debate about its exact percentages, has pointed at the same three culprits for decades: lack of user involvement, incomplete requirements, and changing requirements. Academic researchers have argued the headline numbers are shakier than they’re usually quoted, and they’re right to, but the underlying pattern has been replicated enough that the direction isn’t seriously in dispute. Unclear requirements are one of the most reliable predictors of a project going sideways. That’s the real thing the “write a spec” camp is reacting to, and they’re not wrong that it matters.

Let me walk the models, because each one is right somewhere and wrong somewhere else.

The heavyweight PRD, the detailed written spec, is what I used building enterprise and commerce products at IBM. People love to mock it now, but it earns its keep in exactly one situation: when the cost of being wrong is high, the stakeholders are many, and the thing you’re building is hard to change later. Regulated systems, platform decisions, anything with compliance or contractual weight. In that world, the written spec isn’t bureaucracy. It’s the forcing function that surfaces disagreement before it’s expensive. Skip it there and you find out what you disagreed about after you’ve shipped it, which is precisely the “incomplete requirements” failure the CHAOS data keeps flagging.

The lean, just-in-time user story is the reaction to that, and it’s right in its own domain. When you’re early, the problem is fuzzy, and the cost of being wrong is a few days of work, writing a fifteen-page spec is genuinely wasteful. You’d spend more time documenting the uncertainty than it would take to resolve it by building. I ran this way validating mobile products at a startup, where the goal was to learn fast and the worst case was cheap. A heavy spec there would have been a way to feel productive while avoiding the actual work of learning. And the actual work matters: remember that the most common reason products fail, per a decade of CB Insights post-mortems, is building something nobody needed. Early on, a lightweight artifact that gets you to real validation faster is worth more than a beautiful document.

Prototype-driven development, figuring it out by building rather than writing, sits in the middle and shines when the risk is about the experience itself. Some things you cannot specify your way to. You have to feel them. When the open question is “will this interaction actually work for a human,” a prototype answers it and a document doesn’t.

Which brings me to the AI argument, that prototyping is now so cheap the written spec is dead. I use AI prototyping constantly, and I think this take is half right in a way that’s dangerous. Yes, AI collapses the cost of exploration. You can generate five working prototypes before lunch. But here’s what actually happened when the tools got good: the spec didn’t disappear, it moved. The prompt is the spec now. The clearer you are about what you actually want, the constraints, the edge cases, the definition of done, the better the output. AI didn’t kill written requirements. It revived them and disguised them as prompts, and the people who write vague prompts get vague products, exactly like they always did, and exactly like the CHAOS research would predict.

So here’s my actual position. No single model wins, and anyone selling you one as the universal answer is selling their own comfort, not your outcome. The heavy-spec people are avoiding the discomfort of ambiguity. The no-documentation people are avoiding the discomfort of being pinned down. Both are optimizing for how they like to work rather than what the decision in front of them requires.

The discipline isn’t picking a methodology and defending it. It’s asking, every time: what’s the cost of being wrong here, and what’s the lightest artifact that meaningfully reduces that risk. Sometimes that’s a one-line story. Sometimes it’s a ten-page spec that saves you a six-month mistake. Usually it’s something in between, and the skill is knowing which. The teams that get this right aren’t the ones with the best template. They’re the ones who stopped treating the artifact as a religion and started treating it as a tool.

Sources: The Standish Group CHAOS Report (1994 and later); academic critiques of CHAOS methodology (Eveleens & Verhoef; Jorgensen & Molokken); CB Insights startup failure post-mortems.