There's no single correct spec. Different situations need different levels of detail — from a one-line ticket to a full PRD — and choosing the right document type is itself a core PM skill.
▸ Try the interactive toolA specification is the PM's primary tool for communicating what to build and why. But there's no single correct spec — different situations require different levels of detail, and choosing the right document type is itself a skill. Over-specify a simple feature and you waste hours writing (and others waste hours reading); under-specify a complex one and the team builds the wrong thing.
Specs sit on a spectrum of fidelity: a one-line ticket for a trivial change, a short brief for a small feature, a full PRD for a complex initiative, a technical spec for engineering-heavy work. The skill is matching the spec's weight to the feature's complexity and risk — the same judgement as the prototype fidelity spectrum from discovery. The right amount of specification is the minimum that lets the team build the right thing confidently; anything more is waste, anything less is risk.
One-line ticket → short brief / one-pager → full PRD → technical spec. Match the weight to the feature's complexity and risk: enough to build the right thing confidently, no more.
Specs fail in two opposite directions — bloated documents nobody reads for trivial work, and thin tickets that leave a complex feature ambiguous — and both come from not matching the spec to the work.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Over-specifying simple work | Hours writing a heavy doc for a trivial change; readers tune out. | Matching spec weight to complexity saves everyone's time. |
| Under-specifying complex work | A thin ticket leaves a complex feature ambiguous; the team guesses. | A fuller spec for complex work removes the ambiguity. |
| One template for everything | Forcing every feature into the same doc fits none well. | A spectrum lets each feature get the right level of detail. |
| Spec as box-ticking | Writing the document to satisfy process, not to communicate. | Choosing the fitting spec keeps it a real communication tool. |
How complex is the work, how many unknowns, how costly to get wrong, how many people need to coordinate? This determines how much specification is warranted.
Pick the document type that gives the team enough to build the right thing confidently — and no more. A trivial change needs a ticket; a complex initiative needs a PRD.
Whatever the type, the spec's job is to pre-answer the questions engineers and designers will have. The right length is ‘enough to remove ambiguity,’ not a fixed page count.
Resist the urge to bloat a simple spec to look thorough, and resist shipping a thin spec for genuinely complex work to save time. Both are costly in different ways.
A spec for a known team building a small change can be lighter than one for a cross-functional, high-stakes initiative. Calibrate to who needs to understand it.
A PM wrote a detailed, multi-page PRD for a trivial copy-and-styling change — hours of work that engineers skimmed and largely ignored, because the change was obvious. The same PM, pressed for time later, dropped a one-line ticket for a genuinely complex, cross-team feature — and the team built something subtly wrong because the ambiguity was never resolved.
Both failures were the same mistake in opposite directions: the spec's weight didn't match the work. The trivial change needed a ticket; the complex feature needed a real PRD. Choosing the right document type per feature — light where light suffices, heavy where heavy is warranted — would have saved hours on one and prevented rework on the other.
The deliverable is the appropriate spec type for the feature at hand — chosen by complexity and risk, sized to remove ambiguity without waste.
| Spec type | Fits | Risk if mismatched |
|---|---|---|
| One-line ticket | Trivial, obvious changes | Too heavy = wasted hours |
| Short brief / one-pager | Small, low-risk features | — |
| Full PRD | Complex, high-stakes initiatives | Too light = built wrong |
| Technical spec | Engineering-heavy work | Missing = integration failures |
Choosing the spec is a judgement call, not a template choice. The right amount of specification is the minimum that lets the team build the right thing confidently — a moving target set by the feature's complexity and risk.
This mirrors the prototype fidelity lesson from discovery: fidelity is a cost, not a virtue, and the skill is matching it to the question. A heavy PRD for a trivial change wastes the PM's time writing and everyone's time reading, and it trains the team to skim specs — so when a genuinely complex feature gets a heavy spec, that one gets skimmed too. Conversely, a thin ticket for complex work pushes the ambiguity downstream, where it surfaces as the team building the wrong thing. The PM who calibrates spec weight to the actual work keeps specs useful — read, trusted, and sufficient — rather than either ignored bloat or dangerous gaps.
A heavy doc for a simple change wastes everyone's time and trains people to skim specs.
A thin ticket for a complex feature pushes ambiguity downstream into wrong builds.
Every feature forced into the same format fits none well. Use the spectrum.
A spec exists to communicate and remove ambiguity, not to tick a box.
The heaviest common spec type, the PRD, gets its own treatment (Tool 13).
Specs are assembled from user stories (Tool 14) and acceptance criteria (Tool 15).
Matching spec weight to complexity is the same instinct as matching prototype fidelity (Module 3, Tool 16).
Clear, right-sized specs are one of the things engineers most want from PMs (Tool 19).
AI drafts specifications quickly across types — useful, provided you treat its output as a first draft to verify.
The judgment that stays yours: AI doesn't know your system's real constraints — it will produce confident, plausible specs that don't match reality. Specs still require your and your engineers' verification; AI speeds the writing, not the knowing.
Take a trivial change and a complex feature you can imagine. For each, name the spec type that fits — and notice how different they are.
Then ask: what would go wrong if you swapped them — a PRD for the trivial change, a one-liner for the complex one?
If swapping them produces wasted effort on one and a wrong build on the other, you've understood that choosing the spec type is itself the skill — not just writing the spec well.