What product managers need BEFORE they prioritize release investments

The fact that I see lots of blog posts and other content on feature prioritization makes sense -- it's generally considered one of the key accountabilities of product managers. There are all kinds of prioritization techniques, e.g., value vs. complexity, the Kano Model and MoSCoW,  that can help you focus on investments that are most likely to contribute to your product's success. Recently, I realized that I see much less emphasis placed on the preparation required to prioritize features, irrespective of the approach adopted. It also occurred to me that very often product managers are prioritizing the wrong things.

It is common for product managers to create lists of requirements or the associated features (requirements and features are *not* the same thing) and then try to prioritize or even stack rank them based on a combination of intuition and perhaps one or more of the prioritization techniques mentioned above. The problem with this approach is that individual features, by themselves, don't necessarily support a broader use case or scenario that actually delivers customer value. Imagine someone asking you as a car buyer if you prefer a stereo in the car *or* speakers. The truth is, your requirement is that you can listen to music. I was years into my career before I realized that I should be prioritizing use cases/scenarios rather than individual features. I must admit I'm a bit embarrassed that I regularly provided customers and partners with flat lists of features and asked them to prioritize them (sometimes based on a fake budget) without their having an understanding of how these features would work together to support their key scenarios. I realize now the results from such exercises were extremely suspect and often misleading.

So now that we know what to prioritize (use cases/user stories scanrios and not features), what do we need as input for the prioritization exercise regardless of the method we plan to use? I would suggest the following:

Business Motivation
Here I refer to the "why"aspect of product development, referring specifically to the OMG's Business Motivation Model, which defines key concepts such as vision, goals and objectives. Defining a product can be thought of as an exercise is balancing stakeholder needs with your product vision, which, if you desire to be innovative, will, by definition, imply investments in features your customers don't know they want yet! Understanding your vision and business objectives clearly is critical to prioritizing investments in your product.  I've written about the business motivation model in a previous post.

Stakeholder Analysis
The use cases or scenarios you're prioritizing should be a reflection of requirements you've gathered from all your stakeholders, including (but not limited to!) customers. Partners, executive management and even product managers of other products in the portfolio can have a profound impact on your product's success; don't overlook them! If you're not aware of all of your stakeholders or don't understand their influence on your product's success, there is a very good chance your prioritization efforts will yield half-baked results and ultimately, unhappy stakeholders. The stakeholder influence-impact grid can be a great start to understanding your stakeholders.

Implementation Estimates
You will need at least high level estimates of how much effort each use case will take to develop and test (development costs can be dwarfed by the cost of testing some features). It is impossible to reason over the net benefit of a given investment if you don't understand the cost side of the equation. Although accurate estimates can be hard to come by early in the release process, techniques such as t-shirt sizing can help.

Business Justification
Each user scenario you prioritize should be justified from a business perspective. I'm not referring here to a full-fledged business case, which can be difficult or impossible to reasonably develop at the feature level. What I mean is that you should have a sense of the likely business impact with enough detail that you can compare scenarios on this basis. Will the scenario increase adoption? Will it unblock a significant number of sales? Doing some thinking here can help exclude features that seem valuable but have questionable business impact and, of course, help determine which scenarios will give you the best bang for your buck.

What do you do to prepare for prioritizing release investments? What other types of data do you collect? What exactly do you prioritize?

Previous post: A simple life hack to deal with the mental "reminders" we receive on the verge of sleep

You can find more information about me (including upcoming training dates) at www.prickril.com.