What requirements are and why they matter
Requirements are the translation layer between "what we want to achieve" and "what we need to build." They bridge the gap between product strategy (why and what) and engineering execution (how). Done well, requirements give engineers enough context to make good decisions without prescribing every implementation detail. Done badly, they create either confusion (too vague) or resentment (too prescriptive).
The format matters less than the content. Whether you write user stories, PRDs, one-pagers, or RFCs, the essential information is the same: who is this for, what problem does it solve, what does success look like, and what are the constraints? The right format depends on your team's culture, the initiative's complexity, and how much shared context already exists.
The biggest requirement mistake isn't choosing the wrong format — it's writing requirements too late. Requirements written after design is complete are documentation, not specification. They should be written early enough to shape design and engineering decisions, not just record them.
Why this matters for your projects
The cost of ambiguity in requirements compounds through the entire build process. An unclear requirement leads to a design assumption, which leads to an engineering interpretation, which leads to a QA question, which leads to a rework cycle. One clear sentence in the spec can prevent a week of back-and-forth during implementation. Requirements aren't bureaucracy — they're the cheapest form of quality assurance.
The specification spectrum
Requirements exist on a spectrum from lightweight to heavyweight. The right position depends on three factors: team maturity (experienced teams need less specification), initiative risk (high-stakes work needs more), and shared context (teams that recently did discovery together need less written down).
Lightweight (1-pager, bullet points): For small features, experienced teams, or when discovery just happened and context is fresh. Takes 30 minutes to write.
Medium (user stories + acceptance criteria): For standard features with clear scope. Takes 1–2 hours. The default for most work.
Heavyweight (full PRD): For major features, cross-team initiatives, or when the team lacks shared context. Takes 4–8 hours. Use sparingly — heavyweight specs often go unread.
Requirements formats
User Stories (INVEST) Core Method
Use when: Breaking down a feature into implementable units for sprint planning. The default format for most agile teams.
A user story follows the format: As a [user type], I want to [action], so that [outcome]. The "so that" clause is the most important part — it provides the context engineers need to make implementation decisions. Without it, the story is just a feature request.
Good stories follow the INVEST criteria: Independent (can be built without other stories), Negotiable (details are open to discussion), Valuable (delivers user value, not just technical value), Estimable (team can roughly size it), Small (fits in one sprint), Testable (you can verify it works).
Practical tip
The story format isn't sacred — the context is. "As a marketing manager, I want to schedule reports, so that I don't have to manually run them every Monday morning" gives an engineer everything they need: the user (marketing manager, not admin), the action (schedule, not just generate), and the reason (avoiding manual work on Monday, which suggests weekly scheduling is the MVP, not arbitrary scheduling).
Acceptance Criteria (Given/When/Then) Core Method
Use when: You need to define what "done" looks like for a user story. Every story should have acceptance criteria — they're the contract between PM and engineering.
Acceptance criteria use the Given/When/Then format borrowed from Behavior-Driven Development:
Given [precondition — the starting state]
When [action — what the user does]
Then [outcome — what should happen]
Example: Given a marketing manager is on the Reports page, When they click "Schedule" and select "Weekly on Monday at 9am," Then the report runs automatically every Monday at 9am and is emailed to them.
Write 3–7 acceptance criteria per story. Include the happy path, at least one error case, and any edge cases that could cause confusion during implementation.
Common mistake
Writing acceptance criteria that describe the UI rather than the behavior. "Then a green success toast appears" is an implementation detail. "Then the user sees confirmation that the schedule was saved" describes the behavior and lets the designer and engineer decide how to show it.
PRD (Product Requirements Document) Heavyweight
Use when: A major initiative needs cross-team alignment, the problem is complex, or the team lacks shared context from recent discovery.
A PRD is a comprehensive document that captures the full context: problem, users, goals, solution, scope, metrics, and dependencies. It's not a spec for engineers — it's a shared understanding document for everyone involved.
One-Pager Lightweight
Use when: A small-to-medium initiative needs enough context to get started but doesn't warrant a full PRD. The 80/20 version of a PRD.
Edge Case Matrix Completeness Tool
Use when: A feature has complex state interactions, permission boundaries, or error conditions. The matrix prevents the "but what happens when..." conversations during code review.
List every relevant condition on one axis and every possible state on the other. Fill in what should happen at each intersection. Common dimensions: user role (admin, member, viewer), plan type (free, pro, enterprise), data state (empty, populated, error), connectivity (online, offline, slow), and platform (web, iOS, Android).
You don't need to fill in every cell — many combinations are irrelevant. But identifying which cells matter and explicitly documenting the expected behavior prevents ambiguity and reduces QA cycles.
Job Story Format Alternative
Use when: User stories feel too role-focused and you want to emphasize the situation and motivation instead.
When [situation], I want to [motivation], so I can [expected outcome].
"When I'm reviewing last week's metrics before the Monday standup, I want to see the key numbers at a glance without opening multiple reports, so I can identify issues in 2 minutes instead of 15." The situation provides context that "As a PM" doesn't — it tells the engineer when this feature matters and what constraints exist (Monday morning, time pressure, multiple reports).
Templates and checklists
- Problem statement links to discovery evidence (not just PM opinion)
- Success metrics defined with specific targets and counter-metrics
- User stories include "so that" context for every story
- Acceptance criteria cover happy path, error cases, and key edge cases
- Scope explicitly lists what's in AND what's out
- Empty states, loading states, and error states are specified
- Permission and role boundaries are documented
- Dependencies identified and owners confirmed
- Design links included (or design brief provided for the designer)
- Open questions are flagged honestly — don't pretend to have answers you don't
- The spec has been reviewed by at least one engineer before sprint planning
- All acceptance criteria pass
- Edge cases from the edge case matrix are handled
- Error states display appropriate messaging
- Empty states are designed and implemented
- Accessibility requirements met (keyboard nav, screen reader, contrast)
- Analytics events are instrumented per the tracking plan
- Feature is behind a feature flag (if applicable)
- Documentation updated (help center, API docs, changelog)
- Stakeholders notified per the communication plan
- Success metric is being tracked and baselined
Real-world examples
Case study
Amazon: The working-backwards press release
Amazon's product development process starts with a press release written before any code is written. The press release describes the product as if it's already launched: what it does, who it's for, why it matters, and a customer quote explaining the benefit. If the press release doesn't sound compelling, the product isn't worth building.
This format works because it forces PM clarity at the specification stage. You can't write a compelling press release for a vague initiative. "We're building a dashboard" produces a weak press release. "We're launching a tool that lets marketing teams see their campaign ROI in real time, eliminating the 3-day lag that currently delays budget decisions" produces a clear one — and the spec practically writes itself from there.
Case study
Basecamp: The "Shape Up" pitch
Basecamp's Shape Up methodology replaces PRDs with "pitches" — short documents that define the problem, the appetite (how much time the team should spend — 2 weeks or 6 weeks), the solution sketch (rough enough to leave room for implementation creativity), and the "rabbit holes" (potential complications that have been pre-addressed). Notably, pitches include "no-gos" — things the solution deliberately doesn't handle.
The pitch format trusts the implementation team to fill in details. It provides boundaries (appetite, scope, no-gos) without specifying every screen and interaction. This requires a mature team but produces faster, more creative implementation.
Case study
Stripe: RFC-driven development
Stripe uses RFCs (Request for Comments) for major technical and product decisions. An RFC proposes a specific approach, explains the alternatives considered, and invites feedback from anyone in the company. RFCs are living documents — they evolve through comments and revisions before a decision is finalized.
The RFC model works well for complex, cross-cutting initiatives where multiple teams need to align on approach. It's more heavyweight than a PRD but produces deeper alignment because the review process surfaces concerns that would otherwise emerge during implementation.
Common pitfalls
Spec as UI prescription
"Put a blue button in the top right corner that says 'Export'" is an implementation detail, not a requirement. "Users need to export their data in CSV format from the dashboard" is a requirement that gives the designer freedom to find the best solution. Specify the what and the why; let design and engineering handle the how.
The 50-page PRD nobody reads
If your spec is longer than 5 pages, most of it won't be read. Long PRDs feel thorough but they diffuse attention. The important decisions get buried among obvious details. If you need a long document, add an executive summary at the top with the 5 most important things. Better yet, break it into a one-pager for alignment and detailed stories for implementation.
Writing specs alone
Requirements written in isolation — PM writes, then throws over the wall to engineering — produce specs that miss technical constraints and design opportunities. The best specs are co-authored: PM provides the context and constraints, engineering flags feasibility issues and suggests alternatives, design identifies UX implications. A 30-minute spec review with the trio catches problems that would take a week to fix during implementation.
Forgetting the "out of scope" section
What you don't build is as important as what you do. Without explicit scope boundaries, well-intentioned engineers add "while I'm in there" improvements that expand scope, delay delivery, and muddy the success metric. "Out of scope: bulk scheduling, custom recurrence patterns, and calendar integration — all deferred to v2" prevents this.
When to use each format
Decision guidance
One-pager: Small features, bug fixes, improvements where the team has shared context. Enough to align on scope without over-documenting.
User stories + acceptance criteria: Standard features. The default for most work. Stories for sprint planning, AC for the definition of done.
Full PRD: Major features, cross-team initiatives, new product areas, or when the team is new and hasn't built shared context yet. Use sparingly.
RFC: Architectural decisions, platform changes, or initiatives that affect multiple teams. When you need cross-company feedback before committing.
Press release / pitch: New products, major pivots, or when you need to test whether the vision is compelling before investing in detailed specs.