High, Medium & Low Don't Work for Agile
Based on field discussions and my recent experience at ProductCamp Toronto, it appears most product managers have no formal methodology to score or rank customer feedback or feature requests. In fact, I suspect very few product managers actually score features against any relevant business criteria --- rather they simply apply a basic prioritization scale, for example, P1, P2, P3 or High, Medium and Low. Is this you? For these PMs, spreadsheets are usually the weapon of choice and are commonly initiated with each roadmap, release or sprint exercise. With every new prioritization, a new spreadsheet gets created, copied, revised and versioned --- over and over again. Sound familiar?
What evidently happens with these methods is that P1s 
(or Highs) become disproportionally represented. For example, on 50 features, poor prioritization will result is 30-40 P1s. Of course, in realty, this means nothing. Essentially, it amounts to an abdication of responsibility --- responsibility for making a product management decision.
As experienced product managers, we all know, "if we don't do our jobs ---someone else will". In this case, it's likely to default back to development. Note, developers make decisions based on technical fun factors --- and they don't consider UI to be fun, ever. Hmmm... I think I'd rather get my teeth pulled...
Few Product Managers Apply Business Attributes to their Backlog
Not sure why, but I imagine lack of training and tools have a lot to do with it. This is particularly disheartening because both are available online --- either for free or very affordable.
The problem with this approach, I believe, lies in its simplicity. Don't get me wrong, simple is good --- but only if it's effective and drives intended results. Truth be told, I'd like to think product management today is a little more sophisticated, intelligent and strategic. I'm curious, if you are a product manager that uses one of the aforementioned prioritization methodologies --- I'd like to hear from you. Specifically, what drives your decision making? What makes one item a P1 and not a P2? How does a simple ranking demonstrate or communicate your strategic objectives, be it short or long term?
The biggest issue with a simple priority system is that it neither supports nor encourages the product team to think strategically. Must Haves, Should Haves and Nice to Haves are fuelled by opinion and filled with conjecture. How does High/Medium/Low demonstrate value or congruency with product objectives? As product managers, aren't we always defending our strategic value? Isn't this an ideal opportunity to demonstrate our business aptitude and strategic thinking?
Problem is Amplified with Agile
Perhaps my position is skewed as an Agile (SCRUM) practitioner and advocate. In fact, I see this issue amplified in an Agile environment. How do P1s, P2s etc. support sprint planning? What do you tell development --- do all the P1s? How do they know where to start or focus?
Aren't we supposed to have a theme or goal at the root of each sprint? If so, how are these objectives reflected and supported in your backlog? The onus is on us. If Product Managers or Product Owners don't step up and effectively control and prioritize their backlog, the team will flounder, lose valuable velocity and become increasingly frustrated.
Certainly, I have some ideas to address this issue and will address them in a follow-up post. In the interim, I'd like to hear from you and learn about your prioritization practices. Are my assumptions way-off? Am I complicating a simple task? Trying to kill and ant with a bazooka?