Don’t let your first Product Requirements Document be your last

10 min read
Share on

Joining a tech company as a new Product Manager can be extremely intimidating – especially that moment when you’re asked to publish your first Product Requirements Document (PRD). 

This post shares some fresh research on how product managers are feeling when writing PRDs followed by a practical tool to hopefully solve this problem. This should help you to auto-generate PRDs with less time, less effort and – most importantly – less anxiety!

Back story

In 2018, less than a month into my new role as VP Product at Gojek (South East Asia’s 100m customer Superapp), I experienced one of these moments. 

After pitching a new product idea to the then CTO Ajey Gore, he asked me to write a PRD before he would commit resources. This made me super nervous. Best case scenario – everyone loves the doc and I get my resource. Worst case – it is publicly torn apart by design/engineers and my personal stock plummets.

In an attempt to avert this mini-crisis, I asked him for a template, but discovered there wasn’t one. I asked him what ‘good’ looked like here and, in return, received a few examples from other product managers. However, these were all very different and left a lot to the imagination.

Is it just me?

Turns out I’m not the only one who has experienced this pain. 

During my final month at Gojek, Dian Rosanti – the Head of Product Management – asked if I could solve this issue for her as she was seeing the same pain across the ~20 product managers in our Consumer Platform team. 

Then just this week, whilst chatting to some FAANG product managers in a private group, I saw an indication that this is actually a wider issue. 

I decided to run a survey to 70 product managers in my personal network across several product companies including Gojek, Google, Flipkart and Square and quickly confirmed this suspicion. This prompted me to share this knowledge more widely as it’s clearly a common problem that doesn’t seem to be talked about – you’re just expected to know.

What is the Job to be Done here?

For those of you who’ve read my blog, you’ll know I’m a huge fan of the Jobs to be Done (JTBD) framework when solving problems. Below you will see the process I followed in order to identify and understand the associated pain points, which ultimately led me to build out a tool. Here are the care jobs:

  • Functional job: Create my first PRD inside a new company
  • Emotional job: Feel proud of my work in my first 90 days as a product manager
  • Social job: Don’t lose status among my new peers

Read more about the JTBD framework

What pain points do product managers have whilst executing this job?

I discovered the pain points below after interviewing a few product managers in Gojek and each one became a question in the survey. After completion I then ranked in descending order of pain intensity:

Pain points in rank order of largest intensity

This certainly resonated with my own experience – especially avoiding engineering confusion! 

After some deeper analysis, I saw that years of product manager experience was a key predictor of pain. The chart below shows the linear trend for each pain point by years of experience. Notice Shaming (worried people say my PRD is of low quality) and Examples (help me know what ‘good’ looks like) both start high and massively decrease as years of experience increase.

Trendline for each pain point by years of product manager experience

Clearly we need to be coaching and mentoring our younger selves before letting them send out these very social documents to avoid confidences taking a huge unnecessary hit.

Interestingly Designers (ensure PRD gives designers the right context) and Structure (effort to ensure PRD has good structure) were two pain points that actually became more intense as experience increased, which again resonates. I recently led Gojek’s superapp integration to an Indonesian neo-bank they’d invested in. The work involved 9 different product teams and 3 design heads all working in sync and needed a very simple PRD to bring all these complex requirements together – particularly compliance, ops and risk.

Whilst the survey covered 13 countries, for one single question, there was a clear difference between Eastern collective cultures (e.g. Vietnam, China, Singapore) and Western individualist ones (e.g. US, GB, Australia). 

Pain compared: Eastern cultures vs Western

Product managers from Eastern cultures cared 32% more about Shaming, which very much aligns to certain cultural anthropological theories and my own experience working in Asia this past decade in mixed culture teams. 

Consumer-facing companies product managers were also more likely to care about being socially bashed – 25% more than the other company types – whereas product managers in SaaS companies cared 25% less. I imagine the difference is that a product change is much more likely to provoke a Twitter storm when you have 100m of consumers vs a few thousand businesses. 

In 2020 we revamped our app design at Gojek (see image above) and the subsequent internet outrage was felt internally for months afterwards leading to a huge pivot to caution for any future release that affected learned UX.

Read The (Def)inition Lab: Our recipe for reducing the risk of product failure

What makes a PRD well received by team members?

After gathering what were commonly believed to be the best PRDs across many product groups, I analyzed what information they contained to understand what made them well-liked; I then categorized them using MoSCoW:

Frequency of sections found in best PRDs (and MoSCoW)

The solution

Due to all the orange ‘should’ sections and the variation in pain points from my survey, I quickly realized that a rigid generic template wasn’t the solution—especially when comparing those PRDs which were front end heavy vs the more technical/platform ones.

I decided, therefore, to create a more flexible PRD Generator that could attempt to solve all these pain points. Product managers can pick from a shortlist of boilerplate sections depending on the type of PRD being created to get a clear logical structure in place from the beginning. I then added simple instructions for what they might want to write under each section header. 

This PRD generator is now being used both inside Gojek and in my new company too. Amazingly, the effort to implement this across my current product team at Prodigy Finance and get 100% adoption consisted of me posting a three-minute Slack video showing a screen share of how to use the tool in our product channel. This suggests that the pain is much higher than the cost of the behaviour change.

A few selected individual’s feedback so far from the two companies:

  • A junior product manager – “I love this… ‘so we spoke to 150 product managers’ 🤣 Product Science for the win!”
  • A lead product manager – “It is terrifying that first one.. This really helps – especially for my new product managers”
  • A product head – “It’s amazing!”
  • A Chief Technical Officer – “I’m using this as standard going forward as it sets a base level of expectation”

Two simple steps to use this for your own PRDs

  1. Open the PRD Generator and tick the sections in column D you’d like in your PRD. There are two examples in column E and F for reference, although this could be different in your company.
  2. Click the ‘Generate PRD’ button and follow the instructions. You’ll then see a new PRD open in your Google Drive Recents. Note: you must be logged into a Google hosted account and will need to Authorise the app script permissions in order to run. If you get a ‘Google hasn’t verified’ warning, you can go to ‘advanced’ to let it run or copy the sheet to your personal account first and run there.

How did I create this?

I started by creating this simple Google Doc template, which you can copy and change to your own company’s branding. NOTE: You would then need to change the doc ID to your new template in the App Script line 10 – you can get this from your new template’s browser URL).

templateFile = DriveApp.getFileById(‘1e0spBzwQDWG45oLeS42G5_UxZshC759D5YRnhi9Wdio’);

I then wrote code to go row by row, in order to see which sections you ticked and then pull the respective headers and boilerplate text from the sheet into the doc. This gives you flexibility depending on the PRD; also if these sections and boilerplate aren’t quite right for your company, you can simply edit them.

I really hope you find this useful for yourself and your teams. It would be great to get your feedback as I’m sure there are many different viewpoints out there with some even saying PRDs aren’t necessary in Empowered teams. If you’re interested to chat further or interested to join our team, feel free to connect on LinkedIn

Discover more content on the Product development process. Engage with further insights using our Content A-Z.