Reimagining the term “Stakeholder Management”

…and how to build better relationships within your own team and across teams

I hate the term “stakeholder management”.

If you’ve been following me for a while, you know I tend to take a more holistic vs. silo-ed approach to things.

It’s why I started Conscious Product Development, and also why I hate using terms like “stakeholder management” that refer to people as things, use language that is transactional, and prematurely limit scope without context.

Words matter. They shape how we think and our world. They set expectations. They imply hierarchy. Many of the words and phrases we use in English imply “under the surface meanings” in the way they are worded, in their delivery, or both.

As product managers, we are told we need to have the ability to “lead with influence, not authority” and be the “mini-CEO of the product, without the authority that a CEO has”. I dislike both of these terms and prefer to think of it as:

“How can I build great relationships and collaboration across teams to align on common goals and get the best results out of the effort we’re putting in?”

I can’t tell you how many times I’ve worked in environments where we recruited some of the smartest, niche experts on the planet to solve really challenging problems that no one had solved before, yet probably only got a percentage of the outputs we could have because of:

• Poor product vision and objectives (i.e. no clear idea what problem is being solved, who it is being solved for, what the future looks like that we’re trying to create with what we’re working on, what success looks like and why)
• Poor relationships across and within teams, stemming from the leadership level and filtering down through all of the interwoven projects to deliver the product
• Poor communication across and within teams, verbally and written (i.e. meetings where little to no context was given prior to assembling everyone and when everyone left more confused than they started, meetings with no clear outcomes or action items and costing the company loads of money in wasted time the process, catching up with a colleague from another team for lunch and realizing that their team is working on something identical to another team in the same company and the work is being doubled, visible frustration and anger displayed publicly via Slack, etc.)
• Poor processes (or lack thereof, or unwillingness to adapt processes as the team and product grow)
• No product pillars or tenants or idea of the things that we believe to be the most important things we need to stick to as we gather feedback, adapt our roadmap, update requirements, etc. (or bringing pillars in far too late in the game)
• Poor org structure that creates silos and confusion vs. fostering teamwork and collaboration, focus, and great communication.

Outside of work, I’ve also been part of some kind of sports team since the age of four, growing up playing competitive sports and eventually landing at McGill University, playing hockey with a handful of the Canadian Women’s Olympic Team. I can say that similar patterns surfaced across domains here as well:

Any time you are doing anything with a team — trying to build a product that improves people’s lives, win a National Championship, or prove that something that was previously thought the be impossible is, in fact, possible — the people you bring in, the strengths of the relationships you build, and how well you can work together towards a common and clearly defined goal will matter more than the combined talent of individuals, a lofty vision, amount of funding you’ve got, or technological capabilities you have. (More on this here).

All of the little details matter. The HOW (how you work together) is just as important as the WHO (who you’re working with).

As a product manager, your situation is always context dependent — you’ve got levers that will always be moving, like org structure, new hires in key roles you interface with, changes in product direction, changes in leadership, etc. that you need to be able to adapt to.

As the pieces are moving, here are some tangible ways to develop great relationships with your direct team and the teams you work with, in order to work together to achieve a common goal:

1) Make sure you have a good foundation

Start from the bottom and work your way up. Don’t skip steps. It’s okay if these things need to be adapted and iterated on over time. But if you don’t have them in the early stages, it doesn’t matter how smart or well educated or how skilled the people on your team are — if they aren’t aligned, you’re not going to get the most return from the time, energy and resources invested because the efforts will be diffuse vs. focused. Establish a foundation — give the team a goal and guardrails from the get-go.

Read more on this here: Taking a New Product from 0 to 1

2) Set up 1-on-1s with your direct team and other key players proactively when you start in a new role

Who is your direct team?

I think of this in two ways:

1. Product Team — Your Hiring Manager, Other PMs on the team that you need to interface with and who your work feeds into and vice versa
2. Product Development Team — Technical/Engineering Lead(s) you will be working with, UX and Design Lead(s) you will be working with, Project Management Lead you will be working with, and members of the larger ”building” team, including QA.

