The problem, the requirements and what's left out for one feature, for the people who will build it.
A PRD earns its keep on the day someone asks "wait, are we building that too?" and the answer is already written down. This page has a finished one to open, for a single feature in a made-up booking app, and the prompt that starts your own. Borrow its shape. The numbers and the decisions have to be yours.
Who it's for
Product managers, founders and tech leads who are about to ask engineers and designers for weeks of work. You send it to them before the kickoff, while changing a requirement still costs one sentence.
A published page can't take comments. If your team argues a spec out in a shared doc, keep doing that, and publish the version everyone agreed to.
What a good one contains
- A problem with numbers in it. The sample opens on 4,180 cancelled spots and 1,296 refilled. A figure lets an engineer judge whether the fix is worth its cost.
- Who has the problem, by role. Members, front desk and owners get one line each. A requirement that serves none of them is easy to spot and cut.
- Goals and non-goals side by side. Selling priority and overbooking are written down as non-goals, because someone will suggest both in the review.
- User stories you could test. Five, one sentence each, and each could be shown working in a demo.
- Requirements with an ID and a priority. R1 to R10, five of them P0. An ID lets a ticket say "this is R4". A priority says what gets dropped when time runs short.
- Out of scope, with reasons. Text messages are out because nobody has decided who pays for them. The reason stops the same debate restarting in week three.
- Open questions with an owner and a date. There are four. A question nobody owns turns into an engineer's guess.
- Success measures with today's figure beside the target. Refill rate goes from 31% to 60%, and no-shows are held at 6.5% so the first number can't be won with people who don't turn up.
Too long, or too prescriptive
Length is the usual problem. A twelve-page PRD gets skimmed, and the paragraph people skip is the one that mattered. If a section doesn't change what someone builds or decides, take it out.
The other trap is writing the design into the requirements. "A member can leave a waitlist at any time" leaves the designer room to work. "A red Leave button, top right" doesn't. And when an open question is answered, change the page that day. The link stays the same, so the ticket it's pasted in never points at an old spec.
How to send it
To named people. A PRD describes something you haven't shipped. Limit it to your company's domain, and the link can sit in a ticket without leaking.
Every page you publish gets one link that opens in any browser. You choose who can open it: anyone with the link, anyone with the password, or only the people and company domains you name, who sign in with Google or Microsoft. Change the page later and the link stays the same.
