Product Requirements Template: The PM's Framework for Writing Specs That Get Built

You wrote a requirements document. You made a beautiful Notion page with sections, icons, and color-coded priority labels. You shared it in Slack. Three engineers looked at it once, never opened it again, and asked you seventeen questions in the kickoff meeting.

That's not a team problem. That's a template problem.

The average PM spends 4-6 hours writing a product requirements document that the team treats like a suggestion box. The spec gets written before the problem is fully understood, organized around features instead of outcomes, and formatted in a way that makes it easier to ignore than to use.

Product requirements don't have to live this way. A well-structured requirements template is a decision-making tool, not a documentation exercise. When written correctly, it replaces the kickoff meeting, answers the questions before they're asked, and gives every stakeholder — engineer, designer, executive — the same frame of reference.

This is the template I use. It's not fancy. It's just specific enough that a team can start building without a PM in the room.

Why Most Requirements Templates Fail

Before the template, here's what's actually going wrong. Most requirements documents fail for one of three reasons:

The spec is written in solution language, not problem language. "The user clicks the button and sees a list" describes the mechanism, not the user need. The team can't evaluate whether the mechanism is right if they don't know what problem it's solving. Engineers end up building the button instead of solving the problem behind it.

The spec covers the happy path and nothing else. The main user flow gets three paragraphs. The error states, the empty states, the "what if they do this weird thing that nobody does except our power users" get a one-line note: "handle edge cases." Those edge cases are where most bugs live.

The spec is too long to read and too short to be useful. Thirty pages of bullet points with no hierarchy is not thorough. It's disorganized. Engineers don't read it because the cost of reading it exceeds the value of the answers they get from it.

The fix for all three is the same: write for the decision, not for the document. Every section in this template answers one question the team needs answered before they can make a choice. Nothing else goes in.

The 6 Non-Negotiable Elements of Every Good Spec

Every product requirements document your team writes should contain these six sections. Not optional. Not "if you have time." These are the minimum viable spec:

1. Context: Why this, why now

Two to four sentences. The problem you're solving, the evidence that it matters, and why you're solving it now rather than next quarter. Include a link to the discovery work — user interviews, data, or prior research that produced this decision. If you can't explain why you're building this in four sentences, you don't understand the problem well enough to write the spec yet.

2. User story: Who, what, why

Use the format: "As a [type of user], I want to [action], so that [outcome]." One primary user story, two to three supporting scenarios. Avoid persona placeholders — write about a real person with a real job to do. If you can't write a real user story, you haven't done enough discovery. User interview synthesis and continuous discovery practice are where these come from.

3. Acceptance criteria: What "done" actually means

Format: "Given [condition], when [action], then [result]." Each criterion is testable. Not "the system should be fast" but "the page loads in under 2 seconds on a 3G connection." Not "the user should be notified" but "the user receives a push notification within 30 seconds of the event, unless they've disabled permissions." The engineers should be able to write unit tests from these criteria without asking follow-up questions.

For the specific brief format that engineering can reference at sprint start — not just at kickoff — see the 5-component brief structure that focuses on constraints, success criteria, and explicit out-of-scope definitions.

4. Edge cases and their handling

What happens when things go wrong. Network failure mid-action. Partial data state. User lacks required permissions. A competitor changes their API. Empty states, error states, and the worst-case flows that nobody wants to think about but everyone experiences in production. List at least five edge cases per feature. If you're struggling to find five, ask the engineer on your team — they already know where the landmines are.

5. Dependencies and constraints

What does this feature need from other teams, systems, or timelines to be built correctly? API availability from engineering, legal sign-off on copy, design system components that may or may not exist, data that doesn't exist yet. Label each dependency as "blocked" (can't start without it), "needed by" (can start, must be delivered by date X), or "nice to have" (degrades gracefully if missing). Ambiguous dependencies become scope fights later.

6. Success metrics: How you know it worked

