Specification Drift
The gap that opens between a written specification and the product it is meant to describe — widens with every release that nobody remembers to document.
Specification drift is what happens between the moment a spec is written and the moment it's read. A PM writes a spec. Engineers build against it. During implementation, edge cases surface, requirements get refined, business logic turns out to have three exceptions nobody anticipated. The spec captures the pre-build conversation. The code captures what was actually decided. By the time the feature ships, the spec is already slightly wrong.
Drift isn't a discipline problem. It's a structural one. Documentation is a separate, parallel, manually maintained task with no owner after launch. During planning, the PM owns it. During development, engineers own it. After launch, it exists in a grey zone where everyone assumes someone else is responsible. Only 4% of companies consistently document their processes (BPTrends), and the other 96% aren't failing — they're being rational.
The only fix that works at scale is to eliminate the maintenance question: derive the spec from the code, so there's no separate document to drift. That's the point of a living specification.
Related Terms
Documentation that is structurally incapable of falling out of sync with the product, because it is derived from the code rather than written separately.
A written description of how a product behaves — feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
Further Reading
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.