--- title: "The Prototype Is the New Requirement: How AI Rewrites the Product Operating Model" description: "When a working prototype takes an afternoon rather than a quarter, the requirements document loses its job as a de-risking tool. Product managers now build first, then discover against something real." author: "Kody Everson" url: "https://theipp.org/insights/the-prototype-is-the-new-requirement-how-ai-rewrites-the-product-operating-model" date: "2026-07-02T09:51:48.213Z" --- # The Prototype Is the New Requirement: How AI Rewrites the Product Operating Model ## Summary When a working prototype takes an afternoon rather than a quarter, the requirements document loses its job as a de-risking tool. Product managers now build first, then discover against something real. ## Main content The most expensive artifact in product development was never the code. It was the false confidence a written requirement created before anyone had seen a working thing. For as long as I can remember we have treated the specification as the safe, cheap way to align stakeholders, and the prototype as the costly luxury you earned only after the document was signed off. AI tools have not so quietly inverted that. When a functional, clickable, data-connected prototype can be assembled in an afternoon, the requirements document stops being a de-risking tool and becomes what it often was all along: a way of arguing about a product nobody has yet touched. Claude Code, Lovable, Replit, Codex, whatever your flavour; AI prototyping has changed the sequence of product work. Gone are the days of sequenced discovery, requirements then build. It is now prototype first, discover actively against something real, then rebuild for production. Each stage still exists, but their purpose and ordering have shifted, and so have the skills that make a product manager effective within them. ## Why the classic sequence is breaking The discover-then-build model was rational under a specific constraints. Building was slow and irreversible, so you front-loaded certainty through research, requirements, and sign-off. The whole process of Agile refinement, story points, and backlog grooming existed to reduce the risk of committing engineering time to the wrong thing. Discovery was the insurance policy you bought before the expensive commitment. AI code generation and design tooling change two variables at once. First, the cost of producing a working artifact drops by an order of magnitude for a large class of interfaces and workflows. Second, the cost of producing several competing versions of that artifact drops even further, because variation is close to free. When you can generate three plausible implementations of a feature before lunch, the value of a document describing one of them in words goes almost to zero. The consequence is subtle and often misunderstood. Cheap building does not make discovery obsolete. It relocates it. Logically, discovery used to happen before the outcome existed, through interviews, surveys or market research, but now it can happen against the tangible, clickable prototype which for all intents and purposes a single user has no idea is not production ready. Real discovery through real interaction, observed behaviour, and measured response. This is a strictly better position, because research about a described product is far weaker evidence than observation of an actual one. > The prototype stops being the reward for finishing discovery. It becomes the instrument through which discovery is conducted. ## The new world: prototype, discover actively, rebuild Consider how this reorders the work in practice. A team wants to reduce drop-off in an onboarding flow. Under the old model, they would run discovery, hypothesise causes, write requirements for a redesign, and ship it weeks later, at which point they finally learn whether their hypothesis held. Under the new model, they generate two or three working onboarding variants in days, put them in front of real users, and watch what actually happens. The evidence arrives before the production commitment, not after it. The three stages take on distinct characters: - **Prototype first.** The goal is not to build the thing well. It is to make the smallest real object that can generate evidence. A prototype that cannot be interacted with, or that cannot be measured, has failed its only job. This is deliberately disposable work, and treating it as anything else is the most common early mistake. - **Discover actively.** This is where the intellectual weight now sits. Active discovery means putting the prototype into contact with reality under conditions designed to produce a clear signal. It requires a hypothesis sharp enough to be wrong, and a metric or observation that would prove it so. Without that, cheap prototyping simply produces cheap opinions faster. - **Rebuild for production.** The prototype validated the shape of the solution; it did not validate that the solution is secure, performant, accessible, maintainable, or compliant. Production is a separate act of engineering, informed by the prototype but not derived mechanically from it. ## The evidence standard goes up, not down There is a seductive misconception of this shift: that because building is cheap, we can just try things and see what sticks, and rigour is a relic of the prior era. The opposite is true. When generation is cheap and validation is scarce, the scarce resource is the thing that carries all the value. It is trivially easy to produce a hundred prototypes and learn nothing from any of them, because none was built to answer a specific question. This raises the bar on evidence standards in a way many teams are unprepared for. If you can build almost anything quickly, the constraint is no longer engineering capacity. It is the quality of your questions and the honesty of your interpretation. A PM who ships prototypes without a hypothesis that could be proved wrong is not doing lean product work; they are doing expensive guessing with a cheaper tool. The rigour that used to protect us from building the wrong thing must now protect us from learning the wrong lesson. Prioritisation changes too. When the cost of building drops but the cost of maintaining and supporting production systems does not, the prioritisation question moves downstream. The interesting decision is no longer which few things we can afford to build, but which of the many things we can now cheaply validate actually deserve the far more expensive commitment of production, ongoing support, and cognitive load on users. ## What this demands of product managers The skills that matter are shifting, though not in the direction of becoming a prompt engineer. They are moving toward judgement, framing, and burden of evidence. - **Framing testable hypotheses.** The ability to convert a vague product intuition into a claim sharp enough to be proven wrong is now the highest-leverage skill a PM has. Cheap prototyping only pays off when it is pointed at a real question. - **Curating and interrogating AI output.** AI tools produce plausible artifacts confidently, including plausible mistakes. The PM's job is to treat generated output as a draft to be interrogated, not an answer to be accepted. This requires enough domain and technical literacy to spot where the machine has hallucinated a solution to the wrong problem. - **Managing the disposable-to-durable transition.** Knowing which work is throwaway, communicating that clearly to stakeholders who saw a working demo, and defending the rebuild for production, is a distinct competence. It is largely a matter of expectation management and decision rights. - **Owning outcomes, not artifacts.** When anyone can generate a feature, the PM's accountability shifts decisively from what was built to what changed for the user and the business. Outcome accountability is the only stable ground when the artifacts themselves have become cheap and abundant. Decision rights become sharper in this model, not looser. When three teams can each build a plausible version of the same feature in a week, the organisation needs clarity about who decides which one proceeds to production and on what evidence. Ambiguous decision rights combined with cheap generation produce chaos: parallel prototypes, no arbiter, and no learning. The PM who can hold that decision, backed by evidence rather than opinion, becomes more valuable, not less. ## Practical implications for teams making the shift Start by separating your prototyping environment from your production environment, culturally and technically, so that no prototype can accidentally graduate to production without a deliberate rebuild decision. Establish, in advance, what evidence a prototype must produce to justify that rebuild. Resist the temptation to measure success by the number of prototypes shipped; measure it by the number of validated decisions made. Re-skill discovery, do not abandon it. The interviews, jobs-to-be-done thinking, and problem framing that underpinned good discovery remain essential; they now feed the design of prototypes and the interpretation of their results rather than substituting for them. The teams that throw out discovery because building got cheap will build fast and learn nothing. Finally, protect the rebuild. The single biggest risk in this new operating model is the demo that ships. A prototype that impressed a stakeholder carries enormous political momentum toward production, regardless of whether it is fit for it. The PM who can hold that line, and articulate why validated does not mean ready, is doing the most important work in the room. The era of prototype first is not a relaxation of product discipline. It is a redistribution of it. The cheap part of the job got cheaper, and the hard part, knowing what to build and proving it was worth building, got harder and more central. That is good news for product managers who were always in it for the judgement rather than the paperwork. ## Related pages - [Insights](https://theipp.org/insights.md) - [Product Profile](https://theipp.org/tools/product-profile.md) - [Standards](https://theipp.org/standards.md)