OUR RESEARCH PROCESS
Our product spec templates comes from a veteran PM at Lyft, who created Lyft’s internal spec template.
IF YOU REMEMBER NOTHING ELSE
- A product spec shares the purpose, describes features, defines release criteria and outlines timing for a product or feature.
- Frame requirements in user facing terms to development team and stakeholders.
- Start out high-level. Designers will love you for not telling them how to solve a problem. Only describe user behavior in detail later in the process.
A product spec (or requirements document) is the core information source for product, marketing, engineering and design teams. It captures the essence of a product these teams are collaborating to launch and has four main functions:
- Share purpose
- Describe features
- Define release criteria
- Outline timing
It includes sections describing:
Fill out our template:
Best practices when writing a scope
- Frame requirements as user stories. (You can learn more about writing user stories here.)
- As a TYPE OF USER in a SITUATION, in order to ACCOMPLISH A GOAL, I want ABILITY
- Consider ordering requirements in a flow.
- Separate essential from optional requirements. Some requirements are required for launch, while others are nice to have.
- Write high level requirements first. At first, state the requirements in a way that expresses the need but that does not dictate a solution. This makes the spec useful for design in coming up with a solution, you can include examples of potential solution, but designers will love you for not telling them what to do. Design should be able to evaluate their designs against each item in this section.
- Once design is complete, describe the intended behaviour. How much detail you put here will depend on if you have designs that are annotated and include the copy and interactions, and if your engineers write separate tech specs. Add links to design and tech specs in this stage if you don’t have seperate documents for these. Engineering should be able to review this section to ensure everything needed from them is complete, as such, include any technical considerations such as configurations, localization/internationalization, experimentation needs, tooling, dashboards, etc.
- For larger projects you can break requirements up into various phases or opt to create separate documents for them. For very large projects, you may wish to group similar functionality together or use a spreadsheet to manage various phases of release and priority of requirements.
- Highlight feature ideas that are out of scope. As you share your spec with the project team and stakeholders new ideas will come up. In a separate section, include sample requirements and features that will not be included in this initiative. Including items you may do later here acknowledges you’ve seen their request and creates a mini-backlog of ideas to consider for the future. It also makes it clear what you are not doing.