The way we align on product ideas has changed. We don't start with a PRD any more. We start with a prototype, something you can react to instead of read.
Key insights
- A prototype creates a shared reference a document never can.
- Build it in hours and be willing to throw it away.
- Alignment is faster when people can click instead of imagine.
A requirements doc is a fine record of a decision. It's a bad way to make one. Ten people read the same paragraph and walk out with ten different pictures in their heads. Nobody notices until design is half done and someone has already put an estimate on it.
A prototype closes that gap fast. Put a clickable thing in front of five people and you stop getting opinions about wording. You get reactions. "That's not what I meant." "Why is this step here?" "Oh, now I get it." That's alignment, and it shows up in the first ten minutes rather than the fourth week.
"You can't argue with a document the way you can argue with a prototype."
Why we all still start with the doc
The PRD comes from a time when making anything visual was expensive. Writing was the cheapest thing you could do, so writing went first. Everything downstream inherited that order. Doc, review, wireframe, design, build. Every handover added a fresh round of interpretation, and interpretation costs weeks.
That maths doesn't hold now. Building something credible and interactive costs roughly what a careful document costs. So the reason the PRD went first has quietly gone away, and most teams haven't noticed yet.
What this actually looks like
The point isn't a pretty deliverable. It's the smallest thing that makes the idea arguable. A session usually runs like this:
- Say the bet in one sentence. What behaviour are we trying to change, and for whom?
- Get the look right enough. People need to respond to the idea, not to grey boxes.
- Make it interactive. Two or three real paths. Only the ones the bet depends on.
- Put it in front of people. Stakeholders first, then users. Watch where they hesitate.
- Call it. Go, no-go, or reshape, before anyone has burned real time.
The PRD doesn't die. It moves. You write it after the prototype has settled the arguments, and it comes out shorter and much harder to disagree with, because it describes something everyone has already seen.
The Farfetch exploration
This one is mine. I used Farfetch as the canvas so I could share the thinking publicly. A familiar surface means nobody needs a brief to follow the idea.
Unofficial concept. Not affiliated with, commissioned by, or endorsed by Farfetch. Built purely as a design exploration.
The workflow was not glamorous. ChatGPT for the visuals, then Claude for the interactive prototype. A few prompts. That's it. A blank page in the morning, something you could click through by the afternoon. The same amount of work used to produce a first draft of a doc and nothing anyone could touch.
"Hours, not weeks. Quick enough to get a go or no-go before anyone's burned real time on it."
What changes for the team
Decisions get cheaper
When an idea costs a few hours to see, killing it stops being political. Teams try three directions instead of defending one, and the weak one dies quietly on a Tuesday rather than in a steering committee two months later.
Feedback gets specific
Specs pull in abstract feedback. Prototypes pull in precise feedback. This step, this label, this order. Precise feedback is the only kind you can act on quickly.
Stakeholders stop guessing
We keep asking executives to approve products they can't picture. A clickable prototype turns that into a judgement call instead of an act of faith, and their judgement is usually good once they can see the thing.
Rules that keep it honest
- Fidelity serves the question. Build only the paths the decision depends on.
- Time-box it. If a concept takes more than a day, the question is too big. Split it.
- Keep it disposable. The minute a prototype becomes precious it stops being a thinking tool and turns into debt.
- Test with real users too. Agreement in the room is not evidence.
- Write it up afterwards. Prototypes settle the argument, documents keep the answer.
FAQ
Does prototype-first mean no documentation?
No. It means the documentation follows the decision rather than trying to make it. A spec written after a validated prototype is shorter, more accurate, and nobody fights about it.
How long should a concept prototype take?
Hours, not weeks. With AI doing the visuals and the interaction, one focused day is usually enough to get to a confident go or no-go.
Which tools do you use?
For this one, ChatGPT for the visual direction and Claude for the interactive build. The tools matter less than the order: visual first, interactive second, document last.
Isn't a rough prototype risky in front of executives?
The bigger risk is signing off on something nobody can picture. Call it a disposable exploration up front and the conversation stays on the idea instead of the pixels.
The change is easy to describe and hard to overstate. Stop asking people to imagine the product. Ask them to react to it. The roadmap, the spec and the estimate all get easier once that first argument is already behind you.
