Return to site

Make a Decision and Keep Moving

Four collaborative tools to help product teams quickly find and follow the right path

· priorities,product management,agile

Early in my career, I moved from technical project management to product. I inherited a large software product midway through Testing phase in a waterfall model, weeks from a global launch. The reality of my new career hit me during my first bug scrub with the team.

The question came up: is this bug a blocker for the upcoming Beta? We all shared our opinions, and then there was an expectant silence. Everyone looked at me -- the product lead -- for the final decision. If we deployed without this bugfix, Beta functionality (and our test plans) might be impacted. If we delayed the build to add the fix, we might put subsequent Beta cycles at risk, which in turn could affect launch readiness and quality. What should we do?

As I discovered, making a sound decision is not always easy. Product management is a constant balancing act -- one in which we juggle everything from ad tech to zero tech debt and all the user needs in between -- and, at times, an overwhelming one. How do you make a call and stick by it without being a despotic tyrant or sinking into the quagmire of analysis paralysis?

When faced with the overwhelming prospect of the big proverbial ball of tar, wax, and/or yarn, or that huge heap of unranked "stuff" (which could be priorities, ideas, jobs, tasks, or bugs), you obviously need to quickly hone in on what's "valuable".

However, the tech or design lead's definition of "value" may not be shared by the would-be tinpot product dictator, who often has executives, lawyers, or accessibility experts -- even politicians -- breathing down their neck. This is where context and collaboration will save you. If everyone on the team can establish then operate from some shared degree of knowledge, you'll be less likely to get stuck or make decisions in a vacuum.

How do you decide what's important to the team and the product as a whole? First, frame the decisions to-be-made as questions and experiments, not demands.

Then:

  • visualize the work by writing it on post-its or cards
  • gather context with your team: think about internal goals, user goals, market factors, constraints, ideas, and all the things that engineering, usability, legal etc. need
  • plot the work according to your context and the relative spectrums of value, cost, risk, etc. (See matrices below)
  • analyze, discuss, compare, and shift the priorities, based on your understanding of the context
  • cluster or rank the priorities
  • filter and focus on the remaining important item(s)
  • decide what to do next

Of all the techniques I've learned and used during my career, one prioritization matrix in particular is among the most simple, useful, and widely applicable for framing up the analysis-filter-focus-decide needs of a team. (I learned this technique during Scrum Master certification training facilitated by Rally Software, now CA Technologies.)

Here is the original prioritization matrix technique, along with some suggested variations, to quickly guide teams to productive collaborative analysis and decision-making. I've used these in strategic settings -- for release roadmaps or epic grooming -- as well as to frame up a tactical analysis to a production crisis, tech debt and maintenance backlog scrubs, or integration approaches. I've even used them as companions during design sprints to capture and gradually filter "How Might We" ideas or risks and unknowns.

In almost every instance, these exercises provided me and my team with actionable decisions in under an hour.

With continued use, these approaches will also hopefully foster some autonomous analysis and filtering, and keep your team finding, discussing, and focusing on the "important" stuff.

As filtering and ranking tools, they can be used individually, in sequence, or even in parallel as you grapple with analysis. They're also great compliments for team spaces, and they're terrific for passively sharing context and information with other team mates, stakeholders, and executives after stand-ups or during drive-bys. Ideally, they're employed early and often throughout the project to help everyone keep pace with the fluid contextual changes of our modern world.

Value vs. Cost (or Level of Effort)

prioritization matrix value versus cost. n equals blue

Original prioritization matix

With your team, plot your post-its or cards according to each item's perceived, relative value and cost (or level of effort). The positions you choose and adjust as a team will prompt discussion about context and rationale. Why is item A more valuable, or more costly, than item B?

Give everyone the freedom to adjust the position of the items as needed. Keep moving and adjusting, talking and discussing, until you begin to feel comfortable where things have landed. Depending on the circumstances and the context, this will either be rather quick and obvious, or take multiple rounds of readjustment and discussion.

