writing-product-requirements

Writing Product Requirements

Write requirements by working backwards from the customer's experience, not forwards from a feature list. The PR-FAQ format forces this: you write the press release and customer quote for a product that doesn't exist yet, before any design or engineering work starts, and the difficulty of writing a truthful, compelling press release is itself the test of whether the idea deserves resources.

Step 1: Decide PR-FAQ vs. lighter PRD

Use a full PR-FAQ when:

• The initiative is a new product, a new customer-facing surface, or a strategic bet that will consume more than a few weeks of a team's time.
• Multiple teams or leadership need to align on why before anyone argues about how.
• The idea is genuinely uncertain — if you can't yet write an honest customer quote, that uncertainty is exactly what the exercise surfaces.

Use a lighter one-page PRD (problem, goal, non-goals, requirements, open questions) when:

• The work is a well-understood extension of an existing product (a settings toggle, an internal tool, a known bug-driven feature).
• There is no real ambiguity about customer value — only about implementation.
• Forcing a press release would be theater, not a forcing function. A PR-FAQ written for a task nobody doubts wastes a day and teaches nothing.

Doing this step wrong is a failure mode on its own: writing a PR-FAQ for a trivial internal feature (nobody reads it, it becomes a rubber stamp) or skipping it for a genuinely risky bet (the team argues about implementation before agreeing on customer value) are both common misapplications.

Step 2: Write the press release first

Write it as if the product shipped today and a journalist is covering it. Standard structure, roughly one page:

1. Headline — one sentence, names the product and the customer benefit in language a customer would actually use. Not "New Platform Capability Launched" — that tells no one what changed for them.
2. Sub-headline — one sentence naming the target customer and the primary benefit.
3. Summary paragraph — what the product is, who it's for, the problem it solves. Datelined as if announced.
4. Problem paragraph — the customer's problem today, described from their point of view, not the company's. Should be specific enough that a reader recognizes the pain without being told it's a pain.
5. Solution paragraph — how the product solves it, in plain language, no internal jargon or codenames.
6. A quote attributed to a company spokesperson — states why the company built this, tying it to strategy.
7. A quote attributed to a customer — describes their experience using it, in the customer's own voice, specific enough to be falsifiable (what they could do before vs. after). This is the line most drafts get lazy on — see Gotchas.
8. A call to action — how a customer gets started today.