Author: Nils Janse

Broken crown

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:

  1. The scope of the document – “…containing all the requirements to a certain product…”
  2. 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.

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.

decision delibr

Product Managers face more decisions than they realize (but fear ye not!)

When detailing how to build a feature, PMs must make sure a lot of decisions are made. In our interviews with over 300 PMs, we saw that the best of them handle this without becoming overwhelmed by properly framing and following up on these decisions.

The Iceberg of Micro-Decisions

Most PMs don’t think about it this way, but a core part of their job is facilitating decision making. For every feature they build, they need to make sure lots and lots of decisions are made. Some are obviously decisions, such as when to build the feature and what functionality to include in the first iteration. But if you think about it, almost every aspect of a feature can be boiled down to a decision that needs to be made.

To emphasize this multitude of decisions, we like to talk about micro-decisions.

Micro-decisions can be of all kinds. Their topics range from scope to tech to design to copy. For example, when choosing a tech library or determining what data structure to use, you’re making a micro-decision. Setting the sequence of a user flow and selecting what type of component to use (e.g. modal vs. popover) are also micro-decisions.

There is a challenge to facilitate these micro-decisions effectively. The image below tries to illustrate the process of a typical PM. Most PMs write some kind of document as they detail out a feature to build. Ideally, this document is actively worked on from when the feature is first thought of until it is deployed (otherwise the PM will face even more problems). This, lets call it feature document, is then discussed during a number of meetings. Three types of questions typically pop up:

  1. Questions directly relating to one aspect of the feature, e.g. “What tracking should we add for this feature?”
  2. Questions relating to the status of one of the above questions, e.g. “I can’t remember, did we make a decision on this?” or “What were the reasons for that decision?”
  3. Questions relating to the overall status of the feature, e.g. “What is left to decide for this feature?”

Many PMs struggle – keeping up with so many questions on a daily basis is difficult.

Specifically, two parts of how PMs handle these challenges warrant further attention:

  1. How they frame micro-decisions to make them easy to discuss and come to a joint conclusion on.
  2. Where and how they note down and follow up on micro-decisions to make it easy to see what has been decided, why, and what is left to decide.

In our interviews, we saw many different approaches to this. We also noted a wide variance in how well PMs thought their approaches were working. How you handle this can affect not only your mental health as a PM, but also the quality of your product and the satisfaction of your team. Yes, the devil is in the details.

Framing 101

It matters how PMs try to capture the decisions that are being made. It almost always makes sense to take notes on decisions relating to the feature. Exceptions can be if everything about the feature is entirely obvious or if everybody giving input to or working with the feature will be present in all meetings where the feature is discussed.

When writing down information about a decision, the way it is written down can affect how easy it will be to collaborate around. There are three main ways of framing decisions, with increasing degrees of explicitness:

1. Implicit decision in text

One common way decisions can be captured in a document is by being referred to implicitly.

Let’s clarify by looking at the example of choosing OAuth as the standard for user authorization. Implicitly capturing such a decision could mean part of a technical description of the feature contains text along the lines of:

“..then OAuth access tokens will be sent..”

The benefit of this approach is that it is lightweight and requires little upfront time or effort. But the decision lacks visibility. This increases the risk of the decision not being noticed by people that may have a valid objection. It also increases the risk that different parts of the document imply contradictory decisions.

2. Explicit decision

Another approach for capturing decisions is by simply stating the decision in plain text.

Using the same example of OAuth, this may look something like:

“Users will be authorized using OAuth.”

This approach requires some effort but solves the problem of decision visibility. However, a person reading this does not get any sense of the considerations that preceded the decision or if any alternatives were considered.

3. Explicit question with decision as answer

The third approach is to explicitly state the question that the decision tries to answer, and then write the decision as an answer to that question.

For OAuth, this may look like:

“What standard to use for user authorizarion? OAuth.”

This approach requires a bit more effort upfront, as it forces thinking on what underlying question the decision addresses. Writing both the question and the decision also typically makes the document a bit longer, as opposed to just writing the decision.

