The PRD Collapsed Into Three Artifacts (Brief, Prototype, Eval)

A prototype is not a replacement for the PRD. It is one third of it. Here is the whole workflow, what each piece is responsible for, and the templates to run it tomorrow.

The short version

The PRD did not die, it collapsed. The single document was doing three jobs at once, alignment, commitment, and memory, and it did all three badly because a wall of prose is the wrong format for every one of them. Those jobs now split into three artifacts, each better at one job than the old document was at all three. Alignment moves to a prototype (a working render aligns a team faster than a spec they have to interpret). Commitment moves to an eval (a rule you can run, that fails the build, instead of a sentence nobody rereads). Memory moves to a one-page brief plus the eval's rationale (a document you reread is memory, a document you do not is an archive). I posted a version of this and twenty-one PMs pushed back. Under all of it were only four objections, and the answer to each is one of these three artifacts. The templates are below, and they are copy-paste. This is the same shift behind prototype-first development and the outcome-driven build loop.

Six months ago I wrote my last twelve-page PRD. Two engineers read it. One asked me to just show him what I meant. I built it in forty-five minutes, and they shipped it in a week.

I posted that. It drew twenty-one comments and the debate is still going, and almost all of it came down to one fear: if you drop the PRD, you drop the business context, the commitment, the memory, and the reason the product exists. That fear is correct. It is also aimed at the wrong target.

The PRD did not die. It collapsed. The single document split into three artifacts, each better at one job than the old document was at all three. If you only keep the prototype, the critics are right and you lost something real. The answer is not to bring the twelve pages back. It is to see clearly what the other two artifacts are, and to use all three on purpose.

This is the exact stack I run to build Falkster.AI. Here is how it works, end to end.

The frame the thread converged on

The most useful comment in the thread came from Artem Ermakov, who named the thing precisely: the PRD did three jobs at once, alignment, commitment, and memory, and a prototype nails alignment while quietly dropping the other two.

That is exactly right, and it is the whole key. Alignment was only ever one of the three jobs. The mistake is assuming the other two need twelve pages. They do not. They need a different format each.

• Alignment: getting the team to a shared picture of what we are building.
• Commitment: the obligations we are on the hook for. Regulatory, contractual, SLA, and business rules.
• Memory: why we built it this way, so future iterations do not drift from the original problem.

Watch where each job actually goes now.

Alignment moves to the prototype. Akshay Vashishtha put the mechanism better than I did: when the ambiguity is about flow or interaction, prose is a lossy format. Every reader renders a different picture in their head. The prototype is the shared render, and it removes ten rounds of interpretation. Bharat Maddali argued that if engineers build the wrong thing the team is not asking enough. Sometimes. More often the spec was ambiguous enough that "what was asked" and "what was meant" were two different documents. That gap is what the prototype closes.

Commitment moves to the eval. Prose commitment rots, because nobody reruns a paragraph. An eval is commitment you can run. A regulatory or SLA obligation becomes a check that fails the build, not a sentence buried on page seven that nobody rereads.

Memory moves to the brief and to the eval's rationale. The strategic why lives on a one-page brief. The per-rule why lives as a comment on the eval it justifies, versioned with it, and read every single time that check fails.

So the stack is a one-page brief, a prototype, and an eval. Jim Mandas summed the whole thesis in one line in the thread: the PRD now is a one-page document, a prototype, and an eval. That is it. Nothing important got thrown away. It got relocated to a place where it stays true.

Under twenty-one comments there were only four real objections. Here is each one, and the same answer every time.

Objection 1: "Where does the business why go?"

This was the most common worry, raised by Fabien Cardineau, Kevin Sebastian, Will Meurer, David Koscinski, and Sam Crewe in different words. Fabien's version was the sharpest: dropping the PRD for a prototype is like an architect handing over only a rendering. A PRD anchors the product in the why and the context, disambiguates, highlights risks, and carries the commercial thesis and the support plan. Kevin asked how a prototype explains business case, problem severity, and economic impact. It does not, and it should not try.

All of that is real, and none of it needs twelve pages. The why, the user, the risks, the commercial thesis, and the one metric that says you won fit on a single page. That page is the anchor. Everything past it was documenting the solution, and the solution now lives in the prototype.