Prioritization matrix value versus cost with implied quadrants. n equals blue

Prioritization matrix with implied quadrants.

Now, look at where items are clustered and ranked:

  1. High value, low cost: this is your "low-hanging fruit". Ideally, address this stuff first.
  2. High value, high cost: immediately research the highest-value, highest-cost items. Questions: how might these items be achieved to keep the value high but lessen the cost? (In other words, what would it take to move these items to the left? Could we add new cards that are less costly?)
  3. Low value, low cost: remember that "low" is relative; some things might be medium-ish value, low cost; stuff that brings you basic market parity. Again, context is key. But consider them. 
  4. Low value, high cost? Never do these, or look at ways to reduce their cost down the road. Most importantly, however, don't waste any further time talking about them right now!

Tip: Swap cost with "estimate": You could also adapt the "cost/LOE" axis by using your preferred method of estimation (e.g. t-shirt sizes or story points) instead, just like a relative mass evaluation or bucket system approach (and with the added lens of value):

Value versus level of effort matrix with evil villain examples

Value vs. Level of Effort with Story Points (giving you a relative mass valuation approach for free!)

Questions: Considering the matrix and its evil villain example above, what technologically complex equivalents to trained attack tigers and flying invisible cars are lurking in your team's roadmap or backlog? What alternatives to these ambitious goals are easier to build, getting you results (and feedback) sooner, while remaining true to the original intent?

Variation 1: Value vs. Risk

value versus risk matrix. n equals blue

This matrix replaces "cost" with "risk".

If the team's grasp of cost or level-of-effort is fuzzy for some reason, or you want to add a different lens to your analysis, replace "cost" with "risk". This is a decent exercise for design sprints or concept and strategy phases, because "risk" can be treated as more of an abstraction; you resist the urge to describe or commit to "levels of effort" and solutions before they're fully baked.

Once the items have been clustered, the question remains: how might we decrease risk (or move items to the left)? The following variation is a good tool to follow or accompany the Value vs. Risk exercise.

Variation 2: Risk Severity vs. Risk Likelihood

Risk impact versus likelihood. n equals blue

Risk mitigation matrix.

I adapted the prioritization matrix for my own purposes while helping a team plan a legacy system migration and decommission roadmap. (You could replace "severity" with "impact".)

After plotting, discussing, and cluster-ranking the risks, I facilitated a brainstorming discussion with the team to consider ways that they could bring the high severity-high likelihood risks down to the low impact-low likelihood quadrant in the bottom-left. The takeaways from that exercise became their risk mitigation plan.

My Variation: Why vs. How

Why versus How, a matrix for grooming. n equals blue

Why vs. How, a matrix for backlog or roadmap grooming.

If "value" is the answer the question "why?", then "cost" might be related to "how". Along that line of thinking, it occurred to me that "why vs. how" might be a useful matrix for analyzing the abstracted and relative definition of features and stories while guiding conversations and decisions in a variety of circumstances:

  • Strengthen stories and identify knowledge and confidence gaps before backlog grooming: encourage discussions among the team and the product owner in preparation for, or during, backlog grooming. 
  • Use it as a sanity check exercise during day-of-sprint planning before the team commits. Questions: which stories for the upcoming sprint or release have clear rationales? is the team reasonably clear about the planned approach? if not, what's the root cause? Do we need to add a spike or rethink the better acceptance criteria before this story can be started or completed?
  • Strengthen release road-mapping or higher-level backlog grooming
  • Poke around in previously stalled projects or analyze work transferred to new teams or subcontractors

All The Matrices

Original value vs. cost prioritization matrix and three variations. n equals blue

Original value vs. cost prioritization matrix and three variations.

Decision-making can be difficult, especially if you're alone. Arm yourself and your team with context, get their input, gain (and reciprocate) their trust, and make the best call you can.

Finally, keep the words of the Prime Directive in mind:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

Norm Kerth

Header photo by Jens Lelie.