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 PRD helps with structure, alignment and communication in product development
• A PRD should be designed:
  • Not one company is the same, the elements that go in should be defined based on what you build, what phase you're in, how big the company is, etc
  • As time goes on and you learn more, it can always be adapted to increase its relevance
  • It doesn't have to be a set format: the structure can change even on a per feature level
• The elements that are best to always cover: what are we building and why are we building it?
• We'll give a list of all the other elements that you can cover in a PRD
• It's an important tool, but only part of the story

What exactly is a PRD?

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:

• It helps you communicate what you're building and why
• This communication is useful not just for the collaboration with the people that will build the product, but it's useful to be able to share ideas across the whole company
• It also serves as documentation so you can find things back easily (even after years)
• It helps you structure your thoughts and your story

What should be in a PRD?

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:

• Owner and date started (often forget, but very useful in the long term as your company grows)
• Introduction: why are we here
• What are we building?
• Why are we building it?
• Who is the target user? (this can also be covered in the previous point)
• Problem + solution summary (cutting right to the good stuff)
• Desired end-result
• Planning
• What's in and out of scope
• UX flows
• User research
• Risks
• Legal implications
• Who's involved
• Dependencies
• Metrics and analytics (what do we measure, how do we measure it)
• Sources of truth / documentation
• Technical specifications
• Business case
• Competitive landscape
• Customers
• Localisation
• Security
• Privacy
• Deployment plan
• Post Mortem (come back post-launch and write down some learnings)

What's the best format?

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:

• Keeping it short
• Applying structure (headings, sub-headings)
• Easier to insert images/graphs
• Easier to make it beautiful, and beautiful things are easier to understand, digest and run with. That latter point is important, as the goal of a PRD sometimes is to convince stakeholders.
• Building a story (the flow from one slide to the next should make sense)

How to write a PRD

One section, one slide

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.

Design it

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.

Launch and iterate

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! 🪄

Owner and date

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).

There's more than just the PRD

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.

How ProductNerd helps with writing PRDs

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:

• Collect input, structure it and write your PRD based on insights that you see there. Then from there you can write the features that need to go to engineering in our tool.
• Spec out smaller things that don't require a PRD

Help us grow with your experience 📧

If you have any tips please send them to info@productnerd.io.