Value vs. Effort matrix: Lean approach

The Value vs. Effort matrix (also known as “Action Priority Matrix” or “Impact vs. Effort matrix”) is a lean prioritization approach which is useful in decision making and which helps to identify what is important (or risky) and where to direct the efforts. The matrix is used by product managers and product owners to grade strategic initiatives and features and presents a balancing approach by focusing on the items that are most valuable to the customers compared to the efforts required to implement them. This prioritization technique is similar to the Eisenhower matrix, covered in my previous article, but the Value vs Effort matrix is geared more toward product people, project and operations managers who are managing larger initiatives and teams. This method is quick and simple and has only two variables - Value and Effort - and features are plotted along these two axes.[1]

Let’s discuss the two variables of the matrix – Value (sometimes it is preferred to use Impact as a variable instead) and Effort.

Value: The product manager or product owner estimates the value of a feature (can also be an epic, or another backlog item) from a long-term perspective. The value criteria are arbitrarily defined rather than dictated by a specific formula. Yet, value can be assessed in different ways, but in general the following factors are worth considering:

• Customer benefit (in order to define the degree of need or urgency of solution)
• Customer engagement and satisfaction (in order to improve retention and avoid churn)
• Opportunity size (% of customers impacted)
• Customer acquisition potential
• Competitive positioning (differentiation of the offering)
• Market demand
• Increased company’s brand awareness on the market
• Evaluation of the investment from financial point of view (for example, by calculating return on investment, net present value, or internal rate of return)

Instead of value, impact can alternatively be used for the same axis. This can be very helpful because it makes product people (i.e. product managers and product owners) start thinking about outcomes and prioritize based on estimated impact of a new functionality and not about delivery of specific features (output). To focus on outcomes (and hence be able to estimate impact in the longer term) and avoid the risk of simply working in a “feature factory”, many of the world's leading companies use goal-setting frameworks such as Objectives and Key Results (OKRs). OKRs is great framework to ensure real value delivery by achieving alignment between strategic programs and agile execution, which is a key starting point for strategic flow.

Yet, using Impact (as an alternative to Value) as a variable is also subjective, so the best approach would be to make it transparent (and reach consensus) on how to calculate the real impact of a new functionality. A quick estimate can be done using qualitative variables such as low, medium, high. If you want to be more specific, quantitative variables can be used, such as a numeric score (e.g. a scale 1-5 with 5 being the highest) to estimate the value/impact of any feature. Nevertheless, the recommended approach would be to use relative estimation using (modified) Fibonacci sequence to calculate the value or impact of a feature or a backlog item.

Effort: The second variable in the matrix is effort. The product team estimates a feature total cost to the business and represents it as a proxy for the total effort necessary to realize it. Some people tend to use Complexity, instead of Effort, for the second axis. It is important to note that this usage could be misleading because complexity is one of the factors to be considered when estimating the effort of a backlog item. But it is not the only one, there are also other factors such as amount/volume of work, uncertainty and risks with implementation. You can either estimate the effort with a timeframe here (e.g. hours or days — depending on what your team is using), or use relative estimation using Fibonacci sequence. For high-level rough estimations, T-shirt effort size can be used, but make sure everyone understands the work range (in story points or weeks/months range) for each T-Shirt size. If relative estimation in story points using Fibonacci is used on any of the axes, it’s worth first identifying the item requiring the smallest amount of work and then estimate the remaining features/initiatives relative to it.

Once the features or initiatives are scored based firstly on their value (or impact if this variable is being used instead) and secondly on the effort needed to complete them, you can use the scores to plot these items in one of four quadrants. The four quadrants are: high value (or impact) and low effort, high value (or impact) and high effort, low value (or impact) and low effort, and finally low value (or impact) and low effort.[2] The Value vs Effort matrix is shown in Figure 1:

Figure 1: Value (or Impact) vs. Effort matrix

Let’s now explore each quadrant of the matrix.

Quick Wins (high value and low effort): This quadrant contains attractive projects, initiatives or features requiring only a low degree of effort, which can have a high impact on your product.[2] This is the category you should focus on first, the “low-hanging fruit”, which is a great way to win customers quickly. Depending on your product, you might not find many features here, but the ones landing here are definitely worth implementing. Because these features and initiatives give the best return for relatively little effort, the best approach here is to prioritize these features or initiatives on top of your backlog and deliver them first.

