Guide
How to Write a Product Plan
A practical, engineer-friendly product plan structure - problem, users, requirements, acceptance criteria, and risks - that stays short and stays testable.
A product plan (product requirements document) is the contract between intent and implementation. It answers a single question before any code is written: what does "done" look like, and how will we know? A good product plan is short, testable, and honest about what it excludes.
In an AI-assisted workflow the product plan matters more, not less. Coding agents will happily build whatever you describe - including your ambiguity. Vague requirements produce vague pull requests, and you pay for the round trip in review time and rework. The product plan is where you resolve ambiguity cheaply, in prose, before it becomes expensive to resolve in code.
This guide gives you a practical five-part structure - problem, users, requirements, acceptance criteria, risks - plus the discipline to keep each section tight. It is opinionated toward feature-level product plans an engineering team can actually read in one sitting.
State the problem before the solution
Open with the problem, not the feature. If you lead with "build a dashboard," you have already smuggled in a solution and skipped the reasoning. Lead instead with what is broken or missing today and what it costs.
- Current state: what happens now, concretely.
- Pain: who is blocked, slowed, or at risk - and why it matters now.
- Desired outcome: the change in behavior or metric you want, stated without prescribing implementation.
A useful test: could two reasonable engineers propose different solutions to this problem statement? If not, you have written a spec, not a problem. Keep the "why" separable from the "how" so the team can challenge the approach.
Name the users and their jobs
Requirements are meaningless without knowing whose requirements they are. Identify the specific users or personas and the job each is trying to get done. "Users" is not a persona; "an on-call engineer triaging a failed deploy at 2am" is.
- List each distinct user type and their primary job-to-be-done.
- Note the context they operate in - device, urgency, expertise, permissions.
- Call out non-users explicitly: who is this not for? Scope is defined as much by exclusion as inclusion.
For internal tooling, the "user" is often another engineer or team. Say so, and describe their workflow rather than assuming everyone shares your mental model.
Write requirements as testable statements
Requirements describe what the system must do, ordered by priority. Separate the mandatory from the nice-to-have - MoSCoW (Must / Should / Could / Won't) or a simple P0/P1/P2 both work. The "Won't" list is the most valuable and most often omitted.
- One requirement per line; if it contains "and," it is probably two.
- Prefer active, observable phrasing: "The system rejects uploads over 25MB with a clear error" beats "Handle large files gracefully."
- Distinguish functional requirements (behavior) from non-functional ones (latency, security, accessibility, cost).
Ambiguity here is the single biggest driver of rework. See our guide to generating product plans and the product plan generator for turning a rough problem into structured requirements fast.
Define acceptance criteria for every requirement
Acceptance criteria convert requirements into pass/fail checks. If a requirement has no acceptance criteria, it is not really a requirement - it is a hope. Write them in a form a reviewer, a test, or an agent can verify without asking you a follow-up question.
- Given / When / Then works well: "Given a logged-out user, when they submit the form, then they see a sign-in prompt and no data is saved."
- Cover the happy path and the obvious failure and edge cases - empty states, permissions, limits, concurrency.
- Make them measurable: exact copy, specific status codes, concrete thresholds.
Good criteria double as your test plan and your definition of done. Grade a draft with the acceptance criteria grader or generate a first pass with the acceptance criteria generator.
Surface risks, assumptions, and open questions
Every honest product plan ends with what could go wrong and what you are unsure about. Hiding risk does not remove it; it just moves discovery to production. Make three lists explicit:
- Risks: technical, security, performance, or product risks, each with a mitigation or a decision to accept it.
- Assumptions: things you believe are true but have not verified. When an assumption breaks, the product plan should break with it.
- Open questions: decisions still owed, with an owner and a date. An open question with no owner is a silent blocker.
This section is also where dependencies live - other teams, third-party APIs, feature flags, migrations. Naming them early is how you avoid the "we can't ship because of X" surprise a day before launch.
Keep it short, versioned, and close to the work
A product plan is a working document, not a monument. Favor one to two pages that people actually read over a comprehensive doc they skim. Structure beats prose - bullets, tables, and headings let readers scan for the part they own.
- Version it and note what changed; a stale product plan is worse than none.
- Link it from the tracking issue or PR so the requirements and the code stay in the same orbit.
- Delete resolved open questions rather than letting them accumulate as noise.
When you build with AI agents, feed the product plan in as context so generated code targets your acceptance criteria directly. Then close the loop by measuring what shipped against what you specified - see how FeatureFactory measures shipped work.