The old model asked people what they wanted and wrote it down. The new one shows them something and watches what they do. The difference is the difference between stated needs and real ones.

For most of the history of enterprise software, gathering requirements meant the same sequence of moves. An analyst or product owner interviewed stakeholders, ran workshops, and asked people what they needed. The answers were captured in a document — a requirements specification, a set of user stories, a backlog of “asks.” That document was validated, signed off, and handed to a delivery team to build. The ritual was so established that “requirements elicitation” became a named discipline, with its own techniques and certifications, all organized around a single premise: that if you ask the right people the right questions, they will tell you what to build.

That premise is where the trouble starts. It assumes people can accurately describe what they want before they have seen it. In practice, they usually cannot — not because they are difficult or uninformed, but because most requirements are not fully knowable in the abstract. They become knowable only when there is something concrete to react to. The interview captures what a stakeholder can articulate. The far more valuable information is what they reveal when a working thing is placed in front of them, and that information does not exist yet at the interview stage. This is why prototyping has quietly become the primary way modern product owners and managers gather requirements — not as a replacement for talking to people, but as a replacement for talking to people only.

The gap between what people say and what they need

The central weakness of an interview-only approach is the gap between stated needs and revealed needs. Stated needs are what someone tells you when you ask. Revealed needs are what they demonstrate through their reactions and behavior once something real exists. The two overlap, but never completely, and the space between them is where most failed features are born.

There are good reasons for the gap. People describe the process they think they follow, not the one they actually follow, because the real one is full of exceptions and workarounds they have stopped noticing. They ask for what they can imagine, which is usually a faster version of what they already have, rather than what would actually serve them better. And they answer in the language of features — “I need a dashboard,” “I need a report” — when what they have is a problem, and the feature they name is only their first guess at a solution. An interview faithfully records all of this, and a requirements document faithfully preserves it, and a delivery team faithfully builds it, and at the end everyone discovers that the thing everyone agreed to was not the thing anyone needed.

There is a second, structural problem. The traditional model moves requirements through a chain of translations — stakeholder to analyst, analyst to document, document to developer — and every translation loses fidelity, like a game of telephone conducted in writing over several months. By the time the requirement is built, it has passed through several minds, none of whom can see the others’ assumptions. Large batches of written requirements also behave like inventory: they are produced up front, sit waiting, and steadily go stale as the business changes underneath them. The longer the gap between capturing a requirement and testing whether it was right, the more of that inventory turns out to be waste.

What a prototype actually does

A prototype collapses that chain. Instead of describing a solution in words and hoping the description survives translation, you build a rough version of the thing itself and put it in front of the people who will use it. The shift sounds small and is not. It changes the question being asked from “What do you want?” — which invites a speculative answer — to “Is it this?” — which invites a concrete reaction. Reactions are much higher-fidelity data than statements, because they are involuntary and specific. People who cannot tell you what they need in the abstract will tell you instantly, and precisely, what is wrong with something concrete in front of them.

A prototype does three things an interview cannot. It makes tacit knowledge explicit: the moment someone uses a mock-up, the exceptions and workarounds they never thought to mention surface on their own, because the prototype does not handle them and they notice. It creates a shared artifact: instead of a document that different stakeholders read differently, there is one concrete thing everyone is reacting to, which turns vague disagreements into visible ones that can actually be resolved. And it surfaces disagreement early, when it is cheap — two stakeholders who both “agreed” to a written requirement will often discover, the instant they see it rendered, that they had entirely different things in mind. Finding that out in a prototype review costs an afternoon. Finding it out after the feature is built costs a release.

It is common for a program that has run months of interviews and produced volumes of carefully documented requirements to find that a single working prototype unlocks more clarity in an hour than the interviews did in a quarter — not because the interviews were done badly, but because they were asking people to do something people cannot do: specify the unseen.

The shift this asks of Product Owners and Managers

This is not only a change in technique. It is a change in what the product owner or manager role actually is. In the interview-only model, the product owner is fundamentally a scribe — someone who collects requirements, transcribes them, organizes them into a backlog, and manages the list. The skill is thoroughness: capture everything, miss nothing, keep it tidy. It is a fundamentally passive posture, and it treats stakeholders as authorities who already hold the answer.

Prototyping asks the product owner to become something else: a person who forms a hypothesis and tests it. The work is no longer “find out what they want and write it down.” It is “form the best guess about what would serve them, build the cheapest possible version of it, and put it in front of them to find out where the guess is wrong.” That is an active, empirical posture, and it treats stakeholders not as oracles but as evaluators — people who are far better at judging a concrete proposal than at authoring an abstract one. The product owner stops being the person who owns the list of asks and becomes the person who owns the hypothesis and the experiment that tests it.

This is a genuine identity shift, and it is worth naming because many product owners were trained into the scribe model and measured on it. The move to prototyping does not make them less rigorous; it redirects the rigor from completeness of capture to quality and speed of learning. The best product owners in this mode are not the ones with the most complete backlog. They are the ones who can design the fastest experiment that reveals whether an idea is worth building.

Why this is a discipline, not a fad

It would be easy to dismiss prototyping-as-elicitation as the latest fashion, but it rests on ideas that have been validated repeatedly and are already embedded in modern delivery frameworks. The Lean Startup’s build-measure-learn loop is the same claim in different words: you learn what to build by building something small and measuring the response, not by planning in advance. The minimum viable product is a prototype whose explicit purpose is to generate learning rather than to be the final thing. Scaled agile frameworks encode the same instinct in their principle to “assume variability and preserve options” — the recognition that committing to a single detailed specification too early destroys the information you would have gained by keeping options open and testing them. And the System Demo, the practice of showing real working software on a fixed cadence, is prototyping institutionalized: it exists precisely because a working increment tells you the truth about your requirements in a way that a status report never can.