David Koscinski made the strongest version of this: when the cost of code approaches zero, the persistent value is the PRD, or rather the primary research the PRD captured. One correction. The persistent value is the research and the eval, not the prose that wrapped them. The durable asset is the problem understanding and the tests. That is a page and a test suite, not a chapter.

The one-page brief template is below. It is the architect's brief, not the rendering. Keep the anchor, cut the ballast.

Objection 2: "Where do the commitments and non-functional rules go?"

Alex Polivany put it plainly: give me the prototype, not a document, but non-functional requirements and business rules get missed in vibe-coded prototypes. He is right that they get missed. The fix is not to write them back into prose that nobody reruns. It is to encode them as evals so a prototype cannot pass without honoring them.

This is the job prose was worst at. A paragraph that says "p95 latency must stay under 200ms" is a hope. An eval that fails the build when p95 crosses 200ms is a commitment. A GDPR data-residency clause written on page nine is a liability waiting to be forgotten. The same clause as a guardrail eval blocks any build that routes EU data to a US endpoint. Ed Biden noted you cannot put a launch plan in a prototype, which is true: the launch plan lives in the release evals and a short GTM checklist, not in the prototype and not in twelve pages.

A document describes the rule. An eval enforces it. If it matters, it fails the build. The eval template below has three flavors, outcome, guardrail, and regression, that cover everything prose used to promise and never enforce.

Objection 3: "What preserves memory, and what stops drift?"

This is the objection that lurkers nod along to, and it came in two forms.

The first is Maksim Evdokimov's: in a few months or years the dev team changes, and there is nothing left but rumors of a great prototype. Sam Crewe's version was that the PRD is the document you refer back to so future iterations do not drift, and that a prototype-first generation will produce products that forget their own purpose.

They are describing a real risk and reaching for the wrong guardrail. A twelve-page PRD that nobody reopens cannot stop a product from forgetting its purpose, because a document that is not reread is not memory. It is an archive. The thing that actually prevents veering is the artifact you return to. A one-page problem brief gets reread where twelve pages do not, and an outcome eval encodes the original bet so drift fails the build the moment it happens, instead of being noticed in hindsight by whoever eventually rereads the doc. When the team turns over, the brief still states the bet and the evals still run, each carrying its own rationale. That is more durable memory than prose rotting on a wiki, because the eval is load-bearing and the wiki page is not.

The second form was Artem Ermakov's follow-up, and it was the best challenge in the thread. Where does the eval come from? Someone has to state the rule first. Prose and eval are source and compiled artifact, you need both, and deleting the source is how systems become unexplainable.

I concede the substance and then hold him to his own analogy. Source code does not keep its rationale in a separate specification document. It keeps it inline, as comments and commit history, next to the line it explains. The "why 200ms, because the contract says so" belongs as a docstring on the check, colocated and versioned with it, read every single time that check fails. You are not deleting the source. You are relocating it from a document three directories away, where it rots, to the line it justifies, where it cannot. Rot is a function of distance from the code, not of being prose. This is also Matthew Voshell's unsolved problem, keeping a story map linked to code so it is not outdated in minutes. The answer is not a hand-maintained map. It is an eval suite that lives next to the code and fails when reality drifts from intent. Keep the contract executable.

Objection 4: "A prototype alone loses too much."

Correct. That is why the stack is a brief plus an eval plus a prototype, not a prototype alone. Almost everyone arguing this was arguing against a claim I did not make.

The sharpest test came from Michael Kozloff, who was not theorizing: he spent two months on a full-stack prototype and his engineers still built only half of it in six months. Real counter-evidence, and worth answering directly. The gap there is not the prototype. It is that the prototype had no eval attached. A prototype says what to build. It does not say when you are done, and it cannot hold a team to a definition of done across six months. An eval does both. Attach the acceptance criteria as evals and "they built half of it" becomes "the build passes or it does not."

Two commenters made the point that this frame depends on. Naman Garg and David C. Holley both landed on the same thing: fall in love with the problem, not the solution, and understanding matters first and always. Agreed completely, and nothing forces understanding faster than having to build the thing. A prototype is understanding made testable. If you cannot prototype it, you have not defined it yet, and no amount of prose will save you.

