Modern ways to create Product Requirements Documents (PRDs)

A decade or so ago, if you were starting out in product management, one of your key responsibilities would have been ‘product requirements documentation’ (PRDs). I remember back in 2013, when I had recently joined a startup, I was working quite closely with a former Microsoft PM who had just joined the startup too. I was completely blown away when he showed me the level of detail he included in his user stories.

It included the smallest details about what should happen when something was clicked and a bunch of different error states for each component. A single feature specification could be pages and pages long. Being a relatively new PM at the time, I was actually impressed at the level of detail he’d included. But fast forward just a few months and I quickly realised that extensive, detailed product requirements aren’t necessarily always a good idea.

2/ An incoming PMs asked: is there a standard PRD template we use here at FB?

The FB PM responded: I haven’t written a PRD in 4 years.

The rest of us: ? ? ?

— Zev Lapin (@ZevLapin) February 21, 2022

The downsides of product requirements documentation

An overreliance on highly detailed PRDs can create an unhealthy culture where team members become accustomed to outsourcing their thinking.

Team members can disengage from the scoping process entirely or use the requirements documents to rationalise why something was built a certain way when instinctively it doesn’t feel right (‘well it wasn’t on the ticket so it’s not done’). An excessive focus on PRDs is unhealthy.

The modern approach

More recently, it’s been seen as cool and trendy to not have too many product requirements; PRDs are sometimes perceived as staid, old fashioned and corporate. And there’s some element of truth in that.

Teams shouldn’t rely unnecessarily on PRDs and the idea that the product manager is the sole person who sits down and writes lengthy documents to feed the engineering team with is certainly not the way many modern product companies operate.

But, having said that, there is a healthy balance to be found between the ‘zero requirements go with the flow’ attitude and the JR Tolkien’s Lord of the Requirements approach. And new modern tools plus a shift to remote-first working have kickstarted a renaissance in documentation.

Let’s explore some of the ways you can find the right style for product requirements that works for you and your business. But first…

What do we even mean by requirements anyway?

When you first think of requirements, you probably think of user stories. And sure, user stories are an important part of the picture. But requirements actually start with your product vision, strategy and roadmap.

The PMs role is to define the ‘what’ and the ‘why’ of what it is your team is going to build. Requirements, therefore, are usually the domain of product managers and product designers.

Context setting and scoping

• Vision – who are we? What are we here to achieve?
• Product strategy and roadmapping – what have we decided to build / why?
• Feature scoping – what might the first iteration look like?

Functional requirements

• User stories – specific functional requirements that have been agreed
• Prototypes – designs that have been agreed that can be referenced in user stories

It’s helpful to think of your requirements as contextual vs. functional. For the purpose of this post, we’re going to focus on mainly functional requirements, assuming that your product strategy and roadmap are agreed. But that doesn’t mean that your functional requirements documents won’t acknowledge – and link to – your wider strategy, too.

How it all fits together

Product requirements documents can comprise of a few key elements, each drawn from specific phases of the product creation process:

1. Context – what are you building? Why? What does success look like?
2. Scope / shaping – what does the first iteration look like?
3. Backlog – what are the functional requirements?
• Epics
• User stories (with links to prototypes)

The process of creating requirements can involve cycling through the scoping / shaping phase a few times to agree scope before then agreeing the finer details of the functional requirements.

Hubs for linking docs together

The beauty of modern tools that PMs have at their disposal is that it’s relatively simple now to pull each of these various strands together.

Thanks to interactive document creation tools which encourage the creation of hubs, you can easily embed and reference other docs and consolidate them all in one place.

This is particularly helpful for larger projects which involve multiple stakeholders from various parts of the business.

1. Context

Templates to help you set the context / link to strategy

• 27 questions template – useful for asking yourself fundamental, strategic questions before kickstarting a new piece of work
• Amazon’s ‘Working Backwards’ press release – Amazon employees produce a consumer-focused press release before launching a major new product to help articulate the value it offers to customers
• Roadmap templates – to explain what you’re going to build
• Strategy templates – to explain why you’re going to build it

2. Scoping / shaping requirements

