Feature Spec / PRD Writing

A spec the team can build from without asking what was meant

About this workflow

Turning a prioritized item into a written spec a team can build from — the problem and the one story that proves it, goals with honest baselines, scope and non-goals, and the intended behavior down to the edge cases. The work runs from framing the problem and the appetite, through scenarios and numbered behavior rules written as what the user does and sees, to a versioned spec that the engineers and designer walk through and the assembler re-issues with every change logged.

Its purpose is to make the spec unambiguous without taking the solution away from the people who build it. A spec that prescribes screens gets argued with; one that leaves the edge cases out gets built twice.

The recognizable task

Typical trigger

An item has reached the top of the backlog and needs a spec before anyone builds it
Engineering keeps coming back to ask what a feature was meant to do
A spec exists but has drifted from what the team agreed

What good looks like

Every goal has a metric, and every baseline is real or marked unknown
Every behavior rule traces to a scenario, and none prescribes a screen or a technology
Each review change is logged with its reason, and the version moves with it