A prototype is not a replacement for the PRD. It is one third of it. The PRD collapsed into three artifacts, each better at one job than the old document was at all three.
1. The one-page brief (memory)
This carries the business context and the memory of purpose. One page, hard cap. It is the thing you reread at every major decision, which is the whole point.
# [Product or Feature name]: One-Page Brief
Owner:
Date / version:
## Problem
Who has it, how often, and how much it costs them today. One paragraph. No solution language.
## Who it is for
The specific user or segment. If the answer is "everyone," you have not defined it.
## Why now
What changed that makes this worth building today and not last year.
## The bet
"If we do this, then [measurable change]." One sentence.
## Success metric
One primary metric, one guardrail metric. Not a list.
## Non-goals
What we are explicitly not doing, so scope does not creep silently.
## Open questions
What we do not know yet, and how we will resolve it (prototype, eval, or research).
2. The prototype (alignment)
This carries the solution. It is also the least valuable artifact of the three, by design: its job is to align the team, then be rebuilt properly. A working render aligns a team faster than a spec they have to interpret.
Build a working prototype that lets a user [core action].
Context: [paste the one-page brief]
Constraints:
- Real interactions, not screenshots. It must be clickable.
- Cover the happy path end to end, plus the two most likely failure paths.
- Do not build settings, auth, or edge cases yet. Align on the core flow first.
Success looks like: a teammate can use it without me narrating over their shoulder.
The prototype is disposable. The moment it has done its aligning job, its remaining value is close to zero. Keep the problem understanding. Throw the prototype away.
3. The eval (commitment and memory)
This carries the two jobs a prototype cannot do. Three kinds of eval cover the three things prose used to promise and never enforced: outcome evals (does the behavior move the success metric), guardrail evals (regulatory, SLA, contractual rules that fail the build), and regression evals (rules we already decided).
# Eval: [what it checks]
# Rule: [the invariant in plain language]
# Rationale: [why this rule, and why this threshold. "N ms, because X." This is the memory.]
# Owner / date:
# Violation: [what specifically counts as failing]
test:
given: [starting state]
when: [action]
then: [expected result or threshold]
on_fail: block # use "warn" for non-blocking guardrails
The rationale lives here, in version control, next to the check. When this eval blocks a change two years from now, the person staring at the failure reads why it exists in the same place they see it fail. That is memory that cannot drift, because it moves with the code.
The workflow, start to finish
Write the brief first. Prototype the solution using the brief as context. Extract the commitments into evals as the team aligns on the prototype. Build the real thing against the evals. Reread the brief at every major decision.
Five steps: brief, prototype, evals, build, reread. Keep the thinking. Kill the artifact. Pick your next feature and run it: write the one page first, prototype second, encode the commitments third.