During the scoping / shaping phase, it’s likely that you’ll have wireframes, user journeys or prototypes that you’ve potentially tested with customers that bring to life the idea or the concept of what it is you’re aiming to build.

Engineers, designers and product managers can work together during this phase to agree the scope and shape the first iteration of the product.

2. Backlog

Should this even be called a backlog any more? The word backlog already creates the impression that the team is running behind on timelines and that there’s a big list of stuff sitting on a Jira board waiting to be done. Now, that’s probably factually correct (there’s always stuff to be done), but the word ‘backlog’ is hardly inspiring – and is potentially anxiety inducing!

One way to resolve this could be to separate out your backlog from the work you’ve actually committed to work on to build the features you’re building.

Any fans of the Getting Things Done framework or users of the ‘Things’ app will understand this concept of dumping stuff into an inbox that can later be prioritised. When I think of a backlog, I think of a dumping ground like this. But there’s no need to expose engineering teams to this, unless those items are set to be developed. In this case, it’s probably best to separate out your dumping ground backlog (things you might do) vs. your execution backlog (things you’ve decided to build).

Alternative names for your backlog to describe the work you’re focused on

• Focus board
• Commitment board
• Team board
• Build board
• Delivery board
• Execution bucket

Whatever you call it, we’ll stick to backlog for now, just for ease.

Epics

According to our survey, the majority of product teams are using Jira. And one of the neat features of Jira is the ability to create Epics. The simplest way to use an epic is to create an epic which represents a specific feature.

You can also use epics to link back to goals, but I find that this can confuse things. You’re probably better off using labels instead for this or linking items back to goals in your context / strategy instead.

User stories

Caveat: not everything has to be a user story. A task on a Jira board might just be a simple representation of the work rather than a detailed set of requirements.

It’s also important to note that whilst this can be used as a guide, you don’t have to stick to a rigid template for every single story. The challenge with functional requirements is getting the balance right between having a structured set of requirements that will help your engineering teams understand what you’re trying to build and having a rigid set of dogmatic processes that are always adhered to, regardless of other factors. It’s best to be pragmatic and not dogmatic.

The anatomy of a pragmatic user story

Our suggestion is that a pragmatic user story should contain the following elements:

• Core user story including actor e.g. as an admin user, I can X so that
• Essential functional details – a summary of the core functional details. Bullet points keep this brief and easy to understand
• Scenarios – information about what to do in different scenarios. These can be discussed during scoping / sizing sessions and don’t need to be completely exhaustive! Smart engineers will think through scenarios and work with you and the team as they’re building it and agree pragmatic solutions on the fly
• Link to designs – ideally these designs should be as fleshed out as possible, but you’ll inevitably need to tweak and iterate the designs as you build
• Link to epic or labels – provide wider context on where this story fits into the bigger picture.
• Comments or questions – use the comments space to document important decisions or clarify questions. There may be a time lag between agreeing the size and scope of a functional requirement and actually implementing it. Comments that are easy to reference and understand will be super helpful for your future self to re-read and understand why a decision was made.

Example

A note on subtasks

Instead of creating user stories for every single piece of detail, in my experience it’s easier to keep user stories relatively broad and then create sub tasks – or smaller chunks of work – off the back of these.

The subtasks can be created by the engineering team to ensure the work is more easily digestible. A user story will often (but not always) represent so much engineering work that it sits in progress for a long time which can be confusing and demotivating. Splitting user stories into smaller, more digestible chunks keeps things fluid.

Bringing it all together

As we mentioned at the beginning, the era of lengthy, 20 page+ documents written by PMs designed to ‘feed’ the engineers with as much work as possible are mostly over.

In modern product teams, pragmatism wins over dogmatism. People wins over too much process and communication wins over the Jira-ticketification of everything.

That said, with the shift to remote and hybrid working, documentation is actually becoming a little more important than perhaps it was in the pre-covid era. This shift has led to the creation of a bunch of super helpful tools designed to make document creation and linking knowledge bases much easier.

The challenge for modern product teams is to figure out how to use these tools best, without returning to the dark days of death by documentation.