Sometimes you won’t have a project/program manager, and sometimes the team will be structured differently or re-orgs will happen.

The most important rule of thumb is make sure you know the people you’re working directly with to deliver the part of the product you’re responsible for really, really well. These are your most critical relationships. When the going gets tough (which it will), you’ll need to lean on each other. Don’t wait until there’s a crisis to try to build great relationships — do it up front.

Key players can include job functions that you need to interface with in any way, like:

• Leadership
• Customer Success
• Marketing
• Sales
• Legal
• Finance
• Clinicians or Direct Service Providers (i.e. for health tech products that require some specialization or designation to deliver part of the product experience)
• Manufacturing
• Retail

The makeup of your direct and indirect team will vary depending on what kind of product you’re working on. Make sure you understand what the important interfacing job functions are, who does them, and how they connect with each other.

What should your goal be going into these initial 1:1s?

1. Get to know each person on a personal level to start to build meaningful connection and trust
2. Understand each individual’s context and scope of work
3. Understand how everything connects from a birds-eye-view within the org
4. Give each person a better idea of who you are, what your why is, and how you operate

To do this, you can ask personal questions like:

• What is their scope of work?
• How long have they been on the team?
• Do they like working there?
• What do they care most about?
• What are their biggest challenges and why?
• How have they interfaced with Product in the past? What could be improved?
• How do they like to work?
• What drives them?
• What do they like to do outside of work? What are they really passionate about?

You can also probe and ask larger org-related questions like:

• Are roles and expectations clearly defined?
• How are decisions made?
• Who drives which types of decisions?
• What are the biggest organizational challenges?
• Where are the gaps?
• How does Product fit into the larger picture?

And you can talk to personal points like:

• Your unique background
• Your why and what drives you
• How you think/work
• Expectations (i.e. “I am a very open person with a growth mindset — if there’s something I’m doing that isn’t working or is causing frustration, more work, etc. please let me know immediately. I really appreciate objective feedback and I want to improve.”)

Consolidating this information will help you establish a T-shaped mental model to understand what the org looks like from a birds-eye-view, how the puzzle pieces fit together, and what drives and is challenging for each person leading specific initiatives. This is extremely valuable information to have to figure out how you can exercise emotional intelligence to drive more meaningful connections and impact with the people you work with.

For instance, understanding your audience better and what they care about prior to a scope review can help greatly in informing how you communicate information to achieve the desired result.

Understanding how the pieces fit together will also help you establish what your own guardrails are in your role (i.e. in a lot of early-stage startups, there are no project managers and product needs to wear a project hat some of the time.)

3) Be strategic about who you need to be connected with, when to ensure teams are aligned, and come up with a plan for how to approach sharing information with each of these people

In one of my roles, I had 13 different job functions I needed to keep informed to some extent when any major product decision was made. I felt overwhelmed a lot of the time and was bombarded with questions that made me feel like I was constantly on my heels, putting out fires.

Once you understand how decisions are typically made in the larger org, you can use frameworks like RACI and DACI to figure out who needs to be involved and to what extent, in different contexts.

D — Driver (the person responsible for driving projects from beginning to end)

A — Approver (the person who makes decisions about the project, who has veto power)

C — Contributor (people who should be consulted during the decision making process who have a voice but no vote)

I — Informed (people who don’t have authority to change outcomes but who should be told about decisions made with relevant context)

and…

R — Responsible (the one who does the work to complete the task)

A — Accountable (the one who must answer for the proper completion of the project or the correct decision)

C — Consulted (people who should be consulted during the decision making process who have a voice but no vote)

I — Informed (people who don’t have authority to change outcomes but who should be told about decisions made with relevant context)

Something I have found helpful in startup settings is to keep a simple list on my desktop with two columns to keep me focused on:

1. Who the people are that I should be spending the most time with in doing proactive work leading up to a decision

