A Flexible Approach to PRD Templates | John's Tips 2024W48
Make your product discovery a little bit easier with my customisable PRD templates. I show how I adapt them for any product size, along with AI prompts you can use that work well with them
Over the past few months, I have been tailoring my approach to PRDs to better align with my current way of thinking. In my last role, I had one PRD template for Boulders (L), and one template for rocks/pebbles (M/S).
I was using it for the first few of my main projects here and the structure I had just didn’t feel right, and it’s taken me a while to actually pinpoint what was bothering me. I understand it now, have fixed it, and am finally happy to share the finished product.
Here’s an example of my old template.
For anyone who has read my Jira Discovery Series, you’ll notice that I’m working through the same opportunity stages that I mention here. This is the key for my Discover, Build framework I mention on that blog, and eventually I’ll have an automation that will append the relevant PRD template sections in JPD based on the opportunity stage. I’ll update this with the link when I create that blog.
As you can see in the image above, I explain the different sections and am trying to tell whoever is writing the PRD that they need to delete the text.
This annoyed me every time I had to do it, and I have wanting to fix that for a while but didn’t know if I wanted to have an info bar on every header.
I wanted to flood the document with info about each section and examples, but I hated having to delete them every time, so I only had them on key sections. That said, I do feel info or examples are really useful. Especially for junior PMs.
Why are templates important, and why should I explain the headers?
When I was first building my own PRD template in my last role, I had just come from 3 years in a feature factory-like role, and had no idea what questions needed to go on PRD templates. Discovery wasn’t something I had a lot of experience in, and didn’t exactly want to go about shouting this off the rooftops in my new role.
When I asked PMs in my last company what they put into their PRDs, many of the responses I got were - “Oh I don’t use a template, it’s all in my head”
These responses were from PMs with 5/10+ years working in environments where discovery was commonplace, and not just done over 2 days quarterly. I didn’t have that kind of experience, and we didn’t yet have AI to tell me what questions I should be asking, as well as the answers for questions I haven’t heard before.
This frustrated me because if I’m just ‘supposed to know’, what about the engineering teams without a PM?
What about all the associate or recently senior PMs who have been just thrown in at the deep end to manage 3/4 teams like I was?
These more senior PMs may remember all the questions they have been trained to ask over the years, but the act of thinking through the questions as well as the answers is a totally unnecessary burden to put on someone more junior who is already probably overworked as well as out of their depth.
These people may very well be on critical products within their own company, so it makes no sense to me why people wouldn’t support them with well fleshed out templates with contextual examples and information like I will show you now.
At the very least, it will fill the knowledge gaps in the people who are managing the products, and it will provide a baseline for their product discovery and documentation.
Beyond that, there are a bunch of other positives you are missing out on.
Let me talk through some of these, and share how I structure and save my PRD templates in google docs & Confluence so you can copy it yourself.
A PRD Template for Every Need
I have four PRD templates currently.
Here’s the one I use for Boulders: Template: PRD - Boulders
Here’s the one I use for Rocks/Pebbles: Template: PRD - Rocks/Pebbles
I’m aware your first thought is going to be “Multiple templates? Now I’ll have to maintain multiple versions of the same files any time anything changes!”
That is a valid concern, however it is one single inefficiency in a pool of useful contexts that can save you time, while also raising the bar for the PRDs throughout your company to have an average baseline.
So, why four? You have only linked two?
Well, that’s because I create two versions of each PRD template.
One with the tooltips and examples:
This version serves as a guide, complete with context-specific examples and explanations tailored to my company’s environment. It’s perfect for those drafting a PRD for the first time or needing extra clarity on specific sections. If you make one for yourself, you should add contextual examples that make sense for your company
In confluence I use the Info Panel function, change background to grey and change the logo. I feel this is the least imposing design I can come up with for this.
As you’ll see in the google docs I shared, I’m trying our their shape functionality as they don’t have any info bars like confluence, so I’ll see how that works. I also can just take screenshots of the info panels and use those in the doc. Not as easy to maintain, but they key is that they have to be able to be deleted quickly, so both options work.
The Bare-Bones Version:
This stripped-down version has no tooltips or examples. It’s ideal for experienced team members who want to jump straight into writing. On top of that, it supports AI-based PRD drafting by offering a clean slate for prompt engineering.
If you haven’t already been using AI for creating PRDs, you really should. It is super quick to give you a few really good ideas of content to add to your template.
Below is an example of a prompt I use when creating PRDs with my above template, as it gives me a good variation of answers to consider and paths to go down.
It’s worth noting that I’ve already included my company name and seniority level in my custom instructions and trained the AI to mimic my tone of voice.
My PRDs will come out (hopefully) in the manner of speaking familiar to myself, and this makes them a lot quicker to edit. I created a custom GPT you can use if you want to try that out at the below link.
I am a Senior Product Manager at XYZ, working on the XYZ division in the company in Ireland. I need your help to fill out a PRD (Product Requirements Document) for a project/product and I need your help to do so. You are a CPO that has held the CPO role across many different companies worldwide, but specifically in <your country>/<your industry>
Attached is the PRD template I want to use, and I need help filling out Section 1. Problem Definition. Below this will be the Objective of the project/rough description of the project.
Knowing what you know about projects/products similar to those in my division and my company, Can you take my PRD template and give me 3 different versions of the Problem Definition - one version with short answers for each header, one version with the same answers in a longer format for each header, and the final version will have different answers to the previous 2 versions for each header.
Ask up to five clarifying questions if needed to ensure the draft aligns closely with the objective.
Objective/Rough Problem: Our platform faces challenges with customer churn, particularly during the onboarding process. New users report difficulty understanding key product features, leading to low activation rates and eventual attrition. This project aims to design a more intuitive onboarding flow, supported by in-app guidance and contextual help, to improve user engagement and retention while reducing support tickets.
The bold is what you could potentially change or add to your custom instructions, saving you time each time you prompt. I’ve used chatGPT to create a random problem for me, so that obviously needs to change to your own problem.
If you haven’t already been using AI for creating PRDs, you really should. It is super quick to give you a few really good ideas of content to add to your template.
NOTE: One important caveat when using AI tools, and one of the main reasons for the barebones PRD: If you prompt the AI with a PRD template that still contains contextual info boxes or tooltips, the AI may mistakenly incorporate these tips into the final document as though they were part of the prompt description. To avoid this, always use the bare template or remove all guidance text before prompting.
Optional Header PRD for Smaller Projects
The PRD I use for smaller projects/opportunities - most Rocks and Pebble sized pieces of work - are designed with flexibility in mind. Certain headers are marked as optional, and are flagged as such in the doc and in confluence. In confluence, I hide these headers in expands, for people to move them out of the expand if they wish to actually fill in some information.
This ensures that team members:
Feel No Pressure: You don’t need to fill out every section for smaller initiatives. Optional headers streamline the process while maintaining focus on the essentials.
Encourage Thoroughness: While some fields are optional, that doesn’t mean they’re unnecessary. Providing more information can only strengthen your PRD, but having optional sections enforces a baseline for discovery, allowing teams to focus on what’s most relevant while adding additional details as needed.
For larger projects, like Boulders, these sections are treated as mandatory to capture the full scope of discovery, validation, and execution.
Flexibility in Formats
By offering both options, I aim to cater to different team preferences and working styles.
Stay tuned for more updates, and feel free to explore my PRD structure to help your own product documentation process. If you can see areas of improvement, please let me know! I appreciate all feedback.
For More Tips
I have some other Product Management content here if you found this useful.
For my past tips check out my past posts on Substack or check out the hashtag #JohnsTipOfTheWeek on LinkedIn.
I’d love if you subscribed! I’m trying to build a bit of a following to try and help folks in the industry and make their jobs a little bit easier.