Document coach
Product Requirements Document
A PRD a stakeholder can challenge — evidence in, wishlist out.
Turn conviction about a feature into a document a team can execute and a skeptic can argue with. This guided PRD works the way a seasoned product lead reviews one: it demands evidence for the problem before any solution talk, makes you name who the feature is NOT for, pairs every goal with a non-goal of equal confidence, forces requirements into must/should/later with a test for each, and refuses to let "launch it" stand in for success. You end with the document that aligns a team on what to build and why — and, just as loudly, on what you are deliberately not building.
What this expert will cover
- 2 questions
Core Problem
working notesThe user problem this PRD exists to solve, held as one working claim — the note every scope debate returns to, never a section of the document. Complete means: the problem in a single solution-free sentence, plus the skeptical stakeholder the document must convince and what they currently believe instead.
- 3 questions
Problem & Evidence
The case for doing anything at all, made before any solution talk. Complete means: a falsifiable problem statement a reader could argue with, evidence with a named source (tickets, data, quoted users), and the cost of doing nothing.
- 3 questions
Target Users
A user definition with an outside. Complete means: who this is for, specifically enough that they would recognize themselves and the situation they are in; how they cope today; and who this is explicitly NOT for in this release.
- 2 questions
Goals & Non-Goals
The outcomes this ships for, paired with what it deliberately will not attempt. Complete means: user and business outcomes stated as changes in the world (not features shipped), and non-goals stated with the same confidence — each with a reason, so scope has a defense.
- 4 questions
Requirements
What is being built, then the prioritized, testable capabilities — not a wishlist and not a design doc. Complete means: a one-paragraph description of the thing as the user will encounter it, must-haves someone could verify from the outside, should/later items explicitly deferred, and acceptance tests for the must-haves. Capabilities, never implementation choices.
- 3 questions
Success Metrics
What success measurably means — and what must not get worse. Complete means: a primary metric with a number and a timeframe, a guardrail metric that must hold while you chase it, and a named check-in where a miss triggers a decision. "Launch it" is not a success metric.
- 2 questions
Risks & Open Questions
The honest ledger of what could sink this. Complete means: the riskiest assumption flagged explicitly — the belief that, if wrong, invalidates the whole effort — with the cheapest way to test it, plus the open questions that remain, each with an owner.
The kind of questions it asks
- Before the full case: what is the user problem this PRD exists to solve, in one solution-free sentence? This is the working claim we will hold every requirement and cut against — the Problem & Evidence section will make the argued case.
- State the problem in one or two sentences — without mentioning your solution. Make it falsifiable: a claim about users and their situation that a skeptical stakeholder could actually dispute.
- Who exactly is this for? Describe them in a recognizable situation — role, moment, trigger — not a demographic. "Support leads triaging a queue of 200+ tickets on Monday morning" is a user; "SMB customers" is a spreadsheet column.
Ready when you are.
Every answer inks the page in. Skip anything; return anytime.