The Dethroning of the PRD by Agile Feature Documents

As a Product Manager, you have most likely come across the term “Product Requirements Document” (PRD). You have probably also iterated with different ways of working to be more Agile. Maybe you then also experienced that the PRD is a bit of an awkward fit, even though you felt the need for some kind of document. At Delibr, we have interviewed over 300 PMs about how they work with detailing out new features, and so are starting to get a grasp of the zeitgeist of the PM community. Let’s have a closer look at what made PRDs so common, and how PMs are gradually adapting the concept to fit an Agile world.

Hail to the PRD!

If you are not entirely new as a Product Manager, the concept of PRDs will be familiar to you. PRDs have been around for a long time. They are widely spread and commonly used by PMs, and there are good reasons for that. Essentially, a PRD defines the product you are going to build, its purpose, features, and functionality. It focuses on things like why you’re building the product, what problem it solves and how to measure success (often through KPIs). PRDs provide clarity of expectations.

Having a document that captures these details makes a lot of sense in most cases. It helps to collect and explain everything the development team needs to know in one place. It simplifies creating clarity around the development process, capturing input from stakeholders, and ensuring all relevant details are covered.

In the land of Waterfall, the PRD is king

So, it makes sense to write some kind of document, and the PRD is the most common kind. But is it common because it represents the best way of working, or is there another reason? Let’s look at how Wikipedia defines PRD:

“A product requirements document (PRD) is a document containing all the requirements to a certain product.”

If we look closely at what it says, we can see clear remnants of the origin of the PRD, namely the Waterfall methodology. It turns out that the concept of the PRD predates the Agile Manifesto, and so has had plenty of time to spread. Specifically, there are two aspects that can be problematic for teams that try to be Agile:

The scope of the document - “...containing all the requirements to a certain product…”
The format of the content - “...the requirements…”

One document to rule them all

As originally defined, the scope of a PRD is a product, meaning all of the features of that product. This runs counter to how many PMs work nowadays, as the team is usually only working with a single feature at a time, not across the whole product. A feature, sometimes referred to as an “epic”, is commonly expressed as several user stories. Having all the features with all their user stories laid out with details in a single document, one after another, risks creating a very long and complicated document. Such documents are hard to manage, and risk making the life of the PM unnecessarily messy and confusing. Not only that, but having a document with such a large scope, will also make it harder for the PM to work with smaller, clearly separated, and thus more manageable increments. There is a risk that a product-level document will pull the PM from Agile towards the Waterfall, so to speak.

Requirements, handed down from above

Another aspect of the PRD that is problematic and has remnants of the Waterfall methodology, is what is implied by the word “Requirements”. In Waterfall development, the role of the PM is to a large extent that of a requirements gatherer, who hands down a list of requirements to the development team and is less involved in the process after that.

The first issue with thinking about “requirements” handed over from the PM to the team, is that it gives the team both less opportunity and less inclination to give input. The development team often knows better than the PM how long time it would take to build certain functionality. Therefore, handing down a fixed set of user stories and acceptance criteria without any back-and-forth with the team before, risks going wrong in two ways. Either, the PM might “require” something that is valuable but very time-consuming to do. Or, the PM might hold back on something that would provide some value, and would be very simple to do. Both scenarios would bring down the pace of value-creation by the team.

The second issue is that, in reality, a clean handover almost never happens. The initial requirements may have made perfect sense to the development team at the time of the handover. But new issues come up all the time, as reality often catches up with plans. Once it does, if the process implies a one-way handover, the team will be less likely to go back to the PM. As a result, there is a risk that the team spends its time building functionality that would not have been prioritized, had the PM known the actual amount of time required to build it. It’s hard to swim up a waterfall.

The PRD is dead, long live the Feature Document

Ok, so it is good practice to use a document for feature refinement, and most PMs work with a document they call a PRD. But arguably, the scope of that document should be a single feature, rather than a whole “product”, and it is important not to be too literal about the word “requirements”, but to think of it as a back-and-forth.

Therefore, we suggest dropping both “product” and “requirements” from the term PRD, and as only “Document” would be too nondescript, we suggest using the term “Feature Document” (sometimes descriptive is better than imaginative). Many teams already de facto work along these lines, and so it may not seem that using the term “Feature Document” instead of the term “PRD” will make much of a difference. However, how we talk about things matter.

By clarifying that the document is about a “feature”, it becomes clear to everyone what the scope of the document is. This clarity will make it easier not only to keep the scope of the document small and manageable, but also to actually work with smaller and more manageable increments.
By moving away from the term “requirements”, the implication of a clean handover from product to tech is reduced, opening up for the necessary discussion between product and tech regarding value vs. feasibility. Many teams are missing out on this, and so often work on features whose benefits are not proportional to the time they take to implement.

Live like a king, using Feature Documents

As you have probably been able to tell by now, we believe “Feature Documents” is the right frame of mind to work with. But we did not only interview lots of PMs to figure out the best way of working. We also developed Delibr as a tool to make life easy for PMs writing and collaborating around this kind of documents.

To help PMs write documents that allow for focused collaboration at the feature level, we worked together with PMs to create the perfect setup and template (as an example, here is an article on the impact this had for Storytel).
To help PMs move from handing down requirements to instead collaborate around features to build, we included advanced features for collaborative decision making, an integration that allows the PM to let the document live on in Jira (no duplication of work, relevant parts from the document visible to the developers right within Jira), and a way to instantly turn selected parts of the document into a stakeholder presentation.

By working in smarter ways, it is possible to spend less time creating a shared understanding of features to build. And that makes life as a PM a lot easier.