But this approach also brings a number of benefits:

  • Writing the question also means thinking about the problem being solved.
  • Asking a question opens up the thinking to alternative answers.
  • Evaluating different alternatives typically yields better decisions.
  • Writing the rationale down makes it easier to come back to the decisions.

Many decisions benefit from being formulated as answers to a question. And the effort of doing so is often worthwhile. When formulating explicit questions for your micro-decisions, there are three things to think about:

Use judgment when evaluating the number of micro-decisions write out explicitly as both question and decision.

Too many questions and you won’t see the forest for all the trees, too few questions and it is likely that you are not exposing your thinking enough to your team/stakeholders to enable them to give you feedback. For example, questions, where the answer would be a point of fact rather than a decision, do not need to be written out. The litmus test for elevating a micro-decision as an explicit question is:

“Is this an obvious choice, or is it possible that any stakeholder/team member would object to this?”

So, how many questions should there be for a feature? – “How long is a piece of string?” – no seriously, it of course depends, but if forced to generalize, based on what we have seen, 10-20 questions are probably the right amount for a feature that takes one two-week sprint to complete.

Aim to formulate unbiased questions with options that can be expressed concisely.

To simplify, there are three types of questions: Yes/no, multi-option, and open. Some decisions are better stated as yes/no questions, but often it is meaningful to rephrase them as multi-option questions, as that opens up the thinking to alternative answers. Don’t use questions that are too open, as these are harder to give a clear answer to, and thus to make a decision on. Instead, break them down to questions that can have concise answers. Moreover, formulate your questions in an unbiased way, even when there is a strong hypothesis, making a preliminary decision is a better way to reveal the hypothesis.

Differentiate between enumeration and evaluation.

For less obvious decisions, it often makes sense to enumerate multiple options by brainstorming. When doing so, try to forget which options are “good” or “bad”. Collect and list everything that comes to mind. Then evaluate them to see which is best, and make a decision. Separating these different kinds of thinking often leads to better decisions.

Following Up 101

PMs who are diligent about capturing micro-decisions and framing them properly run into the next problem: Now there are a lot of decisions to facilitate and follow up on.

In our interviews with PMs, we found four different ways of dealing with this challenge, each with its pros and cons:

1. Separate Spreadsheet

Some PMs keep a separate spreadsheet where they track all the decisions to be made relating to a certain feature (as in the image below).

This approach makes it natural for PMs to formulate decisions as explicit questions as well as show decision status and other comments. However, it tends to be cumbersome and time-consuming, especially since the questions are removed from their context, into a separate document.

2. Separate Section

Some PMs have a separate section in their feature document where they write down questions that need a decision (see image below).

This approach also makes it natural for PMs to formulate decisions as explicit questions, but decision status is often not as clear. Also, even though the decisions are now in the same document, they are still somewhat separated from context, which typically leads to a lot of scrolling.

3. Document Highlights or Comments

Some PMs make highlights and/or comments in the sections of the document that the decisions pertain to. A common pattern is to highlight parts of the document to indicate that a decision is needed, another is to call out that a decision is needed using document commenting functionality (the image below shows what highlights might look like).

Unlike the other two approaches, the decisions are not separated from the context. However, the approach often leads to decisions never being stated as questions, the status of the decision is not always clear, and comments can be somewhat disorganized. Also, once the decision is made, highlights and comments are often removed, which makes it difficult to know if there was any discussion, and if so what was said.

4. Within Relevant Sections

Some PMs write decisions as explicit questions in the sections of the document that the decisions pertain to. This is typically done by writing the question on a new line. Alternatives considered and other details on the discussion can be added and indented below (see animation below).

This approach ties together the best parts of the previous approaches, and we found that PMs that use this approach managed to combine working within a context with clarity regarding decisions being made.

It is probably not a surprise that we at Delibr are strong advocates for the last alternative, option 4. We typically advise PMs to move away from option 1 (separate spreadsheet). But if a question has come up and it is not clear where in the document a question should go, option 2 can make sense (separate section in the document with open questions). Option 3 (highlights and comments) can make sense when the underlying question is not yet clear or to indicate parts of the document that needs more work.

Taken together, we have come to believe that by capturing the many micro-decisions as explicit questions, written within the section of the feature document they pertain to, PMs can stay on top of facilitating all the micro-decisions they face.

