From HiPPOthesis Driven to Hypothesis Driven
If as a Product Manager you haven’t heard about the HiPPO concept before, I bet you will easily recognize it.
HiPPO stands for “Highest Paid Person’s Opinion”
(1) The acronym is used to describe the tendency for lower-paid employees to defer to higher-paid employees when a decision has to be made.
(2) The term can also be used to describe an organization’s reliance on human instinct rather than data in the decision-making process.
Source: https://whatis.techtarget.com/definition/HiPPOs-highest-paid-persons-opinions
Both definitions have a strong relation to what we might encounter in our wild PM world.
We should work in harmony with HiPPOs as their -often strong- opinions may have a good reason behind.
HiPPOthesis Driven
A C-Level (HiPPO) from your company sends you an email: “I’ve seen our strongest competitor testing XYZ. I want it implemented ASAP.”
Your biggest client (HiPPO) is asking for XYZ features to seal a deal and your sales team is on their side. We have to do it or we’ll lose the client!
A strong stakeholder (HiPPO) saw a prototype your team is working on: “This won’t work, I know this will damage our department’s KPIs. Please adjust it by making these changes, we can’t allow your proposed design to go live.”
The CTO/CIO (HiPPO) found a bug and wants it to be solved in the next release.
As a HiPPO
I want this
Period.
In order to cope with these requests both soft and hard skills can help us. One of the most import tools is our ability to say No.
In case you don’t want to say No — and that’s a decision you are making — this situations can often lead to reprioritized backlogs, expedite tickets, multiple extra features added (feature creep), last minute changes to your User Stories, roadmap adjustments, team motivation diminishing, and the list goes on and on.
There should be a way to tame the beast, live together peacefully and achieve much more working together. We want to create a symbiotic relationship where we can all thrive.
Hypothesis Driven
In a Hypothesis Driven environment, we have an experimental approach where the outcome of each experiment is to gather measurable data and learnings. We also rely on data to prioritize our experiments, predict the time needed for experiments to reach statistical significance, and compare the previous and new data to identify improvement signals.
This article doesn’t want to be deep dive into hypothesis driven theory (and practice). There are many books you can read, online articles and experienced PMs you can reach.
Barry O’Reilly gives an excellent overview about How to implement Hypothesis-Driven development. I encourage you to read the article to familiarize with the concepts behind.
A business story, Barry suggests should look like:
We believe that <this capability>
Will result in <this outcome>
We will know we have succeeded when <we see a measurable signal>
Of course, for some trivial changes, HiPPo’s requests can be easily tested without investing much time and effort. But what if doing our “new” feature is a 4 months project with many uncertainties and underlying risks. We will be able to validate or discard the HiPPOthesis only after those 4 months, neither we nor the HiPPO would be happy with the result of our experiment.
A team simply taking orders from a business owner is not utilizing the full potential, experience and competency that a cross-functional multi-disciplined team offers.
- Barry O’Reilly
Here is where Lean Thinking can help. Is there a fastest way to validate your hypothesis without building the real thing? Can you validate demand first? Is there enough people willing to pay for/interact with your new feature? Do you have supporting data? Is there any qualitative research you can refer to?
In other words, can we demonstrate ourselves and the HiPPO that it’s worth pursuing his/her idea? At the very end, we both want the best for the business, the HiPPO might be right but we need to follow him through our processes, make him/her understand that everyone can be wrong (Have you seen business cases fail?) and that nobody is trying to outsmart the other. But how?
From HiPPOthesis Driven to Hypothesis Driven
The reason behind this change is to make HiPPOs aware of the processes we adhere to, make them understand that there are assumptions in their requests that need to be validated, guide them through our thinking process, inform them about what data we have to support/discard their request and last but not least show them that we are in the same ‘swamp’.
We take their ideas seriously and we will consider them if we see an opportunity, there is evidence behind it and we can validate the assumptions in an easy way (same process we shall apply to everything we embark into).
As mentioned before, if we don’t do it, our product management processes will suffer, we can be ending up in waterfall-land.
Product management is people management, there are no standard procedures you can follow in every situation, there are no good or bad frameworks, but there are certain things you learn from experience that might be useful. Here is what I learned.
Understand what’s below the surface
There is more than meets the eye. Behind any request there are beliefs, assumptions and hope. HiPPOs might be worried about business performance, they need results to steer the current situation and they have lots of ideas. If they are spending time with these requests is because they want to contribute .
We first need to analyze the request as if another colleague, designer or close friend suggested it. Does it make sense? Do we have enough data to check beforehand? Have we seen the results of something similar inside/outside the company? If this idea would come from your team or from yourself, what would you do? All this questions are useful to isolate the weight effect, there will be pressure, but we need to think and take a deep breath.
Don’t be intimidated
HiPPOs can be intimidating. If they open their jaws in a threatening way, just be patient, don’t panic. They probably need attention and you just need to listen.
Exercise your active listening and ask questions, let them know that you care for the business as much as they do .
Do you think that your request is more important than the current thing we are working on? We prioritized our work based on this data, do you have some extra data that I might be missing for your request? Is this a strategic request that will put us on top of our competitors, if so, can we first finish what we are doing while thinking on the best execution for this new request? Do you believe your request will have a bigger impact than the things we have in our backlog? We considered this in the past and it was discarded as we didn’t have any supporting data to prioritize this, has something change that we need to be aware of?
By making this questions, you let them know that data should matter more than opinions but also that you are humble and if something has changed or there is something you are missing you are willing to work on their request.
Build a symbiotic relationship
Demonstrating that you are aware of the business performance, that you prioritize based on data but also that you want to help is a good way to build a symbiotic relationship.
A symbiotic relationship is built on trust. HiPPOs need to believe you are there, that you have your opinions based on data and you want the best the company. You have to trust on them, they can be the leaders of the company and by nature they have a different set of skills than you. Diversity matters.
Delivering results is important to foster this collaboration but also the process behind.
Try to create this relationship where mutual trust is key.
Feed them
Every now and then, you need to feed them. Once you’ve implemented their request, communicate what you’ve learned from it. Did it have the impact they were expecting? Were you able to validate his/her hypothesis? What was the effort needed to build it and the outcome of it?
By doing this, you keep communicating your process, an in a subtle way you let them know that their assumptions might be wrong too.
Speak often and clear
You have to tell them the whole story. No missing pieces. Story telling is key for the communication to succeed.
Regardless if you will discard, postpone, proceed or iterate their request; let them know how you managed to reach this conclusion.
Don’t bore them
Story telling again, know your audience, deliver the message in words they can understand and build trust. Adapt your message to your audience: technical stakeholders, business owners, data people, people people, expressive people.
Collaboration is key
If you manage to effectively collaborate with your HiPPOs, they will remain quiet, knowing that you are working towards the same objectives and considering their requests with processes that maximize the return for the company.
Final words
Let’s face it. There are no frameworks nor recipes that you can follow every time. This is not rocket science, product management is people management.
Leave a comment to learn more about how others are working with HiPPOs.
*No HiPPOs were harmed in the making of this post.
