Product Requirements Document

Deciding what to build used to happen out loud. Someone from product walked over to an engineer's desk and said "add a coupon code field to the checkout screen," and that was the requirement. One sentence, so it was fast, and for anything urgent it genuinely was the fastest route.

The trouble was everything that sentence left out. What message shows when the coupon has expired, whether it stacks on an order that already has a discount, what happens when you paste someone else's code — nobody said. The engineer could ask, but once there are more than ten open questions, most people just pick something and build. Two weeks later the screen appears and only then does someone say "we meant expired coupons shouldn't show up at all," and rebuilding the same piece costs another two days.

Looking back, the problem wasn't missing information but information that lived only in conversation. The designer who wasn't in the room doesn't know the expiry message, the person who joins a month later has nowhere to ask why it was decided that way, and six months on even the person who decided has forgotten. A meeting could reach a decision, and the decision evaporated the moment the meeting ended. Pagedeck settled its first refund policy in a meeting exactly that way, and when the same question came back from a customer eight months later, nobody could remember the answer, so the discussion started over.

The product requirements document (PRD) is the proposal to write that conversation down in one place. What gets written is not a picture of the screen but the reasoning and the boundaries: why this now, how far it goes this time and what it excludes, what condition makes it finished. Written down, the people who missed the meeting read the same thing, and when someone asks two months later why it was built this way, the answer is still in the document. The conversation is still needed; what changes is that its conclusions stop evaporating. More writing doesn't make a better document. For a coupon feature, button color and letter spacing don't belong here, while how expired coupons behave and the decision not to build an admin issuing screen this time do. The line is whether someone will ask about it again later.

The terms under a PRD fall into two groups: the fields the document is made of (components) and what actually happens when a field is left blank (phenomena). The first five are places to fill in while writing, and the last one is the bill that arrives when you don't.

There are five components. The order carries meaning — the field for what gets done comes first, and the conditions and limits on doing it follow.

1. Functional requirement — what the product has to do. Write it as a sentence with a subject, an action, and a result: "when a user enters a coupon code on the checkout screen, the discount amount appears immediately." What usually goes missing here is everything off the happy path. Write what appears when the code is wrong, when it has already been used, and when it has expired, and an engineer can build it without coming back to ask.
2. Non-functional requirement — quality conditions rather than behavior. The discount appears in under a second; coupon codes are never written to the logs in the clear; the field is reachable with a keyboard alone. Leave these out and you get a screen where every function works and each one takes three seconds, and fixing that later often means reworking the structure underneath.
3. Success criteria — the condition under which this work counts as a success. Not the fact that it shipped, but what has to be different after it ships. "Improve coupon usage" is not a criterion; "four weeks after launch, a coupon is applied on at least 15 percent of completed checkouts" is. A number and a date are what let you reopen the document later and rule on it.
4. Scope — the boundary of what you agreed to build this time. Write it as a list, with how much of each item is included. One sentence saying you'll add a coupon field doesn't settle whether an admin issuing screen is in or out. Say that the field goes on the checkout screen, that only one type of code is handled, and that codes get issued by the operations team directly for now, and three lines have drawn the boundary. Start with a blurry boundary and the estimate blurs with it. The person who answered two weeks and the person who answered six were often just picturing different scopes.
5. Out of scope — the field where you write plainly what you are not doing this time. Recording what you won't build looks odd, and it earns its keep more than any other field. One line saying automatically applied coupons are not part of this round ends the discussion in five minutes when it comes up three weeks later. Without that line, the same conversation reopens every week.

The phenomena group holds one term, scope creep: the quiet expansion of scope without anyone agreeing to it, which follows almost automatically when the two fields above are empty. What started as one coupon field grows into an admin issuing screen, a usage history view, and expiry reminder emails. It never arrives in one large piece — each addition comes attached to the words "this one's small" — so nobody can point to when the work grew. There is no single day on which a two-week job gained four weeks on the way to becoming six. With scope and out of scope written down, a new request has to pass through a decision to amend the document, and that one step is what reopens the schedule conversation.

The people filling the fields and the people reading them are not the same. Writing is usually one person, the product manager who owns the area. Reading splits four ways, and each side reads only the fields it needs. Engineers read functional and non-functional requirements to answer whether it can be built and how long it takes. Designers read scope and functional requirements to count how many screens they have to draw. Sales and customer success open out of scope first, to check what they must not promise yet. Whoever approves the start reads only the success criteria, to decide whether to put people on this. So an empty field stops exactly the person who reads it. Leave success criteria blank and development begins while approval never comes; leave out of scope blank and the builders are fine while sales promises a customer something that doesn't exist.

Holding these six in one document doesn't make the PRD a replacement for every other document. It's a branch point, not a terminus. Split its requirements into one-sentence units from the user's point of view and you get user stories; items nobody has started sit in the product backlog in priority order. When the exact behavior in every situation, exceptions included, has to be nailed down, that part moves out into a product policy. A single coupon attracts twenty lines of rules about stacking, restoration on refund, and partial cancellation, and putting all of that in the body wears the reader out before the good part. Keep the decision that coupons don't stack and the reason for it in the body, send the table of which rule wins in which combination to the policy document, and link to it.

"That isn't in the PRD. It's listed as out of scope for this round."

The new request can't be squeezed into the current schedule; doing it means amending the document and resetting the dates.

"The success criteria says users will find it easier. Can we rule on that four months from now?"

A request to rewrite an unmeasurable field as a sentence with a number and a date in it.

"Draft is up. Comments by Thursday, and I'll close it Friday and we start building."

Announcing when the document shuts, so that opinions arriving later have to go through the change process.

At Pagedeck the person who writes this document is Mia. On the coupon feature, she wrote down why now and how far this round goes, shared the draft, and gave everyone three days to read it at their own desk. Theo found the gaps in the functional requirements and came back with two: expired codes and repeat use. Noa pointed out that where the discount amount appears had never been decided. Sofia left a comment noting that enterprise contracts already carry a separate discount, so overlapping with this coupon would cause trouble.

Where the comments land shows exactly where the document is thin. When three people comment on the same paragraph, that paragraph isn't short of sentences; it's a decision nobody has made. Mia folded all three in, named the enterprise contract case under out of scope, and closed the document on Friday. When another request arrived the following week, she reopened it, made the change, and left one line at the bottom with the date and the reason.

The most common mistake is reading this as a screen design document. Being asked for requirements and starting with screens is natural enough. Screens are the most concrete thing available, and a picture really does end the conversation faster. But settling the screen first seats one solution in the chair where the problem definition belongs. Write down that a coupon field goes in, and from then on nobody thinks of applying the discount automatically at checkout. Left alone, the team builds without ever checking whether a better approach existed, and when usage comes in low after launch there's nothing on record to trace it back through.

The second is treating it as a contract that can't change once written. The word "final" gets attached and it doubles as the signal to start building, so it reads that way easily. But building always turns up something. That the payment provider can't handle a coupon amount inside a partial refund is not knowable until you wire it up. Treated as unchangeable, a team does one of two things: ignore the document and build to its own judgment, or force an approach that doesn't work in order to match the document. Changing it while recording when and why is closer to right, and that record is what keeps the next quarter out of the same trap. One line at the bottom of the document — on October 12, coupon restoration on partial refunds moved out of scope because of a payment provider limitation — covers it.