In this post I hope to quickly break apart the feature prioritization process. My goal is to help make prioritization more of a science and less of an art. Nothing below is ground breaking, but breaking it apart may help understand and manage the process better. Looking forward to hearing your thoughts and comments.
Prioritization Model:
There is always too much to do, but not enough time. In addition, the environment around us is constantly changing and PMs are fighting to keep up and create the most value. If value creation is the goal then we should proceed to do the highest value tasks/features, but in order to get the most done we must account for costs & time as well. Therefore the highest “Value to Time (V2T)” tasks should be done first.
Example – (Skip if the above is clear)
I will illustrate this in a quick example. Let’s assume we can choose amongst the following features and have a total of 60 development hours this month:
1. Better graphic design for the main screen. Value:200, Cost: 50 dev hours. V2T=4
2. Email alerts for new users. Value: 100, Cost: 20 dev hours. V2T=5
3. User tutorial. Value: 150. Cost: 25 development hours. V2T=6
If we choose only by value alone we will get 200 value unit by creating a better graphic design. If however we calculate the V2T ratios we will see that features 2 and 3 are of higher priority and will get us more value (250 units).
Understanding Value:
If we agree with the prioritization formula we should now try to understand it’s parts. Again, my goal here is only to give a high level overview allowing further investigation of each part.
Value is hard to calculate but is derived from the perception of the following stakeholders:
- Customers
- Management (who drive overall company strategy)
- All other company employees (the closer they are to the customer the more valuable they usually are)
There are many methodologies to understand perceived value from surveys to focus groups, but assuming the features are broken apart to small enough chunks it usually as simple as asking each of the stakeholders. Conjoint analysis is another useful method which asks stakeholders to choose between feature-set producing a comparative ranking.
Estimating Costs & Time:
Estimating costs and time is crucial. This is a major topic on it’s own on which I won’t elaborate on. An interesting discussion on the topic can be found here.
THE SECRET: Break tasks into smaller logical parts
In my view, the secret to software product management is being able to break apart the tasks into small, logical and understandable parts (i.e. strong logical modularity). Once you do that the road is paved to prioritization and execution. How to do so is a whole other issue and may change radically from project to project. I am still thinking of a simple model for this, but would love to hear your thoughts.
In future posts I will try to dive deeper into each of these topics and add additional models and frameworks. Stay tuned. Thanks for reading, if you liked it or have additional thoughts please leave me a comments and signup for my mailing list for future posts.
How to use this blog and where to go from here
My goal in this post and others is to build a knowledge map for the main activities Software Product Managers are responsible for. I plan to continue discussing and breaking apart each activity. Slowly, I hope to turn some of the art behind product management into a science. Take a look at the Product Management Framework page for more info.