14 Feb 2020

PRONOW: Prioritize Outcomes, Not Work

Product development teams have to deal with multiple stakeholders. They each have their own set of priorities. That's natural. Reconciling these priorities into a single-threaded product backlog can be a thankless task. In theory, "cost of delay" based prioritization techniques should let us avoid "HiPPO prioritization". In practice, these techniques help only so much. How do you validate and normalize costs assigned by different stakeholders? The whole process is vulnerable to false rigor and gaming. But what if, instead of trying so hard to avoid HiPPO prioritization, we let it happen within guard rails and compensate for it with tight feedback loops? We'd end up with a much simpler prioritization process. I call it PRONOW (Prioritize Outcomes, Not Work).

Co-conspirators: Ricardo Cavalcanti, Cristiane Higashi


Step 1: A Tree of Success starts with "overall success" at the top, branches off into high-level business measures of success, and drills down all the way to metrics that can be tracked on a regular basis via production analytics, surveys, ratings, etc.

Step 2: Outcomes are defined in terms of improvements to any metric on the tree of success. Stakeholders prioritize outcomes that they expect to improve through next quarter's (or other planning period) efforts.

Step 3: Independent of step 2, product backlog owners map items in their backlog (representing demand from various stakeholders) to nodes in the tree of success.

Step 4: The output of steps 2 and 3 allow us to derive priority for backlog items. They still need to be matched against team capacity but that's just detail. Did you notice what just happened? We did not prioritize work directly. We prioritized outcomes, not work, avoiding a lot of bickering in the process.

How do we know we've prioritized the right things? By tracking actual benefits with a tight feedback loop. We've deployed it at a client with good results. If you'd like to try it, get in touch. There's a ton of detail not covered here, such as dealing with dependencies, for example.

Note: This may appear to be just another prioritization technique but its actually a framework for greater outcome-orientation across business, product, and engineering teams. Business buy-in is mandatory for successful adoption. Old habits might need to change. After effects might be long-lasting and transformational. You've been warned.