To Succeed Product Owners Cannot Ask for Permission!
By: David Pereira
Tags: Product Management, Leadership, Software Development, Agile, Startup

The HiPPO Challenge!

Decision-making is one of the biggest problems in organizations. The Scrum Guide is clear on what needs to happen to allow Product Owners to succeed. Let’s have a look at it.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. — The Scrum Guide, November 2020

From my experience, most companies don’t trust Product Owners to make decisions. A common anti-pattern is the HiPPO (highest paid person opinion). The person with the highest pay-check in the room will decide what has to be done. In this case, the Product Owner executes someone else’s plan. Suppose the idea results in a failure, shame on the Product Owner. If the idea leads to success, the credits go to the HiPPO.

Someone cannot be a value maximizer without being able to make the decisions. But can Product Owners escape from this trap? Yes, but it requires a lot of courage. If you want to overcome this challenge, you’ve got to ignore the HiPPO’s opinion and lead the team towards what should be done.

As Product Owners, you cannot ask for permission. You are responsible for maximizing the value. You do what you understand to be the best for the product. You don’t need to justify your decisions. You need to prove them by maximizing the real value for end-users and the business.

“If one asked permission there was a 50% chance it would be refused. If one just got on with it, 19 times out of 20 nothing was said.” — Trevor Kletz

Don’t Follow Orders Blindly.

In 2016, I joined a startup. Our mission was to disrupt the second-hand car market in Brazil. Car owners had a hard time dealing with bureaucracy, dealers, and swindlers to sell their cars. We wanted to solve this problem by removing these complexities. The value proposition was simple: “Sell your car in 60 minutes. Don’t worry about bureaucracy and safety; we make everything easy for you.”

The business model was simple. Car owners would come to one of our inspection points. We would then inspect the car, take some pictures, and put the car into our auction platform. For 30 minutes, dealers all over Brazil would compete for the car. After the auction, we would present the offer to the car owner; he would then have the option of taking it and going home by cab or rejecting it and going home without paying anything.

During my first day at the startup, the CEO told me: “I have a mission for you. The dealers are not engaging in our Auction App. I want you to increase the engagement by 50% during the next three months. No excuse. Just do it.” It was a five minutes conversation, after which he left the room.

My head tried to process the request for a while. I had to make a tough decision on my first day, I thought, “Am I going to do what the CEO wants, or am I going to do what should be done?” I decided to do what should be done. Although it could cost me my job, I knew it was the right thing to do.

The CEO requested to solve a problem with a solution defined by him. But what if the solution was the problem? I had to build a clear understanding of the problem instead of doing it for the sake of pleasing the CEO. I created a plan to clarify the problem.

Don’t Settle Until You Uncover the Hidden Problems.

During my first two weeks, I visited twenty dealers. After a couple of visits, I made a painful discovery: Dealers hated our App. The reason was simple: the smartphone screen was too small to evaluate the car properly. A common question I got was, “How am I supposed to buy a car if I cannot even see a decent picture size?”

The dealers didn’t want an App to buy cars. But they indeed had problems finding the cars they wanted. During the visits, I observed how dealers found the cars they wanted. They used a desktop computer to search on multiple classified portals or called multiple people until they found the car they needed. It was a tiring process. It was a problem worth solving.

I presented the discoveries to the Development Team. We thought about the problem for some time, trying to find a proper solution for the problem. We decided to create a web-portal where dealers could create a list of the cars they needed. Once the car was in auction, the dealers would receive a notification inviting them to compete for the cars they needed.

The Result Will Justify Your Decisions

After our changes, dealers engagement increased significantly. We found a problem worth solving. More and more dealers participated in the auctions, and consequently, our offer to the car owners improved. The result was great. But I still had to talk to the CEO and tell him I decided to lead the team differently.

Photo by Mika Baumeister on Unsplash

The day came to present the results. It was not the easiest day of my life. It was raining heavily in São Paulo, which meant getting to the office would be a huge challenge. After one and a half hours instead of twenty minutes, there I was in front of the CEO. He started the conversation by saying: “I guess we have a problem. I am looking at the engagement with the Auctions App. You haven’t achieved the mission I gave you.”

Somehow I suspected the CEO was obsessed with the solution, but I had good news. I told him, “I will be brief with you. Look at bids placed over the last week compared to twelve weeks ago. Make the same comparison with the amount of deals we closed. Please trust me and have a look at it.” He seemed skeptical. But he looked at our dashboards and said, “What??? I don’t understand. The app engagement looks awful! But the bids tripled. What have you done?”

I did what should be done, not what the CEO wanted me to get done.

If you want to solve real problems as a Product Owner. You need to take Ownership instead of following orders! It might be scary, but don’t worry. A significant positive change can convince the most skeptical person. You just need to be bold to do what should be done!

Do you want to write for Serious Scrum or seriously discuss Scrum?