Prototypes instead of PRDs, user stories and epics
Ten teams have built in my rooms so far, in Athens and in Warsaw. All ten shipped a working thing and pitched it. Between them they wrote zero PRDs, zero user stories and zero epics. What they had was one sentence on the wall and a deadline.
I am not going to tell you documents are dead. Plenty of people are selling that line this year and most of them have a tool underneath it. I want to tell you something less comfortable and more useful. The document was never the point, and the people who invented the user story said so at the time.
Start with one story and four screens
Here is a normal user story. Nothing wrong with it. It would pass refinement in most teams I have worked in.
As a returning shopper, I want to browse my saved looks, so that I can choose an outfit quickly.
Now give that sentence to four people and ask each of them to build it. You will get four different products, and every one of them serves the story.
Builder oneA grid of saved looks with a filter bar. Browse meant browse.
Builder twoToday's feed first, saved looks behind a tab. Browse meant discovery.
Builder threeOne outfit for today plus a swap button. The goal said quickly.
Builder fourA search box and a list. Browsing a big collection means searching it.
Nobody in the refinement session noticed the disagreement, because everybody agreed with the words. Jeff Patton, who wrote the book on story mapping, has the line for this: people "can even 'sign off' on the document believing they're in agreement."
Build any one of those four and the argument takes about thirty seconds. Where do saved looks sit? Does she pick a whole outfit or assemble one? What happens when she has three saved looks instead of thirty? Nobody argues about those questions in the abstract. Everybody argues about them the moment there is a screen.
The artifacts were never meant to be documents
Here is the part the "PRDs are dead" posts skip, and it is the part that changes what you do on Monday.
Kent Beck came up with user stories on the Chrysler payroll project in the late 1990s. Years later Jeff Patton asked him where the idea came from, and Beck wrote back:
What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. If you can tell stories about what the software does and generate interest and vision in the listener's mind, then why not tell stories before the software does it?
Telling. Not writing. The whole idea was that a person describes the thing out loud and you can picture it.
Ron Jeffries wrote the version most teams half-remember, back in 2001. He called it the three Cs: card, conversation, confirmation. Read what he actually said about the card.
The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement.
A token. The requirement itself, he wrote, "is communicated from customer to programmers through conversation." He was blunt about teams who wanted more than that, listing the use cases, spreadsheets, window layouts and "even multi-page documents looking much like conventional specifications" that people kept reaching for. His verdict, twenty-five years ago: "looking back over the years I have almost never found this kind of document to be ideal."
The template everyone still types came out of Connextra, a London shop doing extreme programming around the turn of the century. They printed a stack of cards to show off at a small conference in London in 2001 and it spread from there. It was a good trick, and it spread because it worked. Nobody printing those cards thought they were publishing a specification format.
Epics have an even thinner claim. Patton called his chapter on them "Epics Are Big Rocks Sometimes Used to Hit People" and admitted he does not know who coined the word. His complaint is that in practice the label mostly gets used to tell someone their request is too big and they have done something wrong.
- 1997Kent Beck starts using stories at Chrysler. The idea is that someone tells you what the software does.
- 2001Ron Jeffries writes the three Cs. The card is a token. The requirement lives in the conversation.
- 2001Connextra print their "As a, I want, so that" cards for a conference in London. A handy format, not a spec.
- 2014Jeff Patton: shared documents aren't shared understanding. By now the card is a ticket with fields.
- 2019Jeffries again, on a team where writing the story took longer than doing the work.
- 2026You can build the thing in an hour, which is less time than the refinement session about it.
Patton's summary of the whole business is the line I keep coming back to.
Shared documents aren't shared understanding.
Then we wrote them all down anyway
You know what happened next. The card became a ticket. The ticket grew a description field. The description field grew acceptance criteria, a definition of ready, a definition of done, a linked Confluence page, and a story point estimate argued over by eight people on a Tuesday.
In 2019 Ron Jeffries wrote about a team that came to him for help, with a problem he could not have designed if he had tried.
Sometimes getting the story "right" and into the backlog took longer than doing the work, which was already done.
That was six years before AI could build anything. The ratio has only got worse since. In May this year a product manager called Sriram Kothandaraman wrote a line in Mind the Product that I have not been able to shake: "I spent 6 hours writing the spec. I built the prototype in 1. The EPIC took longer than the thing it was describing."
Write the brief that replaces the story
If you drop the story, you need something in its place, and it is not nothing. It is one sentence that aims the build without describing the solution.
Here is the one I wrote for Ionian Technologies in Thessaloniki. Thirty-one words, and eight people built against it for six hours.
How might we help a returning 25-year-old Zara shopper open the app at 7:45 a.m. and choose a complete outfit from her saved looks and today's feed in under 90 seconds?
Take it apart, because every fragment is carrying weight.
Notice what the sentence leaves out. No screen. No feature. No AI stylist, no recommendation engine. Four teams could take that brief and come back with four different products, and all four would have served it. That spread is the point. The story earlier produced four different products by accident. The brief produces them on purpose, and you can compare them.
Anyone can write a prompt. Not everyone can write a brief.
Run it on Monday, in ninety minutes
Take the oldest ticket in your backlog. The one that has been refined three times and is still sitting there. Do not refine it again.
- 10 minutesRewrite it as a brief. User, context, goal, finish line. Aim for about thirty words. Delete every noun that names a screen or a feature.
- 5 minutesAgree the one thing it must let someone do, and how you would know. One click, one timer, one number.
- 45 minutesBuild the smallest version with whatever tool you already have. Ugly is fine. Half the flows missing is fine.
- 10 minutesPut it in front of one person who is not on your team, and stay quiet while they use it. Do not explain it. Watch where their thumb hesitates.
- 20 minutesWrite down only what the prototype could not show. That is your document, and it is usually a page.
You learn one of two things. Either the ticket was clear all along and you just proved it in an hour and a half, or it was not, and four people had quietly agreed to four different things.
The five things you still have to write down
A prototype is very good at settling shape and flow. It is silent on everything else, and this is where I have seen teams get burned.
- ConstraintsWhat the thing is not allowed to do, and what it has to work inside.
- Non-functional requirementsSpeed, scale and cost. A demo with four rows says nothing about forty thousand.
- Edge cases nobody finds by clickingEmpty states, the payment provider down at two in the morning, the user with three saved looks instead of thirty.
- AccessibilityKeyboard order, focus, contrast, screen readers. A clickable demo shows the happy path beautifully and is silent on all of it.
- The reasoningWhy you chose this over the other three, so the next person does not undo it by accident.
Add anything with an auditor or a regulator attached. Then stop. Five headings and a page is usually the whole document.
Now the part where I argue against myself
Four honest problems, and I would rather name them than have you find them.
It is not new
Marty Cagan wrote in 2006 that "most specs take too long to write, they are seldom read, they don't provide the necessary detail," and that "there's only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype." Anyone selling prototype-as-spec as a 2026 discovery is twenty years late. What changed is the cost of making one, not the idea.
Communicating is the prototype's second job, not its first
Cagan again, and this one matters most. The primary purpose is to discover a solution that works. Using it to communicate intent is a real benefit, but "the danger is that many people mistakenly confuse this with the primary purpose of the prototype... without testing the prototype, they end up spending the time and money to build a product that ends up failing in the market." A prototype you never put in front of a user is an expensive opinion with animations on it.
People mistake the demo for the product
This one costs real money. Red Access scanned more than 380,000 web assets this year and found around 5,000 vibe-coded applications built for company use. Forty percent of them held sensitive data with no basic security controls. Two thousand had no authentication, no access control and no audit trail. An engineer on Blind, watching PMs demo to leadership, put it plainly: "The minute the demo is available people will think that it's almost built and 2 weeks from being ship ready."
Say the words out loud when you show it. "This is a question, not a release." It sounds small. It is the difference between a room that gives you feedback and a room that puts your prototype on the roadmap.
The document is not the villain
Uber, who have the best public numbers on this, did not throw theirs away. They moved it: frame the problem, prototype early, then write a sharper PRD, then final designs. Their line is "Prototypes open up the space quickly. PRDs slow things down just enough to make decisions explicit and durable." And the sharpest objection I found came from a stranger on Hacker News: "The problem with waterfall wasn't the detailed spec, it was the inability to change the spec."
That is right, and it is the whole thing. The artifact was never the villain. The speed of changing it was.
Where this leaves you
The prototype is now the cheapest way to build shared understanding, which is what the user story was invented to do and mostly stopped doing. Write the document after, when there is something real to be precise about, and write only the five things above.
But notice what none of this touches. A prototype does not tell you what to build. It shows you what you asked for, faster and more honestly than a paragraph ever did. If the ask is vague you now get a vague product in four minutes instead of four weeks, and it arrives looking finished, which is worse.
Anyone can generate a prototype. Not everyone can say what it has to prove.
- 01One user story produces four different products, and nobody notices, because everyone agrees with the words.
- 02The story was invented as a conversation. Beck's word was telling. Jeffries called the card a token and put the requirement in the conversation.
- 03Replace it with a brief: user, context, goal, finish line, about thirty words, no screens and no features.
- 04Ninety minutes on Monday beats a fourth refinement session. Ten to write, five to agree the test, forty-five to build, ten to watch, twenty to write down what the prototype could not show.
- 05Five things still need writing: constraints, non-functional requirements, edge cases, accessibility, and the reasoning.
The autumn build evenings run three hours, in English, and you leave with something working. Pick a city.
The whole method, with the brief worksheet and the run sheet, is free in the playbook.
Run one, then tell me how it went. You built it, you get the credit.
Frequently asked questions
Are PRDs dead?
No, and be careful with anyone who says so while selling you something. What has died is the sequence where a document is written first, argued over, signed off, and only then turned into something you can see. Uber's public workflow is a good model: frame the problem, prototype early, then write a sharper PRD once there is something real to be precise about.
Should we stop writing user stories?
Stop writing them as specifications, which they were never meant to be. Ron Jeffries described the card as a token that reminds people what to talk about. If your team spends longer wording a ticket than building the thing it describes, the ticket has stopped being a token and become a very slow way of avoiding a conversation.
What about epics?
An epic is just a user story too big to finish in one go. Jeff Patton is honest that nobody knows who coined the term, and warns against using it as a stick to tell people their request is wrong. If an epic in your backlog is really a container for six months of guessing, a prototype will tell you more about it in an afternoon than another refinement session will.
What does a brief look like if my product is not consumer?
The same four parts. “A warehouse shift lead, on the floor with gloves on, needs to reassign a picker to a different aisle before the next wave starts, in under thirty seconds.” Person, context, goal, finish line. If you cannot name the person, that is the first thing to go and find out.
What does a prototype still not replace?
Constraints, non-functional requirements, edge cases nobody finds by clicking, accessibility, and the reasoning behind decisions. Add anything with an auditor attached. Write those down after, and only those. It is usually a page.
Isn't a vibe-coded prototype dangerous?
It is if you let it near production. Red Access found around 5,000 vibe-coded applications built for company use this year, and 40% held sensitive data with no basic security controls. A prototype is a question, not a release. Build it to learn, show it, then let engineers build the real thing properly.
