Kill the PRD. The Prototype Is the Spec.

The PRD was a workaround.

It existed because engineering time was expensive, misunderstanding was expensive, and the cheapest way to reduce both was to front-load the thinking into a shared document. That document, passed from product to engineering, carried the context that would otherwise get lost in translation.

Every part of that premise has weakened. Engineering time is not cheap, but it's no longer the scarce resource. Misunderstanding has not disappeared, but its cost has been collapsed by the ability to just build the thing and see. The translation layer is automatable.

The PRD is a 2015 solution to a 2015 problem. Most product orgs still write them. Most product leaders still ask for them. Most candidates in PM interviews are asked to produce one. All of this is residual behavior.

This is the post where I make the case for killing it, and I tell you what to ship in its place.

The short version

The PRD is a 2015 solution to a 2015 problem. Three artifacts replace it. None of them are documents. A working prototype, built in Claude Code in four to six hours, real enough that a customer can use it for five minutes. An eval rubric, one page, three to five criteria scored 1-5 with at least 20 test cases. A one-page README with why, what, open questions, and links. Together they answer all five things the PRD used to contain. Done is when the rubric passes the threshold, not when the doc gets approved.

For more on the broader PM rebuild, see Kill the Feature Request Queue and Kill the OKR(coming May 13). For the role definition that ships prototypes instead of PRDs, see the PM Standard.

What the PRD was actually solving for

Before we kill something, it helps to name what it was doing. The PRD was a container for five things:

1. The problem statement. What customer need or business opportunity is this solving.
2. The proposed solution. What are we going to build, at a high level.
3. The scope boundaries. What's in, what's out, what's a future phase.
4. The success criteria. What does "done" mean, what does "working" mean.
5. The open questions. What we don't know yet, what could break the plan.

Good PRDs did all five well. Bad PRDs did one or two well. Most PRDs existed primarily so that a product leader could approve something without having to have a real conversation with the team.

Three of those five containers no longer need a document. Two of them still do, but not in PRD form.

The three artifacts that replace the PRD

In every team I've run or advised since 2024, the replacement is the same three artifacts. None of them is longer than a page. All three can be produced in under a day for a typical feature.

Artifact 1: The working prototype

This is the only artifact that is not optional. Before a build is funded, there's a working prototype.

The prototype answers three of the PRD's five containers at once. It demonstrates the problem (by being built for a specific user). It demonstrates the solution (it is the solution, in clickable form). And it collapses the scope boundary question, because the scope is whatever's in the prototype.

The prototype does not have to be production-quality. It has to be real enough that:

• A customer can use it for five minutes and give you feedback that isn't polite.
• An engineer can look at it and tell you what's hacky and what's load-bearing.
• A designer can tell you where the interaction is wrong.

In Claude Code or Cursor, the median time to this prototype is four to six hours. If it's taking longer, the prototype is probably trying to do too much, or the setup is wrong.

Artifact 2: The eval rubric

If the feature has any AI-driven behavior (and in 2026, most do), the rubric is the replacement for the "success criteria" section of the PRD.

A rubric is not prose. It's a scoring system, usually 1-5 on three to five criteria, applied to a set of test cases. A good rubric for a typical AI feature fits on one page and includes:

• Three to five criteria (correctness, completeness, tone, safety, whatever matters)
• A short description of what each score means on each criterion
• At least 20 test cases (happy path, edge cases, adversarial)
• A target threshold score for ship

The rubric is both the spec and the acceptance test. The engineering team doesn't need to ask "when is this done." Done is when the rubric passes on the threshold score.

For non-AI features, the equivalent is a short list of measurable outcomes with thresholds. "This flow should increase activation by X percentage points in a 10% test. Ship criteria: retention at 7 days does not decline."

Artifact 3: The README

One page. Maximum. This is where the remaining PRD-ish content lives.

What the README contains:

• Why. Two sentences. The customer problem or business opportunity.
• What it is. One paragraph. What the prototype actually does.
• Out of scope. Bullet list. What this does not do, and why.
• Open questions. Bullet list. What we don't know, with a specific person owning each question.
• Links. Prototype URL, rubric, any test data, any customer interviews.

That's it. The README is a navigation tool, not a plan. Anyone on the team should be able to read it in two minutes and know what the prototype is, what it's for, and what's uncertain.

What happens to the five PRD containers

Mapped to the three artifacts:

• Problem statement: lives in the README (two sentences) and is demonstrated by the prototype.
• Proposed solution: is the prototype.
• Scope boundaries: encoded in the prototype's actual surface area, plus an explicit "out of scope" list in the README.
• Success criteria: the eval rubric or the measurable outcomes list.
• Open questions: in the README, with specific owners and deadlines.

