Prioritization Beyond Algorithms
The problem of prioritization comes up in many of my coaching discussions with product leaders, and in almost every product forum. We want it to be a trivial, mechanical process: pick a metric (usually current revenue), estimate ROI for the entire backlog, then do whatever scores highest. But that very rarely works in practice. Prioritization fits into a larger strategic and organizational framework.
First, some frequent symptoms (or myths) that expose the problem:
— Requests for a magical, universal prioritization spreadsheet. I don’t believe in one, since every product has its own goals/definition of success; its own point in the lifecycle; its own history of good/poor technical investments; its own economic and revenue urgency; and its own competitive situation.
— Forcing unlike things into one (financial) metric. It takes different kinds of work to deliver and support and grow a software product: innovative capabilities, competitive table stakes, bug fixes, scalable infrastructure, intellectually honest discovery, crazy technical experiments, and more. Different categories of work each need appropriate (different) metrics. Otherwise, we’ll only work on “shiny new” features and wander into market irrelevance or technical bankruptcy. I don’t see one uniform metric for all requests getting good results.
— Wanting to rough-size everything in the backlog.
Please log in or sign up below to read the rest of the article.