The designer's survival guide to working with stakeholders
Practical advice to understand and leverage different types of stakeholders
👋 Hey, it’s Filippos! Welcome to this issue of the Designary newsletter. If you are new here, I write about product design, including frameworks, career advice and advanced technical tips.
If you are new to product design, I also recommend checking out my product design masterclass, a self-paced, end-to-end product design course for beginners and mid-level designers.
Working with stakeholders is hard.
It’s also something that no one prepares you for.
Most bootcamps and courses are great at teaching you the design process, but nothing can really prepare you for the variety and challenging nature of working with different people from different backgrounds, all with different expectations of how design can help them achieve what they want.
Good stakeholder relationships can greatly influence the impact of your work, and also keep you sane.
Bad stakeholder relationships often make your daily work a struggle.
In this piece, we’ll explore the different types of stakeholders and how you can build healthy, effective relationships that enable you to do your best work.
1. What is a stakeholder?
Simply speaking, a stakeholder is anyone that has vested interest in what you are working on, and has some influence in decision making.
In product design, we often think of the primary stakeholders as the people that have some influence on what gets to see the light of day, and how it is designed and implemented.
Common stakeholders are:
Product leadership (Director, VP): They are influencing the roadmap and may be involved directly in initiatives depending on how strategic/impactful they are for the business.
Commercial/revenue leads: They influence company objectives and projections, and are very invested in ensuring that the product roadmap is set up to hit these objectives effectively.
Founders & Senior leadership: Depending on the size of organization, senior leadership may or may not be involved in key product decisions.
Experts: In specialized industries, domain experts may be needed to consult on niche topics.
Legal: They influence what you can and can’t say, promise or do, which is heavily dependent on the industry you are in.
Marketing: They control how your audience first gets in touch with your product, and are interested in how you acquire new customers but also how you market new products and features to them.
Customer support / success: They have a lot of input on the problems your customers experience.
In some teams, the Product Manager and Engineering Lead might also be considered stakeholders, albeit in most cases they will (and should) be working with you on a day-to-day basis as part of a squad or pod. So for the sake of simplicity, I’m not including them in the list of common stakeholders.
2. Understand different types of stakeholders
Not every stakeholder is the same, and their level of involvement needs to change accordingly.
Decision makers: These are the people that need to approve an initiative or solution and have very strong interest in what is being built. This is usually a combination of product & commercial leads.
Consulted: These are people that you need to consult before making a decision. Think legal, risk, brand and so on. They won’t be invested in their day to day, but may have a lot of power in influencing a decision, and usually have the ability to completely block an initiative or a specific solution.
Informed: That’s a group of people that need visibility on what you are working on, whether that’s temporary as part of an initiative, or a wider group that always needs to be informed. They won’t influence your work as much, but your work might influence theirs so they need to be kept in the loop.
Any individual or group that doesn’t belong in these groups shouldn’t be actively managed by you. You can still choose to give them visibility through company-wide updates, but your effort should go towards people that either have influence or vested interest on your work.
When joining a new team, it’s often a good idea to make a mental map of the above, simply by speaking to different people and understanding team dynamics and approval process.
The practical bit:
Ask yourself and your team the following questions:
Who are the key decision makers?
Do we have any domain experts on [area]?
Whom do I need to consult for my ideas and solutions?
Are there other people we need to keep informed?
3. Process, rituals and cadence
Once you figure out who your stakeholders are, you need to find a way to involve them in your process while keeping clear boundaries.
This will largely depend on your operating model, but this is an approach that I have found to work time and time again with varying team shapes and sizes:
Decision makers: Involve them on a regular basis, and as early as possible. For smaller teams I’d recommend a weekly basis. However, make sure to not involve them so frequently that they land up micromanaging decisions on the solution to take. Give yourself and your team enough space to operate, but involve them frequently and early on to make sure there is alignment.
Consulted: Involve them as and when needed, depending on the nature of what you are working on. Some stakeholders e.g. domain experts will likely need to be involved at the beginning of an initiative, whereas others e.g. marketing, legal may need to be involved at the later stages.
Informed: Most communication with stakeholders that simply need visibility can be asynchronous and as simple as a Slack message or email. You may choose to involve them in wider sharing sessions once in a while, particularly to give your wider team visibility on what’s being worked on.
Examples of rituals
Choosing the right rituals is about finding something that fits into your existing model without adding much overhead for you or the stakeholders. Here are some examples:
Stakeholder design reviews (Suggested Weekly): You can hold these on a weekly basis, and involve key Decision Makers. It’s a simple yet effective way to have a regular cadence of engaging Decision Makers and bringing them along in your process.
Async updates (Weekly & Monthly) : Best for Informed stakeholders and also to summarize progress in a particular initiative. Send out a weekly update on Slack/Teams/Email with the latest updates.
Expert interviews (Ad hoc): At the beginning of an initiative, make sure to schedule sessions with experts and people in the Consulted pool, to understand what your restrictions are.
Research playbacks (Ad hoc): You can hold these as and when you have new insight to be shared. I’d suggest inviting every stakeholder in a relevant initiative or team, but making sure Decision Makers attend.
Design sprints (Ad hoc): Involve at least one non-product Decision Maker to bring them inside your process. Also invite Consulted stakeholders at the beginning of the sprint.
The practical bit:
🔴 No: Invite 10 stakeholders in a design review session, and ask them to share feedback on everything they see.
🟢 Yes: Keep design reviews as tight as possible (try limit to 3-4 people outside the product team), whether it’s on a call or async. If you want to do wider design critiques to make people feel involved, do it less frequently and as a means to give more people in the organization a voice.
4. Avoiding “design by committee”
You can’t, and shouldn’t action everyone’s opinion at all times.
It’s ineffective, and overwhelming.
As a designer, you will need to choose whose opinions to get, and even more importantly, whose opinions to action.
One of the hardest challenges of becoming more senior is having the clarity, critical mindset and intuition to understand what feedback to action, and what not to.
Assuming you have found your ideal working group of people, you will often encounter situations where you have an overwhelming amount of feedback from a number of people, and you are trying to please everyone.
This is what we call “design by committee” and it’s one of the most common errors we see in product organizations.
Here is how to avoid it:
Don’t create the expectation that you will action everyone’s feedback.
Be highly critical when it comes to feedback. If you disagree with something, try and have a quick 1:1 conversation to try and get your points across.
Filter what’s a hard requirement e.g. from an expert or a key decision maker vs. what’s simply an opinion that you may or may not choose to action.
Remember that you have the most amount of context.
The practical bit:
🔴 No: Send a Figma link to a group of 30 people and ask for feedback from everyone.
🟢 Yes: At the final stages or after launching an initiative, send an async update with either the final design or live product update, tagging relevant departments and explaining your hypothesis and thought process. This will give great visibility to the wider team and make them feel included.
🔴 No: Try and resolve every single bit of feedback.
🟢 Yes: Practice critical thinking — Evaluate feedback with your product trio and separate what’s useful vs. what’s a distraction.
5. Managing and improving people’s feedback
Most stakeholders aren’t great at giving feedback.
Plain and simple.
They give feedback on the wrong thing
They give opinion rather than argumentation
They are heavily biased and don’t recognize their biases
And even if they are good at it, it’s likely that they have their own way of giving feedback that doesn’t match your expectations of the wider team’s expectations.
Unless you train people on how to give feedback, they won’t have any guidance on how to improve.
Here are a few practical tips on getting better feedback from different types of stakeholders:
Give people adequate context.
Clearly express what feedback you are looking for.
If you are getting feedback on the wrong thing, call it out politely and direct the conversation to where it needs to be.
🔴 No: (Stakeholder) “Make it pop more”
(Designer) “Ok, we’ll do our best”
🟢 Yes: (Stakeholder) “Make it pop more”(Designer) “In all respect, this isn’t very helpful to us as it stands. Pop could mean a number of different things. Could you tell me a bit more on what it is specifically that you are missing? Is this about the visual design, the interaction pattern, or something else?
🔴 No: (Designer) “What do you think? Do you like it?”
🟢 Yes: (Designer) “I’m looking for feedback specifically on this new interaction pattern. It’s something we haven’t used before, but could really help guide the user towards completing the funnel.”
6. Understanding people’s goals and building relationships
If there is one piece of advice that you take away from this article, it’s this:
Stakeholder management boils down to relationships.
You can’t expect a stakeholder to get you without investing in building a relationship that is founded in mutual respect and understanding. They can’t expect that from you either.
There are two foundational principles in building a professional relationship with your key stakeholders.
Understanding, and caring.
To build strong relationships with product leadership, you need to show that you understand and care about finding and solving the right problems, delivering on time.
To build strong relationships with commercial teams, you need to show that you understand and care about your company’s financial performance, and understand the link between your work and its commercial impact.
To build strong relationships with engineers, you need to show that you understand and care about the feasibility, scalability and performance of the solutions you are designing.
To build strong relationships with marketers, you need to show that you understand and care about how you communicate your value proposition and what types of people are buying your product.
You can’t possibly give the same amount of attention to all these different areas — and you can’t possibly care the same either — but starting with trying to understand their perspective and showing that you care can make a huge amount of difference.
The best designers I have met act as a connecting bridge between different departments, often offering alignment and shared understanding.
The practical bit:
🔴 No: After not having a single conversation, add 5 people to a session and ask for the input.
🟢 Yes: Set up a monthly chat with one person from each relevant department. Grab a coffee, understand their biggest challenges and share yours too. Discuss how you might work together.
In summary
At its core, good stakeholder management is about clarity, boundaries and genuine relationships.
When you know who is who, bring people in at the right moments, and avoid the trap of trying to please everyone, you create the space to do your best work.
And when you take the time to truly understand people’s goals, pressures and incentives, you turn them from blockers into product/design champions.
The designers who thrive aren’t the ones who say yes to everyone — they’re the ones who communicate with intention, build trust over time, and guide teams toward the right decisions.
Thanks for making it to the end 🙌. What did you think of this post? What have you found useful in managing stakeholders as a designer? I would love to know in the comments.
awesome and very useful, thank you very much!
Share context with stakeholders and speak their language and always bear in mind the business objectives.