vs.

2. The people I need to keep informed either during the process or after the fact.

4) Meet People Where They’re At

Be empathetic. Everyone’s “orbit” will look slightly different than yours and will have different context. Be aware of this and when communicating with others, think:

“What is their current context?”

“What is my current context?”

“Where are the gaps?”

“What’s the easiest/most efficient way to close these gaps?”

This can be really challenging when things are moving quickly and work is remote. You may feel incredibly frustrated feeling like people should just “know” what you’re talking about sometimes. Be patient — understand if there are gaps that overlap across teams and think of ways that you can close these in a batched way. i.e. Do most people not fully understand critical background context for a part of the roadmap? Maybe you can host a “lunch and learn” session to do a deep dive here. Frequently being asked the same question about something in a slide deck? Include the answer in the deck or link out to it so you’re not the bottleneck in providing an answer. Try to figure out how you can leverage a single action to solve the problem for many.

5) Use inclusive and collaborative language

Understand what people’s preferred pronouns are and use them. Make sure you are pronouncing peoples’ names properly and ask for clarification if you’re unsure. Use words like “us”, “team”, “together”, “we” vs. “I”/”you”/”they”/”them”. Avoid using divisive phrases like, “I’m having lunch with the boys”.

As someone who has spent the majority of her career (and life) as the only female at the table, there are so many nuanced things that we do subconsciously that make others feel that they don’t belong.

As soon as that feeling occurs, an invisible wall is put up that makes people less apt to be vulnerable and feel like they can be their authentic selves. When this happens, your team’s potential impact will go down.

Check your unconscious biases and focus on inclusion rather than exclusion.

The strongest teams are built with many different perspectives. Make sure each person on the team feels part of the team.

6) Listen when others are speaking

This is still a huge problem in society as a whole — give people space. Be respectful and don’t interrupt (even if you don’t agree).

7) Ask questions instead of making assumptions

Rather than come in hot based on something that you believe to be true (that may not actually be true), try to approach things with curiosity vs. frustration and anger.

Didn’t like a decision that was made? Ask questions to better understand the context and why that decision was made.

Did the CEO just send a crazy ask your way to add something to the roadmap? Talk to them to try to understand their perspective first and why they believe it’s an important ask (for the company and for customers) vs. starting to fume right away. Maybe they’ve got information you don’t and understanding would help you better assess how this fits into your current roadmap.

8) Recognize individual contributions

Did a member of your team do an exceptional job solving a tough problem during a sprint? Recognize this publicly in your retrospective.

Did you notice one of your team members go out of their way to help another team member out? Walk over to them and let them know you noticed and thought it was awesome.

Have a companywide presentation about your area of product? Say thank you to individual contributors on the team for their efforts.

People need to feel like the work that they are doing matters. People need to feel like THEY matter.

It’s the little things that make a big difference.

9) Be conscious of your time. Block out time to do your own focused product vision/strategy/roadmap work so that things are easier for the teams you’re impacting

One of the biggest mistakes I made early on as a product manager was spending too much time with others putting out fires and not enough time blocked out for my own focused work.

Because I didn’t make the time to consolidate all of the things that needed to be connected in the long- and medium-term, I actually wasted more time trying to chase and fix things in the short term instead of what would have been the happier path — doing the work proactively to inform product vision, strategy, roadmap, and requirements to show where we are headed, and bringing the right people in early to help me.

How much time are you spending on NOW vs. NEXT vs. LATER things and having critical conversations up front about these? What does a % breakdown look like during a typical week? What % of your time are you spending building relationships? Talking to users? Doing product discovery work? Research? Strategy? Creating tickets in Jira? Defining Requirements? Updating the roadmap?

Look at what the biggest blockers are and where you’re spending your time. Put more focus on the areas where there are gaps.

More on this here: A Few Thoughts on Conscious Time.

10) Do your homework and ask for advice on this

