0→1 New Product PRD Template

A 0→1 PRD argues for spending real time and money to find out whether a product that does not exist yet is real. Most of what is in it is a hypothesis, not a fact, and the document should read that way — specific about what would prove it wrong, not just what would prove it right.

When you need one

Write one when you are proposing a product that does not exist yet: a new surface, a new business line, a spinout. If the work is an addition to a product with existing users, the Standard PRD template is the right shape — this one carries market-sizing and kill-criteria sections that do not apply once you already have a metric to move. The signal: if you cannot point at an existing number this work would change, you are proposing something new enough for this template.

The template

# [Product name] — 0→1 PRD
Owner: [name] · Status: [draft/review/approved] · Last updated: [date]

## TL;DR
[2-3 sentences: what this product is, who it is for, why now.]

## Why now
[The market, technology, or organizational shift that makes this the right time — not "we think it's a good idea."]

## Target customer
[The specific first customer segment — not "everyone who has this problem."]

## Problem & evidence
[The problem this customer has today, and the evidence it is real: interviews, existing workarounds, spend.]

## Market & competitive landscape
[Who else solves this today, including "nothing" and "manual workarounds." Why existing options fall short.]

## Riskiest assumptions
- [The assumption that kills this bet if wrong, and how you will test it.]
- [The assumption that kills this bet if wrong, and how you will test it.]

## Strategic alternatives
| Option | What it costs | What we learn | Decision |
| --- | --- | --- | --- |
| Build | | | |
| Partner | | | |
| Acquire | | | |
| Don't build | | | |

## MVP scope
In scope: [the smallest version that tests the riskiest assumption]
Out of scope: [everything else, explicitly]

## Technical feasibility
[The build approach, and anything that could make this materially harder or slower than assumed.]

## Success criteria
[The signal that says keep going — a metric, a threshold, a date.]

## Kill criteria
[The signal that says stop, stated as specifically as success criteria — not "if it doesn't work out."]

## Go-to-market motion
[How the first customers find this, one paragraph — link the full Go-to-Market Strategy for the real plan.]

## Resourcing & team
[Who is on this, full-time or borrowed, and for how long before the next checkpoint.]

## Risks
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| [risk] | [H/M/L] | [impact] | [mitigation] |

## Open questions
- [Question] — Owner: [name] — Needed by: [date]

Section by section

TL;DR and why now

TL;DR states the bet; "why now" states the forcing function. Without it, a reader assumes this could have been proposed any time in the last three years.

Target customer and problem & evidence

The narrower the first customer, the more useful this section is. A 0→1 PRD written for "everyone" is a PRD for no one, and it usually means the evidence underneath is thin.

Market & competitive landscape

A reviewer asks this whether you answer it or not: who else has tried this, and why didn't it work for them.

Riskiest assumptions and strategic alternatives

This is the section a 0→1 PRD lives or dies on. Everything else is downstream of whether these assumptions survive contact with a real customer.

MVP scope and technical feasibility

MVP scope is a bet-testing instrument, not a smaller product. Feasibility tells you whether the bet can actually be tested in the time you have.

Success criteria and kill criteria

Success criteria without kill criteria is optimism with a due date. A bet that can never fail on paper is not being tested, it is being justified.

Go-to-market motion and resourcing & team

Two paragraphs, not a plan — the full plan belongs in its own document once this bet is funded.

Risks and open questions

The risks a reviewer has not already guessed are the ones worth writing down.

Worked example

Here are two sections from an analytics company proposing a standalone alerting product for its existing customer base.

Riskiest assumptions

• Customers who already use our dashboards will set up alerts inside a new, separate product rather than requesting the feature inside the tool they already have open daily. Test: a landing page and waitlist pitched inside the existing product, measured against a 15% signup benchmark from a comparable past launch.
• Alerting is valuable enough on its own that customers will pay an incremental fee, rather than expecting it bundled into their existing plan. Test: a paid pilot with 10 existing customers at a real price point, not a survey asking whether they would pay.

Strategic alternatives

| Option | What it costs | What we learn | Decision | | --- | --- | --- | --- | | Build as a new product | 2 eng, 1 quarter | Whether this stands on its own, and whether customers accept a second surface | Chosen — tests both assumptions above | | Build as a feature in the existing product | 1 eng, 3 weeks | Whether customers want alerting at all | Rejected — skips the harder assumption | | Partner with an existing alerting tool | Integration only | Whether demand exists | Rejected — tells us nothing about whether we can own this |

Both sections do what a reviewer wants: each assumption is falsifiable, and the alternatives table shows the recommended option was chosen for what it teaches, not just what it costs.

The deliberate weakness: the second assumption's test — "a paid pilot at a real price point" — never names the price, and price sensitivity is usually the actual crux of a bundling-versus-standalone bet. A reviewer will ask what price was tested, because the result means something different at $10 a month than at $200. The honest fix: [TBD: pilot price $49/month, the midpoint between our current per-seat add-on and the standalone tools customers already evaluate, confirm with 3 pilot customers by 20 Aug]. Naming the number is what makes the pilot's result mean something afterward.

Common mistakes

• A market-sizing claim with no first customer named. TAM without a specific, findable first buyer is a number nobody can act on.
• Riskiest assumptions that are already proven. If you already know the answer, it is not the risk. Look for the one that would genuinely surprise the team if it failed.
• No kill criteria, only success criteria. A bet that can only succeed on paper never gets the resourcing pulled when it should.
• MVP scope padded with features that do not test the risky assumption. Every line should exist to answer a specific open question, not to make v1 feel more complete.
• Resourcing with roles but no names. A bet nobody has actually been assigned to full-time loses every prioritization fight against shipped-product work.

Run it through a review

A 0→1 PRD gets the same eleven passes as any other draft, and the domain-gap check tends to do more work here than usual — Thinkr's critique does not soften the bar because the product doesn't exist yet. An unproven bet is exactly where a missing kill criterion costs the most.