Major Projects (high value and high effort). This category is also known as “Big Bets” or “Strategic initiatives”. These initiatives or features have a high value or impact, but also require high levels of effort (high resources and costs involved with them).[2] Big usability redesigns and new major business functionalities often fall into this bucket. The best approach here is to be selective, pursue these initiatives and features and prioritize them high if they are likely to be worth the effort (and of course if you have the time and resources). But plan carefully and execute efficiently, if possible, by breaking down these big work packages into less complex and better-defined work items (this is where the art of slicing work comes in handy). Moreover, due to the complexity and effort of these initiatives, it is a good practice to set specific deadlines and build checkpoints/milestones into your schedule to allow for easy follow-up.

Fill-ins (low value and low effort).[2] This category is also known as “Maybes”. These are unimportant items that are usually “nice to have”. Things like small improvements to an interface, or minor software updates. These features should definitely not be picked up first and can be parked for later phases/releases or can be delegated. These are the activities your team can pick up when they have some spare time, as they can represent small wins without the need to invest a great deal of effort or resources.

Thankless tasks (low value and high effort). This category is also known as “Not worth it”, “Money pit” or “Time Wasters”. The implementation of these tasks/features would bring very little value and these items are time consuming and require a high degree of effort from your team to implement.[2] These activities or features are generally not worth implementing as they are simply waste, so the best approach here is to try to eliminate them altogether. However, if this is not acceptable, then deprioritize them and try to defer them to a later date when potentially it makes sense to implement them.

Overall, looking at this matrix, we can conclude that the highest-priority features and initiatives are the ones that you can get more value with less effort. In numerical terms, this means dividing the value by the effort and prioritizing on top of the backlog the items with the highest total score.

Let’s now discuss the pros and cons of the Value vs. Effort matrix.

• No detailed and time-consuming calculations are required. Even though you can compare features by calculating numeric scores for both value and effort variables, this is not mandatory. For example, if you don’t have time to calculate specific numeric scores for value and effort variables, you can simply think about ‘low’ or ‘high’ value or effort for the assessed items and place them on the matrix, or make a quick estimation using Fibonacci sequence.
• Easy and quick customization of the method. As you can arbitrarily define the value, you can do the same with the second dimension. Instead of effort as the second axis, you can decide to replace it with other more variables such as risks, costs, time or feasibility.

• Subjective nature. Since there is no well-specified scoring formula (yet, some guidance and estimation tips are described above), the prioritization method is still quite open to debate and can be considered as subjective. As a result, it is very important when prioritizing with this method to make it transparent to everyone and explain clearly why a feature or initiative is defined with such a value or effort.
  

• Some ambiguity of the effort variable. The easiest would be to simply estimate an initiative’s overall cost to the business and use that cost to serve as a proxy for the total effort required for implementation. This single metric is often sufficient. However, it is important to note that the effort variable can have a broad scope and if divided into subcategories, multiple components can be considered, such as operational costs, developer hours, risk, available in-house development skills and others.
• Not a valuable method when having a big comprehensive product. The method can be time-consuming for big product teams dealing with extensive product features. This is especially true when more accurate effort calculation is needed (and not high-level rough estimations using T-shirt sizing, for example), and developers/engineers participate in refinement sessions to estimate the effort score of each single feature.

The Value vs. Effort matrix works great when you are in the early stages of new product development, for example when you are building a new product. With new products, this matrix can help a team uncover many low-hanging-fruit opportunities (i.e. high-impact initiatives requiring low effort of implementation).

Another good use case for this prioritization technique is when you have a strict deadline in the near future or very limited development resources (e.g. there is a need to identify MVP when you are building a product from scratch and have limited time or budget). This prioritization method is then helpful to find out what you can realistically deliver with the current available resources, it might be the case that you can only implement low-effort features. Moreover, the method does a very good job when you want to apply a more objective lens to the initiatives your team is feeling very positive or very negative about. By simply plotting initiatives on the Value vs Effort prioritization matrix, you may find out that some initiatives are indeed with very high business value but require significant implementation effort and are not the recommended ones to pursue straight away (as they don’t bring quick wins).

As the product matures, you may run out of low-hanging fruit and the only approach would be to embark on implementation of some bigger features. This is when this matrix is not so effective, and you’d better use another prioritization scheme.

In my next article I will talk about the Weighted Shortest Job First (WSJF) model. Meanwhile, if you want to know more about prioritizing using the Value vs. Effort matrix, please feel free to contact me.

[1] Gonzalez, E. L. (2011). How to Become an Extraordinary Manager. AuthorHouse

[2] MindTools (n.d.). The Action Priority Matrix: Making the Most of Your Opportunities. Retrieved from mindtools.com