And on the priming point, Tim Haines and Mathivathan V. are right that writing something down, even briefly, organizes your thoughts and helps the AI understand what to build. The key word is briefly. The one-pager that primes the model, plus the prompts and the paths you rejected, is the surviving artifact. Kedar Prabhu drew the exact line: align on goals and outcomes, not on design and features. A prototype plus a one-line success metric beats a feature spec.

Now the templates.

Template 1: The One-Page Brief

This carries the business context and the memory of purpose. It is the thing you reread at every major decision, which is the whole point. A document you reread is memory. A document you do not is an archive. This is the answer to Objection 1.

# [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
The outcome we believe this produces. One sentence.
"If we do this, then [measurable change]."

## Success metric
The one number that tells us we won. 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).

Rule: one page, hard cap. If it does not fit on a page, you are describing the solution. The solution belongs in the prototype, not here.

Template 2: The Prototype

This carries the solution. It is also the least valuable artifact of the three, and that is by design. Its job is to align the team, then to be rebuilt properly. Do not fall in love with the prototype. Fall in love with the problem. This is the answer to Objection 4, and to Akshay's point about flow ambiguity.

Here is how to brief it so you get an aligning prototype instead of a demo. If you want the full minute-by-minute version, I wrote it up in how to build a working prototype in 60 minutes.

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.

Rule: 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.

Template 3: The Eval

This carries commitment and memory, the two jobs a prototype cannot do. It is the answer to Objections 2 and 3, and to Michael Kozloff's "they built half of it." Three kinds of eval cover the three things prose used to promise and never enforced.

1. Outcome evals: does the behavior actually move the success metric from the brief. This is the anti-drift check.
2. Guardrail evals: the commitments. Regulatory, SLA, contractual, and business rules. These fail the build.
3. Regression evals: the rules we already decided, so a future change cannot quietly break them.

The template below has one feature that matters more than the rest, and it is the direct answer to Artem's compiler challenge: the rationale lives next to the check.

# 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. Do not delete it.]
# 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

Rule: the rationale lives here, in version control, next to the check it explains. Not in a separate document three directories away that may or may not have been updated. 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

1. Write the brief first. One page. Get the problem and the bet right before anything else exists. If you cannot write the brief, you do not understand the problem yet, and no prototype will save you.
2. Prototype the solution. Use the brief as context. Build the core flow, make it clickable, and put it in front of the team. This is your alignment, and it is faster than any spec.
3. Extract the commitments into evals. As the team aligns on the prototype, every rule, obligation, and success criterion becomes an eval with its rationale attached.
4. Build against the evals. Engineers build the real thing. The evals tell them when they are done, and hold them there. This is the step that turns "they built half of it" into "the build passes or it does not."
5. Reread the brief at every major decision. It is one page. There is no excuse. This is the thing that stops a product from forgetting its original purpose.

The objection map

Twenty-one PMs, four objections, one frame. If you take nothing else, take this map.

1. "Where does the business why go?" The one-page brief.
2. "Where do commitments and non-functional rules go?" Evals that fail the build.
3. "What preserves memory and prevents drift?" A brief you reread, plus evals that carry their own rationale, colocated with the code.
4. "A prototype alone loses too much." Correct, which is why it is brief plus eval plus prototype, not prototype alone.

The bottom line

The people afraid of dropping the PRD are protecting something worth protecting: the business context, the commitments, and the memory. They are right that a lone prototype throws all of it away. They are wrong that the twelve-page document was ever the thing keeping it safe. It was the thing letting it rot quietly, in a file nobody reopened.

Keep the thinking. Kill the artifact. Replace it with a page you reread, a prototype you throw away, and evals you can run.

That is the workflow. The three templates above are copy-paste. Pick your next feature and run it: write the one page first, prototype second, encode the commitments third. Steal it.

With thanks to the twenty-one PMs who argued this out in the comments, especially Artem Ermakov, Fabien Cardineau, Alex Polivany, Maksim Evdokimov, Michael Kozloff, Akshay Vashishtha, David Koscinski, and Sam Crewe, whose objections shaped this piece.