Product Requirements Documents are one of the key documents that product managers use to communicate what they are building and why.
Everyone writes their PRDs a little differently, so we’ve pulled together a selection of the best PRD examples and templates from across the internet, as well as provided some notes on what makes them different.
- Figma
- Lenny Rachitsky (Airbnb)
- Kevin Yien (Square)
- Asana
- Intercom
- Product Hunt
- Adam Waxman’s (SeatGeek)
- Steve Morin’s (Asana)
- Adam Thomas
- Amazon
- Hustle Badger
If you want more information on what a PRD is, how to write one and the principles behind it, then check out our guide here
1. Figma’s PRD template
Get Figma’s PRD template: [Coda]
Figma’s Product Requirements Document template Figma’s PRD template is a clean, comprehensive option, which elegantly incorporates features from Coda to supercharge it, such as Figma designs, tables and checklists. This is a great place to start if your team is already using Coda, as you’ll easily be able to link to team members and other documentation.
There’s a particular focus on launch planning, with an extensive launch checklist. How much product managers are involved in feature marketing will depend on the company, but if a feature isn’t launched well then it won’t live up to its full potential, so you should be interested in and make sure the launch plans are robust either way.
Note that if the rest of your team is not currently using Coda, you might be better off translating this into another tool – it’s difficult to get team members to adopt something new, as well as an additional cost.
2. Lenny Rachitsky’s PRD template
Get Lenny’s PRD template: [Google Doc]
Lenny Rachitsky’s Product Requirements Document (PRD) template This is a super simple PRD template to get you started on any project from Lenny Rachitsky (ex Airbnb). This is a good template for experienced or small teams to make sure they put some structure around their thinking on what they are building.
Whilst this template doesn’t have the guidance notes that some of the others have, the questions cover all the major bases and are clear enough to be intuitive. The question about audience is a useful detail to include, even on a template this lightweight many features will only be relevant to one customer segment, rather than the entire user base. Being explicit about this means that you don’t forget the target customers’ needs, and the expected reach of the feature when you plan and prioritize it.
3. Kevin Yien’s (Square) PRD template
Get Kevin Yien’s PRD template: [Google Doc]
Kevin Yien’s (Square) Product Requirements Document (PRD) template What is great about Kevin’s template is that he has added a lot of guidance on how to fill it out. It’s more detailed than a lot of the other templates, and you might want to cut out some of the sections to keep it short. If you’ve never written a PRD before then this is a great place to start because of the notes, and if you’re an experienced PM then you’re likely to get a fresh perspective by looking over this.
He’s also managed to pack a lot of detail into what is overall still quite a short format. The milestones make it clear the timeline for delivery, whilst the operational checklist gives you somewhere to note all the necessary non-product activities that are often overlooked.
4. Asana’s PRD template
Get Asana’s PRD template: [Google Doc]
Asana’s Product Requirements Document (PRD) template Asana call their equivalent of a PRD a “Spec Template”. It has a well thought through problem definition, and then is very lightweight for the definition of the solution and release plans. The focus is very much on defining the problem to be solved and giving teams context with three notable features.
Firstly, it has structured formats for problem statements and hypotheses. Whilst these are fairly similar, having a clear idea of who you are building this, why they will value it, and the impact this will have on the business is the fundamental rationale you have for building a feature.
Second, and as with many PRDs, it includes non-goals as well as goals. This helps you keep the feature scope and requirements tight, and front load any difficult discussions where stakeholders are expecting different things.
Third, it prompts you to describe the vision in a narrative style. Whilst we tend to nudge people towards more visual approaches to vision setting, being clear on what this looks like upfront is a powerful way of aligning and inspiring people.
Overall, this is a great inspiration for problem definition statements, but you will probably want more detail on the solution and release plans as development actually starts.
5. Intercom’s PRD template
Get Intercom’s PRD template here: [PDF]
Intercom’s Product Requirements Document (PRD) template Intercom call their version of a PRD an “Intermission” or “Job Story”. These are at the very lightweight end of the spectrum, and contain specific guidance to keep the document under 1 page (advice which you’ll find on several of the other templates).
The notes that accompany this template are probably the most interesting bits, including:
- Do not add the solution here.
- An Intermission must always fit on a printed A4 page.
- Always have active and upcoming Intermissions printed in your team area or war room.
- Always use plain simple English, no technical terminology or codenames.
Together you get a window into Intercom’s culture, being super focused on the problem to solve, empowering teams to come up with the solutions, and creating a sense of urgency to keep things moving.
6. Product Hunt’s PRD template
Get Product Hunt’s PRD template here: [Google Doc]
Product Hunt’s Product Requirements Document (PRD) template At the other end of the spectrum, Product Hunt have a very comprehensive PRD template with sections for go-to-market plans, technical architecture and mockups. It’s worth checking this template out, because if you decide you don’t need this level of detail in your PRDs (e.g. tracking codes), then you need to decide where else this information will be captured.
But just because PRDs are a single source of truth doesn’t mean everything should be captured in them. Before you start adding millions of additional sections to your PRD though, you need to ask yourself who is the audience for the document, and what function it serves. With every section you add, the document gets longer and people are less likely to read it, so you want to err on the side of keeping things lean rather than bulking them out.
7. Adam Waxman’s (SeatGeek) PRD template
Get Adam Waxman’s PRD template here: [Google Docs]
Adam Waxman’s Product Requirements Document (PRD) template This is another more detailed PRD example that has an emphasis on easing communication, featuring a decision journal, explored directions and decided direction.
These are particularly useful if you often find that stakeholders are pulling you round and round in circles demanding different things and rehashing past conversations. In this case, having a decision journal and documenting why you took particular decisions can remind people how you got to where you are. These sorts of problems are often helped with more explicit decision rights, which you might want to include in your PRD.
There are a number of optional sections, but if you’re taking inspiration from this template as always, double check that you need every section before including it, to avoid bloating the document, and keeping it readable.
8. Steve Morin’s (Asana) 1-pager template
Get Steve Morin’s PRD template here: [Google Docs]
Steve Morin’s (Asana) Product Requirements Document (PRD) template Another more detailed PRD template that starts at 5 pages long (!) including accompanying notes. This one has a focus on risks, mitigations and open questions. If nothing else, product managers need to reduce risk throughout development to ensure that any investment in technology (e.g. engineering time) is spent wisely and has the best chances of delivering results.
Being really explicit about what the risks of a particular feature are, and how you are tackling them is therefore time well spent.
9. Adam Thomas’ initiative template
Get Adam Thomas’ PRD template here: [Google Docs]
Adam Thomas’ Product Requirements Document (PRD) template This template focuses on brevity, with a timely reminder to keep PRDs to a single page if at all possible. With only five sections this template includes only the most important questions. Adam includes some detailed notes throughout on how to complete each section, as well as at the end of the template, noting:
- Meeting notes and retrospective notes can also be added so that the PRD acts as a complete log of the project.
- You shouldn’t worry if other people take copies of your PRD and use it for their own purposes. That’s generally a good thing as it shows they are engaged.
- PRDs need to be living documents to be useful. You should use PRDs regularly to lead meetings and explain what you are doing.
It’s a good reminder that PRDs are communication tools, and the only test they should be measured against is how effectively they help you communicate with team members and stakeholders.
10. Amazon’s PRD template
Get Amazon’s PRD template here: Google Doc | Notion
Amazon’s Product Requirements Document (PRD) template Amazon famously uses its PR/FAQ format in a similar way to how many companies use PRDs. Whilst the format is not a 1:1 match, there are similarities that make it worth reviewing. PR/FAQ documents are usually written for projects that aren’t just product focused, but are multi-disciplinary efforts to launch new products or services.
We’ve got a full write up of Amazon’s PR/FAQ process here, but in essence, the PR/FAQ model aims to work backwards from a desirable outcome and work out what is required to get there. The press release captures the main benefits to customers and outlines the vision for this initiative, whilst the FAQs answer critical questions from both a customer and business perspective.
11. Hustle Badger PRD template
Get Hustle Badger’s PRD template here: [Google Doc | Notion | Word]
Hustle Badger’s Product Requirements Document (PRD) template We’ve aimed to create a general purpose PRD template that could be used in a wide variety of situations. Critically in our opinion, we’ve mapped the sections of the PRD to the key decision points or product reviews that you might have throughout developing a feature. The template is designed to be filled out sequentially as you go through development, rather than all upfront before you get started.
We’ve also included a section on Impact at the end, because this closes the loop on development. Your PRD then tells the whole story of what you were trying to achieve, how you approached the problem and whether or not you were successful. This also acts as a reminder to check back on how past releases have performed, which can sometimes be overlooked.
As always though, you’ll be best off adapting this template to your specific circumstances to get the best results.
Summary
There’s no one way to write a PRD. Different companies have different uses and standards for them. It’s great to be inspired by the selection that we’ve got here, but really you should think about who will read your PRDs and what they want to know before selecting one. Once you’re clear on the role your PRD is doing, you can select an appropriate template and adapt it to your particular context and needs.
See our full guide on what PRDs are and how to write them here
FAQs
What is the best PRD template?
Whilst we’ve tried to provide a solid PRD here that you can use off the shelf, every company and team situation is different. You will get the best results when you co-create your own PRD format with your team and stakeholders to suit your own needs. This will also give you better buy in from them when using the PRD going forward.
