Are HiPPOs driving your development?

The highest paid person’s opinion (more commonly known as HiPPO) is something I hadn’t really considered until recently when one of the UX guys I was working with mentioned it.

After hearing the term, it seemed that everywhere I looked I could see decisions on priorities about what should be developed next being determined by people in high ranking positions who, in my opinion, didn’t necessarily have all of the necessary information to make an informed decision but instead had a “gut feel” about what should be done.

This may have just been the Baader-Meinhof phenomenon at work but it got me to thinking about some of the requirements that were coming into our development pipeline.

Instead of our stakeholders coming to the table with something like “the business has X problem and we need to find a solution”, the features we were being asked to develop were pre-determined solutions without a clear definition of what problem it was supposed to be solving.

When we dug a little deeper into why we were being asked to develop some of the features it became apparent that the motivation seemed a little misplaced, the feature was to satisfy external investors that we were selling our products in the “right way” rather than focusing on solving a problem for our core customer base.

This raised a red flag with the development team. We were concerned that introducing this new feature might not be solving a “real” problem for our core customer and may well have a detrimental affect on the main revenue streams for the business.

We needed to try and better understand why we should develop the feature in the first place.

I had been following the Lean Startup movement for some time and liked some of the principles and practices that it introduces especially those introduced by Ash Maurya in both of his books Running Lean and Scaling Lean.

Ultimately we were trying to solve a problem, so it seemed appropriate that we could take some of those ideas and principles and apply them within an already established company in order to validate new feature requests and avoid building something nobody wants.

The first step was to see whether a Lean Canvas could be used as a starting point to begin understanding what problem the proposed solution was supposed to be solving. Initially my UX colleague and I went through an exercise of filling out a lean canvas. We focused on 4 sections:

1. Customer Segment & Early Adopters — who are the users and customers of the new feature, how do we find customers that would take the product on in its early stages?
2. Problem & Existing Alternatives — what is the perceived problem that we thought the customer has and how does that customer currently solve this problem using things that are currently at their disposal.
3. Solution — what is the initial proposed solution to this problem.
4. Metrics — how would we track whether this feature has succeeded.

Once we had captured our initial thoughts on this we then set about performing a 5 whys analysis process in attempt to get to the root cause of why the customer was experiencing the suggested problem.

The results were quite eye opening and we found that off of the back of this process we could come up with a bunch of potential questions that needed clarification through a form of experimentation in order to de-risk whether this would actually be a problem worth solving before we built anything.

Of course, we had only performed this analysis between my UX colleague and myself — we needed more input before we could move forward.

The next step will be to introduce the process to our stakeholders through some small workshops to help us understand their thoughts on the proposed solutions and come up with a proposed way forward.

HiPPOs will always exist in any business and lot of the time they should be listened to because that person does have the relevant skills and experience required to determine what should be developed.

However, there may be times when you as a developer need to challenge your stakeholders to understand why the feature should be developed in the first place. Without a structured approach it may be difficult to explain to your stakeholders what you are trying to achieve by asking “Why?”, but using a tool such as a Lean Canvas we can begin to better understand the problem.

Doing so could lead to uncovering alternative solutions that result in far better business outcomes or at the very least stop you building something that nobody wants.