Start with a PRD or a prototype? A guide to defining products with AI

Ravi Mehta's article starts from a practical shift: with AI tools, building a working prototype can take less time than drafting a well-thought-out PRD (product requirements document). That reopens a classic question: which comes first? His answer is that you start with neither, but with the product decision that needs to be made. Then you choose the artifact that gives the most clarity on that decision.

According to the author, if you are still choosing a direction, it makes sense to build a concept prototype, which gives you something concrete from which to start the PRD. As the direction becomes clearer, the PRD serves to explain why you are building, how success will be measured and what is in, out or still undecided. The design prototype, for its part, shows exactly what the team is building. The two don't compete: the PRD preserves the why and the prototype makes the what tangible. The best teams move between the two as they learn.

The piece contrasts this with the old, linear model: write the PRD, hand it to design, hold a product review, hand it to engineering and ship. Each stage was expensive, so work moved like an assembly line. That constraint has changed. Now PRDs and prototypes can evolve together in a learning loop: feedback can change the reason for building, the goals or the metrics, and lead to a new prototype that explores another concept or goes deeper into the current one. Each artifact sharpens the other until the feedback justifies shipping.

On what belongs in each, the author proposes a simple split. The PRD captures the customer problem, why it matters, the desired outcome, how success will be measured, how it will be delivered, the scope, what remains to be decided, where customers will find the product and how adoption will be driven. The prototype clarifies the experience and flow, the product's behavior, what users see and do, how interactions feel, how the pieces fit together and whether the experience is believable. A prototype, however polished, answers only part of the product question; a PRD, on the other hand, leaves room for interpretation, because two people can read the same paragraph and picture different products. The prototype creates a shared object that customers, stakeholders, designers and engineers can react to.

Can a prototype replace a PRD? Usually not. It can replace the parts of the PRD that laboriously describe the interface or interaction, but not why the product should exist, how success will be measured or what is in, out or pending. This matters more when an AI builds from the artifacts: a convincing prototype can hide hundreds of small decisions the model made on its own, some sensible and others contrary to what was learned from customers. The goal, the author says, is not to produce more documentation, but to make intentional decisions visible and the AI's incidental decisions easy to spot.

As an example, the author recounts that during his time at TripAdvisor he saw one of the best PRDs, which defined a complex trip-planning product. A cross-functional team spent about six weeks on the mission, research and wireframes. An early assumption treated planning as a solo activity, but research showed it needed to support multiple travelers from the start. Years later, he fed that material, with some additional context, into Magic Patterns and asked it to infer a design system from the TripAdvisor site. In about 20 minutes he had a working prototype in which he could open places, view conversations, remove an item from a trip, review unscheduled saves and walk through each day on a map. The prototype communicated the experience better than the document alone, but it also made unapproved decisions: removing an item didn't ask for confirmation, it was unclear what happened to the conversation tied to a deleted place, and some data and design details were wrong. Speed, he concludes, does not turn generated decisions into product intent.

The article then presents four types of prototype, each tied to a decision. The concept prototype answers which direction to take: it is used when the problem is understood but no solution has been chosen, and its goal is not polish but deciding where to go. The design prototype answers what exactly is being built: it defines the intended experience at higher fidelity, works alongside the PRD and should serve as a blueprint for the delivery team. The research prototype answers whether customers will want and use it: it must be believable enough for people to react as if it were real, so the copy, images and data matter; if those details break the illusion, you end up testing the prototype's quality rather than the idea's value. The technical prototype answers whether it is possible: it tests feasibility, something especially important for AI features (can the prompts be tuned? can the model do what's needed?), and it may never be shown to a customer. Before creating any prototype, he poses one question: what decision will it help us make? If there is no clear answer, don't build it yet, because cheap prototypes with no decision behind them create noise, not clarity.

To use the PRD and prototype as a learning loop, he proposes these steps: identify the key unanswered question, choose the artifact that can answer it, put it in front of the right people, record what was learned, what changed and what remains undecided, update the PRD, the prototype or both, and repeat until there is enough conviction to build. The sequence isn't universal; the discipline is: at every stage the team must know which question it is answering, which decisions are closed and which assumptions still need evidence.

The author also warns of a “Feature Factory 2.0.” The old feature factory was constrained by the cost of building, and months of investment created pressure to ship what had been built (sunk cost). AI removes much of that constraint, and a team can generate more concepts and working prototypes than customers can absorb. His proposal is to add an explicit curation step: after creating and testing something, ask whether it is worthy of the customer's attention, and make that a formal decision before production or launch. He compares it to a photographer who doesn't publish every frame or a director who doesn't release every scene: create broadly, learn fast, discard fearlessly and ship only the best.

Finally, he addresses how to avoid a 30-page AI-written PRD. Such a document can appear in a minute, but the question is whether whoever generated it read it in full, understood every decision and agreed with every assumption. His process is deliberately narrower: write the initial prompt himself (sometimes he spends 30 minutes to an hour on it, because every word represents a decision rather than an assumption silently introduced by the AI); ask for divergence before convergence, that is, four or five genuinely different approaches to compare and choose from; give meticulous feedback, since a single word of copy or a data point can reveal a bigger misunderstanding; do a human pass on the copy, because AI-generated copy sounds complete but is often generic or slightly wrong; minimize layers of assumptions (tools, templates and skills add their own); and read the full output, rather than generating a long PRD, summarizing it with another AI and assuming the intent survived. He says he learned this while building a self-assessment product: he asked the AI to turn a little context into a PRD of about 20 pages, seemingly impressive, but on reading it closely he found assumptions he never made and features he never chose. He started over and spent an hour writing the prompt himself.

As a final practical guide: if you don't know which solution to pursue, a concept prototype; if you need to clarify the why, how success is measured or what is in, out or undecided, the PRD; if the team can't picture the experience, a design prototype; if you need evidence that customers will value it, a research prototype; if you doubt the technology allows it, a technical one; if you have too many artifacts, synthesize them into a concise, coherent and actionable definition; and if you already have something working, curate before shipping. The author's conclusion is that the speed of building has changed, but the hard part hasn't: deciding what the customer wants, what deserves to exist and what level of quality the product must reach.

Note on the material: the written article is free and complete. The workshop recording (with sections on context, metrics once story points stop being useful, and the Q&A) and the PDF slides are reserved for paid members of the Top 1% Builder Club, so this summary is based solely on the written guide.