Value vs. Complexity Prioritization Model

Value vs. complexity is one of many prioritization models product managers can use to prioritize initiatives on the product roadmap. It is a popular method among product teams looking for an objective way to allocate time and finite development resources to initiatives based on their perceived or potential benefit.

Product managers frequently use the value vs. complexity framework (and variations of it) to standardize a set of decision-making parameters. These parameters (usually, as the name suggests, value and complexity) can apply to all features, product enhancements, fixes, and other initiatives competing for space on the product roadmap. This objective prioritization technique enables product teams to apply strategic and quantifiable reasoning to decisions about which initiatives to prioritize and which to shelve.

What is the Value vs. Complexity Model?

Value vs. complexity is a prioritization framework that allows a product team to evaluate initiatives according to how much value they bring and how difficult or complex they are to implement.

The methodology is straightforward. A product team builds a graph or prioritization matrix with axes for “Business Value” and “Complexity/Effort.” The chart is then broken down into quadrants as follows: high value, low complexity; high value, high complexity; low value, low complexity; and low value, high complexity. The team will then evaluate each initiative and plot it on the graph, providing a visual representation of every initiative’s anticipated value and required effort.

How Value vs. Complexity Prioritization Works

The value vs. complexity framework is built on a prioritization matrix, like the one shown here.

The model works as follows: For each initiative under consideration, the product team will make two separate assessments:

  1. How much value it anticipates the initiative to deliver.
  2. How much effort implementing it will require.

The objective of this prioritization exercise is to uncover those initiatives that promise to deliver the most value for the least effort.

The initiatives that deliver the highest value and require the least effort will represent the top-priority items to add to your product roadmap. The initiatives that fall on the other end of the spectrum—promising relatively low business value and a high degree of difficulty to implement—should probably be shelved.

Now let’s examine in greater detail what this process may look like in practice.

Prioritizing Features with the Value vs. Complexity Model

1. Determine a value score for your features

In the value vs. complexity model, there are at least two types of value to consider.

  • The value an initiative will deliver to your user personas or your market more broadly. This type of value would include, for example, the degree to which your initiative will reduce users’ pain or improve their efficiency, and how urgently your market seems to be demanding it.
  • An estimation of the initiative’s direct business value to your company. This value might be reflected in terms of acquiring new customers, retaining existing customers, the ability to upsell customers, and the anticipated new revenue the initiative will bring.

When assessing the business value of an initiative, you might want to consider multiple factors. Will it enhance your company’s brand awareness in the market? Does the initiative affect enough customers to make it worth the effort? (Some initiatives might impact only a small subset of your user base and prospects, and might therefore have a relatively low business value.)

Once you have reached a score for each of your value subcategories, you can combine them into a single numerical score. The numerical score should represent the initiative’s overall estimated business value.

You might choose to weigh either of these subcategories more strongly than the other. You might, for example, decide that the bottom-line contribution that implementing an initiative could make to your business deserves more weight than its potential impact on your user’s experience. This is fine, as long as you apply your formula consistently across all initiatives you are evaluating.

2. Determine a “complexity” score for each initiative

What exactly does complexity mean in the value vs. complexity prioritization framework?

One shorthand many product teams use is simply to estimate an initiative’s overall cost to the business and let that cost serve as a proxy for complexity or effort required to implement it.

In some cases, this single metric might be sufficient. But you can also choose to dig much deeper than this. You can divide your complexity/effort scoring into several subcategories, such as:

  • Operational costs
  • Developer hours
  • Time on the schedule (days, weeks, months)
  • Customer training, migration effort, and handling potential questions or complaints
  • Risk (including the potential for your new initiative to be supplanted soon by newer technology or processes)
  • In-house development skills (if only one or two developers have the knowledge to implement an initiative, this would mean pulling those developers off of other projects, and also that progress on the initiative could be delayed if those individuals get sick, leave for vacation, etc.)

3. Plot initiatives on your matrix and prioritize

