“If you don’t have a plan when you hit the beach, you are dead. If you don’t change the plan the minute you hit the beach, you are dead.” — Unknown Navy Seal

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

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

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

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. There are many models which intend to help us prioritize in a more objective and data based the balance between value, cost and various risks.

This rarely works because it is nearly impossible to capture, in any objective way all of the possible factors which influence those things. What tends to happen when trying to use logic to objectively prioritize features in a software product is the creation of politics, lobbying and divisiveness between factions.

In my experience, the most outspoken and/or highest paid person in the room, the HiPPO, typically makes or powerfully influences the priorities out of default. This is how it had always been done and it was how our teams were prioritizing before we realized this. We knew it wasn’t working for our users. In this fast paced environment, where the entire business landscape is changing around us in near real-time, we needed a better way to prioritize and to empower our teams to prioritize.

No matter how much data we have, it is still a prediction. There are unknown factors and unpredictable “black swans,” as we are seeing now, which will impact our priority decisions for the worse. Sometimes there are even “bluebirds” which might work to our advantage. Thus, we are always using our intuition at the end of the day. Generally, it is better to have a group of motivated people, who are each 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 the group is able prioritize together.

Feature prioritization is hard work. Determining the right MVP (Minimum Viable Product) for your solution is near impossible to get right on the first try and doing it well has the potential to make or break your product. At the end of whatever process you use to prioritize your features and whatever you initially choose to include, will most likely be wrong. It has to be OK to make imperfect priority decisions for the sake or progress.

The term “MVP” is often thrown around as a buzzword and we have found 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 keep focused on how to create a feature prioritization scheme to keep your backlog relevant and robust for your product.

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. Once you get your leadership to agree on the methodology for determining the priority stack, you will have earned their confidence in your ability to do the everyday, micro-prioritizations which are required for your product to find success in the wild.

Imagine, being able to walk away from a prioritization session with everyone in the room in agreement on how prioritization decisions are made. Imagine how empowering it will be for your team if everyone knew and agreed we will not get it perfect, but we are all aligned and confident in our prioritization scheme?

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 we might do it better.

We have found the MoSCoW (Must Have, Should Have, Could Have, Won’t Have) method causes confusion for the team because of its complete subjectivity and lack of a unifying scheme for prioritization. Everyone has a good argument for why each feature should be in the “Must Have” column. Without a method to restrict what goes in each column with a way to break ties, it quickly dissolves into a deadlock with political factions arguing for their own subjective interests.

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

We have tried using a number of algorithmic tools in the past, such as:

The Eisenhower Matrix (Impact vs. Effort)
RICE (Reach, Impact, Confidence, Effort)
ICE method (Impact, Cost and Effort)
And many other various 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 and sub-factors involved in prioritizing the features the business needs to include in aproduct, 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 have some useful dialog, but very little will get done.

Every product serves a myriad of 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” 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 looking at those features to add a ton of value for your users in the context of your product, even if they don’t add much value to the business. The idea with those features is to get creative with ways in which you might valorize or monetize the data you are able to collect. For items valuable to the business, but not to the users, you might want to find ways to make it fun through engagement mechanics or gamification.

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

Short term revenue opportunities
Long term profitability opportunities
Support costs
Team morale
Embarrassment to the firm
Competitive positioning
Current market opportunities
Funding priorities

Lastly, effort is ALWAYS subjective. You never know how much it will really take until it is done, according to your definition of “done.” This is why we use relative sizing. This diagram shows how complex systematic prioritization is when you factor in these three subjective scales.

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.

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. — Robert Sapolsky

So where do we start?

Mariano Sigman and Dan Ariely have been doing some research into how groups make good decisions and have found some pretty amazing results. 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 properly for the group, then allow the group to have the challenging dialogs together in a safe environment to jointly create a prioritization scheme.

In order to adequately frame this problem means we must start by understanding who we are serving and agreeing on the importance of the user of the software product in the whole equation. Instilling customer empathy into the team is a step which 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 make optimal decisions with the information we have in regards to the features the firm will be investing in.

“Of course everyone wants to reach the maximum audience. To be seen by millions, to maximize return on investment, to have a huge impact. And so we fall all over ourselves to dumb it down, average it out, pleasing everyone and anyone. You can see the problem. When you seek to engage with everyone, you rarely delight anyone. “ — Seth Godin

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

A. Your team must have assembled and agreed upon a primary persona for your system.

B. 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 which represent the relationship you are building with the user. The best goals are those which demonstrate how you are maximizing the number of “Advocates” produced by the system.

RPI: Relationship Performance Indices

Short term goals or Objectives and Key Results are critical steps in the short term process to achieve tactical success along the way, but we need motivating, long-term success goals first 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, but it has proven to work extremely well.

Once we have these things, we follow this procedure:

Assemble the right team with the best 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 businesses interests. Marketing, IT, Sales, Customer Service, Support, Call Center, Etc. should all be included. If you can include a couple of customers who are already advocates of your business, this can be extremely powerful. Make sure whatever decisions this team makes — the team has the influence and power to make those decisions stick.
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, with the right team, 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 cognitive load of the team when they are shuffling the features. {5, 10, 25 & 50}
Coach the team through the creation of a list of the top five concerns of the primary persona. Make sure they are clearly articulated and agreed upon by the team. You cannot do this without a healthy, agreed upon persona and the alignment with the team on the persona or persona set.
Coach the product leadership team through the use of the Hoshin Star methodology to prioritize these concerns. Everyone must agree. We have created a workbook to walk through how to do this. {Reach out to me if you want a copy of it}
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.
Establish a number of columns on the board with 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.
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.
Have each member of the team (or sub-team) choose their features. Using their best judgement, based upon everything they know about the business, they 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. They go in order of “Power .” In other words, leaders go last. Those who are newest to the organization or have 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 groups thoughts and arguments into consideration.
Each team member places their chosen features into the 1st 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. As a facilitator, you 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 why to the team. If there is any debate about what should come first, the team MUST use the “Cascade of Concerns” to break ties and have impactful dialog about “why” each feature is important from the customer’s perspective. By the time you get to the most influential folks in the room, as they will go last, 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.
Get confirmation from everyone. To complete the exercise, re-read everything the team placed into column one, then re-read the “Cascade of Concerns” and 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, but prudent leaders would be very careful not to change the decisions made by their entire team without a healthy dialog.

Now you have prioritized the next set of features for your product. More importantly, your team has accomplished these powerful things together:

They have mutually agreed upon the primary persona, and the core concerns they are solving for.
They have mutually agreed upon a starting point and initial priorities for your product.
They have mutually agreed to a scheme for future prioritization.
Everyone on the team is aligned with both the initial priorities and with the prioritization scheme.
The team will naturally have more confidence in how feature decisions are made in an ongoing way.
They 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.
They will be jump-started and 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 your more detailed approach to micro-feature prioritization for your product.

The health of a product is dependent upon the health of its backlog.

The Idea Prioritization Funnel

If you like this, share and let me know what you learn from using it!