What is a PRD and what goes in one?

A structure that works

Problem — what's broken, for whom, with evidence. If this section cites no data or research, stop here; the rest is decoration.

Why now — what changed. Competitive move, platform shift, a support queue that's grown 40%. This is the section that gets cut and the one that most often exposes that the answer is "someone senior asked".

Success criteria — the metric and the target. Stated before building, so the result can't be reinterpreted afterwards.

Scope — in and, more importantly, out. The out-of-scope list prevents the slow expansion that turns a two-week feature into a quarter.

Open questions — what you don't know yet, named. A PRD with no open questions is usually hiding them.

Notably absent: solution detail. The PRD frames the problem; design and engineering own the shape of the answer.

Amazon's inversion

Amazon's working-backwards method replaces the requirements doc with a press release and FAQ written as if the product already shipped. It's a forcing function — if the press release is boring, the product is boring, and you've learned that before spending a quarter rather than after.

The mechanism transfers even if the format doesn't: write the outcome first, in language a customer would recognise, and check whether it's worth wanting.

The test of a good one

Hand it to an engineer and a designer who weren't in the discovery. If they can independently explain who this is for, what problem it solves, and how you'll know it worked, it's doing its job. If they come back asking what it's actually for, no amount of additional requirements will fix it.