Once you have plotted each of the initiatives on your list on your prioritization matrix, you can decide which to place on your roadmap and in what order of priority. Here is an overview of what you’ll find in each quadrant.

High business value, low implementation complexity (upper-left)

Ideally, this will be your top priorities, because they have earned high marks for value while at the same time scoring low on anticipated effort. You’ll want to prioritize these features or initiatives above the others.

It is worth noting, however, that the chances are low you will actually plot your team’s proposed initiatives in this quadrant, because if they are so important and so relatively easy to implement you probably will have already completed them. In fact, in Mind the Product’s discussion of value vs. complexity prioritization, they describe this as the “Why are you doing this now?” quadrant.

High business value, high implementation complexity (upper-right)

These initiatives are definitely worth prioritizing, probably second only to your high-value, low-complexity initiatives (if you have any).

But initiatives that fall into this category might have to be shelved because of the effort required to implement them.

Low business value, low implementation complexity (lower-left)

This category might represent your team’s wild-card list of initiatives. They score low on business value, but they might still represent nice-to-have features, fixes, or other elements worth adding to your product—particularly because they don’t also demand a lot of work or effort from your development team.

You might want to set aside these items for periods when your development team is transitioning between projects or has short cycles of downtime. They represent an opportunity to make small wins without expending a great deal of effort or resources.

Low business value, high implementation complexity (lower-right)

Unless you have a legitimate reason for carving out time to work on an initiative that doesn’t offer much business value and also promises to be difficult to implement, you should probably cross these items off of your list entirely.

In fact, one of the best reasons to use the value vs. complexity prioritization model in the first place is to help your team identify these low-value, high-effort initiatives so that you can make sure you don’t waste important development time and resources on them.

When Should You Use the Value vs. Complexity Model?

Product managers can use many frameworks for prioritizing features, so when should your team use the value vs. complexity approach? Because it offers an objective, quantifiable method weighing each initiative’s potential benefit against the effort it will require, this framework can be helpful in any prioritization scenario. But here are a few examples of where the value. vs. complexity model can be particularly useful:

1. When you are developing a new product.

Product teams with mature products are not likely to uncover many low-hanging-fruit opportunities in a value vs. complexity prioritization matrix—those “high value, low effort” initiatives in the upper-left quadrant. If the product is successful enough to have matured and still be on the market, then chances are the team has already implemented the elements that delivered high value and didn’t require much effort to build.

But with a new product, this framework can help a team uncover those high-impact initiatives. So it’s definitely worth a try when you are in the early strategic stages of new product development.

2. If you have only a very short timeframe or very limited development resources.

During instances in which your team is extremely short on resources, you might be limited to taking on only low-complexity or low-effort projects. In other words, even if an initiative is a high priority, it might just not be feasible given your time or personnel limitations.

In these cases, it will be helpful to have a way of seeing what you can do with the resources you have.

3. When you want to apply a more objective lens to the initiatives your team is feeling very positive (or very negative) about.

Teams often uncover interesting insights about the proposed initiatives on their list when they subject those initiatives to the value vs. complexity prioritization exercise.

Only after they’ve plotted them on the prioritization matrix, for example, will they realize that perhaps the reason so many in the organization have been arguing against an initiative isn’t that it won’t provide real business value—it certainly will—but rather that it represents a lot of difficult work.

Similarly, when they’ve completed this prioritization exercise and applied their business-value formula to a given initiative, a product team might discover that the development team’s enthusiasm for that initiative was not based on its potential value to the company—which is relatively low—but because they were enthused about the technology or development process this initiative would allow them to work on.

The value vs. complexity prioritization matrix forces your team to build a visual representation of the truth behind each proposed initiative—whether good or bad.

Conclusion

The value vs. complexity model can be a helpful strategy for product teams trying to turn a long list of proposed features, enhancements, and other items into a strategically sound list of priorities.

To learn more, download our free book: The Product Manager’s Complete Guide to Prioritization.