PRD Best Practices That Survive Contact With a Team

Most PRD best-practice lists are written for the ideal case: unlimited time, a team that reads carefully, no deadline. The advice is usually correct and mostly useless, because the moment that matters is the one where a stakeholder skimmed it, an engineer disagrees, and the date is next Thursday.

A practice earns its place if it can name the failure it prevents. Below are seven that survive, and five that sound right and reliably do not.

Seven that survive

1 · Write the problem before the solution

Prevents: a beautifully specified version of the wrong thing.

A spec that opens with the feature has skipped the argument. Nobody reviewing it can evaluate whether the solution fits, because the problem is only implied — so the review becomes a critique of implementation detail, which is the cheapest and least useful kind.

Costs: you sometimes discover the problem does not justify the work, after you were already attached to building it.

2 · Write what you are not doing

Prevents: the scope fight that arrives after approval, when your leverage is gone.

Two to five explicit exclusions, each labelled adjacent, deferred, or rejected. Nothing in a PRD produces a better ratio of effort to conflict avoided.

Costs: you have to make decisions earlier, and some of them will be argued in the review rather than quietly deferred.

3 · Put a number on every adjective

Prevents: requirements that cannot fail, and therefore cannot be tested or built for.

Fast, large, quickly, most, minimal, seamless. Every one is a decision wearing the costume of a requirement. If you cannot supply the number, that is worth knowing before the build rather than during it.

Costs: occasionally you have to admit you do not know the right threshold, which is uncomfortable and much cheaper than the alternative.

4 · Name every state, not only the success path

Prevents: the generic red toast, and features that work perfectly until they do not.

Empty, loading, error, partial, permission-denied. Most specs describe one state. Users spend real time in the others.

Costs: length, and the discomfort of writing down all the ways your feature will fail.

5 · Put a human name on every dependency

Prevents: the unowned blocker — the most reliable predictor of a slipped date.

Not a team. A person, a date, and whether the dependency is confirmed or assumed. The confirmed/assumed distinction alone will change how your timeline reads.

Costs: it makes visible how much of your plan rests on hope, which is the point and is still unpleasant.

6 · Write the metric with its baseline

Prevents: an unfalsifiable claim of success.

"Increase activation to 40%" is not a metric if nobody knows today's number. Either state the baseline or state that establishing one is the first task — both are honest, and the second is frequently the real situation.

Costs: sometimes the baseline shows the problem is smaller than the pitch implied.

7 · Get it reviewed by someone willing to disagree

Prevents: the fluent, well-organised, empty spec that passes review because it reads well.

A supportive reviewer improves your sentences. An adversarial one finds the decisions you did not make. You need the second kind, and you have to actively ask for it, because the default social setting of a review is agreement.

Costs: it is genuinely unpleasant, and it is the single highest-yield practice on this list.

Five that do not survive

These appear on most lists. Watch what happens to each under pressure.

"Keep it to one page." A proxy for the real goal — every section earning its place — that fails on any feature with genuine complexity. Under a page limit, decisions do not disappear; they move out of the document and into a sprint. Cut sections that add nothing, not sections that add length.

"Always use the company template." Templates encode assumptions about a kind of work. Applying the standard one to a small internal tool produces ten empty headings, which teaches everyone that headings are decoration. Match the template to the work, or write the sections the work needs.

"Get sign-off from every stakeholder." Broad sign-off diffuses ownership rather than creating it. When everyone approved, nobody is accountable, and the review turns into a scheduling problem. One accountable approver plus named reviewers for specific sections is faster and produces better specs.

"Write it in the tool engineering already uses." Tooling is not the bottleneck. A weak spec in Jira is a weak spec. This advice survives because it is easy to act on and feels like progress.

"Keep the PRD continuously updated." The most-recommended and least-practised item in the category. Nobody maintains a document after the build starts. The durable version is to version the decisions, not the document: when something changes, append three lines — what changed, what was traded for it, who agreed. That actually happens, and it preserves the only thing anyone needs later, which is why the product is the way it is.

The pattern

Look at the two lists together and the difference is not sophistication. It is specificity.

Every practice that survives names a failure: the wrong thing built well, the scope fight, the untestable line, the missing state, the unowned dependency, the unfalsifiable metric, the empty spec. Every practice that does not survive names a quality — brevity, consistency, alignment, maintenance. Qualities are real, but they are outcomes rather than actions, and under deadline pressure an action beats an aspiration every time.

Which gives you a test for any advice, including everything above:

What specific failure does this prevent, and would I notice if it happened?

If the answer is vague, the practice will not survive contact with your team. It will survive contact with a document about best practices, which is a different and much easier environment.

Where to start

If you adopt one thing, adopt the adversarial review — practice seven. It is the only one that catches the absence of the other six, and it works even when your process is otherwise a mess.

If you adopt two, add the not-doing list. It costs a paragraph and prevents the argument that otherwise eats a week of your build.

FAQ

The most important practices? The ones that prevent a nameable failure — problem before solution, explicit exclusions, numbers on adjectives, every state named, owned dependencies, a baselined metric, an adversarial review.

Should a PRD be one page? Only if the feature fits. Page limits push decisions out of the document and into the sprint.

How often to update after approval? Version the decisions, not the document. Three appended lines when something changes.

Sign-off from everyone? No. One accountable approver, plus named reviewers for specific sections.