A functioning prototype can now take less time to create than a thoughtful PRD. That has made an old product question newly urgent: which should come first?
Start with neither. Start with the decision you need to make.
If you are still choosing a direction, build a concept prototype. It will give you something concrete to begin the PRD from. As the direction becomes clearer, use the PRD to explain why you are building, how you will measure success, and what is in, out, and still undecided. Use a design prototype to show exactly what the team is building.
The PRD and prototype are not competing artifacts. The PRD preserves why you are building. The prototype makes what you are building tangible. The best teams move between them as they learn.
This article contains the complete written guide. Paid Top 1% Builder Club members can also watch the workshop replay and download the full slide deck.
Watch this part of the workshop: At 1:55, I pose the PRD-or-prototype question and explain why creating a prototype can now take less time than writing a PRD.
Should you start with a PRD or a prototype?
Start with the artifact that will answer your most important unanswered question.
That means the answer can change from one product to another, and even from one stage of the same product to the next.
Use a concept prototype when you have identified the problem but still need to choose a direction. It lets you explore the solution space in enough detail to decide where to go next.
Then use the PRD to answer the questions the prototype leaves open: why you are building, how you will get it done, when you will launch, where customers will find it, and how you will drive adoption.
The right sequence depends on the critical question. A concept prototype can give you a direction to begin the PRD from. Design and research prototypes can then feed back into the PRD as the team learns what to build and whether it is right for customers.
The old product development model encouraged a fixed sequence: write the PRD, hand it to design, conduct a product review, hand it to engineering, and launch. Each stage was expensive, so work moved like an assembly line.
That constraint has changed. PRDs and prototypes can now evolve together in a learning loop as the team explores, reviews, tests, and builds. Feedback can change why you are building, what you need to accomplish, or how you will measure success. That can lead to another prototype, one that explores a different concept or goes further on the current one. Each artifact sharpens the other until feedback earns the launch.
Today, PRDs and prototypes work together to help us learn.
Go deeper in the workshop: At 26:45, I explain why PRDs and prototypes should evolve together instead of moving through the old linear handoff process. Upgrade to watch this section â
What belongs in a PRD versus a prototype?
A useful division is simple: the PRD preserves the why, while the prototype makes the what tangible.
Use the PRD to clarify the customer problem, why it matters, the outcome you want, how success will be measured, how you will get it done, what is in and out of scope, what remains undecided, where customers will find it, and how you will drive adoption.
Use the prototype to clarify the experience and flow, how the product behaves, what users see and do, how interactions feel, how the parts fit together, what the intended solution looks like, whether customers want and use it, and whether the experience is believable.
A prototype, no matter how polished, answers only part of the product question. It can show how a feature works, but it usually does not explain why the feature should exist, how the team will get it done, when it will launch, where customers will find it, or how the team will judge success.
A PRD has the opposite limitation. It can preserve rationale and decisions, but words leave room for interpretation. Two people can read the same paragraph and imagine different products. A prototype creates a shared object that customers, stakeholders, designers, and engineers can respond to.
The artifacts should not duplicate one another. They should form a connected definition of the product.
The PRD holds the problem, the bet, the success measures, and the non-goals. The prototype holds the flows, interactions, and intended experience. Product review records which decisions have been made and what remains open. The handoff communicates the intent the team should preserve as implementation evolves.
One participant described the distinction well: âPRDs preserve the why and key trade-offs. Prototypes make the solution tangible. The interesting question now is what context belongs in each.â
Can a prototype replace a PRD?
Usually, no.
A prototype can replace parts of a PRD that laboriously describe the interface or interaction. It should not replace why the product deserves to exist, how success will be measured, or what is in, out, and still undecided.
This matters even more when AI builds from the artifacts. A convincing prototype can hide hundreds of small decisions the model made on your behalf. Some may be sensible. Others may contradict what you learned from customers or create behavior you never intended.
The goal is not to produce more documentation around the prototype. The goal is to make intentional decisions visible and incidental AI decisions easy to identify.
What can a 20-minute prototype teach you that a PRD cannot?
One of the best PRDs I saw during my time at TripAdvisor defined a complex trip-planning product. A cross-functional team spent about six weeks developing the mission, research, and wireframes. The work was detailed enough to align a team around a multi-quarter build.
The team also learned through customer conversations. An early assumption treated trip planning as a single-player activity. Research showed that it needed to support multiple travelers from the beginning.
Years later, I put that material, along with a little additional context, into Magic Patterns. I asked it to infer a design system from TripAdvisorâs site. In about 20 minutes, I had a functioning prototype. I could open places, see conversations, remove an item from a trip, review unscheduled saves, and move through each day on a map.
The prototype communicated the experience more clearly than the document alone could. It also made decisions I had not approved. Removing an item had no confirmation. It was unclear what should happen to the conversation around a removed place. Some data and design details were wrong.
That is the promise and the danger of AI prototyping. Six weeks of context can become a tangible starting point in 20 minutes. But speed does not turn generated decisions into product intent.
See the prototype in action: Starting at 23:17, I walk through the six-week TripAdvisor definition and the functioning prototype it helped produce, including choices the AI made that still needed review.
What are the four types of prototypes?
A prototype is a decision-making tool. The type you build should match the decision you need to make.
1. Concept prototype: Which direction should we pursue?
Use a concept prototype when you understand the problem but have not chosen a solution. Its purpose is to explore the solution space with enough detail to compare directions.
The goal is not polish. The goal is a decision about where to go next.
2. Design prototype: What exactly are we building?
Use a design prototype after you have chosen a direction and need to define the intended experience at higher fidelity. It works closely with the PRD to create the context the delivery team needs.
The test is whether the team can use it as a blueprint for what to build.
3. Research prototype: Will customers want and use it?
Use a research prototype when you need customers to react to the proposed product. It must be believable enough that people respond as if it were real.
That means the copy, images, data, and surrounding context matter. If those details break the illusion, you may end up testing the quality of the prototype instead of the value of the idea.
4. Technical prototype: Is this possible?
Use a technical prototype to test feasibility. This is especially important for AI features. Can you get the prompts right? Can the model do what you need it to do? Is the product possible with the technology available today?
The output may never be shown to a customer. Its job is to tell the team whether the proposed product can work.
Prototypes are decision-making tools.
Before anyone creates a prototype, ask one question: What decision will this prototype help us make?
If there is no clear answer, do not build it yet. Cheap prototypes without a decision behind them create noise, not clarity.
Watch the full framework: At 29:57, I walk through the four prototype types and the decision each one is designed to support.
How should a PRD and prototype evolve together?
Use them as a learning loop:
Identify the most important unanswered question.
Choose the artifact that can answer it.
Put that artifact in front of the right people.
Record what you learned, what changed, and what remains undecided.
Update the PRD, prototype, or both.
Repeat until the team has enough conviction to build.
You may begin with a concept prototype and use it to choose a direction. That direction gives you a starting point for the PRD. A design prototype then makes the intended experience concrete. A research prototype reveals what customers value or misunderstand. A technical prototype tests whether the hardest parts are feasible.
The sequence is not universal. The discipline is.
At every stage, the team should know which question it is answering, which decisions are settled, and which assumptions still need evidence.
How do you stop prototypes from creating Feature Factory 2.0?
Add an explicit curation step to the product lifecycle.
The old feature factory was rate-limited by the cost of building. When a team invested months in a feature, sunk cost created enormous pressure to ship it. AI removes much of that rate limit. A team can now generate more concepts and functional prototypes than customers have the time or attention to absorb.
The answer is not to stop exploring. It is to stop treating everything you build as something you must ship.
After the team creates and tests something, ask:
Is this worthy of the customerâs attention?
Make that a formal decision before production or launch. A photographer does not publish every frame. A director does not release every scene. Product teams can now work the same way: create broadly, learn quickly, discard freely, and ship the selects.
We can now build a lot, throw a lot away, and pick the selects. The audience should see only the best of what the team created.
Hear the full Q&A: At 56:03, I answer how teams can prevent cheap prototypes from turning into Feature Factory 2.0 and why curation now belongs in the product lifecycle. Upgrade to watch the Q&A â
How do you avoid a 30-page AI-written PRD?
Do not ask AI to make the foundational product decisions for you and then mistake the volume of its output for completeness.
A 30-page PRD can appear in a minute. The question is whether the person who generated it read every page, understood every decision, and agreed with every assumption before asking a team or an agent to build from it.
My process is deliberately more constrained:
Write the initial prompt yourself
I sometimes spend 30 minutes to an hour writing a prototype prompt by hand. that sounds long when you can get a perfectly reasonable prototype built with just a few lines of text, but for me, that time is intentional. Every word represents a decision I considered rather than an assumption the AI quietly introduced.
Ask for divergence before convergence
Ask for four or five meaningfully different approaches. Compare them, choose a direction, and only then invest in detail.
Give fine-grained feedback
Correct the small things. A word of copy, an interaction, or a piece of data can reveal a larger misunderstanding of the product intent.
Perform a human copy pass
AI-generated copy often sounds complete while remaining generic or slightly wrong. A careful copy pass makes the prototype more believable and exposes decisions that need attention.
Minimize layers of assumptions
Tools, templates, and skills can each add their own assumptions. Use only what helps the task. Constrain the system when faithful execution matters more than ambition.
Read the entire result
Do not use AI to generate a long PRD, use another AI to summarize it, and assume your intent survived. These are probabilistic systems. Every transformation creates another opportunity for the original reasoning to disappear.
I learned this while building a self-assessment product. I asked AI to turn a small amount of context into a PRD. The result looked impressive: roughly 20 pages, filled with features and detail. Then I read it closely and found assumptions I had never made and features I had never chosen. Building from it would have produced slop on top of slop.
I started again and spent an hour writing the prompt myself.
See how I do this in practice: At 58:33, I share the techniques I use to turn AI output into a usable product definition. At 1:00:59, I explain where my own process went wrong.
A practical guide to choosing the next artifact
If you do not know which solution to pursue, build a concept prototype.
If you need to clarify why you are building, how success will be measured, or what is in, out, and still undecided, use the PRD.
If the team cannot picture the experience, build a design prototype.
If you need evidence that customers will value it, build a research prototype.
If you do not know whether the technology can deliver, build a technical prototype.
If you have too many artifacts, synthesize them into one concise, coherent, executable definition.
If you have something working, curate before shipping.
The speed of building has changed. The hard part has not.
You still need to decide what the customer wants, what deserves to exist, and what quality bar the product must meet. A PRD and a prototype are useful only to the extent that they help the team make those decisions with greater clarity.
Start with the decision. Choose the artifact. Learn. Update the definition. Then build what is worthy of the customerâs attention.
Ravi
Watch the Product Definition workshop and get the slides
The complete article above is free. The workshop replay and full PDF slide deck are available to paid Top 1% Builder Club members.
The replay includes:
1:55 PRD or prototype: which should come first?
13:02 How to avoid too little and too much context
23:17 The six-week PRD and 20-minute prototype
26:45 How PRDs and prototypes work together
29:57 The four types of prototypes
34:51 How the artifacts fit together
50:28 What to measure when story points stop working
56:03 How to prevent Feature Factory 2.0
58:33 How to replace a 30-page AI document with an intentional definition
1:00:59 Where my own AI-assisted process went wrong
Upgrade to the Top 1% Builder Club â
