The 6 Sections to Include in Your Next PRD
Let’s talk about PRDs. Now, if you’re not familiar with the PRD, a PRD is overview of a feature or a product or something big that you’re about to build, what it should include, look like, and do. PRD writing comes after customer interviews and discovery.
Once you’ve gathered up all your notes from customer discovery, it’s time to pull out the insights, map them to the feature you’re about to build, write a bit more about it, tie your new thing to your bigger overall objectives, and get ready to hand it off to engineering.
This is the spec writing process in a nutshell. But what about the actual document? What goes in there?
Well, there are a few key sections to include. You may find you need more or less than these. This outline is a good starting point. The sections are:
- Quick overview of key dates/people
- Objectives
- Success metrics
- Requirements
- Documents
- Scope
Let’s cover a couple of points about each one:
Quick Facts
At the top of your spec you’ll usually put a table that lists out things like:
- due date
- document status
- epic
- product owner
- other responsible parties
It’s just the key stuff at a glance. Simple.
Objectives
This section covers the really big picture stuff. Here you’ll outline what this is, who it’s for, why you’re doing it, how you may plan on doing it and how it fits into the organization’s larger objectives.
Success Metrics
Once this feature is completed, how will you know it’s working?
This is optional, but helps remove some of the ambiguity of “did this work?”.
Requirements
The requirements section is where all of your user stories come into play. If you’d like to learn how to write a good user story, check out this post.
You may also choose to add technical requirements or business requirements in this section.
Documents
Here is where you’re going to add:
- Wireframes
- Mockups
- Design elements
- Database documents
- Copy
- etc.
Basically whatever documents you have that could make the implementation of this spec easier for your engineers should be included in this section.
Scope
Finally, we have the section that includes everything that is out of scope or is future work that we’re not going to worry about right now.
By spelling out what you’re not working on, it removes some of the ambiguity that can come with working on such a big feature or product. No need for the team to worry about xyz when all you need is abc.
Happy spec writing!