Living Documentation
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 living documentation system is one where the documentation updates itself as the underlying code changes. Instead of a PM writing a spec, an engineer building it, and then hoping someone remembers to update the spec afterwards, a living system treats the code as the source of truth and regenerates the documentation on every release.
The term is often used loosely. In engineering circles, it sometimes means API specs generated from code comments, or Cucumber test suites that double as behaviour descriptions. These are useful for engineers, but they don't help the PM who needs to answer a stakeholder question, or the customer success manager with no visibility into last Tuesday's release.
A living product specification extends the same idea to non-engineering audiences. The spec is still derived from the code, but it's written in plain language: structured scenarios anyone on the team can read without needing to parse TypeScript. That's the distinction that matters.
Related Terms
A written description of how a product behaves — feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
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.
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a living product specification.
Further Reading
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.