The prioritization of anything complex must be a collaborative process.

This article is a refreshed version of the original, which was published on Medium, Feb. 14, 2020.

According to Dictionary.com, the first two definitions of priority are listed as:

1. The state or quality of being earlier in time, occurrence, etc.
2. The right to precede others in order, rank, privilege, etc.; precedence.

We use the term a little differently in the software development industry.

In our world, prioritization is –

The art of combining everything we think we know about the past with the fixed resources we have right now to predict the order in which to do things to improve our collective future.

It is complicated, imperfect, and messy. The most powerful prioritization schemes are those which align our teams and empower them to make better decisions.

Many models exist intending to help us prioritize in a more objective and data-based way. These frameworks try to balance value, cost, and risk. In my experience, they rarely work because it is nearly impossible to capture, in any objective way, all of the possible factors that influence those things. When trying to use logic to objectively prioritize features in a software product, what tends to happen is the creation of politics, lobbying, and divisiveness between factions.

Seemingly by default, the most outspoken and/or highest-paid person in the room, the HiPPO, typically makes or powerfully influences the priorities. Before we came to this realization, this is how it had always been done and it was how our teams were practicing prioritization.

We also realized that our approach wasn’t working for our users. In our fast-paced environment, where the entire business landscape is changing around us in real-time, we needed a better way to prioritize and to empower our teams to drive what happens first, next, or not at all.

No matter the quantity and quality of the data we have, the best that we can ask of it is a prediction. There are unknown factors and unpredictable “black swans,” as we are seeing now, that impact our decisions around priority – often to our detriment, but not always. Sticking with the theme, black swans can be positive; we refer to them as blue birds, which symbolize joy, hope, and harmony.

Thus, we are always using a combination of data and intuition to navigate these decisions. From where I sit, it is better to have a group of motivated people, each of whom is committed to a shared set of goals, agree to a prioritization scheme together than to rely on the intuition of a single leader.

Alignment, confidence, and commitment result when a group is able to prioritize together.

Feature prioritization is hard work. Determining the minimum viable product (MVP) for your digital solution is near impossible to get right on the first try. For many, that can be a tough pill to swallow, because getting the MVP right has the potential to make or break your product. But remember this: whatever features you decide to include and whatever process you choose to prioritize them will most likely be wrong.

It’s not an ideal outcome, but it is not a fatal one either. The key is to understand that it is OK to make imperfect priority decisions for the sake of progress.

The term “MVP” is an industry buzzword thrown around with the broad assumption that its meaning is accepted by all. But I have learned that it has vastly different meanings to different people.

The concept of keeping your sprints and your requirements lean is what is important to a management team, so I’ll stay focused on how to create a feature prioritization scheme to keep your backlog relevant and robust for your product.

In our 25+ years of doing this work, we have found it is more important to agree on a scheme for prioritizing features than it is to gain perfect consensus on the actual feature prioritization.

Getting leadership to agree on your prioritization methodology is a signal that you have earned their trust, and that they have confidence in your ability to do the everyday, micro-prioritizations that are required for your product to find success in the wild.

Imagine emerging from a prioritization session knowing that everyone in the room agrees on how prioritization decisions are to be made. Imagine how empowering it will be for your team knowing that that same group accepts the fact that not all decisions will be perfect, and that we are all aligned and confident in our prioritization scheme. It truly is energizing!

Each product team is different and has to figure out the right tools to work with for their unique combination of skills, knowledge, and personalities. I am not suggesting your current prioritization scheme, which you might feel is objective, is not useful. I believe any thoughtful system is better than the ad-hoc, squeakiest wheel method. However, determining how to prioritize features is extremely difficult and it is imperative to learn how to do it better.

We have found the MoSCoW (Must Have, Should Have, Could Have, Won’t Have) method creates confusion for the team because of its complete subjectivity and lack of a unifying scheme for prioritization. There’s no shortage of solid arguments for why each feature should land in the “Must Have” column. But without criteria for evaluating them and a decisionmaking process for restricting where each feature goes, discussion quickly dissolves into a deadlock with political factions arguing for their own subjective interests.

Key takeaway: Using an “objective” prioritization scheme creates a distraction from what is important: The prioritization process.

My teams here at ITX have also tried using a number of algorithmic tools and methods in the past, such as:

• The Eisenhower Matrix (Impact vs. Effort)
• RICE (Reach, Impact, Confidence, Effort)
• ICE (Impact, Cost, Effort)
• WSJF (Weighted Shortest Job First)
• And many other decision matrix “algorithms”

In most situations I have encountered, no matter what “algorithm” we are using, we still have humans filling out the scoring and weighing the variables.

While Reach (in RICE) may be objective, Impact, Confidence, and Effort are not. There are many other factors involved in prioritizing product features, but almost all of them are difficult and cost-prohibitive to quantify. They are subjective and imperfect. Using an algorithmic method will get your team stuck in analysis paralysis.