What does success look like in data? Define the primary metric — the one number that tells you whether this feature solved the problem it was built to solve. Define a secondary metric that acts as a guardrail (what you watch to make sure you're not breaking something else). Include the baseline: where these numbers are today. If you can't define a success metric for a feature, question whether the feature is the right thing to build.

The Product Requirements Template

Copy this structure for every feature you spec. Replace the prompts with your specific context. Keep it under 1,500 words per feature — if you're writing more than that, you've probably merged two features into one document.

Problem: [One sentence. What user problem does this solve?]

Evidence: [Link to discovery artifact, data, or research that
 validates this is the right problem to solve.]

Why now: [What changed — new data, strategic shift, customer
 signal — that makes this the right time to solve it?]

Owner: [PM name]
Last updated: [Date]

As a [user type], I want to [specific action], so that
[measurable outcome].

Primary scenario: [Walk through the main user flow step by step]
Alternative scenario 1: [What if the user takes a different path?]
Alternative scenario 2: [What if the user tries to do the same
thing but their context is different?]

Given [condition], when [action], then [result].

1. Given [ ], when [ ], then [ ].
2. Given [ ], when [ ], then [ ].
3. Given [ ], when [ ], then [ ].
4. Given [ ], when [ ], then [ ].
5. Given [ ], when [ ], then [ ].

1. [Edge case]: [How the system handles it]
2. [Edge case]: [How the system handles it]
3. [Edge case]: [How the system handles it]
4. [Edge case]: [How the system handles it]
5. [Edge case]: [How the system handles it]

Unknown edge cases: [Any states you know exist but can't
fully specify — flag these explicitly rather than ignoring them]

Team dependency: [Team name] | [What's needed] | [Status: blocked/needed-by/nice-to-have]
System dependency: [System name] | [What's needed] | [Status]
Legal/Compliance: [Any sign-offs required] | [Status]
Design system: [Any components needed] | [Available: yes/no/partially]

Constraint: [Any hard technical, legal, or business constraints
that limit the solution space]

Primary metric: [The one number that tells you this worked]
  - Baseline: [Current value]
  - Target: [What success looks like]
  - Measurement method: [How you get this number]

Secondary metric (guardrail): [The one number that tells you
you didn't break something else]
  - Baseline: [Current value]
  - Alert threshold: [Where you'd pause and investigate]

Measurement window: [How long you'll measure before declaring
success or failure — typically 2-4 weeks post-launch]

Real Example: Notification Permission Request

Here's this template in action — a real feature spec for a mobile app's notification permission flow. The pattern holds for any product area.

This is what "good spec" looks like: specific enough to test, short enough to read, and structured so that every reviewer knows exactly what they're evaluating. You can copy the format, replace the content, and ship a spec in 45 minutes instead of three hours.

Five Mistakes That Make Specs Useless

1. Writing specs for features instead of problems

The spec should answer "why are we building this?" before it answers "what are we building?" If the context section doesn't explain the user problem with evidence, the team has no frame for evaluating whether the solution is right. Sprint planning starts with the problem, not the ticket — the spec is where that discipline lives.

2. Filling every section with placeholder content

Spec sections that say "TBD" or "see with engineering" with no plan to resolve that are worse than empty sections. Empty means the team knows it's unresolved. "TBD" with no owner and no date implies false confidence. If a section is unresolved, name that in the spec: "Open: need legal review of notification copy before this can be finalized."

3. Writing acceptance criteria as goals, not tests

"The user should have a great experience" is not an acceptance criterion. "The page should be fast" is not an acceptance criterion. The test for an acceptance criterion: can a QA engineer write a test that passes or fails based on this criterion without calling the PM? If the answer is no, it's not a criterion — it's a vibe. Convert it to a number.

4. Spec-ing the solution instead of the outcome

When you write "the system sends an email" instead of "the user receives a reminder 24 hours before their appointment," you're making an implementation decision that might be wrong. Let the engineers own the mechanism; you own the outcome. If the outcome is "user receives a reminder," the implementation might be email, push notification, or in-app alert — and the right choice depends on context you may not have.

5. Never updating the spec after kickoff

Discovery happens before spec writing. Implementation happens after kickoff. But things change: new data arrives, engineering finds a better approach, a dependency slips. The spec is a living document — if it's not updated when the context changes, it's lying to everyone who reads it. Treat an outdated spec as a bug in your process, not a documentation problem.

The 20-Minute Editing Rule That Fixes Everything

After writing your first draft, do this before sharing it with anyone:

Set a timer for 20 minutes. Read your spec as if you are a senior engineer on your team who has 40 other tickets in their queue. Ask yourself:

• Can I understand the problem in 30 seconds? If not, the context is too thin.
• Are the acceptance criteria testable? Can I write a failing test for each one? If not, they're goals, not criteria.
• Have I covered the five most likely failure modes? If not, the edge case section needs work.
• Are there any "TBD" items with no owner or date attached? Those are landmines — move them to a dependency table or resolve them before publishing.
• Is there anything in this spec that is my job to decide but isn't my job to implement? If yes, leave it in the spec as a constraint, not a directive.

This 20-minute edit is the difference between a spec that gets read and one that gets forwarded into a Slack thread for "PM to clarify." It's not extra work — it's the work. The first draft is thinking. The edit is communication.