Feature Brief Template for Product Planning

A user story captures a single behavior from the user's perspective ("As a user, I want to..."). A feature brief captures the full scope of a feature that may contain multiple user stories. The brief includes problem evidence, scope boundaries, success metrics, and dependencies that user stories do not cover. Think of the brief as the container that holds and contextualizes 3-10 user stories. For more on [user stories](/glossary/user-story) and how they relate to epics, see the glossary.

The product manager writes the brief, but engineering and design should contribute to it. A good pattern is for the PM to draft sections 1-4 (problem, solution, scope, success criteria), then review with the engineering lead who adds dependencies and risks. The design lead reviews and flags any UX concerns. The whole review takes 15-30 minutes.

If the engineering lead reads the brief and has more than 3 open questions about how the feature should work, the brief needs more detail. If the feature touches multiple services, requires database migrations, or changes data models used by other teams, step up to the full [Feature Specification Template](/templates/feature-spec-template). The brief is not the right format for ambiguous or exploratory work.

Yes. Store briefs in your wiki or docs system with version history. As scope changes during development, update the brief so it remains the canonical reference. Add a "Changelog" row to the header table if the brief undergoes significant revision after approval. ---