Not a deep expert in the new area you’re focused on? Let the experts inform where you focus. Understand where your biggest gaps are. Talk to key people on your team to help determine how to best fill in those gaps.

i.e. Working on a new project that involves machine learning? Have lunch or virtual coffee with one of your machine learning leads or ask them to school you (initially) and then ask for the best resources to look into. Working on a purchasing flow for the first time? Talk to someone in marketing to find out what they think the best purchasing flows are for other products and try to understand why they’re the best. Walk yourself through purchasing flows of products you use regularly and make notes — what works well, what doesn’t and why.

Doing your homework is hard on top of your regular day-to-day PM tasks but it almost always pays off in dividends.

11) Bring people in EARLY

Teresa Torres frequently talks about The Product Trio — A designer, engineer, and product manager — who are responsible for a shared outcome. They are ALL involved in product discovery in the early stages — customer interviews, solution ideas, and early prototypes. By bringing key people in EARLY in the product development process, it helps to ensure everyone’s on equal playing ground to understand and frame the problem to be solved and the people who it is being solved for so that cross-functional development efforts are more aligned (and more powerful) than they would be if you work in a waterfall, (i.e. Product manager writes requirements, gives those requirements to a developer, and then the developer works directly with a designer). Don’t do this. It creates more work and often results in solutions that are quite disconnected from the original problem to be solved.

12) Keep a decision tracker

I’ve worked on a couple of projects now that involved me taking over a project that another product manager had started.

This happens a lot and can be quite frustrating, especially immediately after the handoff, because you’ve often got a large number of people coming to you and asking you questions that you are not equipped to answer because you don’t have the context and don’t know why certain decisions were made in the past.

I started making a Decision Journal for myself to address this. Here’s a version that you can use.

Not only did I use it to keep track of my own decisions as we were moving through product development, I also used it to track previous decisions after meeting with the previous PM to fill in the gaps and understand the context behind why we ended up where we did.

If anyone asked me a question about a previous decision that was made, I could share the context behind the decision with them with transparency because I’ve tracked it.

13) Be open to having the tough conversations that need to be had in an objective way.

Don’t ignore the elephant in the room — it will only get bigger.

Approach touch conversations objectively:

• Show that you understand what the other person cares about
• Talk to the fact that you have the same overarching goals that they do
• Don’t make assumptions
• Ask questions to clarify where they’re coming from — maybe they have information that you don’t and they have very valuable viewpoints
• If it’s a 1:1 issue, have this conversation 1:1 and not in public. If it’s a team issue, address it during the team retrospective and do this as objectively as possible (i.e. giving everyone a few minutes to write down want went well, what was challenging, and ideas for improvement on sticky notes that one member of the team reads aloud and the team then talks through together, openly)

Thanks for reading!

I’d love to hear your suggestions for building great relationships in the comments below!

I’m going to be doing a couple of follow-up articles in this subject area as there’s a lot to unpack, including:

• Developing great relationships with users
• Building great relationships with UX as a Product Manager
• Building great relationships with Engineering as a Product Manager
• Building great relationships with Customer Success as a Product Manager
• Building great relationships with Marketing and Sales as a Product Manager

If you’ve got any other ideas for content you’d love to read, let me know in the comments or DM me here!

-Lisa 🧢

Follow me on Twitter: @lisazane15

🧠 Join 800+ people interested in building products and their product careers more consciously: https://www.consciousproductdevelopment.com/newsletter

🧭 If you’re ready for a role transition or just want to make more conscious career moves going forward, check out The Product Manager’s Career Guide that I just launched: https://www.consciousproductdevelopment.com/the-product-managers-career-guide

Related:

• What It Takes To Be An Exceptional Product Manager
• “How Can I Build Tech Knowledge In A Specific Domain as a PM?”
• What It Takes to Bring A New Product From 0 to 1
• What Product Teams Can Learn From The Mayo Clinic’s Care Model
• A Call for More Conscious Products
• “How Should I Approach Product Strategy?”
• A Few Thoughts on Conscious Time