Priority first
A modular feature prioritization framework
Delivery on time, requirement analysis, roadmap planning, and people management are some of the things that a product owner or a manager has on his mind. However, the key to success for all the above is, without any doubt, being able to prioritize. This article presents a modular feature prioritization framework and acts as a self-fulfilling prophecy on my claim to treat priority as a priority.
Thinking strategically and roadmap planning for a product owner/manager will inevitably, at some point, require prioritizing features. Prioritizing tasks also appears as a necessity in technical teams whenever, for example, they need to plan technical debt tasks for the next sprints. This work is an endeavor of formalizing a process for doing so, and I hope it provides a consistent, standardized, and straightforward approach in the form of a framework. Hence the term Feature Prioritisation Framework.
As an engineer, and since I could not waste too much time on it, modularity and composability came as an essential requirement for it to be simple and extensible for future enhancements.
Value vs. Effort
We are going to apply the Value vs. Effort model¹, one of the most popular prioritization frameworks. It is essentially a cost-value analysis model that allows you to evaluate each feature based on how much business value it will bring and how difficult or complex it will be to implement it.
We assign initial (Value, Effort) value pairs for each of the features, and then we plot them on a scatterplot, as seen in the image below.
The scatterplot allows for a quick comparative overview of all the features’ priorities. We even divide the chart area into four regions, each one forming a bucket of features that further help with the prioritization.
High Effort, High Value: long-term strategy
Low Effort, High Value: quick wins
Low Effort, Low Value: pet projects
High Effort, Low Value: time sinks
Assigning initial weights
To start putting features to the scatterplot, we need a way to calculate the initial values for Effort and Business Value².
Choosing a scale
The absolute values we assign to a feature do not really matter. For example, it makes no difference if we use values from the scale of [0–100] or [0–200] or any other. We choose a range and stick to it since the only thing that matters is the relative difference between the values. For that purpose, it is more suitable to think of these values as weights.
For example, if feature #1 (𝔽1) has double the Effort compared to feature #2 (𝔽2), we could assign weights to them like the following: 𝔽1=100 and 𝔽2=50, or 𝔽1=200 and 𝔽2=100, etc.
Deciding on a methodology
The methodology we follow to derive those initial weights is arbitrary but must be consistent. Every team can come up with a process that suits its needs and follow it. There is plenty of room here for devising smart and consensus-aware methodologies.
Here is an example of a consensus-aware decision strategy about Business Value weights³. Let’s say that a team of product stakeholders has to prioritize six features. Each stakeholder is given a bag of 6 weight units, where each weight is a number of the Fibonacci sequence. In our example, each stakeholder’s bag will have the following weights {1, 2, 3, 5, 8, 13}. In secret, he assigns a weight to each feature, and when everyone is done, the total weight for each feature is calculated. Finally, we normalize these weights to our scale of choice (e.g., [0–100])⁴, making sure we preserve the relative differences between them.
The engineering team can, for example, follow a similar strategy when choosing initial Effort weights. Τhe weights themselves could be an estimation of the person-hours needed for task completion.
Once we decide on the methodology for calculating initial values for both Effort and Business Value, we can start adding features on the scatterplot.
Considering multiple factors
When calculating the Effort or the Business Value of a feature, it is often the case that the initial estimation of weights is not enough. A product owner or a team might also, and probably should, want to consider multiple factors.
For example, competition analysis (what features does the competition have or is missing), feedback analysis (e.g., comments on the App Store, feedback emails, questionnaires), user testing analysis (e.g., through interactive prototypes), etc. should affect the Business Value and should be taken into account.
Every factor is a module that transforms the weights
The proposed framework tries to do that in a simple, modular, and composable way. Every factor that we think should affect the weight of a feature is a stand-alone module that increases or decreases the existing weight. How the weight is changed, it depends on the module itself and the data we have in our possession.
For example, if we keep track of the user comments on the App Store asking for missing features, we could come up with a “user feedback module” that would increase the Business Value weight of all the features users are requesting.
It is entirely up to us to identify modules like the “user feedback module” that affect either the Business Value or the Effort, define how they change them in the form of a transformation function, and apply them. And since the transformation functions are of the form f: Value → Value (endomorphism⁵), they compose infinitely. That means we can use any number of modules we want and chain them one after another in a plug-n-play fashion.
The power of compositionality is that it allows us to modify at any time the chain of modules by adding any other module we would like to affect e.g the Business Value or by removing an existing one. We could even apply normalization² after each module application to keep the weights within the selected scale.
Let’s have a look at two examples of how modules could look like, one for Business Value and one for Effort.
An example module for Business Value
Competition analysis module
Let’s assume that we want to factor in the competition status when calculating the Business Value weights. We start by identifying the competitors and writing down all the features that our application is missing, but the competitors might have in a competition analysis matrix like below.
We note the presence of the feature in a competitor with an (X) and the absence with an (-). Features like 𝔽3 that do not exist in our competitors but are something that we might be interested in implementing ourselves, we call them competitive advantages. Features like 𝔽2 that appear in all competitors except our application, we call them competitive disadvantages.
For example, we could choose to promote competitive advantages by 20% and competitive disadvantages by 10% (based on some reasoning that we should catch up with the competition), while applying no change to all other features.
Applying the “competition analysis module” to our initial values will shift the Business Value weights in the scatterplot along the y-axis.
An example module for Effort
Implementation complexity module
For this example, we will assume that we would like to factor in the implementation complexity of a feature when calculating the Effort. First, we would have to agree on how to model complexity. We could divide the tasks into high, medium, low, and none complexity and increase the weights accordingly.
Again, it is essential to state that how we model complexity and how it transforms the Effort weights is entirely up to us. There is no magic number here; we only have to agree on something that suits our data and use that consistently. It is the same process as when defining a module for Business Value, but now the features on the scatterplot are shifted along the x-axis.
Below you can see an examples on how the features would be further affected when applying the “implementation complexity module” (we assume none complexity for 𝔽1 and 𝔽3).
Conclusion
The Effort-Value model makes prioritization of new features very clear and understandable by visualizing them on a scatterplot. The values that we feed the model, though, could be more than just once-off initial weights that we have chosen. What if there are multiple factors to consider when estimating the Business Value or the Effor? The current proposal extends the basic model to account for any other factor in a simple and plug-n-play fashion.
In this proposed framework, every factor is an independent module that can be plugged in and out whenever we want and can compose well with the other modules. The composable module is the core of this framework as it gives flexibility and increases our modelling capabilities.
This proposal is not about providing a concrete prioritization framework. It proposes something more powerful, a way to build a prioritization framework that can be extended and formed to meet the specific needs of each team. Thus, although I tried to present some module examples, every team should try to come up with their own based on intelligence and data they have in their possession. I cannot wait to see what you can come up with.
[1] https://www.mindtheproduct.com/enter-matrix-lean-prioritisation/ https://www.productplan.com/glossary/value-vs-complexity/
[2] Usually, choosing values for the Business Value is done by the product team, and selecting values for the Effort is done by the project manager and the engineering team.
[3] https://en.wikipedia.org/wiki/Planning_poker
[4] Every time we want to transform our values and keep them within an initially selected scale (e.g. [0–100]), we should normalize. We take the maximum weight, divide it with the maximum scale value, and compute a normalization factor. We then need to multiply all weights with this factor.
[5] In mathematics, an endomorphism is a morphism from a mathematical object to itself. https://en.wikipedia.org/wiki/Endomorphism. The input and output are of the same type, and in our case, it is a function that takes as input a value and produces a value again. That enables us to compose them easily by chaining one after another.
