PRD Writing Rules

A PRD's job is to align a team on what to build and why before anyone writes code — not to document a decision that was already made in someone's head. If the problem section could be deleted without changing the solution section, the PRD hasn't done its job.

Problem before solution

• Open with the problem, stated in terms of user or business pain, before any mention of the proposed feature. If you can't state the problem in 2–3 sentences without referencing the solution, you don't understand it well enough to write the PRD yet.
• Include evidence for the problem — a metric, a support ticket pattern, a research finding, a competitive gap — not just an assertion that it exists. "Users are confused by X" needs a source; "Users are confused by X (42% of support tickets in Q2 reference X)" doesn't.
• State who has this problem specifically. "Users" is rarely the real answer — name the segment (new signups, enterprise admins, mobile-only users) so the solution can be scoped to them instead of everyone.

User stories with acceptance criteria

• Write each user story as "As a [specific role], I want [action], so that [outcome]" — the outcome clause is not optional decoration; it's what lets a reviewer catch a story that solves the wrong problem.
• Give every user story explicit, testable acceptance criteria (Given/When/Then or a plain checklist) — a story without acceptance criteria is a wish, not a requirement, and engineering will build to their own interpretation of "done."
• Order stories by priority, not by the order they occurred to you. The first few stories should be the ones that make the feature minimally viable; everything after is enhancement.

Non-goals

• Include an explicit "Non-goals" or "Out of scope" section listing things this PRD deliberately does NOT cover, even if they seem obviously related. This is the section that prevents silent scope creep and the "wait, doesn't this also need to handle Y" conversation three weeks into the build.
• Write non-goals as specific exclusions ("Does not support bulk import in this phase"), not vague hedges ("We're not trying to boil the ocean").

Success metrics

• Define how success will be measured before the feature ships, not after — a metric picked retroactively tends to be whichever number went up. State the specific metric, its current baseline, and the target.
• Distinguish leading indicators (usage in week 1) from lagging outcomes (retention at 90 days) and specify which one actually gates a launch decision versus which one is just monitored.
• Cap it at 2–4 metrics. A PRD with a dozen success metrics has no success metric — nobody can hold a launch accountable to twelve simultaneous targets.

Open questions

• Maintain an explicit "Open questions" section for anything unresolved at write time, each with an owner and, where possible, a date by which it needs an answer. An unresolved question left out of the document doesn't disappear — it just resurfaces mid-build as a surprise.
• Close out answered questions by moving the resolution into the relevant section and marking the question resolved, rather than deleting it silently — this keeps a visible record of what changed and why.

Keeping it short enough to be read

• Target a length that a busy engineer or stakeholder can read in one sitting without skimming — as a rule of thumb, if it doesn't fit on 2-3 screens without scrolling fatigue, cut supporting detail into an appendix or a linked doc.
• Push detailed edge-case handling, exhaustive error states, and implementation-level specifics into linked technical specs or the eventual engineering design doc — the PRD states what and why; a separate doc can carry the exhaustive how.
• Use bullets and tables over prose paragraphs wherever the content is inherently list-shaped (requirements, criteria, metrics) — a PRD that reads like an essay is optimized for the writer's process, not the reader's comprehension.

What to avoid

• Don't specify implementation details (which database, which library, which internal API) unless they're a genuine hard constraint — that's an engineering decision, and prescribing it in the PRD invites the team to build to the letter of your spec instead of the best solution to the problem.
• Don't write a PRD for a decision that's already fully made and non-negotiable — that's a spec announcement, not a requirements document, and dressing it up with a "Problem" section that nobody can actually influence wastes the team's time reviewing it.
• Don't let the PRD go stale after major decisions change mid-build — either update it and flag what changed, or it stops being a shared source of truth and becomes actively misleading.