Nothing is lost. Everything the PRD tried to do is still done. It's just done in a form that's 10x faster to produce, 10x faster to consume, and substantially harder to fake.

The specific advantages over the PRD

When I run this model with teams, five things show up within a quarter.

1. Reviews get faster and better. A 20-page PRD takes 45 minutes to review and produces vague feedback. A prototype, a rubric, and a README take 15 minutes to review and produce specific feedback. The faster loop doesn't just save time, it raises the quality of the conversation.
2. Scope creep goes down. The prototype is a tangible scope boundary. You can't argue your way into expanding the scope without actually building the expanded scope, at which point the cost is in your face.
3. Engineering trust goes up. A prototype is a serious signal. A PRD is a document anyone can write. When a PM hands a prototype to engineering, engineering treats the work as seriously as the PM did. The trust dynamic changes.
4. Customer feedback happens earlier. It's much easier to put a prototype in front of a customer than a PRD. You don't walk them through a document. You hand them the thing. The feedback you get is specific and immediate.
5. Your hiring changes. PMs who can't prototype self-select out. PMs who can get promoted faster. This is uncomfortable in the short run and correct in the long run.

The specific objections, answered

"Our engineering team wants a PRD. They won't accept a prototype." Some will say that. Some will push back. In my experience, the engineers who push back hardest are the ones who've been burned by bad PMs shipping bad specs. A working prototype solves their problem better than a PRD does, and most of them figure this out within two ships. Give it a quarter.

"Our legal and compliance teams require documentation." They require documentation for compliance. They don't require PRDs. The README plus the rubric plus the prototype's changelog is more than enough documentation for any reasonable audit. Compliance lawyers don't want PRDs. They want a record of decisions, which the README provides.

"Our large enterprise customers require PRDs." A few do. Very few. When they do, you can produce one from the three artifacts in about 30 minutes using Claude. You do not need to write the PRD first.

"My team doesn't know how to prototype yet." Start them this week. The gap between "can't prototype" and "can prototype" is about two weeks of focused time with Claude Code. I've coached PMs through this transition personally, and the most skeptical ones are usually the fastest once they start.

The transition plan

If your org currently runs on PRDs, here's the move I'd make. It's not instant, and it's not painless.

Month 1: The parallel path

For every new feature starting this month, the owning PM produces both a PRD (because your org still expects one) and the three artifacts (because they're what actually work). Compare the two after each ship. In almost every case, the three artifacts will have carried the real decision-making and the PRD will have been backward-looking documentation.

Month 2: The pilot team

Pick one team. Declare that this team ships on the three artifacts only, no PRD required. Track their cycle time, their ship quality, and their engineering partner satisfaction. Publish the comparison internally.

Month 3: The policy change

Based on the pilot, change the policy. PRDs are optional. Three artifacts are required. New PMs are trained on the new model from day one.

By month six, the PRD is a legacy artifact in your org. Some teams still produce them out of habit. Some senior leaders still ask for them. The work, though, has moved to the three artifacts, and everyone who's been through the transition can articulate why.

The one case where the PRD is still right

I want to be honest about where this model breaks. There is one context where a PRD still works better than the three artifacts.

Large, long, multi-year, regulated initiatives. If you're building a new core banking system, or an FDA-regulated medical device, or a defense product, the regulatory and organizational requirements are such that you need a heavier document. The PRD, or more likely something meatier than a PRD, is still the right artifact.

If you're building a typical SaaS feature, an AI agent, a growth experiment, or anything that can be prototyped in under a week, the three artifacts are better. That's the vast majority of what product orgs do.

Where to start

Pick one feature in your current backlog. The smallest, simplest one. Before your team writes a PRD for it, do this instead:

1. In Claude Code, describe the feature and ask for a prototype. Give it the problem, the user, and the constraint. Ask for the prototype first, with a deploy URL.
2. Write a 10-line README. Why, what, out-of-scope, open questions. Fifteen minutes.
3. If it's AI-driven, write the rubric next. Five criteria, 20 test cases. One hour.
4. Share all three with your team instead of a PRD.

Watch what happens. In most cases, the review conversation is better than any PRD review you've been in. The prototype answers questions before they're asked. The rubric gives engineering a clear target. The README keeps the team oriented.

Do this three times. By the third one, you'll have a hard time going back to writing PRDs.

---

The three-artifact template is on the toolkit at falkster.com/toolkit. Fork it, ship it, never write another PRD.

Further reading

• Marty Cagan / SVPG on prototypes as the real requirements document
• Teresa Torres on why prototypes beat written specs for alignment
• John Cutler / Amplitude on the evolving role of PM artifacts
• Lenny Rachitsky on how modern teams replace the PRD