writing-prds

Writing PRDs

Scope

Covers

• Turning a product idea into a decision-ready PRD with unambiguous scope, requirements, and success metrics
• Optionally producing a PR/FAQ (press release + FAQ) to force customer-centric narrative first
• For AI features: adding a Prompt Set + Eval Spec so “requirements” are testable and continuously checkable

When to use

• “Write a PRD / product spec / requirements doc for this feature.”
• “Turn these messy notes into a PRD we can align on.”
• “Create a PR/FAQ and then a PRD.”
• “This is an AI feature; I need evals + prompts to define behavior.”

When NOT to use

• You’re still choosing what strategy/market to pursue (do product vision / strategy first)
• You need discovery from scratch (research plan, problem validation) more than requirements -> use problem-definition
• You need a detailed engineering design doc (APIs, schemas, low-level architecture)
• You’re prioritizing among many initiatives -> use working-backwards or roadmap prioritization first
• You need build-ready interaction specs, user flows, or prototype briefs -> use writing-specs-designs
• You need to define or refresh the success metric / North Star before writing requirements -> use writing-north-star-metrics

Inputs

Minimum required

• Product + target user/customer segment
• Problem statement + why now (what changed, what’s broken, or what opportunity exists)
• Goal(s) + non-goal(s) + key constraints (timeline, policy/legal, platform, dependencies)
• Success metric(s) + 2–5 guardrails (quality, safety, cost, latency, trust)

If it’s an AI feature (additionally)

• What the model/system should do vs must never do (policy + safety)
• Concrete examples of desired and undesired outputs
• How correctness will be evaluated (offline tests, human review, online metrics)

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md.
• If answers are still missing, proceed with clearly labeled assumptions and provide 2–3 options (scope, metric, rollout).