You may generate some useful dialog, but very little will get done.

Every product serves myriad user personas, so it is challenging to articulate feature priority for any given user in a vacuum. You must prioritize the personas and balance your deliveries across personas. Assessing “impact” (the ‘I’ in RICE) within each persona is also completely subjective.

The following diagram expresses how these two dimensions are often represented.

User Value vs. Business Value: Two subjective scales

There is significant merit to considering product features that bring value to your users in the context of your product, even if they don’t add much value directly to the business. Including well-thought-out features allows you to be creative with ways to valorize or monetize the data you are able to collect. For items valuable to the business, but not to users, you might want to find ways to make it fun using engagement mechanics or gamification.

Some examples of other business factors that impact your feature decisions include:

• Short-term revenue opportunities
• Long-term profitability opportunities
• Support costs
• Team morale
• Brand and Firm reputation
• Competitive positioning
• Market opportunities
• Funding priorities

Final comment on this: the effort required is ALWAYS subjective. You never know how much time and money and other resources will be needed until the work is done, according to your definition of “done.”

This is why my teams and I use relative sizing. This diagram demonstrates the complexity of systematic prioritization when you factor in these three subjective scales.

Maximizing this equation also requires a distinct understanding of who does not fit this mold. Let’s call this our core advocacy position.

If we were to draw a simple graph that shows the number of persona sets (people) that we serve on the vertical axis and the problem sets that we solve on the horizontal, our core advocacy position would be found in the lower left-hand quadrant of the graph.

As I said before, this is a difficult task. It involves creating clarity around all of the relationships that the organization has to sustain, from employees and vendors to investors and customers. The key to understanding here is that there are a limited number of people whom you can turn into advocates for your organization. Without a clear understanding of who we are here to serve, confusion ensues.

OK, here’s how to graph the equation:

a. Place the subset of customers that you have the most success in creating a sustainable advocacy relationship with, in the number 1 spot toward the core. Place the second most important group of people that you can create sustainable advocacy relationships within the number 2 spot, and so on.

b. Do the same with the problems that you solve for those people with the most important problems on the x-axis in the number 1 spot, and so on. As the graph expands, it becomes easier to see what group of people most of your energy should be focused on.

Note, however, this won’t last forever.

User Value vs. Business Value vs. Effort: All Subjective

In short, software products have to live in a dynamic world where priorities need to change regularly in order to ensure their short-term health and long-term survival. There is no perfect prioritization system.

As researcher and author Robert Sapolsky tells us:

Evolution is not about getting more complicated. Evolution is about running faster and faster while staying in the same place to deal with whatever the current pressures are.

So where do we start?

Mariano Sigman and Dan Ariely have been conducting some research into how groups make good decisions and have found results that demand our attention.

Their research shows how predictably making better decisions requires better framing of the problem. It reminds me of the quote attributed to Einstein: “If I had an hour to solve a problem, I would spend 55 minutes defining the problem and 5 minutes solving it.” (Although it is a great quote, there is no evidence Einstein ever uttered those words.)

For software product teams, our job is to frame the problem for the group properly, then allow the group to engage in challenging dialogue together in a safe environment to jointly create a prioritization scheme.

Adequately framing this problem means we must start by understanding who we are serving and agreeing on the importance of the user in the whole equation. Instilling customer empathy into the team is a step that cannot be skipped.

Brian Clark wrote about a concept called the “Minimum Viable Audience,” which is a useful way to think about the problem. If we can hone in on the minimum viable audience with whom we can achieve success by turning them into advocates, our team will be able to better focus and optimize feature prioritization decisions with the information we have.

These are the predecessors to creating your prioritization scheme before any prioritization can be useful:

• Your team must have assembled and agreed upon a primary user persona.
• Your team must have agreed on strategic goals for the user.

Stated another way, we have to agree to the long-term goals, and they should be indices that represent the relationship you are building with the user. The best goals are those that demonstrate how you are maximizing the number of “advocates” produced by the system.

RPI: Relationship Performance Indices

Short-term goals (i.e., objectives and key results) are critical steps in the short-term process to achieve tactical success along the way. But first we need motivating, long-term goals so we know where we are aiming.

The team can now make these decisions together, but with these agreements, they will now do it with a “user-centric-mind.” It is not a perfect system (as I mention above, no system is), but it has proven to work extremely well.

Once we have these things, we follow this procedure:

1. Assemble the right team with the most diverse customer perspectives. A healthy team of leaders will represent the customer from as many angles as possible in the business. It will also sufficiently represent the business’s interests. Marketing, IT, Sales, Customer Service, Support, Call Center, etc. should all be included. Including a couple of customers who are already advocates of your business can be extremely powerful.

Key takeaway: make sure the team has the influence and power to make their decisions stick.