Seen this way, prototyping is not a replacement for the rigor of requirements work. It is the rigor, relocated to where it produces the most information — after there is something real to evaluate, rather than before.

Where the work lives: the discovery track

If prototyping is how requirements are discovered, the natural next question is where in a team’s rhythm that discovery actually happens. The answer that has emerged is a dedicated discovery track running continuously alongside the delivery track — an arrangement often called dual-track development. It is worth understanding, because it is the structural change that turns prototyping from an occasional activity into a reliable operating model.

The traditional approach treated requirements gathering as a phase: understand everything first, then build. Dual-track rejects the phase entirely. Discovery and delivery become two parallel, continuous streams of work. The delivery track builds production-ready software from validated ideas on a steady cadence. The discovery track runs a step ahead of it, continuously exploring problems, building prototypes, and testing them with real users so that by the time an idea reaches the delivery backlog, it has already been de-risked. Discovery is always slightly ahead; delivery is always building the last thing discovery proved worth building. Neither track ever stops.

In SAFe this discovery work has a name and a home: Continuous Exploration, the first stage of the Continuous Delivery Pipeline. It is the space where teams hypothesize, research with customers, and synthesize what they learn into the backlog — and prototyping, design thinking, personas, and the minimum viable product all live inside it. Continuous Exploration is, in effect, the operational home for the hypothesis-testing posture described earlier: it is where a product owner forms and tests a hypothesis before committing the team’s scarce build capacity to it, rather than after. The dual-track structure is what makes that sequence routine instead of heroic.

The reason to separate the tracks is flow. If discovery and delivery are fused into a single stream, the team is forced to choose at every moment between figuring out what to build and building it, and under pressure it will always choose to build. Splitting them lets delivery keep a predictable rhythm while discovery keeps feeding it a pipeline of validated, ready work — so the team is neither building unvalidated guesses nor idling while requirements get sorted out.

This is also where the model most often quietly fails, and the failure mode is familiar. The common collapse is back to a single delivery track: a team that simply builds whatever is in the backlog, with no discovery running ahead of it. That recreates the interview-only problem one level down — unvalidated asks march straight into build, and the prototype-as-learning step never happens because there is no track for it to happen in. And because discovery produces no immediately shippable output, its capacity is the first thing sacrificed when delivery falls behind — the same starvation that befalls any foundational, invisible work. Protecting a standing slice of team capacity for discovery, and defending it against the constant pull toward pure delivery, is what keeps the whole approach from reverting to building the list.

Where prototyping misleads

Precisely because prototypes are powerful, they are also easy to misuse, and an honest account has to include the failure modes. A prototype is a form of evidence, and like any evidence it can be read wrong.

The first trap is fidelity. A polished, high-fidelity prototype invites people to react to the surface — the colors, the layout, the visual polish — rather than to the logic and workflow underneath, which is what actually matters. Paradoxically, a rougher prototype often elicits better requirements, because it keeps attention on the structure of the solution rather than its finish. The second trap is anchoring: the first concept shown becomes the frame everyone reasons within, and genuinely different alternatives stop being considered because the prototype has quietly defined the option space. Showing a single prototype can narrow thinking as easily as it can open it, which is one reason exploring more than one option early is worth the cost. The third trap is the most consequential in an enterprise setting, and it connects directly to the state of the organization’s data: a prototype built on fabricated or fragmented data produces confident nonsense. It looks like it works, stakeholders react to it as though it works, and the reactions are worthless because the thing they are reacting to could never behave that way on real data. Prototyping on an untrustworthy data foundation does not gather requirements; it manufactures false confidence.

And there is a boundary the enthusiasm tends to blur: prototyping does not remove the need to understand whose problem you are solving. You still have to do enough discovery to know which users matter, what they are actually trying to accomplish, and what “better” would even mean for them. A prototype tests a solution; it cannot, by itself, tell you that you are solving the right problem for the right people. Put in front of the wrong users, or aimed at a misframed problem, it will generate crisp, convincing, useless feedback.

Doing it well

The mature practice, then, is not “prototype instead of talking to people.” It is a rebalancing. Discovery conversations still happen, but they get sharper, fewer, and better-aimed: enough to frame the problem and identify whose reactions will matter, rather than an exhaustive attempt to extract a full specification that the prototype will gather far more reliably. The prototype becomes the primary elicitation instrument, and the remaining interviews become the means of interpreting what the prototype reveals — asking why someone reacted the way they did, not asking them to imagine what they might want.

A few habits separate prototyping that gathers real requirements from prototyping that flatters an idea. Prototype the riskiest assumption first, not the whole solution — the point is to test where you are most likely to be wrong, cheaply, before committing. Keep the fidelity low until the structure is validated, so attention stays on the logic. Put it in front of real users with realistic data, because reactions from the wrong audience or against fake data are the two fastest ways to learn something false. And treat the prototype as a question rather than a demo of an answer — the goal is to be proven wrong quickly, not to be admired. A product owner who walks out of a prototype review with a list of things that surprised them has done the job. One who walks out only with applause has learned nothing.

The real change

The shift from eliciting requirements to prototyping them is often described as a change in tools, but it is really a change in epistemology — in how an organization believes it comes to know what to build. The old model held that requirements exist in stakeholders’ heads and the job is to extract them. The new one holds that requirements are largely discovered, not extracted: they come into focus only when there is something concrete to react to, and the fastest path to a real requirement is to build the cheapest thing that provokes a real reaction.

This does not mean stop listening. It means change what you are listening to — from what people say they want, which is a guess, to what they do when they see something, which is evidence. For product owners and managers, that is the whole shift in a sentence: the job is no longer to capture requirements, but to design the fastest experiment that reveals them.