Stakeholder management 101: My customer isn’t listening, what do I do now?
My customer wants everything at once. They have the wrong priorities. Their internal arguments turn into inconsistent direction. Here’s how to get your stakeholder conversations under control.

One of the reasons I wanted to write this article is to address a lack of practical knowledge that’s easy to apply. There are a lot of “how to manage your stakeholder” articles, but they mostly repeat the same half-dozen strategies and don’t give specific steps and real-world examples to make those strategies tangible. That’s what I’ve set out to do here.
Introduction
I’ve had a lot of tough stakeholder conversations. Like the time we were building a new mobile app and, of course, the CEO of our company wanted to ship the product as fast as possible but also wanted a dramatically different, unproven user interface on day one. We couldn’t reach agreement about key design decisions. The CEO and product manager just weren’t hearing the team’s concerns.
We also had some very high standards when it came to the user experience and features in version 1.0. From a quality of experience point of view, this was great — it would mean a really enjoyable, feature rich product.
It was a high bar and came with challenges. The most obvious conflict was around the time needed to build the application — more features meant more time, and more money, to ship version 1.0. But a “big bang” release also meant no user feedback loop in the development cycle. The company wanted to build the whole application in secret, then reveal it all at once. With a radically new user experience, which was supposed to be really cool but also very different. There was a good chance users would be confused or — worse — just not like it.
Unfortunately, the product team and CEO were absolutely convinced the user experience was fabulous. “Everyone is going to love it.” They didn’t want to slow down and make sure they were right.
Our team knew better — they saw the flaws and problems — but our stakeholders weren’t listening.
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
Anytime you'd like to read more, you can upgrade to a paid subscription.
In this article I’ll offer some strategies you can use to take control of your stakeholder conversations, build buy-in and get on the same page. The first step is understanding how to change stakeholder behavior. If you’re stuck trying to “explain the problem away” with your stakeholder, it’s time to stop and rethink how you interact with your stakeholders:
Explaining is not enough. Explaining your position doesn’t build the deep, shared understanding you need with your stakeholder. Sure, you can explain your position, and your stakeholder will take it as an invitation to explain theirs right back at you. You both end up frustrated, trying to figure out why the other is so intractable.
Buy-in depends on creating a sense of ownership and control over the problem. Without first creating a foundation based on ownership and control, you set up your stakeholder as an “outsider,” creating a potentially adversarial relationship.
Different stakeholders mean different strategies. If you don’t pay due attention to who your stakeholders are, what they care about, and how to influence them, you will trap yourself in a “one size fits all” approach. Most of the time, you won’t be approaching your stakeholder with a strategy that matters to them.
I’ve divided this article in two parts. In the first part, I’ll talk about how to tackle these challenges effectively: building your shared understanding, creating buy-in, and figuring out how to approach your different stakeholders. In the second part, I’ll recap some real-world situations and stories that illustrate these solutions in tangible ways.
Customer or stakeholder?
Before going any deeper, it’s important to understand exactly what I mean by “stakeholder.” It’s not as simple as it may seem. Depending on your own situation, a stakeholder could be:
A product owner, sponsor, or client — someone responsible for defining your product.
Your boss, manager, or leadership team — someone with decision making power, having authority over your project.
A business unit, vendor, service provider — in other words, someone that provides something you need.
An external team, committee or governing body — perhaps an architecture review board, DevSecOps team, quality assurance or security division.
Potential influencers, rivals or even competitors — anyone that will be impacted by your product or the change it brings to market.
Your team — the people building your product.
Your end-user — the individuals that will ultimately put your product to use.
Any and all of these, and more, describe your stakeholders: your stakeholders are anyone that can influence your project, or who have an interest in your project’s outcome.
It may be a very long list — but it’s also a very important one. Knowing who your stakeholders are is a precursor to taking control. Stakeholders will influence your project in many ways. Understanding that influence and finding ways to turn it to your benefit can be the difference between success and failure.
Later in this article we’ll explore a “stakeholder mapping exercise.” It’s an effective tool to help identify and prepare for your stakeholder conversations.
Throughout the rest of this article, I’ll use “customer” and “stakeholder” somewhat interchangeably, depending on context. Just remember, both are roles with interest and influence in your project.
Creating shared ownership
Most of the strategies I’ll talk about focus on building a sense of shared ownership across your project and the hard decisions your team faces. Only if your stakeholder is involved, contributing to your decisions, will your journey be smooth. It’s the difference between an argumentative, “us versus them” relationship and a whole team mentality. You want that “we’re in this together” feeling, making decisions as a team that’s self-supporting — not as an outsider, hoping to influence someone else.
Shared understanding
Conflict arises when there is a lack of shared understanding. This essentially means your stakeholder sees the project as an opaque cloud of decisions where they have no control. The only way forward — in their mind — would be to blindly trust the team, even when they are convinced that somehow the team is missing important details. It’s just not a realistic expectation to believe any stakeholder will move forward under such conditions.
It is challenging to establishing a shared understanding of a problem space. You want to bring your stakeholder to essentially the same level of understanding that you have about a specific decision. Having that in-depth understanding of the problem makes joint decision-making possible.
Where many teams go wrong is not understanding how important this is. They lose patience, just trying to explain a technical necessity with hand-wavy jargon, or telling a stakeholder it’s “best practice.”
Instead, you need to plan for fostering a shared understanding in your project timeline. You need activities focused on developing stakeholder understanding. Taking the time to inform and guide your stakeholders so they can select a correct, fit for purpose solution.
It means putting the decision making in your stakeholder’s hands. At first you’ll feel like you are giving up control — but you’re not. You are sharing control with important team members.
Building this level of understanding cannot be achieved with simple explanations. Instead, think of it as mentoring a new team member:
Build a project plan that involves your stakeholder sufficiently so that you can guide them in understanding — just like you would with a new team member who needs to learn your technical foundation. Give them a shared spot at the table, schedule discovery workshops, add time into your planning sessions. (See this article on running a successful workshop).
Avoid explanations in favor of asking questions. I wrote about this in How a scientific mindset engages your customer, and it’s a really important skill. Using the Socratic Method to guide and inform is a fantastic way to get your stakeholder (or any new team member) focusing on reasoning about the problem space. It develops a firmly grounded understanding.
Treat your stakeholders as valuable team members. Recognize that they are bringing important concerns to the conversation — and be open to learning, for your own part. Make sure it’s a two-way street so your stakeholder knows their opinions and positions are not only heard, but also part of the solution.
Another very important point about developing a shared understanding: without it, your stakeholder cannot effectively weigh-in with their own opinion. The problem here is that if they can’t weigh-in, you will never develop buy-in with your stakeholder.
I hope you get some great value from this article. Writing is hard work! Please help me grow with a referral so I can keep it up! (Plus, earn yourself free premium access.)
Weighing-in
Buy-in depends on ownership and is predicated on weighing-in. What I mean by this is that your stakeholder isn’t going to become invested in a solution they don’t feel they own. On the other hand, the more they invest in developing the solution with you, the more they will have ownership in the solution.
This means investing the time (between both yourself and your stakeholder) to make informed decisions. Building shared understanding and ownership of the problem effectively puts the decision making power in your stakeholder’s hands. They can weigh the pros and cons, the impact of each choice.
Support your stakeholder by giving them the information they need. Help them break problems down with small examples so they understand them — and can effectively weigh in with their opinion.
This is where putting the decision in your stakeholder’s hands is a real win. Rather than pushing them to agree with your decision, push them to make the decision. You’ll see this approach has long-term benefits:
Keep reading with a 7-day free trial
Subscribe to Customer Obsessed Engineering to keep reading this post and get 7 days of free access to the full post archives.