To make working this way even better, we have built-in collaborative decision making features into Delibr, that make working this way even easier (the animation above shows how it works).

How the Storytel team uses Delibr

How Storytel gets a shared understanding of features they build

Good PMs write some kind of document to detail how to develop a feature. This gives the team a central place to know what has been said and decided regarding the feature. To be useful, this document needs to cover the most important details, and so commonly runs to a couple of pages. With several PMs writing quite a few such documents, this amounts to a lot of information.

Some teams go all-in on writing things down and get stuck and lost with all the resulting information. Some teams balk at the prospect and don’t write much down at all, with insights being lost and mistakes made. At Delibr, we believe that it is possible to get the best out of both worlds by working in a structured way, using a template as a starting point.

David Božjak, Tech Manager at Storytel, put it succinctly:

“My team at Storytel has been using Delibr’s feature refinement templates for several months now. There are too many benefits to enumerate all, but giving a consistent structure to our projects is key.

Now everyone in the organization, regardless of position, knows what to expect when they follow a project link and knows where the information relevant to them will be in the structure.

We no longer struggle with keeping our projects sufficiently documented, we always start with a template and then we insist we do all our work – even Jira – from the Delibr document, and the documentation is done automatically.”

Let’s break it down to (i) why a template helps, (ii) what template specifically to use, and (iii) what is required of a tool to make the most out of using a template.

The Magic of Using a Template

Every feature is different, and the details will vary. But over time, the documents often need to cover the same or similar topics. Therefore PMs will typically find their writing style over time, and converge on a format to use as a starting point.

This works well with 1 or 2 PMs in the organization. But, as the organization grows, so does the total number of people writing feature refinement documents. Without any effort or thought going into this, the result is likely that these documents will look quite different.

Generally, for any process that is repeated many times, variance can be problematic. Specifically, if every PM has their individual style of writing documents, this will lead to two problems:

  • It will be much harder for the person who will read these documents to find the information they want if they all look different.
  • If the PMs have not talked to each other to find a “best practice” for writing feature refinement documents, it is likely that variance between how they write these documents means that some PMs do it less well. This likely means that feature refinement quality is suffering as a result.

The solution to problems with variance is to standardize. A good way to do this is to agree on a template for all PMs to use as a starting point when writing feature refinement documents. To keep flexibility and avoid limiting the PMs in their work, it is important that the template is just that, a starting point.

Using a template as a starting point for writing feature refinement documents can yield three benefits:

  • It can reduce “writer’s block”. If you have ever dealt with it, you know that this can be quite a hurdle. Templates can help with this. Rather than starting from a blank page, you will have something to look at and start with, helping you place your thoughts into a structure. This will speed up the writing process.
  • It can make it easier for the team and stakeholders to navigate within the document and find what they are looking for. If a consistent structure is used across documents, the documents will be readable and easy to use for the whole product development team.
  • It can ensure that the most important aspects of your features are covered. This, in turn, can increase the quality not only of the documents but the entire feature refinement process. Of course, this requires that your template actually covers the most important aspects.

Principles for Good Template UX

At Delibr, we have interviewed over 300 PMs about how they work with feature refinement. We found some principles that the best PMs use to write documents that help facilitate the conversation. Based on those, we developed what we believe is the best feature refinement document template to start with.

Some of the principles we found:

At the epic level. With a too big scope, the document tends to grow and become unwieldy and risk becoming obsolete. With a too narrow scope, it risks not properly capturing the reasoning for developing the feature. Normally a single user story is a too narrow scope, as it is often a combination of several user stories, an epic, that solves a user need. It all depends, but if forced to generalize, we’d say that an epic should comprise of 3-12 user stories, and last for 1-3 sprints. If an epic risks lasting more than a quarter, it is probably better to restructure it.

Both discovery and delivery. As we have written about before, it makes sense to spend time in a phase of feature discovery. Separating out discovery ensures that only features that make sense to do, i.e. that are valuable, usable, and feasible, go into development. The big risk with this is that discovery and delivery get too separated. It is surprisingly common that the actual feedback or data that led up to the feature being developed is not known to the developers implementing the feature. A good way to mitigate this is by using the same document for discovery and delivery. That way those who develop it can always just scroll up to see the problem statement as well as any recorded customer feedback or underlying data. (I know what you’re thinking, these documents could get massive. Don’t worry, we got a solution for this).

