Extending features of existing products (that is… little “i”) versus big “I” (new product innovation), has gotten a lot of debate on the best way to prioritize product requirements.
Let’s face it… the features that often move to the top are those that the most profitable customer needs or what the CEO thinks is important. In many cases, legacy product request prioritization is not scientific. But should it be?
If this was a perfect world, how should a good product manager prioritize features in a release? Do you segment and rank benefits that are closest in congruence with long term business strategy…. those that return the most profit over the near term… those that are easiest to develop… etc.?
It seems everyone has their own approach… their own “best practice.” It seems most product managers assign attributes to each feature. Examples of these include:
* Build customer loyalty
* Create competitive advantage
* Further business strategy
* …and, of course, the near term financial contribution (more revenue, lower cost, etc)
Aligning each feature request to a list of attributes is vital. As business cycles change, so does product investment. In a down cycle, for example, management may want to advance features that provide revenue sooner versus investing in features that return value further out.
Most product managers that I speak with assign a weighting to each benefit on a scale of 1-10 based on the stakeholder voting. They then calculate a weighted sum score of all the benefits in a release to get to a “Total Return.”
Then they assign a cost value to implement the “Investment” in the release again on a scale of 1-10. Dividing the “Total Return” by “Investment” will give a simple (real simple) ROI Metric for the release. The goal is to craft a portfolio of features that best meets the needs of the stakeholders.
You can then use it to prioritize the features and get a straightforward structured method to prioritize the features in each release. This type of a methodology is much more repeatable and defensible than ad-hoc judgments often used to prioritize requirements and features.
Obviously, the trick is to get the stakeholders to value the various features similarly. Value agreement isn’t expected to be exact, but outliers can be a problem. For example, the client user committee may value highest those features that give more immediate operational relief (i.e., short-term focused), the sales reps may value the features that they have already promised to their sales prospects (i.e., whatever generates new sales in the next quarter), and the marketing team may value highest those features that improves competitive advantage in that new market segment that have been promoting.
Consensus? I think not.
Years ago, a mentor told me that being a product manager is about balance. And she was right. All stakeholders are right… all the time. Disagreements in feature value assignment is largely due to perspective. Like skiing on ice, its all about negotiating the bumps and achieving perfect balance.
The Product Pipe 