A prototype is the best tool there is for discovering what people need — and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype’s learning survives; skip it, and you ship the mock-up’s accidents as if they were the plan.
An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react to something concrete far better than they can describe it in the abstract. That leaves a problem no one talks about. At the end of a good prototyping cycle you have a working prototype and a rich set of reactions — but a prototype is not a requirement. It is a user interface, full of specific choices, some of which encode a real need and some of which are just how you happened to mock it up. If you hand that prototype to a delivery team as “build this,” you ship both kinds of choice indiscriminately, and you lose the ability to say why any of it exists.
The step that closes the gap is reverse-engineering: working backward from each element of the prototype to the underlying requirement it serves, and recording that link. It is unglamorous, it takes a day or two, and it is the difference between a prototype that produced durable requirements and one that produced a pile of pixels no one can defend.
The trap: treating the prototype as the specification
The default move, once a prototype tests well, is to treat it as the spec. It feels efficient — the thing works, people liked it, just build it. But a prototype-as-spec carries three hidden defects.
It bakes in incidental choices as if they were requirements. A prototype is full of concrete decisions — a particular threshold, a particular routing rule, a particular screen layout — that were made to get something in front of people, not because the business decided they were correct. Handed to developers verbatim, those conveniences harden into requirements no one actually chose.
It loses the why. A prototype shows what, never why. Six months later, when someone asks why a feature behaves the way it does, the answer is “it was in the prototype,” which is not a reason. The need that justified it — and the person who voiced it — has been dropped.
And it produces no traceability. A prototype cannot tell you which business need each feature serves, whether every need is covered, or whether some feature serves no need at all. It is, by nature, untraceable — the opposite of what a program needs when it has to cut scope, defend a decision, or onboard a new team.
The reframe that makes it tractable
The insight that makes reverse-engineering straightforward is this: prototype features are almost always tactical implementations of strategic requirements that already exist. If the prototype was built on real discovery — real interviews, real observed needs — then most of what it contains is a delivery mechanism for a need you already captured somewhere. The prototype did not invent the requirement to coordinate across teams; it rendered one particular way of doing it. The requirement predates the mock-up.
That reframes the whole exercise. Reverse-engineering is not writing new requirements from the prototype; it is mapping each prototype element back to the requirement it implements, and flagging the small residue that genuinely is new. Most of the work is connection, not authorship — which is what makes it a day or two rather than a re-do.
The method
The mechanics are a mapping, one row per meaningful prototype element. For each feature, screen, or interaction in the prototype, you record: the capability and the process it implements; the source requirement it maps to — ideally the interview or observed need where that requirement was first voiced; a requirement identifier linking it into the traceability chain; and a short rationale naming the specific pain point it addresses and who raised it.
Worked through, a single prototype feature resolves into something like: this collaboration channel implements the cross-team coordination capability, in the opportunity process; it maps to the existing requirement for automated notification when a shared deal is created; it addresses the pain point a named role raised about losing hours a week to manual coordination. The feature is now anchored. It has a why, a source, and a place in the structure — none of which the prototype itself carried.
Where a prototype element maps cleanly to an existing requirement, you link it. Where it maps to a need you can see in your discovery notes but never formally captured, you write the requirement now and give it a provisional identifier. And where it maps to nothing — no requirement, no observed need — you have found something important, which the next section is about.
What the mapping catches
The reverse-engineering pass earns its keep through what it exposes, because the act of trying to connect every prototype element to a real need surfaces three things that were invisible while the prototype was just “the thing that tested well.”
It catches orphan features — prototype elements that map to no requirement at all. These are pure invention: something that seemed like a good idea while mocking up, that no stakeholder actually needs. Finding them forces the honest question of whether to keep them (and write the real requirement) or cut them before they consume build effort no one asked for.
It catches coverage gaps — requirements from discovery that the prototype never addressed. These are the needs you learned about but did not render, and they are easy to forget precisely because the prototype is so vivid that whatever it doesn’t show falls out of mind. The mapping makes the absence visible.
And it catches incidental choices masquerading as requirements — the threshold, the routing rule, the layout that ended up in the prototype as a convenience. The mapping forces you to ask, for each one, whether it reflects a real decision the business made or just how you happened to build the mock-up. That single question keeps a pile of accidental UI decisions from being enshrined as requirements the delivery team is now obligated to honour.
Why it matters
The deeper payoff is that reverse-engineering plugs the prototype into the traceability chain. Before the mapping, the prototype-elicited learning lives only in the prototype and in people’s memories of the demo. After it, that learning is a set of requirements with provenance — each one linked to a source need and buildable by a team that now understands what it is building and why. The delivery team builds the requirement, not the pixels; and when someone later asks why a feature exists, or whether a particular behaviour reflects a real need, the answer is on the record.
This is what lets prototyping and rigor coexist. You get the discovery power of putting something concrete in front of people, and you get the auditability of a traced requirement set — instead of trading one for the other, which is what happens when the prototype is either skipped or shipped raw.
The discipline
A few habits separate a reverse-engineering pass that works from one that goes through the motions. Do it while the reactions are fresh — the rationale for each element is only fully knowable right after the sessions, and it evaporates fast. Rigorously distinguish requirement from implementation; the whole value is in separating the need from the particular rendering, and it is tempting to blur them. Feed anything genuinely new back into the requirement set rather than leaving it stranded in the prototype. And resist the pull to just ship the mock-up because it tested well; the test told you the direction was right, not that every incidental choice in it was.
The real point
A prototype is a superb instrument for learning and a terrible medium for remembering. Its strength — that it is concrete, specific, and immediate — is exactly what makes it a bad record, because it cannot tell you which of its many specifics matter. Reverse-engineering is how you keep the learning and drop the accident: you walk backward from the thing people reacted to, connect every part of it to a real need or cut it, and end up with requirements a team can build and an organization can defend. The prototype got you the insight. This step is how you keep it.