Structured for stakeholder readability. People will read the document in different ways. Executive stakeholders will read from the top and want a concise description of the problem, the solution, the success criteria, and the roll-out plan. The stakeholders that requested or are affected by the feature will also be interested in what user stories will be implemented. Specific functional stakeholders find it helpful to have a section of the document that speaks directly to them (e.g. QA, design, analytics, copywriting). And the team will go all the way, into the details of each user story and down to further details.

Focused on user stories. Stating the obvious here, but user stories are really useful. We found the main benefit of user stories (relative to “pure tech tasks”) is that they make it easier for non-tech people to understand what is being developed, and so enable better slicing decisions (i.e. decisions on feature scope). Because of this, we have found that documents centered around user stories are more effective. The way to make a document truly centered on user stories is to let the document evolve with the user stories.

  • In the early stages of writing the document, the focus will be on clarifying the problem and sketching a rough picture of what the solution might look like. Then it will be enough to capture relevant user stories and write them down in the document.
  • In the middle stages, the focus will be agreeing on the scope of the feature. Then the most important thing will be to prioritize which user stories to include, sorting them and moving some of them into a “later” subheading. To do this, it can be a good idea to do a user story mapping session and then paste a photo from the whiteboard into the document.
  • In the later stages, the focus will be figuring out more about how to fulfill the user stories in the first iteration. Then it is time to add more details under each user story heading, e.g. acceptance criteria and use cases as well as designs, copy, flow, and technical micro-decisions. If done properly, this can save time, in the transition to Jira.

Based on the above principles, we developed the “Epic Refinement Template” for our app:

But of course, the template is just a starting point. It should only be used as a base and be open to changes. Depending on the feature, it can be adapted with judgment, with headings and sections added, changed, moved, or removed. And working dynamically with the structure of a document is much easier using an outliner.

A Powerful Duo: the Template and the Outliner

An outliner is a type of document editor where the document is represented as a tree structure with bullets.

The screenshot above is an example of what a document can look like in an outliner. It is possible to switch view and see the document like a “normal document” without indentation and with headings of a different font.

Working with a document in an outliner gives the editor more flexibility in engaging with the structure of the document, e.g. zooming into, collapsing, or moving around parts of it.

In combination with a template, an outliner brings three benefits

  • First, by collapsing the document down, a reader can navigate among the headings of the template faster. A reader that is new to a document does not have to be overwhelmed by all its content but can dive directly into the parts relevant to them.
  • Second, working from an overview of the headings in the document, it becomes simpler to add things to the right place. This makes it easier to adhere to the structure of the document.
  • Third, changing the hierarchy of headings or adding new sections is effortless and does not risk messing up the whole document. This gives flexibility and reduces the risk of becoming too rigid in following the initial structure of the template.

Delibr is an outlining tool designed to make all of this easy. In addition, since it is made for Product Managers, it has an integration with Jira. The integration makes it possible to create and link Jira issues to parts of the tree structure, as shown below.

Taken together, this helps Storytel to create a shared understanding of the features they build in the whole organization. Are you interested in trying Delibr and see what it can do for your organization?

Double Diamond: Designer’s Mindset for Improving Feature Development

Double Diamond: Designer’s Mindset for Improving Feature Development

Does the term “Double Diamond” sound familiar? Chances are, it does. The Double Diamond model describes a framework that designers use. Originally intended for developing physical products, this model has recently started gaining popularity in software development, and for good reason. Understanding how the Double Diamond fits into Dual-Track Scrum can help you work better with discovery sprints and understand the design process on a deeper level.

Read more

feature discovery and delivery

Feature Discovery and Delivery: To Split or Not to Split?

Being a PM is not a piece of cake. You probably know that by now. You have probably also encountered a long list of features hanging in the air, unsure why half of these features were on that list in the first place. This is exactly why brief discovery projects are important in figuring out whether it’s worth developing a feature before going into the details of how to develop it at all.

Read more