Prioritizing Requirements - What is the Best Way?
7 Comments Latest comment by: Paul
reddit
| 
digg it!
| 
del.icio.us
I just read an interesting post by Jason at '37 signals' blog on Essential vs. Non-Essential requirements.
He discusses the process their team went through to prioritize requirements while developing their Campfire software that was released recently. In essence, it involves classifying requirements into Essential (must have) and Non-Essential (nice & cool).
This leads to the question of what is the best way to prioritize requirements? And is there a "best way" really? How exactly do you decide which requirements fall under the "Essential" bucket and which don't?
How is it done in most companies?
Product managers and Product marketing managers routinely go through this exercise of prioritization. For a high-value B2B software, any requirement demanded by a large customer gets Essential status while those that someone at the company came up with get Non-Essential status. In small startups, the requirements the founder(s) really want could end up getting the Essential status.
In other words, which requirements get the Essential status is often decided by the importance of the originator of that requirement! Is this the best way?
What is the best way?
In theory, capital should be allocated to maximize ROI (return on investment). ROI can be defined in many ways - but is usually defined in terms of a financial metric such as NPV (net present value).
If that is the case, requirements should be prioritized in terms of financial return they will generate. We can grossly oversimplify (for the purposes of this discussion) and say that requirements should be prioritized in terms of incremental revenue they can generate. I say "revenue" instead of "profit" (more accurately "free cash flow") since it is usually easier to estimate.
Your customers will pay the highest incremental price to those features that provide them the most incremental value in achieving their own goals.
Once we are able to estimate the incremental revenue generated and incremental customer value added by each requirement, we should be able to arrange them in a prioritized list. Sounds simple enough, right? Wrong!
Some challenges
The most common challenge is: How do you estimate the incremental revenue generated by each requirement?
This is usually done via some guesstimation work by the product/marketing manager. They usually use some third party reports (IDC, et al), data analysis of customers, and some guesswork. Sometimes customer feedback is solicited as well - but could be very cumbersome. Net, this is a very inexact science.
The next common challenge is: Strategic fit. What if a requirement can indeed generate high incremental revenue but does not align with "Corporate/Product Strategy"? This fit is usually decided by someone in the executive team and is the most common means through which execs contribute to prioritization.
Another common challenge is: Technical fit. What if a requirement can indeed generate high incremental revenue but does not fit with the technical expertise of the company? This fit is usually decided by an engineering/development manager. This is the most common means through which engineering management contributes to prioritization.
Final word?
When all is said and done, prioritization of requirements is an inexact, social activity. Lot of things need to be taken into account - in the case of larger companies, even some corporate politics!
Two factors: 1) ROI to company, and 2) Value added to customers should be the dominant factors - but other "soft" factors should be taken into account as well.
About the Author: I'm your author, Michael Shrivathsan, an expert in product management and product marketing with successful experience spanning two decades. I live in Silicon Valley, USA. For my day job, I manage the product management group at an exciting software startup.
Comments
Nice post, Michael. How do you calculate NPV for requirements? Is there a formula?
I found a nice article on NPV at http://hadm.sph.sc.edu/COURSES/ECON/invest/invest.html , but not sure how this applies here. Thanks.
Posted by: Josh | February 20, 2006 08:01 PM
Josh,
You are correct - it is hard to use such equation for each requirement.
As a short cut, you can use incremental revenue in the numerator in place of I0, I1, I2...
As long as you use the same equation for all requiements - the comparison should be fair.
Posted by: Michael | February 20, 2006 10:39 PM
I have a question. Setting aside corporate politics, what do you think should be the critical factors driving prioritization?
Plus, who should do this prioritization? In our company, the Product Marketing (a.k.a. Business Unit) team assigns the business priorities. Product Management team uses this priorities as much as possible in their MRD. Dev team simply implements to specs.
Posted by: Megan | February 21, 2006 12:59 AM
Megan,
I believe ROI and 'Customer value added' should be the driving factors in prioritizing requirements.
In terms of who does the prioritization, what you describe sounds normal at most medium or large companies. In smaller companies, there is usually no separation of Product Marketing vs Product Management.
Posted by: Michael | February 21, 2006 12:13 PM
In our organization, I just found out we prioritize based on NPV and IRR (internal rate of return). It rhymes with what you're saying.
Posted by: Vikram Singh | March 1, 2006 02:23 AM
Michael,
When I read this post and the related one, "Requirements vs. Feature" it brought me back to the challenge we had in developing our product. We prioritize our features by multiple criteria, (popularity, new revenue, new customers, cost to develop, etc) to define our releases. We do this at the feature level because the requirements are too granular, as you state in your other post, and they also tend to have dependancies on other requirements. Features tend to be more stand-alone and can be ranked independently.
Regards,
Posted by: Jim Begley | March 21, 2006 10:06 PM
I believe most companies fudge the science to do what they want to do. Whether it is a product manager, product marketing manager, senior executive, head of r+d, or the whole product team it doesn't matter. There is no way to create anything better than an approximate guess of revenue, NPV, IRR, ROI - whatever you want to use as your yardstick, unless customers are asked to pay in advance for enhancements.
The reasons for this are varied, but it is certain in any company that charges maintenance fees which include a subscription to future product upgrades that it is very rare that any individual feature can be assigned a specific value based on a percentage of subscription loss and likelihood of losses if a feature is absent. In the case of features that your competition already has, and that may cause lost future sales if you don't have them, or specific items that are important to a large customer which would cause them to defect if you don't provide them, you can attach some hard numbers, but everything else is guesswork. This is why these types of enhancements will usually move to the top of the list (probability = 100%, actual revenue gained or lost in short term is quantifiable), ahead of things which might yield much greater benefit in the long term but can't be proven.
In my opinion, the best way to do this is to acknowledge that there is no perfect science, do the things you know generate or protect revenue at something close to 100%, and give product management latitude to go with their gut and long term vision for almost everything else based on spending a lot of time talking to customers and watching where they have problems and successes.
If you use ROI calculations, use them as a guideline, but don't believe in them or sell them to your company as absolute. Has any sales team ever produced a 100% accurate revenue forecast? Can you accurately account for turnover in the sales department, or competitive initiatives or disruptive technology changes? Then why lie to yourself that this is anything more than a black art?
Posted by: Paul | May 1, 2006 01:33 PM