This is the second in an ongoing series of blog posts originally published on the UserVoice Product Management blog.
There’s no Product Manager alive who hasn’t spent time dreading a HiPPO attack; the sudden derailing of well-laid plans by a management or executive-level stakeholder who insisted that their direction was the right one simply because it was their idea – regardless of whether or not they’d actually done any research or validation.
This is the HiPPO problem – the moment when the “Highest Paid Person’s Opinion” is asserted as fact and intended to be directional. Often, these HiPPOs come from the executive level, from the CEO who has a new “vision” for the company or from the CTO who wants to take the company’s technology in a “new direction.” HiPPOs can also pop up in other contexts, such as sales management trying to ram through a hypothetically big sale, development managers asserting that they know the “only” way to solve a problem, or service delivery management teams insisting that the way they use the product is the way all customers use the product.
HiPPOs usually come with good intent – rarely does the HiPPO represent ill intent or a desire to be obstructive; but that doesn’t necessarily mean that they’re right or that they should be allowed to dictate product direction without further investigation.
Why are HiPPOs Problematic?
The problem with HiPPOs, as elaborated by Paul Jackson of Newsmart, is that HiPPOs are subjective and unscientific – in fact, they are “emblematic of large, autocratic organizations instead of smaller, more democratic startups.” They are a holdover from classic command-line structured organizations where people did what they were told to do, simply because they had no say in the matter. HiPPOs were once part of the corporate food-chain, primarily because the cost and effort to challenge their decisions simply wasn’t available to others in the organization or to people outside their “chain of command.” This simply isn’t the case in the present day world of Big Data and a culture where data is shared rather than being locked up at the executive level.
HiPPOs can cause problems in organizations for several reasons. First, there are cultural impacts to HiPPO behavior.For example, the people who are executing product efforts on a daily basis may begin feeling micromanaged or a lack of confidence.. When decisions are being made primarily by one or two people, seemingly based on their own whimsy and opinions, others in the organization begin to doubt their own impact on the direction or strategy of the product – especially those who are closest to the customer, such as support, sales, or even product management.
The more often decisions wind up being made by a HiPPO, the less likely customer-facing teams are to engage in planning; and the further afield the company winds up getting from solving the actual problems of their real markets and customers. The HiPPO often used to live among the people that the product serves, but doesn’t realize that they’ve lost that contact and context simply by virtue of their new role in the company they’re working in. So they think they’re representing the best interests of the customer, but in fact may no longer have the context to do so – while actively (if not intentionally) pushing away those who maintain that very context.
Second, there are confidence impacts, where changing plans or direction based on what appears to be the whims of the HiPPO cause massive disruption in strategic planning and tactical execution. HiPPO decisions that don’t cause change are rarely problematic – in fact, if a HiPPO confirms the direction you’re already going, it’s unlikely to even look like a HiPPO. But, when these decisions do make changes, they’re rarely course corrections and often require charting an entirely new direction, out of whole cloth. And, when that happens, it causes others in the organization to question not only the prior path that the company was on, but also the new direction.
People like to see things through once they begin them; they want to know that their work is valued, and that it is valuable. They want to believe that when the company starts something, it is with an intent to finish it, and that the decision is based on some reliable course of thought or discussion. Repeated changes of direction through HiPPO influence can undercut confidence in the product, in the leadership, and even in the company as a whole which can have a disastrous effect on company morale.
Third, there are practical impacts on work-in-progress that often explode when a HiPPO asserts a new and unsubstantiated opinion on what the company should be doing or where the product should be going. HiPPOs often don’t realize that their thoughts and comments have real impacts on the day-to-day work that goes on around them. They sometimes don’t understand that changes in product strategy, work to deliver something to a valuable client, or even changes in technology incur opportunity costs against work that’s already in progress. It’s not uncommon, in fact, for a HiPPO to inquire about why previously-planned work is delayed after having provided new direction or deliverables that cost resources, time, and effort to deliver. The more often this happens to execution teams, the more disillusioned they become in the work that they’re being asked to do on a daily basis.
What Strategies Work When Taming HiPPOs?
Fortunately, there are a wide variety of strategies that can be used to manage around the wants and desires of the HiPPO.
Fight Opinions With Data
Dan Barksdale of Netscape is credited with a famous quote that encapsulates both the problem of a HiPPO and the primary solution: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” This simple quote really tells us all that we need to begin to attack the HiPPO problem – in the absence of data, the HiPPO wins – every time. That’s because without data, all that we have are opinions, and the more experienced voice in the room is often also that of the HiPPO. Thus, the best and easiest way to work to correct for HiPPO behavior in an organization is to either have the data ready when engaging in discussions likely to result in HiPPO decisions, or to defuse the situation so that you can either validate or invalidate the HiPPO’s decisions and desires.
If we have data, let’s look at data. If all we have are opinions, let’s go with mine.
As noted by Dan Pitrowiski in an excellent Medium post on small team product management, it’s important to note that the data that you might want or need doesn’t always have to be quantitative data. While it’s great to test and validate ideas with solid numbers, it’s sometimes expensive to do so. And, if we lack quantitative data, we can always collect, collate, and present qualitative data. As Dan says, “When there are no metrics, gather opinions.” But the opinions that you collect must either be strongly compelling (such as a quick survey of important clients) and/or opinions focused on identifying how the proposed course of action contributes to the important metrics for your organization. It’s about reframing the conversation so that the opinion is not the target of the inquiry, but rather that the goals of the company frame the discussion and the proposed course of action is bounced off of those goals. It ceases to be a battle of opinion and becomes a battle of rationalization.
Lastly, it’s essential that the Product Management team have direct customer contact and market interaction in order to defuse HiPPO situations. As Rich Mironov notes, very often a HiPPO conversation comes from a singular meeting with an important customer or an influential analyst. In those instances, the data that can be used to deflect the HiPPO input is the exposure that the Product Manager has in the market – “I’ve talked to 12 customers in the past 2 weeks, and 8 of the 12 told me [X]; it sounds like what we’re talking about might be an outlier.” It won’t necessarily end the conversation, but it does set the context for the discussion that perhaps the HiPPO’s opinion doesn’t represent a broadly applicable request, but more of a one-off interest.
Prioritize the Work
One of the most entertaining ideas I’ve encountered with regard to product input and prioritization is Rich Mironov’s famous “Idea Train.” As Rich puts it, the idea train “pulls into the product station every day and delivers hundreds of ‘good ideas.’” However, Rich notes, few of these ideas are really as new or earthshaking as those onboard the train would like to believe. And the HiPPO’s input really should be treated as just another piece of cargo carried by that train, one that needs to be validated and prioritized against the current backlog of work that’s already been discussed and agreed upon. After all, the development team can only implement a couple of new ideas this week from among the hundreds proposed.
Aside from having hard data to use in challenging a HiPPO’s directions, the next best thing that a product manager can have is a solid, prioritized, and clearly-elaborated product backlog (or product roadmap). This backlog and the process used to create it need to be transparent and inclusive of the management and executive teams, so that when a new and disruptive proposal comes up, it’s entirely unsurprising for the product manager to simply say, “That’s a great idea, but where does it stack against the top 10 tactical projects that we have going on right now?” It could be that the HiPPO will assert that it’s “obviously” the most important thing, but when faced with the actual list, upon which other groups in the company may have based their own deliverables, it’s very likely that what is important in the moment falls down below the line for consideration when others get involved.
Deflect the Input
Often, however, product managers wind up in a tough situation when a HiPPO shows its true colors, because these decisions or objectives come out of nowhere, with little to no warning. When this happens, you may not have the data, and your attempts to get the HiPPO to prioritize the work against current efforts may be a difficult row to hoe. It is in these situations where Rich recommends a deflection approach:
That’s a very interesting and smart idea of yours. Let’s take it offline so that I can learn more, write up some requirements, and see what kind of effort we’re looking at.
The goal of this approach is to deflect the impact of the HiPPO’s decision and to buy you time as the product manager to…well, do your job. It reinforces the HiPPO’s position of authority, gives their ego just enough polish so that they don’t feel attacked, and buys the team valuable time to actually validate the opinion, confirm the existence of a market problem that it solves, and to size out the effort so that a valid prioritization decision can be made at a later date.
The other important thing that this buys the product manager is time and separation – many times the opinions of a HiPPO change drastically from moment to moment, and what was of the utmost importance yesterday because it was top-of-mind after an analyst call, becomes far less important over the course of a day or two. Deflection is an amazing tool when used properly, as it both allows the HiPPO to assert their opinion and authority, but also reinforces the role of product management in validating, confirming, and prioritizing improvements to the product.
HiPPOs Aren’t Always Evil, Though…
Although many people see HiPPOs as an entirely evil or destructive force, the truth is that’s simply not always the case.
Tristan Kromer wrote a great piece “In Defense of the HiPPO” in which he identifies three situations where bending to the will of a HiPPO is actually productive, and proposes that the HiPPO is far less dangerous to a product company than the “ZEBRA” (Zero Evidence But Really Arrogant). Tristan’s thesis centers around the costs of testing ideas, which can sometimes be far greater than simply executing them and retrospectively confirming their delivery; on the need for Product Managers to choose their battles and to occasionally bend to HiPPOs for purely political reasons (when the impact to the product is negligible); and that a HiPPO decision can simply end debates that had no point in the first place. Even though we often see HiPPOs as a destructive force or source of undue randomization, we should also realize that the HiPPO often is in a role of authority or leadership, and that sometimes just doing what they’re asking is less trouble than it is fighting them.
In Tristan’s article, he explains the difference between a HiPPO and a ZEBRA is that the HiPPO can still be swayed by facts – the HiPPO is a Barksdale, in the absence of data, their opinion rules. A ZEBRA, on the other hand, asserts their opinion as fact, and is not only uninterested in debate, but actively shuts it down. Anyone who’s heard an exec tell them, “The customer is just wrong,” or “The customer just doesn’t get it,” was dealing with a ZEBRA and not a HiPPO. HiPPOs can be reasoned with, engaged with in prioritization, and swayed with facts and data – ZEBRAs are stubborn and insist that you do what they say simply because they said it.
As product managers, understanding how to identify a HiPPO (or even a ZEBRA) is something that we should focus on every day. Dealing with the impacts of their decisions, or deflecting those decisions with data-driven decision making is a skill that separates merely good product managers from great ones.
