Deciding what features to do in your next product release and beyond can be a difficult process. There are always more requests than can be done, different priorities from various stakeholders, and even vastly different types of features that are competing for attention. This paper discusses a framework and tools for assessing how to attack the problem and can be used in both traditional and Agile projects.
I ran across a short YouTube video a few years ago that I have found to be very useful in looking at the feature prioritization problem and have used it often. It is titled Value vs. Complexity & the Product Management Trap and identifies a structure for looking at all of your feature requests and where the process can run down a rabbit hole with little benefit. In my own experience, there are actually two Product Management Traps to watch out for, as I’ll discuss later.
The basic premise of the concept is every feature under consideration has an inherent level of Business Value that it brings to the table and an associated level of Implementation Complexity that it presents in delivering it. The final priority of any feature is the composite score of both. If you assume some mechanism for scoring these candidate features along both the Value and Complexity axes, you would end up with plot similar to Figure 1:
Figure 1 – Candidate features scored against Value and Complexity
Before proceeding, let’s stop a minute and discuss how to measure Business Value and Implementation Complexity to generate this plot.
Defining the Business Value Measures
The Business Value of a feature is comprised of two components. The first one is the expected benefit derived from your target market. A feature can be valuable to existing customers and/or prospective customers. A numeric score can be generated for the relative value of any feature using some scoring criteria. This moves you beyond a simple High/Medium/Low assessment. Some typical scoring criteria could be measure of pain experienced by the customer, how often they experience it and how urgent is it to solve the problem.
The second component is the expected benefit derived by your company. Every company has specific strategic objectives it is trying accomplish at any point in time, and the more alignment the feature has in achieving those objectives, the higher the company value it has. The objectives can be to increase revenue, increase market share, enter a new market, decrease costs, increase customer satisfaction, etc. Some scoring criteria could be how much of the market would be impacted, does it increase differentiation, does it increase overall customer satisfaction (or decrease dissatisfaction), and is it aligned to strategic objectives.
The total value of a feature is the sum of the customer value plus company value and can be expressed numerically. You may decide to weight either one higher, but the basic formula holds, and the features that rate high on both measures will have the highest total value, while those scoring high only one measure will generally fall in the middle of the scoring. The Business value is typically assigned by business level functions, such as Product Management, Sales, and Execs.
One observation to make is the Business Value assigned to a feature is not static and can change over time. The value to your customers may diminish or increase as their situation changes, such as in a recession or as new technology begins to move through an adoption curve. Conversely, the value to your company will certainly change as you set different business objectives, probably on an annual basis.
Defining the Implementation Complexity Measures
The Implementation Complexity of a feature measures how difficult it will be to implement. This is most often expressed in effort (man-hours) or schedule time (weeks or months) for the development effort. A high level estimate can be generated by the development team based on assumptions of requirements and assumed solution generated. This can also be assigned a relative numeric rating, like the Business Value.
Another factor that can be included is the expected operational cost. Will the feature require investment to put it into production and/or carry a high operating expense? Would there be a high migration and support effort to move customers from an old implementation to the new one?
And finally, the amount of risk can factored into the assessment. Do you have the technical skills available to develop the solution? Is the technology required leading edge? Is there potential for system destabilization to deploy it?
The total Implementation Complexity is then the sum of the decided measures, with any weighting you may choose. These ratings would be provided by the development and potentially operational and support teams.
For both the Value and Complexity ratings, you can decide as an organization how much rigor you want to put into this. A large amount of progress can be made with a few informed people generating very high level assessments.
The Product Management Trap(s)
If you then divide the plot of features from above into a 2x2 grid, you create four quadrants that the features will fall into, as shown in Figure 2:
Figure 2 - 2x2 grid with 4 quadrants
Let’s take a look at each of the quadrants and assess what we should do with features in each. The features in the upper left hand quadrant represent those with a high Value rating and low Complexity rating. In essence these are easy-to-do features that both your customers and company value and thus are low hanging fruit you should be going after. These features are priority #1. Unfortunately, there are typically very few of these juicy little nuggets just laying around, especially for a mature product, so you’re going to need to look at other quadrants most of the time.
The features in the lower right hand quadrant represent those with a low Value rating and high Complexity rating. This means that neither your customers nor your company value the feature highly and the feature is hard to do. This is the first Product Management trap. Because they are high complexity, they may have a high attraction to do them from a technical perspective. As we are technologists, we love to solve problems, and may spend an inordinate amount of time talking about and planning the solutions to these features and getting lost in the fact they really are low value and we should be moving on.
To be fair, these features may have at one time been higher value, but business conditions changed enough to lower them to the point of being useless to continue. Features in this quadrant should be shelved and removed from the plate as soon as possible so they don’t consume valuable organization time discussing requirements or solutions.
Figure 3 illustrates where we are at this point, and the question is which of the remaining two quadrants should be our next priority?
Figure 3 - Priority 1 & Priority Never Assignments
Our options then are to focus either on high value, but also hard-to-do features, or low value, but easy-to-do features. This decision becomes even more difficult in an Agile development environment, where none of the features in the upper right hand quadrant may fit into any desired release cycle. This is what I’ll call the second Product Management Trap and where I diverge from the YouTube video.
There is a tendency in many organizations to prioritize the features in the lower left hand quadrant #2 for the very reason that you can deliver them. In essence, this weights Implementation Complexity above Business Value. The results, unfortunately and predictably, are releases that are neither inspiring to your customers nor delivering much value to your company. This is also the quadrant in which the majority of the feature requests that you receive are likely residing. The vast majority of feature requests does not generate much business value and are simply nice-to-have for most customers. Sure, someone wants them, and if they are easy to do, why not just do those, especially to keep key customers happy?
The reason NOT to do them is because you have a limited set of resources, and as a business you should be trying to maximize the total value that you can create with them. The sum of several low value features does not create higher value for your customers or your business. They just use up your scarce resource opportunities. Therefore, the upper right hand quadrant should be your priority #2. You should be doing whatever you can with these features to attempt to break them down into smaller, incremental deliverables or to reduce costs or to reduce risk. This takes resource commitment to dive into them to a deeper level and a plan that likely takes time to achieve. Your longer term product roadmap is derived from the features in this quadrant.
The lower left hand quadrant then becomes a distant priority #3. Do a few, if have to for goodwill, and reassess the value rating in this group periodically but resist the temptation to do them just because you can. Have you got extra cycles of available people sitting around in Development? Then use them to figure out how to either:
- develop a higher value solution inspired by the low value feature that can move up to one of the upper quadrants, or
- work on small deliverable that will move the ball on one of the larger high value features.
It is not a law that every developer must focus all their attention on the current release. Figure 4 shows the final priorities for each of the quadrants.
Figure 4 - Final Quadrant Priorities
Summary
This article has presented a high level framework for prioritizing new features into your product by using a simple 2x2 grid of Business Value versus Implementation Complexity. There are two Product Management Traps awaiting the unsuspecting in burning up valuable scarce resources on the planning or implementation of lower value features, thus leaving higher value opportunities on the table.
For additional reading on this topic, check out a slightly different spin at:
For more tools on scoring feature requests as indicated in this article, you can also download the Prioritization Scoring Worksheet at the bottom of this article HERE.
Related Articles:
| File | Description | File size | Created |
|---|---|---|---|
 Feature Prioritization Worksheet.xls | 74 kB | 2012-09-03 20:51 | |
 Value_vs_Complexity_A_Prioritization_Framework.pdf | 493 kB | 2012-09-03 20:43 |