Even the most organized people only have so much time, which makes prioritizing work all the more important. But how do you prioritize which tasks or product features to focus on when you’re faced with dozens of potential opportunities and a small army of stakeholders?

Matrices are simple organizational tools that can help you and your team visualize your product’s potential features within the context of all the possible features you could develop.

Although there are several different types of prioritization matrices, in today’s post we’ll be looking at three of the most common: the value-complexity matrix, the value-risk matrix, and agile user story mapping.

Prioritizing Product Features Using a Value-Complexity Matrix

As its name implies, value-complexity matrices plot the potential value of a product feature alongside the complexity of implementing such features. Put another way, this kind of matrix categorizes product features by their expected business value and their implementation complexity.

The definition of “business value” will vary from one company to another, even among competing businesses in the same industry or vertical. There are dozens, if not hundreds, of factors that can determine the business value of a product feature, from a proposed feature’s potential value to end users to the traffic or revenue that feature could potentially generate.

“Implementation complexity” is a similarly broad term that can encompass a range of technical challenges, from the length of time a proposed feature will take to integrate into an existing system to the costs of actually developing that feature.

At their simplest, value-complexity matrices can be formatted as a 2×2 grid of quadrants. The business value of a project can be categorized as either high or low, whereas the implementation complexity of a project can be represented as low or high.

[Source]

High-value, low-complexity items are the “low-hanging” fruit; these items should be strongly considered for further development given their high potential impact on the business and the ease with which they can be implemented. However, while you can and should pursue these high-value, low-complexity opportunities, it’s vital not to focus on these opportunities to the exclusion of all others. Many startups mistakenly focus all their efforts on securing these easier wins, often to the detriment of high-value, high-complexity features.

High-value, high-complexity items are often broader, more strategic initiatives that require a much greater investment of time, money, and/or effort. Despite the higher costs of implementing these features, high-value, high-complexity features can be immensely valuable in the long run. Rather than overlook these opportunities, consider examining these items to see if any of these longer-term goals can be broken down into simpler, easier subtasks.

Low-value, low-complexity opportunities may be worthwhile exploring eventually, but they should not be prioritized above the high-value features you’ve identified in your project. These ideas may be worth revisiting further down the road, and it may be worth examining whether there are opportunities to derive greater value from these items in the future.

Low-value, high-complexity items should be avoided at all costs. Not only do these opportunities offer little in terms of business value, the complexity of their implementation means these features are effectively off-limits.

Prioritizing Product Features Using a Value-Risk Matrix

Another way to evaluate the potential business impact of proposed product features is to use a value-risk matrix. Similarly to our value-complexity matrix above, value-risk matrices also categorize product features according to their potential business impact but also categorize these opportunities by the overall risk that their implementation poses to the business.

No business can completely insulate itself from all risk, especially when it comes to product development. However, you can categorize and plan for potential risks using a value-risk matrix, especially if you’re not completely sure about your underlying assumptions about a particular product feature. This makes value-risk matrices ideally suited to calculating the potential impact of completely new ideas and initiatives.

Like our value-complexity matrix, value-risk matrices can be structured as a 2×2 grid of quadrants: a project’s value can be categorized as either low or high, as can the associated risk:

High-value, low-risk opportunities are your most urgent priorities. These items promise high value to the business or user while carrying little or no risk, making them the most effective investment of your time and resources.

High-value, high-risk items are also deserving of serious consideration. However, while the potential impact of these opportunities can be exciting, the risks associated with these features can necessitate a more strategic approach, particularly if the risks are primarily financial.

Low-value, low-risk opportunities are definitely worth exploring but only once your high-value, low-risk opportunities have been prioritized. Implementing several lower-value features can have a larger cumulative impact over time, but their individual value makes them less urgent than other priorities.

Low-value, high-risk items should generally be avoided. Not only does their risk outweigh the potential benefits, but pursuing these opportunities could jeopardize the execution of higher-priority items.

Prioritizing Product Features with User Story Maps

So far, we’ve focused on techniques that emphasize the needs of your business and your product development teams. Sometimes, however, you need to put your users first, which is when user story mapping comes into play.

Originally developed by product management consultant Jeff Patton in 2005, user story maps plot your product development priorities against your users’ experiences of actually using your product.

[Source]

Unlike our first two examples, there is no one definitive way to structure or visualize a user story map. There are, however, some commonalities you’ll see among many user story maps.

The top row in our example user story map above (in blue) focuses on things that the user can do. This might include searching for a specific product, adding that product to an ecommerce shopping cart, paying for the product at checkout, or abandoning the cart. These events are typically presented sequentially from left to right, representing the various stages of the user journey.

The second row (in green) represents the various actions that the user can take to complete a given task. The remaining rows (in yellow) represent available subtasks or actions. As you can see in the figure above, the lower an item is in the user story map, the less significant or necessary that subtask is. Many companies can and do segment their subtasks by planned release, which allows development teams to further prioritize subtasks by urgency.

One aspect of user story maps that makes them so versatile is the freedom with which teams can reorganize and reorder tasks as a product is developed. This flexibility can be a major advantage when planning development cycles, as unlike the value-complexity and value-risk matrices, the stories within a user map can be changed, moved, and adjusted over time.

Where the Rubber Meets the Road(map)

The three examples are great starting points for further project planning. For example, if budgetary concerns are among your most urgent priorities, you might find that adapting a value-complexity matrix into a value-cost matrix is more useful.

Your team’s objectives will inform not only what you should be focusing your time and efforts on, but also how you’ll identify and distinguish urgent opportunities; a scrappy, two-person startup that needs to reach product-market fit ASAP will have very different priorities than an established, cutting-edge technology firm.

When it comes to product development and planning your next dev cycle, there’s no one-size-fits-all solution. There is no “correct” way of developing your product roadmap. When putting your product roadmap together, encourage every member of your team to help define and structure the process rather than forcing your team to adapt to a rigid, inflexible roadmap. Your team will be happier, your product will be better, and your users will definitely appreciate it.

P.S. If you liked this article, you should subscribe to our newsletter. We’ll email you a daily blog post with actionable and unconventional advice on how to work better.