“I know better than you.”

Product Managers, you are going to hear those dreaded words from a stakeholder at some point in your careers. I sure have. (And by stakeholder, I mean the decision maker, whether they are part of the company you’re currently at or a client.)

You know what follows next: 

  • All the research you’ve carefully invested into understanding the product’s users 
  • The time and effort you’ve made to uncover that hidden customer insight 

. . . it’s all tossed aside in favor of the stakeholder’s gut feel, sometimes based on their position of founding and running a business. You sigh deeply and realize that the key decision maker was never going to change their thinking all along, and your work was an exercise in wasted money and time. Or maybe it wasn’t. 

So what are you going to do about it?

Well, first off, take a deep breath. Your work might not be wasted after all. And if your effort was rejected for a whimsical reason, remember, it’s not about you


Put yourself and your understandable frustration aside and try to put yourselves in the shoes of your stakeholder. What might have motivated them to respond that way? 

Sometimes, fear is the motivator. Fear of the unknown. Fear of living up to public and investor expectations. Fear of changing a product feature that has been developed and is testing well. Sometimes ego is the motivator. And then, there are times when a miscommunication has occurred – either you didn’t share your ideas clearly, the decision maker misinterpreted your thinking, or both.

Figure out the motivation, and try to address it. You might be able to make progress and chip away at the pushback. Just maybe.

I was once meeting with a decision maker to discuss a roll-out plan for some new features being designed for a new product. I had developed a product roadmap that included a few key features that our team was confident would have the most impact, while also taking into consideration our development cadence and timeline, at which we were bound. We shared our recommendations, rooted in careful user research and data.

A pause filled the air as we awaited the decision maker’s reaction.

“We need all the features,” they replied. Not just the features we recommended, but every conceivable feature we’d originally considered in the backlog. 

The request was just not feasible. But the decision maker emphasized how they know their users. Yep, they made the dreaded, “ I know better than you,” statement despite the queue of research results opposing their assumptions. They were sold on the fact that the product could not and would not be launched, without having all features built.

I sensed that we were just not on the same page because of a misunderstanding over what our team could and should deliver. So, that evening, I created a completely new product roadmap that included the delivery of every possible feature the stakeholder wanted. I knew the roadmap was technically a nonstarter. Based on our burndown rate, there was no way our current team make-up was going to execute on the roadmap, as revised. However, this was my way to show the stakeholder how the deadlines, deliverables, and cost would change dramatically if we attempted to deliver what the client wanted. The only way we would be able to squeeze it all in would be for the entire development team to put in work 24/7 and literally not sleep. I had to spend an entire night on my own time to create the roadmap, but this solution worked. It wasn’t just my opinion anymore. It was visualized. It was documented proof.

Could this all have been avoided if the stakeholder trusted their team to align to the product goals, user goals, and business goals?

You may have other options, based on how you read the situation.


We learned by empathizing with the stakeholder that leading with data doesn’t always attract the buy-in you’re attempting to gain.  We also learned that this decision maker could be influenced by emotional reasons such as ego. We are, in fact, emotional beings and I believe there is such a thing as persuasion for positive outcome. 

In this case, you may need to find an ally who can help you – someone who may have more of the stakeholder’s emotional trust than you do. And, yes, coming to this realization and choosing this option can be humbling. Teamwork makes the dream work, am I right?

If the stakeholder is afraid of your idea because they didn’t think of it, you may need to conduct additional testing with the users – and then involve the decision maker, so that they feel like they have a stake in the idea. 

At the end of the day, Product Managers need to have the best interest of the user while keeping the product team’s morale high. Burn out is a thing and we don’t want that. 


Another option may very well be walking away. And not just walking away from the project. You may need to walk away from the relationship. Unfortunately, the discord can reveal deeper problems with the organization itself. Watch what’s happening around you. Are you getting paid reliably? How are your benefits? What’s the quality of your life? Are you consistently working nights and weekends without a chance for time-off? You might not realize it, but you may be in a toxic environment.

It’s not always easy to leave. Like the decision maker who shot down your idea, you might be afraid of the unknown, too. What happens if you make the wrong decision? How marketable are you?

These are all understandable fears. But a toxic situation is hurting you more than you know. 

Maybe that “I know better than you” moment is an isolated one. But if it’s more than that, then you may have a bigger issue on your hands. 

Whatever you do and  whatever the nature of the conflict, exercise self-care. That’s always the right answer.