What Hippos Have to do With Your Software Product

There are many things that can prevent you from delivering a great roadmap, one of which is the HiPPO…the Highest Paid Person’s Opinion.

The HiPPO can be a customer, an internal user, a colleague, or your boss; they are high-status individuals that are accustomed to setting the agenda and having their opinions heard and acted upon.

It doesn’t matter where they come from, HiPPOs are dangerous if not handled with care.

Thanks to Stefan Steinbauer, Unsplash: https://unsplash.com/photos/1O1hLL-v7Hc

What’s so bad about a HiPPO?

It’s all too easy to start implementing feature requests that your boss is shouting about, but this does not always end well. The problem is that it feels like what you should be doing, when in fact it’s often the opposite.

HiPPOs are dangerous because when you start valuing the feedback of one person too highly, it is often at the expense of the weight of evidence and data.

The HiPPO is often too far removed from the problem that your product solves to be able to understand how best to solve it.

You can’t build the best product by building what one person wants; seeking ideas, prioritisation and validation from a wide range of user groups will help you to make the best product decisions.

Unbounce did a great April Fool’s prank to illustrate this very problem.

That isn’t to say you shouldn’t be focussed…knowing and understanding your end user and target market is something we should all strive for. HiPPO specifically relates to when too much weighting is placed on the opinions of:

• One company or individual; or
• A number of people more senior in your organisation.

Note the importance of the word “opinion” here. The best product decisions need to be backed up with data as well as qualitative information.

Taming the HiPPO

Don’t get me wrong, HiPPOs can be extremely helpful but next time you encounter one, proceed with caution.  Here’s our top tips for when you see one hurtling towards you:

Know what a HiPPO looks like

Knowing what a HiPPO is and why they can be dangerous is most of the battle. When you spot one, you can take action. Look for a lack of day-to-day use of your product combined with an impressive job title.

Handle with care

The HiPPO’s opinion does matter but it can’t be the only voice you listen to. Be aware of this. Listen but explain how their feature request fits in with the bigger picture. Which leads on to:

Get some data to back you up

Backing feature requests up with real data matters. Weigh the information up against their opinion, share this with them then make an informed decision.

What to do when the HiPPO is your boss

Ah the HiPPO boss, I think most of us have been there. The answer, as it is to most work problems, is good communication. Easier said than done though right? Here’s what’s helped me before:

Pitch feature updates and information at the right level

Of course the senior team need information on product, but you have to pitch it at the right level. Do your homework – know what’s important to them, understand the business objectives as a whole and create an agenda in advance. Preparation = confidence.

Be prescriptive about input into feature requests…if you can

If you need to produce a detailed update on feature requests, use themes as areas for discussion. Adding a little structure ensures you avoid the “blank slate” problem of HiPPOs having free reign to suggest whatever features they like.

Make the HiPPOs understand where their feature requests fit by showing them in context

Opinions and gut-feeling are great but they have to be balanced against data. Presenting prioritised feature request information from other relevant departments or customers can help counteract the opinions from that one loud voice.

Help, I think I’m a HiPPO!

Don’t panic. You can change your HiPPO ways. It’s a wonderful and healthy thing to bring new ideas and opinions to the very large feature request table. However, try to balance your opinions with data and the priorities of others. Get the product team to prove you wrong…or right…ask for the data to back up product decisions and run experiments when you need to.