Product Specification
A written description of how a product behaves — feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
A product specification answers the question “how does this product behave?” without requiring the reader to understand how it's built. It describes behaviour in terms of what a user sees, what they do, and how the product responds — not classes, functions, or database schemas.
Traditional product specs are written once, before development, and then abandoned. They describe what was planned, not what shipped. A spec read from the code is different: it reflects the product as it shipped, and updates on every release.
The audience matters. A product spec is read by product managers, customer success teams, engineering managers, and stakeholders. It isn't read by compilers. That's why the format matters: structured enough to be unambiguous, plain enough that nobody needs a glossary.
Related terms
- CONCEPT
Living Documentation
The mechanism behind product observability: a spec derived from the code rather than written separately, so it moves with the product instead of falling out of sync.
- SPEC
Scenario
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a Specsight spec.
- SPEC
Feature
A logical grouping of scenarios that represents a meaningful unit of the product — like “Document Upload” or “User Authentication.” Features form the structure of a Specsight spec.