Feature Specification Template for PMs

Detailed enough that an engineer can start building without needing a follow-up conversation for every decision. The test is: can a senior engineer read this spec and produce a first draft that matches your intent within 80%? If they would need to make more than 2-3 significant assumptions, the spec needs more detail.

The PM writes the product sections (overview, user stories, acceptance criteria, analytics, out of scope). The tech lead writes or co-authors the technical sections (API design, data model, performance requirements). The best specs are a collaboration, not a handoff document thrown over the wall.

A PRD covers the strategic context: why you are building something, who it is for, what success looks like, and how it fits into the product strategy. A feature spec is the tactical follow-up: the exact behavior, API contracts, edge cases, and error states that engineering needs to implement it. One PRD might generate multiple feature specs. For a full guide to writing effective PRDs with real examples and common pitfalls, see [How to Write a PRD](/blog/how-to-write-a-prd).

Link to the Figma file rather than embedding screenshots. Screenshots go stale the moment design iterates. A live link ensures engineering always references the latest version. Call out specific interaction details in the spec that might be missed in a visual review: loading states, error messages, keyboard shortcuts, and responsive breakpoints.

Update the spec whenever scope changes, edge cases surface, or a design revision alters the expected behavior. Treat the spec as a living document during the sprint. After launch, archive it as the record of what was actually built (not what was originally planned). Note any deviations in a "Changes During Development" section at the bottom.