How to Write Product Requirements: A Field Guide for Product Managers
A field guide to the process of writing product requirements, organized by the six phases that show up in every cycle.
The classic tire-swing cartoon is funny because it's true: every step of the requirements process loses something. The customer described one thing, the project manager interpreted another, the analyst designed a third, the developers built a fourth, the deployed product was a fifth, and what the customer actually needed was a tire on a rope.
The cartoon is also a useful frame for the work. Writing good product requirements is a process of staying close to the actual problem at every step from idea to release. This guide collects ProductFTW's writing on that process, organized into six phases that show up in every product cycle: figure out the problem, write the brief, write the PRD, draw the diagrams, handle the edge cases, and ship + learn.
Phase 1: What's the problem?
Most requirements failures aren't writing failures — they're problem-definition failures. The wrong thing gets designed because the wrong question was asked, or asked of the wrong person. Before you write a line of a PRD, you need to know who has the problem, why it's worth solving, and what failure would look like.
- The Tire Swing Cartoon →
- User Problems →
- Determining the Problem to be Solved →
- For Whom Are You Building →
- The Biggest Mistake You Can Make During User Interviews →
- You Don't Have a Roadmap Problem. You Have a Problem-Definition Problem. →
Phase 2: The brief
The product brief is the bridge between problem and solution. It's not a PRD — it's the document where you commit to what you're solving (and what you're not), define success, and scope down to an MVP that's defensible.
Phase 3: The PRD
This is where most PM writing actually happens. The PRD describes the system you're building: what it does, who uses it, what edge cases matter, and how each piece connects. A good PRD is detailed enough that engineers can implement it without ambiguity but doesn't pre-design the implementation.
- Mastering the Art of Requirements: PRDs that Actually Work →
- User Stories →
- Tips for Terrific Tickets →
Phase 4: Diagrams
A good flow diagram saves a thousand words of PRD prose. The tradeoff is: it has to be readable.
Phase 5: Edge cases
Most software ships its happy path and gets surprised by the other 95% of real usage. Identifying edge cases is product work, not just QA work — they belong in the requirements doc, not just in the bug tracker.
Phase 6: Launch and learn
The work doesn't end at ship date. Knowing when to launch, writing release notes that users actually read, and managing the bugs that surface afterward are all part of the requirements lifecycle.
Cross-cutting: team norms
Two practices that don't fit a single phase but show up in every one of them: working agreements that prevent re-litigating the same arguments, and decision logs that scale your judgment beyond the room.
This is one of the ProductFTW field guides — curated paths through the archive. Explore them all: Product Requirements, Product Leadership, Product Talks, Fintech Product Management, and Templates.