Do you prioritise like a HiPPO?

3 min readOct 18, 2016

By Craig Rees, Chief Product Officer at Unlockd

Product managers have one job above everything else: making sure their teams are working on the right things at the right time.

Whether they be financial, capability or people based, constraints will always have an impact on how quickly you can move forward This means a key role of the product manager is to prioritise the goals his or her teams are working on now vs goals they should do later or even not at all.

Seems straightforward enough doesn’t it?

Yet in a number of organisations (actually in my experience, in most organisations) you will see the ‘HiPPO’ methodology being used to determine which initiatives should be worked on and in

For those new to this term, HiPPO is an acronym for ‘highest paid person’s opinion’.

A throwback to an old school management style whereby the person with the highest paid job is seen as the expert with the best understanding of the overall situation and therefore in the best position to make key decisions, particularly surrounding product development.

Today’s agile product delivery model means the idea of an ‘expert leader’ is becoming less common, with a more inclusive and organic decision making process happening much closer to the action. Further away from the “weeds”, this naturally means that HiPPOs are less likely to be right when it comes to deciding what your teams should be working on next.

As well as more robust, tangible and relevant product outcomes, there are also soft benefits to an alternate approach. The HiPPO methodology can alienate team members, create a top down leadership structure and foster animosity across teams.

As always, there has to be a better way.

‘Cost of delay’ is one such approach. The framework was popularised by Don Reinertsen in his book Flow, about lean product development, and is based on the scheduling concept of ‘Weighted Shortest Job First (WSJF).

WSJF is based on the concept of product development flow and is a key component of the scaled agile approach recommended by Dean Leffingwell. It takes an economic view of delivery, ignores sunk costs and creates a framework for more objective discussion.

How to determine your WSJF, or cost of delay:

  • Identify and assess the impact an initiative will have to key business driver
  • Assess the value it will deliver, including any business risks it will reduce or opportunities it will open up across the business, as well as the time criticality of an initiative
  • Look at how long it will take to deliver the initiative, the duration or job size

Divide one by the other and you get a score.The higher the score, the higher the priority. This is your WSJF.

WSJF = Cost of delay (Business Value + Time Criticality + Risk or Enablement) / Duration

If you are really on top of your game, you can define true financial figures for your value and then calculate the true bottom line cost of delay.

At Unlockd, I like to fill in the model with a group of stakeholders who all have skin in the game when it comes to what gets done and when. For me, the best part of using a model like this is not the first cut of the prioritised list — but the conversations it drives. Instead of initiative owners arguing over whose project is the most important, you start to look at the value drivers and discuss which initiative will drive more value in comparison to another. Can value be delivered faster?

There is no silver bullet, but if you can get stakeholders and teams focusing on the value drivers, they can get a better understanding of what makes a particular initiative important.

This is a crucial need for a growing business. When you start to get into delivery and priorities, calls have to be made or features tweaked. As Jeff Patton talked about in his book User Story Mapping, the value is in the conversation over the artefact.

What are your thoughts? Get in touch.




Forever changing the way people use and pay with their digital devices