2. Use relative sizing. Using t-shirt sizes with relative points works well for this. At this stage, it is less important to be right about the size than it is to get them right in relation to each other. Working at the right level of granularity to make feature prioritization useful is a bit of an art. It is also super important to use relative sizes and not actual sizes to keep the environment feeling “safe” from over-commitment. It is easiest to use a scale based on 5’s to reduce the team’s cognitive load when they are shuffling the features. {5, 10, 25 & 50}
3. Coach the team through the creation of the primary persona’s top five concerns. Make sure they are clearly articulated and supported by the team. You cannot do this without (a) a healthy, agreed-upon persona, and (b) alignment with the team on the persona or persona set.
4. Coach the product leadership team through the use of the Hoshin Star methodology to prioritize these concerns. Everyone must agree. My colleagues and I have created a workbook to walk through how to do this. {Reach out to me if you want a copy of it}
5. Organize the prioritized user concerns into what we call a “Cascade of User Concerns.” Place these concerns front and center for the rest of the prioritization session.
6. Establish a number of columns on the board, using titles like First Priority, Second Priority, Third Priority, etc. We then divide the number of columns by the total number of points. Each column will be boxed in by this number of points. We have found a maximum of four columns works well.
7. Issue each team member an equal number of “points” to distribute. For large groups, create groups of 2 or 3 people who will prioritize together. It is important for each member, or sub-team, to get the same number of points, as each perspective is equal and important.
8. Have each member of the team (or sub-team) choose their features. Using their best judgment, members choose their top features. They should consider ALL of the factors the business cares about from the list above but should have the user front-and-center in their decisions. Proceed in reverse order of “authority.” In other words, leaders go last. Those who are newest to the organization or who have generated the least amount of political capital, get to express their opinions first. This helps us avoid the HiPPO problem discussed above and ensures the leadership has taken the entire group’s thoughts and arguments into consideration before inserting their opinion.
9. Each team member places their chosen features into the first available bucket. But here is the key: Before anyone can place their chosen features on the board, they have to first agree to the prioritization of ALL of the features placed in front of their chosen features.
   
   Facilitators have to make it clear to each member as they are placing their features, to specifically imply agreement with the feature prioritization as it is currently placed. If they do not, they have to negotiate with everyone who went before them to rearrange the features.
   
   

As each member completes their turn, they state out loud which features they chose and explain their rationale. If there is any debate about what should come first, the team must use the “Cascade of Concerns” to break ties and have dialogue that explains “why” each feature is important from the customer’s perspective. By the time you get to the most influential folks in the room, they will have to explain to their entire team why they are re-prioritizing the team’s decisions and use the “Cascade of Concerns” to support their arguments.

10. Get confirmation from everyone. To complete the exercise, re-read everything the team placed into column one; then re-read the “Cascade of Concerns.” Once complete, ask everyone in the room to confirm they have chosen the proper top priorities for the firm.

This process may look like prioritization by consensus, but it is not. It gives everyone a chance to express their concerns and perspectives in a systematic way. If you have set the exercise up properly, the folks with the most power go last and end up with the ultimate say.

Key takeaway. Prudent leaders will be careful not to change the decisions made by their entire team without a healthy dialogue.

Congratulations! You have just prioritized the next set of features for your product. More importantly, your team has accomplished these powerful things together:

1. They have mutually agreed upon the primary persona, and the core concerns they are solving for.
2. They have mutually agreed upon a starting point and initial priorities for your product.
3. They have mutually agreed to a scheme for future prioritization.
4. The team is aligned with both the initial priorities and the prioritization scheme.
5. The team will naturally have more confidence in how feature decisions are made.
6. The team will be aligned and confident because they put the plan together themselves –and have ownership over it. They will be committed to executing it as a result.
7. They will be energized by the work.

These things will enable the team to make sprint-by-sprint decisions more effectively. There is still a lot of work to be done to create a tenable roadmap, but your team will have confidence in the more detailed approach they created to micro-feature prioritization for your product. The health of a product is dependent upon the health of its backlog.

References

The term HiPPO first referenced here: https://www.amazon.com/Web-Analytics-Hour-Avinash-Kaushik/dp/0470130652/

Definition of Priority: https://www.dictionary.com/browse/priority

The Black Swan, by Nassim Taleb

Antifragile, by Nassim Taleb

Why Zebras Don’t Get Ulcers, by Robert Sapolsky

Behave, by Robert Sapolsky (Note: The actual quote above was taken from this video: https://www.youtube.com/watch?v=PV6XKnVWNsk

Minimum Valuable Audience attributed to Brian Clark https://copyblogger.com/unfair-business-advantage/ and later popularized by Seth Godin: https://seths.blog/2017/07/in-search-of-the-minimum-viable-audience/

The Loyalty Ladder, by Sean Flaherty

KPI’s That Inspire, by Sean Flaherty

Product Leadership and Sticky Notes, by Sean Flaherty

The Hoshin North Star Process, by Matthew Cross (From Edwards Demming’s work)