PMs 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, let's 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 authentication.  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 authenticated 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 authentication? 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).