19 September 2021
Ahhh yes, the illustrous PRD. If you're expecting a recipe that you can copy and paste to win with, you're going to be disappointed. In our opinion PRDs should be designed so they are just right for your company, your process and your features.
Before we dive in, here's a short summary:
A Product Requirements Document, or PRD for short, is a document that outlines what should be built, why it's being built (often this part is not included, while it's actually crucial) and what the specifications are. It can be used in product development from hardware to software, from B2B to B2C and everything in between.
It's most often written by a product manager, but can also be written by a product designer, user researcher, engineer or even better: a combination of these.
A PRD is very useful to have for many reasons:
To start, we would say that the 2 items you should always cover are: what are we building and why are we building it. Both of these questions are best answered in a small summary form. It's difficult, but aim for 1 to 3 paragraphs max.
This way when someone starts reading the PRD they instantly know the what and the why which is the most important part. It serves as a strong introduction and summary at the same time.
Imagine that you're onboarding a new colleague and they ask you about Feature X that they heard of. The first 1 or 2 slides should serve as a summary and introduction for that new colleague to instantly understand what this feature is about.
Next, here's a full list of things that can be covered in a PRD. By no means we suggest to cover all of these, this is just for inspiration:
This is the part where we're really opinionated. We don't believe in any text-first tools like Google Docs, Notion and the likes. Why? Because they encourage you to write text, and to keep writing text. That's bad because in a busy company no one likes to read long essays. It also doesn't help you to keep it short and structured (The new KISS? 💋).
So instead we recommend a slide format (eg Google Slides, Pitch). This will help you in many ways:
In our case, using the slide format, we always try to keep one section (from the list above) on one slide. This way you're forced to keep it short, keep it structured as well as only write down the essence of each of the items.
Think about what's relevant for your company, your process and your features. It can be benificial to define with your team what the fixed set of elements are that should always go in a PRD. This way everyone knows that the crucial elements are always covered. For instance: if you work on a privacy focussed product the privacy and legal items could be always required. But do try to keep those to a minimum and then cherry pick the items that are relevant for the project, product or feature that you're currently working on.
Many people think that a PRD takes weeks to complete, but you can write one in 10 minutes or in a few weeks. It all depends on the size and the scope of the product, project of feature.
Product definition and specification is creative work, and therefore it needs time and becomes better when iterating on it a few times.
So take that time. Write for an hour ⏲, leave it for a day 😴, and then pick it up the next day. Gather opinions, take time to digest them, go for a walk 🚶♀️, let it sink in, stare out the window 🪟 or go for a parachute jump 🪂 and spread the work over a few iterations. It will work magic! 🪄
As we mentioned in the list above, make sure you put the owner and the starting date on the cover. As your company grows, people move projects and teams. So knowing who owned the PRD will be useful in the future to quickly find the person that has the most knowledge on the project, as well as determining how relevant the information still is (or is not).
You can write the best PRDs, but if you're not communicating or collaborating effectively then in the end your team and your customers will still be disappointed. A PRD can greatly help with product development, but it's only a part of that process.
The flow of ProductNerd is going from input to structure to writing specs. Somewhere before writing specs you would probably start a PRD. While we're thinking about bringing PRD writing functionality to our app, it's probably best if you keep them separate in Google Slides, and use our tool to:
If you have any tips please send them to email@example.com.