Listen to the audio version of this article:

Why Conflict Matters

Conflict is often seen as something bad that should not occur. But in fact, it’s perfectly normal. It commonly happens when people with different perspectives, needs, and goals engage.[1] This is especially true in product management.

As product people, we work with individuals from various business units or departments with different views and ideas. Think of the salespeople, marketers, and customer support team members, as well as the UX designers, architects, programmers, and testers you might interact with.

What’s more, innovation relies on conflict. How can you create something new and amazing when everybody quickly agrees? In the worst case, you practise design by committee, broker a weak compromise, and agree on the smallest common denominator. But that’s hardly a recipe for achieving product success. Innovation requires diverging ideas and passionate arguments; it requires the willingness to experience and resolve conflict.

Additionally, effective collaboration and teamwork rely on the ability to leverage conflict. Otherwise, teams will find it difficult to perform well and become truly productive, closely-knit units.[2]

What Gives Conflict a Bad Name

Sadly, conflict is often poorly handled, especially at work. Most disputes I have witnessed were not dealt with properly; many were never resolved.[3]

Often, the conflict is suppressed or ignored—it’s swept under the carpet. Say you strongly disagree with the way a senior stakeholder talks to you and requests a new feature. But instead of addressing the issue, you pretend that all is well. Other times, the conflict escalates and turns into a verbal fight, in which the more senior, powerful person typically wins.

In both cases, the conflict has turned toxic. It leaves behind a trail of bad feelings and mistrust. Relationships are damaged, and effective collaboration is difficult, if not impossible, to achieve. What’s more, suppressing the negative emotions, which are usually present in a conflict, increases your stress levels and can harm your mental health.

Resolving Conflict with Non-Violent Communication

So, how can you deal with disputes constructively? How can you have good, healthy conflicts? One way to achieve this is to use Non-Violent Communication (NVC), a conflict resolution framework developed by Marshall Rosenberg. It consists of the four components shown in Table 1:

The framework in Table 1 offers a structure to break down conflict into its key elements and address them step by step. You start by sharing each other’s perspectives. Then, you explore the feelings that are present and connect them to underlying, unmet needs. Following this process builds trust and understanding. It puts you in the position to make a request and address the root cause of the conflict.

Conflict resolution is therefore not about winning, retaliating, or putting the other person in their place. It’s about establishing a dialogue, developing a shared perspective on what happened, agreeing on the changes required, re-establishing trust, and rebuilding the relationship.

To put it differently, if you believe that you are right and the other person is entirely to blame, and if you are not prepared to change your own behaviour, if required, then you won’t be able to apply the NVC framework; resolving the conflict will not be possible.

The Non-Violent Communication framework might be simple, but it can be hard to put in practice. The following tips will help you effectively use it.[4]

Step 1: Observations

The best way to start the process is to schedule a meeting with the other person so you can have a focused and confidential conversation. Clearly state what you saw happening and what you heard the individual say. Avoid criticism, judgment, or blame. Stick to the facts and purely state your observations. As Oren Jay Sofer writes in his book Say What You Mean, “The less blame and criticism are in our words, the easier it will be for others to hear us and to work toward a solution.”

However, sharing your observations is only part of what needs to happen. The other, sometimes more challenging aspect is to attentively listen while refraining from quickly criticising or dismissing what you hear. This does not mean that you have to agree with the other person. But it allows you to understand their perspective, which is a prerequisite for resolving the dispute.

To succeed with step one, make sure that you don’t engage in a blame game. Don’t label the other person, for example, as difficult, mean, bad, or selfish. Don’t assume that you are right, and they are wrong and possibly have bad intentions.[5]

Step 2: Feelings

Emotions play a key role in conflicts. After all, a conflict is a disagreement that involves difficult feelings like confusion, aversion, anger, and fear. It’s a common mistake to ignore the emotional side of a conflict and focus on its rational part.

Take the scenario I shared earlier: A senior stakeholder requests a new feature in a way you find hurtful. If you now focus on the feature, determine if and when it should be implemented using, for instance, a cost-benefit analysis, and you ignore the difficult feelings that are present, then resolving the conflict with the NVC framework will not be possible.

It is therefore important to acknowledge your feelings. To help you recognise them, use the following four questions.[6]

• How do you feel?
• Where do you feel it?
• What does it feel like? Is there pressure, tightness, aching, heaviness?
• Are there any thoughts or stories connected with the emotion? If you had to describe it in one word, what would it be?

Note that emotions don’t define who you are. Instead, they are experienced by all humans. Everybody feels aversion and anxiety at some point in their lives.

Once you are aware of your feelings, share them with the other person. While this may require courage, it is a necessary step: It helps them empathise with you and understand what impact their behaviour had on you. Then attentively listen to the emotions the individual is sharing with you.

Step 3: Needs

In the NVC framework, needs are considered the real reason for the conflict. To discover them, ask yourself why you felt the way you did. What triggered the emotions you uncovered in the previous step? Is it your need for, say, recognition, respect, safety, or belonging? Be truthful with yourself and honestly reflect on your underlying motives and goals.

Sharing the needs helps you understand why you and the other individual acted the way you did and what drove your respective behaviour. This, in turn, enables you to empathise with each other; it makes it more likely to find a mutually agreeable solution that addresses the root cause of the conflict.

Take the scenario with the senior stakeholder again as an example. You might discover that your emotions are connected to your need for respect and recognition and the concern that your authority is undermined by the stakeholder. Similarly, you might learn that the other person’s behaviour is caused by work pressure and stress, together with the worry that their interests are being ignored.

Step 4: Requests

The final step is making and receiving a request. Clearly state what you want the other person to do. If the individual doesn’t fully understand what you are asking for, then it will be hard for them to action it. Additionally, use positive language and communicate the outcome you’d like to achieve. Refrain from stating what you don’t want. For example, instead of saying, “I don’t want you to speak rudely to me anymore,” say, “Please talk respectfully to me in the future even if you are stressed.” [7]

After having shared observations, feelings, and needs, you will hopefully be able to accept each other’s requests. The conflict has now been successfully resolved and you’ve rebuilt the relationship with the other person.

But if that’s not the case and the answer you hear is no, then don’t give up yet. Continue the conversation by asking the individual to share their reasons for declining your request. Ask what prevents them from saying yes and if they have any other suggestions or ideas that would help address your needs.

Alternatively, if you find that you have to decline the request, clearly explain why you cannot accept it and offer to explore more options to find a solution that works for both of you. If, however, you cannot resolve the conflict despite your best intentions, talk to your line manager and the HR department.

Summary: Toxic vs. Healthy Conflict

Conflict can be a blessing or a curse, depending on how we deal with it. Table 2 summarises the differences between destructive, toxic and, constructive, healthy conflict.

While having healthy conflicts is not always easy, it helps you foster innovation and (re-) build relationships. What’s more, reflecting on your underlying motives and needs can help you learn something new about yourself and grow as an individual.

Notes

[1] Please note that I assume that the conflict can be resolved by the people involved, unlike severe transgressions such as violence, sexual harassment, and discrimination. If you are in doubt, always talk to your line manager and human resources.

[2] The Tuckman model shows that teams have to learn to skilfully navigate conflict to perform well. Lencioni argues in his book The Five Dysfunctions of a Team that a lack of constructive conflict holds teams back and leads to artificial, unproductive harmony.

[3] Note that I focus on personal attitudes and behaviours in this article, and I intentionally ignore the organisational context and company culture. While they undoubtedly influence how conflicts are handled, the personal choices we make are more important in my experience. Having said this, if you work in a healthy work environment where people feel comfortable voicing divergent ideas and disagreements, then having constructive conflict will be easier.

[4] The advice below is based on my book How to Lead in Product Management. For more guidance, I recommend reading or listening to the book.

[5] Bruce Patton et al. call these beliefs truth assumption and intention invention in their book Difficult Conversations.

[6] The questions are based on Oren Jay Sofer’s book Say What You Mean.

[7] This method is an appreciative inquiry technique called flipping, which I discuss in more detail in my book How to Lead in Product Management.

Listen to the audio version of this article:

The Core Product Team

Product teams come in different shapes and sizes. But all product teams I have seen consisted of the person in charge of the product—the product manager or Scrum product owner—and development team members. Together, they form the core product team.[1]

Depending on the number and size of the development teams, you may want to include all development team members or ask the teams to nominate representatives to join the product team. Make sure, though, that the necessary skills are represented. For an end-user-facing digital product, this usually requires a UX designer, an architect/programmer, and a tester/QA engineer to be members of the product team, as Figure 1 shows.[2]

The Extended Product Team

Assembling a product team like the one in Figure 1 is great for carrying out product discovery and delivery work—for determining the right user experience and features and deciding how to best implement them. Such a team, however, lacks the expertise to make all product decisions, especially strategic ones. These require the relevant marketing, sales, support, legal, finance, and operations know-how—depending on the type of product and the company structure.

To acquire the relevant knowledge, you have two choices. First, you can either have one-on-one conversations with your stakeholders. You might talk to the sales rep, for example, and ask them about the viability of using existing sales channels or get their feedback on a draft product roadmap. You’ll then repeat the process with the other stakeholders until you have acquired enough information or managed to create a roadmap everybody accepts.

Alternatively, you can form an extended product team that includes stakeholders, as Figure 2 illustrates.[3]

The stakeholders in Figure 2 share their expertise and contribute to product decisions in collaborative workshops, and they work with the other members to progress the product and achieve product success. For instance, you would discuss the viability of the sales channels in a product team meeting. Similarly, you would either co-create the product roadmap or discuss an initial version together with all product team members, as I explain in more detail in the article Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap.[4]

Benefits and Challenges of Having Stakeholders on the Product Team

Everything has its advantages and disadvantages, and that’s no different for extended product teams. Let’s start by looking at four major benefits they offer.

• Better Collaboration: By bringing people together, extended product teams foster strong cross-functional collaboration. They encourage a sense of we-are-in-this-together, break down cross-departmental barriers, and help remove silos.
• Better Alignment: Having stakeholders on the team creates a shared understanding, improves alignment, and brings clarity to what should and can be achieved. People hear each other’s ideas, requests, and concerns. They can better understand their mutual needs and empathise with each other.
• Better Decisions: You are likely to make better decisions as you leverage the collective wisdom of the group. This helps you come up with more creative solutions compared to talking to individual stakeholders. As an added benefit, you no longer have to act as a go-between to negotiate agreements.
• Better Buy-in: Having the stakeholders on the product team generates stronger buy-in to decisions. The individuals now actively contribute to them, participate in a collaborative decision-making process, and are therefore more likely to support the product strategy and product roadmap.

However, adding stakeholders to the product team also has its challenges. Here are three common ones.

• HIPPO: Senior stakeholders might expect that they will make the key decisions. In the worst case, the HIPPO, the highest-paid person’s opinion, wins—no matter if the decision helps create the desired value for the users and the entire business.
• Design by Committee: Reaching agreements in a larger, more diverse team can be challenging, as the team members may have different ideas and diverging perspectives. This can result in tough decisions being avoided and weak compromises brokered. The team might use design by committee instead of working through the process of finding decisions that effectively progress the product and attract as much support as possible.
• Not Enough Time and Authority: The stakeholders might not have the time to attend product team meetings and carry out the necessary work. Additionally, they might lack the authority to represent their functions and make decisions on behalf of their departments/business units.

Having looked into the benefits and drawbacks of extended product teams, let’s now take the next step and discuss how you can leverage the advantages while mitigating the disadvantages.

Tips for Succeeding with an Extended Product Team

To fully leverage extended product teams, apply the following three tips.

Tip #1: Bring the Right People on Board

First, make sure that you involve the key stakeholders. These are the individuals whose expertise and support you need to make the right decisions and implement them. To bring the right people on board, carry out a stakeholder analysis using a tool like the Power-Interest Grid shown in Figure 3.

As I explain the tool in more detail in the article Getting Stakeholder Engagement Right, I’ll keep its discussion brief. The grid in Figure 3 divides stakeholders into four groups depending on their power and interest. The players are the individuals whose expertise and support you require to make the right decisions and progress the product. Consequently, they should be on the extended product team. For a revenue-generating digital product, this might include someone from marketing, sales, and support.

Focussing on the players ensures that you have the right people on the team and that the group is not too large to have effective meetings and successfully practise collaborative decision-making.

Tip #2: Secure the Right Commitment

Second, secure the right commitment from the key stakeholders and their bosses. Clearly communicate that a stakeholder requires the authority to make decisions on behalf of their business unit. A marketer, for instance, has to be empowered to make most, if not all, marketing decisions relating to the product including determining the marketing strategy. Additionally, explain that being a product team member is a long-term commitment. Their membership should last months and years rather than days or weeks. This avoids hand-offs and loss of knowledge and helps the product team become a closely-knit unit whose members respect and trust each other.

Does this mean that the key stakeholders have to be full-time product team members? No, a part-time membership is usually sufficient. This involves carrying out the work required to meet the agreed product-related goals, as well as attending the necessary meetings. These include product strategy and roadmapping meetings, which usually take place bi-monthly or quarterly, and tactical product meetings, for example, sprint review meetings. Being at these meetings gives the stakeholders a holistic understanding of how the product is progressing and the opportunity to share their perspectives and expertise.

Tip #3: Get the Right Support

Finally, involve a coach to help you build an effective product team, facilitate meetings, and practise collaborative decision-making. The role might be filled by a product coach, Scrum Master, or agile coach.[5] Figure 4 shows an extended product team that includes a coach.

While you, the person in charge of the product, should exercise leadership on the product team, having a coach is especially helpful in the following two situations:[6]

First, the team has just been put together or its composition has significantly changed—several members had to leave and have been replaced with new ones. If you have to help the team members build trust, establish an effective way of working, address conflicts, and facilitate team meetings in addition to your other work, it might get too much, and your workload might become unsustainable. Having a coach who supports you mitigates this risk.

Second, stakeholders struggle to embrace the right mindset and don’t act as team players. For example, some might believe that due to their seniority, they should have the final say on important decisions. Some might even try to act as the boss and tell the other team members what to do. An effective product team, however, does not have a hierarchy. Instead, the members treat each other as peers and work together to achieve the desired outcomes. A coach supports you in helping stakeholders develop the right understanding and show the right behaviours, for instance, by establishing ground rules and kindly but firmly reminding people to follow them during meetings.

As the discussion above shows, adding stakeholders to the product team is not always easy. But the rewards offered—better collaboration, decisions, alignment, and buy-in—more than justify the efforts.

Notes

[1] To my knowledge, product teams have been around for at least a couple of decades. The concept has been popularised in recent years by Marty Cagan’s work. Other authors refer to product teams with different terms. Teresa Torres, for example, calls them product trios.

[2] I assume that software architects still write software as described by the ArchitectAlsoImplements pattern.

[3] I am not the first to recommend adding selected stakeholders to the product team. Steve Haines, for example, writes in The Product Manager’s Desk Reference that product team members might come from marketing, finance, sales, operations, legal, and manufacturing (p. 66 and pp. 74).

[4] Note that as the person in charge of the product, you should be empowered to decide if no agreement can be reached by the product team. For more guidance on empowerment, see my article Understanding Empowerment in Product Management.

[5] Being a coach on a product team usually is a part-time job. An experienced coach can therefore support several teams at once.

[6] As the product manager or Scrum product owner, you should exercise emergent leadership within the product team, as I explain in more detail in the article Decoding Product Leadership.

Listen to the audio version of this article:

Involve the Right Stakeholders

Stakeholders can form a large group, especially in bigger companies.[1] They might include senior management, marketing, sales, service, operations, finance, and HR. Securing everyone’s buy-in would be impractical—it would most likely take too much time.

You should therefore focus on the stakeholders whose input and support you really need. To achieve this, perform a stakeholder analysis using a tool like the Power-Interest Grid shown in Figure 1.[2]

The grid divides stakeholders into four groups: crowd, subjects, context setters, and players depending on how interested they are in your product and how much power they have. The individuals whose buy-in to strategy and roadmap decisions is crucial are the players: They are interested in your product, as they, for example, will have to market and sell it. They are also powerful: You need their expertise to make the right decisions and their support to successfully execute them. I refer to this group as key stakeholders.

Keep the other groups in Figure 1 informed about changes in the product strategy and product roadmap, for example, by inviting subjects to bigger review/demo sessions and having one-on-ones with context setters.

Secure the Right Level of Buy-in

Not all strategic decisions are created equal. Some require more stakeholder support than others. Generally speaking, the bigger the impact of a decision is, the more buy-in it needs.

Decisions related to a new or significantly changed strategy have a very high impact. Consequently, the key stakeholders should unanimously agree with them. Smaller strategy updates and product roadmapping decisions, however, are not as critical. Ensuring that everybody consents, and nobody disapproves is usually enough, as Table 1 shows.

When you decide by unanimity and consent, it can be hard to understand whether you have achieved the buy-in required. A great technique to uncover the current level of support is using an agreement scale like the one in Figure 2.

The scale shows five gradients of agreement, ranging from wholehearted endorsement to serious disagreement. You can, of course, use more gradients if you wish to, but I find that in practice, the five options in Figure 2 are usually enough.

With the scale in place, ask the players to express their agreement, for example, by dot-voting. Draw the scale on a whiteboard, be it a physical or virtual one, and invite people to put a dot underneath the appropriate number. The resulting picture nicely visualises the group’s level of agreement.

When most people wholeheartedly endorse a new or reworked strategy and a few agree with minor reservations, you have achieved unanimity. Similarly, consent has been reached when nobody signals that they can’t support the strategy or roadmap and no one has serious disagreements.

If there is no agreement, you have two options: either continue looking for a strategy or roadmap that attracts more support or change the decision rule. Say that you have already had several lengthy discussions with the stakeholders about a strategy change, but people still disagree. It might be best then if the person in charge decides, unblocks the process, and helps everyone to move forward.[3]

Co-create the Product Strategy and Roadmap

The traditional way to engage the stakeholders and secure their support is to present them with a draft strategy and roadmap, collect their feedback, update the plans, and, if necessary, show them the updated version. This process can work when smaller changes are needed and the stakeholders’ perspectives are similar.

But when bigger changes are required or the group is more diverse, the approach is not only time-consuming. It can be hard to reach the required level of buy-in without using design-by-committee, brokering a weak compromise, and agreeing on the smallest common denominator—which is hardly the foundation of a successful product.

A better way is to co-create the product strategy and roadmap with the key stakeholders. This approach makes it easier to reach unanimity and consent without making weak compromises. Additionally, it frees you from resolving conflicting stakeholder views and ideas on your own. Instead, reaching an agreement is a collaborative effort. Stakeholders learn about their respective ideas, concerns, and interests.

A great way to co-develop the product strategy and roadmap—as well as to review and update the plans—is to bring people together through collaborative workshops. Ask a skilled facilitator to help you prep the meetings and facilitate them so that everybody is heard, and nobody dominates. This is especially helpful when the group is new to collaborative decision-making and when the workshops take place online.

You can take this approach further and invite the key stakeholders to join the product team, as Figure 3 shows. See my article Building High-Performing Product Teams for more information on how to form such an extended product team.[4]

Co-creating the product strategy and roadmap replaces a traditional stakeholder management approach with a collaborative one. The individuals are now actively involved in making strategic decisions and thereby contribute to the product success.[5]

Help Stakeholders Meet their Commitments

When a stakeholder agrees with the strategy and roadmap, you should expect that the individual will follow them. Unfortunately, that’s not always the case. Say that Joe, the sales rep and a key stakeholder, helped update the product roadmap. But you now find out that he has promised a feature to an important customer, which is not in line with the plan.

It can be tempting to ignore the issue, add the feature to the roadmap, and get on with things. But this is hardly a recipe for success. As Joe was involved in the decision-making process and consented to the roadmap, he should adhere to the plan and not go against it. If you allow stakeholders to ignore an agreement, what’s the point then of securing their buy-in in the first place?

It is therefore important that you address issues like the one with Joe. A great way to do this is to use the feedback framework shown in Figure 4. (You can download the framework by clicking on the image.)

The framework encourages you to take six steps to address and correct an issue.

• Step 1, Connection: Take the time to check in and empathise with the other person.
• Step 2, Objective: Describe the desired outcome of the meeting, state the issue, and describe the context in which it occurred.
• Step 3, Issue: Address the problem. Start by asking the other person to share their perspective. Listen attentively with the intention to understand. Then describe your observations. Stick to the facts. Don’t judge, blame, or accuse.
• Step 4, Causes: Identify the issue’s underlying causes. Create a shared understanding of why the problem occurred—why the other person acted the way they did.
• Step 5, Actions: Determine the actions required to address the causes and improve the situation. Encourage the individual to come up with suggestions. Then share the actions that you want them to take and the changes you are willing to make. The latter shows that you are prepared to contribute to solving the issue and change your own behaviour if necessary.
• Step 6, Closure: Wrap up the conversation and set up a follow-up meeting if appropriate.

Follow these steps to help stakeholders change their attitudes and behaviours and ensure that securing their support does indeed result in alignment and orchestrated actions.[6]

Notes

[1] A stakeholder is anyone who has a stake in a product—who is interested in or affected by it. While this definition includes users and customers, I use the term in this article to refer to the internal business stakeholders.

[2] The Power-Interest Grid was originally developed by Ackerman and Eden and published in their book Making Strategy. I cover the tool and its application in product management in my book How to Lead in Product Management.

[3] Ideally, the person in charge is the product manager/Scrum product owner, see my article Understanding Empowerment in Product Management. For more advice on decision-making and in-depth guidance on using decision rules, refer to my book How to Lead in Product Management.

[4] As its name suggests, the coach supports and coaches the product team. This includes facilitating collaboration, helping establish an effective way of working, and resolving impediments. The role might be called Scrum Master, agile coach, or product coach.

[5] This assumes that the individuals have the necessary availability and are sufficiently empowered to contribute to decisions on behalf of their groups/business units.

[6] For more advice on offering feedback and applying my framework, see the article How to Offer Constructive Feedback.

Listen to this article:

Be Clear on When to Involve the Stakeholders and Development Teams

You can—and should—make many business-as-usual decisions on your own. Complex and high-impact decisions, however, are best made together with the stakeholders and development teams. There are two reasons for this: First, you usually require people’s expertise to help you tackle complex issues, for instance, to understand technical risks or the impact on the ability to market and sell the product. Second, you need strong support from the stakeholders and dev team members for high-impact decisions in order to ensure that they are effectively followed through. Involving the individuals in the decision-making process show them that you value their input, and it provides them with the opportunity to influence the decision. This, in turn, makes it more likely that they will support and implement the decision.

In practical terms, involve stakeholders and dev teams in decisions that affect the product strategy and the product roadmap—be it that you create the plans or that you make bigger changes to them. Examples of the latter include deciding if you should pivot, address a new market or market segment, retire a product, and if you should replace the product goals or change the dates on a product roadmap. Additionally, include the development team members in product backlog decisions, and always choose sprint goals together.

Bring the Right People Together

Once you’ve established that a decision should be made collaboratively, carefully consider who needs to be involved in the decision-making process to ensure that the right decision is made and that it receives the necessary support. Then invite the right people to a collaborative workshop, no matter if it takes place online or onsite. A joint workshop creates transparency; it allows the individuals to understand each other’s perspectives and interests; and it frees you from having to go forth and back between the individual stakeholders and dev teams until an agreeable proposal has finally been found. 

If you are unsure which stakeholders you should involve, then carry out a stakeholder analysis using, for example, Ackermann and Eden’s power-interest grid shown below.

The grid encourages you to divide the stakeholders into four groups, as I explain in more detail in my article Getting Stakeholder Engagement Right. Once you have done this, focus on the players. These are the individuals whose input you need to make the right decision, who help you progress and offer the product, and who are affected by the product and its ability to create value. For a revenue-generating product, this might be someone from marketing, sales, support, and finance.

If you work with several development teams, ask each team to send one or two representatives to the workshop. I find it useful to have UX design, architecture, programming, and testing skills present to make the right decision. And in a scaled environment where you share product ownership, involve the product people who work with you, for example, feature owners.

Use a Dedicated Facilitator

When you bring people together to make a decision, getting the individuals to engage in a constructive conversation can be challenging, as you might have experienced yourself. Some individuals might enjoy sharing their ideas so much that they won’t stop talking. Others might be shy and reluctant to contribute, and senior members might expect that their suggestions are followed by everyone. What’s more, you are usually required to actively contribute to the decision and share your expertise, as the person in charge of the product.

I therefore recommend using a dedicated, skilled facilitator who runs the meeting and facilitates the decision-making process. This might be your Scrum Master, assuming that the role is filled, and that the individual has the skills required. The facilitator should establish ground rules, help people embrace a collaborative mindset, create an environment where people feel safe to speak their minds, encourage everyone to fully participate and prevent individuals from dominating, ensure that an appropriate decision rule has been chosen, and guide everyone through the decision-making process. Having a dedicated facilitator can be especially useful in an online workshop where people may need more encouragement to fully participate and stay engaged.

Lead by Example

Deciding together becomes difficult when people act in self-centered ways and aim to maximise their personal gain, seek to dominate the discussion, or believe that they know best and that their idea must win. What’s needed to develop an inclusive solution and reach a sustainable agreement is a collaborative mindset.

I therefore recommend that you lead by example, embrace a collaborative attitude, and show that you value the ideas and perspectives of the stakeholders and team members. The following three practices will help you with this: First, show a genuine interest in the perspectives and needs of all attendees—no matter how senior or junior they might be. Second, actively listen to the individuals, give everyone your full attention, and appreciate their contributions even if you disagree. Finally, keep an open mind. While it is important that you have your own perspective and ideas, hold them lightly. Cultivate a receptive and curious attitude and be open to what the stakeholders and development team members have to say. 

Note that attentive listening and open-mindedness do not imply approval. But they make the other person feel understood and appreciated. What’s more, they are likely to free you from being biased towards your own preconceived ideas and help you take full advantage of the collective wisdom of the group in order to make the best possible decision. 

Decide How to Decide

Imagine that you are asking the stakeholders and development team members at the end of a collaborative strategy workshop, “Is everyone OK with changing the needs statement in the product strategy?” Because nobody says anything, you assume that everyone agrees with you. But in reality, people are still thinking about the suggestion. To make things worse, it’s not clear who has the final say on product strategy changes. Is it you, the people present, or possibly the management sponsor?

Choosing a decision rule avoids these issues. Such a rule clearly states who decides and how you can tell that the decision has been made. There are four common decision rules that facilitate group decisions: 

• Unanimity: Everyone agrees with the proposed solution and is happy to endorse it.
• Consent: Nobody disapproves and has any meaningful objections.
• Majority and supermajority: More than half of the people are required to agree with a proposed solution. In the case of supermajority, more support is required, such as two-thirds or 75 per cent.
• Product person decides after discussion: Once everybody has been heard and a shared understanding of the different ideas has been established, the person in charge of the product makes the decision.

Note that each rule has its strengths and weaknesses; none is always appropriate. For example, unanimous agreement generates strong support for important product decisions. Achieving it, however, can take a comparatively long time. Contrast this with the rule, product person decides after discussion, which is much quicker to apply. But it may not generate particularly strong buy-in if your decision does not consider the suggestions of the stakeholders and dev team members.

Don’t Rush Important Decisions

While it can be tempting trying to quickly solve an issue and make a decision, it takes time to leverage the collective wisdom of a group and solve a complex or high-impact issue. The steps described below will help you guide a group through the decision-making process and arrive at a decision that everyone can understand and support. 

Step 1: Gather Diverse Perspectives

Make sure that everybody clearly understands the issue to be addressed. Then ask people to share their perspectives, come up with ideas, and voice any concerns they might have, for example, by using structured brainstorming. It is essential that everyone can contribute and is being listened to. This makes people feel valued and involved, and it allows you to collect different ideas and perspectives. Resist the temptation to shortcut the process and to prematurely reach agreement at this step. Otherwise, you are likely to end up with a mediocre solution based on familiar options.

Step 2: Build Shared Understanding

Help people understand each other’s views and encourage them to explore the underlying needs and interests. For example, ask the individuals to explain why an idea is important to them or why they feel strongly about a suggestion. What are their motives or concerns? Give the group the time required to develop a shared understanding, and don’t rush this step. If people don’t understand each other sufficiently, then it will be very difficult, if not impossible, to come up with a solution that everybody can accept.

Step 3: Develop an Inclusive Solution

Once the group has established a shared understanding and people know the reasoning and motivation behind the different suggestions, you are ready to develop an inclusive solution. But this does not mean that you should try to please everyone by cobbling together different ideas, nor does it entail brokering a compromise or agreeing on the smallest common denominator. That’s the opposite of what a collaborative decision-making process should achieve. A truly inclusive solution addresses the needs of everyone present, move the product in the right direction, and results in a sustainable agreement—a decision that people will follow through.

Use Data to Make Decisions

While it is very helpful to have relevant experience and a solid understanding of the market, don’t make the mistake to blindly trust your gut feeling or to follow the opinion of the most senior stakeholder. Use data instead to make the decision. If you lack the relevant empirical evidence, consider pausing the decision-making process and collecting the data required. 

Say that you are thinking of addressing a new market segment and you are discussing the idea in a collaborative strategy workshop. Some of the attendees, including yourself, have experience in offering products to this segment and are in favour of developing a new product variant for this target group. But if you haven’t done any specific product strategy work and lack data to support this view, I recommend pausing the decision-making process and carrying out the necessary discovery work, for example, interviewing prospective users, and building a throw-away prototype to test your idea. Otherwise, you’ll risk deciding based on experience and beliefs—which may or may not result in the right course of action.

Secure As Much Buy-in As Possible but Do Not Allow Stakeholders to Dictate Decisions

When involving stakeholders and development teams in a decision, it’s natural to try to generate as much buy-in as possible. While I can’t emphasise enough how important it is to attentively listen to the individuals and appreciate their perspectives, ideas, and concerns, you should not make the mistake of trying to please people or allowing individuals to dominate the decision-making process. 

Instead, search for a decision that maximises the value your product creates and at the same time, is inclusive and attracts as much support as possible. But do not agree to a weak compromise. Deciding together does not mean that everybody gets their way or is necessarily super happy with every decision. It means leveraging people’s expertise, ideas, and concerns, creating a shared understanding, and finding an appropriate solution that attracts as much support as possible.

Listen to this article:

Imagine that you are talking to John, a senior salesperson who’s been involved with the product for a while. John mentions the upcoming product release and says, “You really must add the enhanced reporting feature. I’ve spoken to several customers, and they have all confirmed that it is absolutely crucial.” You know, though, that it is impossible to add the feature to the development effort. The dev team is struggling with the current workload, and moving the date is not an option.

What’s more, you suspect that John’s request may be motivated by the desire to meet his sales targets. But John is a well-connected and influential individual who doesn’t like to be told that he is wrong. How can you decline his request without offending him and losing his support?

You can also access the content of this article on my YouTube channel.

Don’t Feel Bad about Saying No

Declining a request can be hard. You might not want to disappoint John in the example above, you might worry that saying no will anger him and lead to conflict, or you might not want to be seen as a naysayer but somebody who has a can-do attitude and wants to help.

Saying no, however, is part and parcel of a product person’s job. If you said yes to every idea and request, you would end up with a feature soup, a product with an uncompelling value proposition and a poor user experience. As Steve Jobs once said, “Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”

If you believe, however, that it would be impossible for you to say no to John, then this may indicate that you are not properly empowered, that you lack the authority and respect required to be in charge of the product and be responsible for its success. If that’s the case, explore how you can strengthen your product leadership. Refer to my article “Boost Your Product Leadership Power” for more guidance.

Empathise with the Stakeholder

Having decided that you can’t accept John’s request, you might be tempted to share your view with the individual and say, for instance: “Sorry, John. But there is no way that I can add the feature to the current release. The development team is struggling to implement the agreed features, and, as you know, we can’t push out the date.” This might seem like a reasonable answer: It’s direct and it offers an explanation. But would it be effective?

If John does not feel heard and understood, it will be hard for him to accept no as an answer, no matter how valid your arguments are. Instead, he might feel rejected and react with disappointment or anger. He might think that you don’t appreciate his views and don’t care about his needs. Consequently, John may no longer fully trust and support you.

To avoid this situation and maximise the chances that John can receive a no, empathise with the individual before you offer an answer. Find out why the feature is important to John. What is his personal, vested interest in getting the feature included in the release? Why does it matter to him? Only if John feels understood will he open up to your perspective, listen to your arguments, and accept that you can’t add the feature to the release. The following listening techniques will help you with this:

• Give your full attention to the individual. Maintain eye contact and show the person that you are interested in what she or he has to say.
• Keep an open mind even if you disagree with what you are hearing or if you dislike the individual. Listen with the intention to understand, not to answer. John might be right, after all, and you should add the feature to the release.
• Pay attention to the person’s body language. Non-verbal information—like voice pitch and volume, gestures, facial expressions, and eye movement—expresses the speaker’s feelings, which help you uncover the individual’s underlying interests.
• Ask clarifying and probing questions to check that you have correctly understood what was said and encourage the other person to provide more information. You might say, for instance, “Can you please help me understand why adding the feature is important to you?”

Reframe the Conversation

Stakeholders often request specific features without necessarily being fully aware of the problem it addresses. But value is hardly created by adding a single piece of functionality—at least as long as a product is young or changing. Instead of debating an individual feature with John, reframe the conversation. Explore which user or customer problem the functionality would help address. How would implementing the feature benefit these individuals? Why do some customers view it as crucial, to stay with the example above? And would there be an alternative way to achieve the desired impact?

Additionally, consider if the feature is aligned with the product goal of the current development effort, the outcome you want to achieve, for example, to enter a new market or to increase engagement. Will addressing the user problem help you meet this goal and create the desired benefit?

If the answer is yes, then you should consider adapting the development effort. You may decide to add the feature to the release, assuming that you make appropriate adjustments like reducing or removing other features or moving the delivery date. But if the answer is no, then you should decline the request.

Don’t Rush the Decision

It can be tempting to quickly make a decision just to be done with it. While you don’t want to procrastinate the decision, rushing it is usually a bad idea.

Say that the conversation with John has turned difficult. He is adamant that the feature must be added, and he doesn’t want to accept your view. What’s more, he suggests that you don’t understand what the customers want, and he threatens to escalate the issue if you decline his request. In such a situation, it’s natural to feel difficult emotions like confusion, worry, and anger.

When this happens, it’s best to pause the conversation and to postpone the decision to regain a cool head and allow the difficult feelings to subside. You might say to John, “It’s really important to me that we find a good solution. But I am feeling upset right now, and I need some time to reflect on what I heard you say. Let’s please continue the conversation in the afternoon.”

Additionally, consider if you can and should make the decision on your own. If the decision has a bigger impact, if you require other people’s input to make the right decision, or if you want to secure their buy-in, I recommend scheduling a meeting with all the key stakeholders and the development team representatives in order to discuss and evaluate the feature request and make a joint decision. You might even find that you need to run an experiment and collect relevant data, for instance, by interviewing users or releasing a feature fake, before you can make the decision.

Try to Find Common Ground, but Don’t Split the Difference

While saying no is sometimes unavoidable, I recommend that you explore if there is an alternative way to meet the stakeholder’s underlying need. Say that your suspicion turned out to be right: John’s request is, at least partly, motivated by the desire to meet his sales targets and claim a bonus.

If that’s the case, find out if you can help him achieve his goal without having to add the feature—assuming that you believe that it is right for you to help John pursue this goal. Would it be helpful, for example, to develop a sales pitch that shows that the product addresses some of the customer needs without providing the extra feature? Or is there another solution you can develop together with John?

Don’t make the mistake, though, to simply split the difference and suggest to John that you will partially implement the feature as part of the current release—unless this would actually meet John’s underlying need and not sacrifice sustainable pace for the development team.

Do what is necessary to maximise the value your product creates but don’t attempt to please individual stakeholders. Be kind and firm. Remember: Successful products are not built on weak compromises or the smallest common denominator.

Listen to this audio version of this article:

Lead the Stakeholders—Don’t Please, Don’t Dictate

As the person in charge of the product, your aspiration should be to lead the stakeholders in order to create value together and achieve product success. In reality, however, some product people either aim to please the stakeholders by saying yes to their requests or by brokering compromises. Others do everything they can to make the stakeholders agree to their ideas and plans. But neither of these two approaches is desirable.

The first one carries the risk of being a feature broker and offering a product that has a weak value proposition, gives rise to a poor user experience, and consists of a loose collection of features. The second approach fails to leverage the knowledge and expertise of the stakeholders. What’s more, it makes it unlikely that the stakeholders will fully support the product decisions and that they will follow them through.

Effective stakeholder management starts by embracing the right attitude: See the stakeholders as equal partners; take an interest in their perspective, ideas, concerns, and underlying needs; build trustful connections with the individuals; and encourage the stakeholders to work together. But do not accept inappropriate behaviour and do not allow people to treat you like a project manager, team lead, or personal assistant. The following tips will help you with this.

Focus on the Key Stakeholders

A stakeholder is anyone who has a stake in your product, who is affected by it, or who shows an interest in the offering. While this definition includes users and customers, I use the term in this article to refer to the internal business stakeholders. For example, these stakeholders are likely to include representatives from marketing, sales, support, and finance for a commercial product.

To focus your stakeholder management effort, identify your key stakeholders—those individuals with whom you want to establish a trustful connection and collaborate on a regular basis. This is particularly helpful when you are faced with a large group of stakeholders, which is not uncommon in bigger companies. A handy stakeholder analysis tool is the power-interest grid developed by Ackermann and Eden.

As its name suggests, the grid analyses the stakeholders by taking into account their power and interest; it assumes that people take a low or high interest in your product and have low or high power. This results in four stakeholder groups: players, subjects, context setters, and crowd, as the picture below shows.

The players are your key stakeholders: These are the individuals whose trust you should earn, who you should closely collaborate with, who you should involve in important product decisions. This avoids the risk that the stakeholder management work becomes overwhelming and consumes too much of your time. For guidance on how to interact with the other stakeholder groups, please see my article “Getting Stakeholder Engagement Right”.

Build Trust

As the person in charge of the product, you lack transactional power: You cannot tell the stakeholders what to do, you cannot assign tasks to the individuals, and you are typically not in a position to offer a bonus, pay raise, or other incentives. At the same time, you rely on their work and support to progress the product, for instance, to market and sell it. How can you then guide the individuals and ensure that everyone moves together in the same direction?

The answer is by building trust. Here is why: As you lack transactional power, you must influence the stakeholders and encourage them to follow your lead. To do so, you have to earn the individuals’ trust. To put it differently, if the stakeholders don’t trust you, they won’t follow you and they won’t support your ideas and suggestions.

The following techniques will help you with earning the stakeholders’ trust:

• Empathise: Take a warm-hearted interest in the stakeholders and try to understand their perspectives, ideas, concerns, interests, and needs—no matter how likeable and agreeable you find the individuals and their views.
• Practice active listening: Make an effort to attentively listen to the stakeholders and cultivate an open mind.
• Speak and act with integrity: Say what you believe is true, be willing to admit mistakes, and walk your own talk.
• Get to know people and, for example, have lunch or coffee together, be it in the same room or online.
• Involve people in product decisions but don’t make the mistake of trying to please them.
• Increase your product management expertise.

Form a Stakeholder Community

Building trust with the stakeholders and effectively collaborating with the individuals is hard when the stakeholder group is changeable, when people come and go, for instance, when a new sales rep is assigned to your product every few months. I therefore recommend that you form a stable group of stakeholders and develop it into a stakeholder community where the individuals work together on a continued basis and learn to trust, respect, and support each other.

To build such a stakeholder community, try the following techniques, which I discuss in more detail in my book How to Lead in Product Management:

• Bring people together and have joint workshops instead of holding separate conversations with the individual stakeholders, see also the section below.
• Establish clear roles and responsibilities. If people aren’t clear on what is expected of them and who is doing what, confusion arises, and collaboration becomes more difficult.
• Collaboratively set goals, for example, user and business goals on the product strategy and product goals on the product roadmap.
• Improve the collaboration within the stakeholder group and address issues, for instance, by holding stakeholder retrospectives.
• Ask the Scrum Master to help you build a stakeholder community.

Engage the Stakeholders Early and Regularly

I’m a big fan of involving the key stakeholders early and often. This starts by inviting them to a kick-off workshop for a brand-new product or a major product update and asking them to contribute to the product strategy work.

It continues with collaboratively creating a product roadmap and having regular joint product strategy workshops, once per quarter as a rule of thumb, where the product strategy and roadmap are reviewed and adapted. Additionally, ask the players to attend the sprint review meetings at least once per month so that the individuals see how the product delivery progresses and are able to share their feedback and any concerns they might have.

In other words, involve the key stakeholders in product strategy and product development work. This allows you to benefit from their expertise, it ensures that everyone is on the same page, and it encourages shared ownership: When developed collaboratively, the product strategy and product roadmap are no longer your plans that people are meant to follow. Instead, they are collectively owned, and everyone involved feels responsible for them.

Note that collaboration means constructively engaging with one another and achieving some form of consensus—not splitting the difference or agreeing on the smallest common denominator, neither of which is a recipe for achieving product success.

Joint workshops, and collaboration in general, become easier and more enjoyable once people have started to trust and respect each other, and the stakeholder group has evolved into a community. The same is true for making product decisions together with the stakeholders, which I discuss next.

Involve the Stakeholders in Important Product Decisions

The most amazing product strategy and the best product roadmap are worthless if the stakeholders don’t support them. But how do you secure people’s buy-in and maximise the chances that the individuals follow the strategy and roadmap? My answer is by involving them in making the appropriate decisions.

When it comes to decision-making, you have two main choices: First, you can make a decision and then try to sell it to the stakeholders. This can be a lengthy iterative process that requires quite a bit of to-and-fro, negotiation, and possibly persuasion. Your second option is to bring the stakeholders together—be it in the same room or a video call—and decide collaboratively. This option takes advantage of the group’s collective knowledge, ensures that everyone has the same understanding, allows the individual stakeholders to be aware of the other people’s perspectives and interests, and typically results in stronger support for the decision, which makes it more likely that the individuals will stick to it and see it through.

To take advantage of collaborative decision-making and effectively involve the stakeholders in important product decisions, try the following techniques:

• Employ a dedicated facilitator who ensures that everyone feels safe to speak her or his mind, that everybody is heard, and that nobody dominates. This mitigates the risk that the HIPPO, the highest paid person’s opinion, wins. You may want to ask your Scrum Master to facilitate the decision-making process, assuming that the individual has the right skills.
• Foster a collaborative mindset and agree on ground rules: Lead by example and attentively listen to people’s ideas while cultivating an open mind.
• Choose a decision rule so that everyone understands who decides and when and how a decision is made. Example decisions rules are consent, unanimity, and product person decides after discussion.
• Encourage people to come up with diverging ideas and create a shared understanding of their underlying interests and needs before you try to find a solution that everyone can agree with.
• Don’t shy away from making tough decisions and declining suggestions and requests after you have attentively listened to the requester and empathised with the individual.

You can find more collaborative decision-making tips in my book How to Lead in Product Management.

Hold People Accountable and Don’t Tolerate Inappropriate Behaviour

It’s great to lead the stakeholder by being collaborative and involving them in important product decisions. But this also means holding people accountable for meeting their agreements. If, for example, the marketer has failed to create the marketing collateral required for the upcoming release, then don’t ignore the issue but address it in the right way. Talk to the individual, empathise with the person, and find out what happened. But do not accept that a stakeholder intentionally acts against a joint decision or a common goal.

Similarly, don’t allow individuals to use a personal conversation with you to make requests, like trying to add a new feature. When this happens, kindly but firmly ask people to attend the appropriate meeting and to share their request with the other stakeholders. This creates transparency, fosters joint ownership, and avoids the impression that you might favour certain individuals.

Finally, don’t put up with inappropriate communication behaviour, like blaming others, bending the truth, or hogging the conversation. Ask people to always treat each other with respect, attentively listen to one another, and refrain from using harsh and false speech. Remember that dealing with people issues is part and parcel of managing a product and that learning to constructively address disagreements and conflict is an important leadership skill.

It’s a Common Challenge

“You just can’t make up your mind. I really wish that for once, you gave us clear priorities,” Jane said accusingly at the end of the workshop and walked out of the room. [1] It felt like a slap in the face, an unprovoked attack. How could she say something so wrong?

Does this story sound familiar? I certainly find that as product managers and product owners, we sometimes have to deal with pushy, stressed, or unhelpful stakeholders and team members—with people who are just being difficult.

If we reflect on the nature of our work, then this shouldn’t come as a surprise: Product management is as much about people as it is about products. Friction and conflict commonly appear when people from different departments work together. What’s more, innovation and effective teamwork are only possible if we can leverage conflict and disagreement. [2]

Don’t Ignore the Conflict

It would be easy brush aside the issue and forget what Jane said. With so many things competing for your attention, should you really worry about Jane’s remark? But what would happen if you did ignore the conflict?

Chances are that you would feel aversion towards Jane, even if you are not fully aware of it. Next time when you meet, this might cause you to say something you later regret, which would make things only worse. What’s more, tolerating wrong behaviour sets a precedence and creates an unhealthy work atmosphere; disrespect invites disrespect.

Therefore, do not ignore conflict. See it as an opportunity to improve your product management practice and leadership skills. This, of course, is sometimes easier said than done: Addressing the issue requires courage. Jane might a powerful or influential individual like senior management stakeholder. Additionally, you have to be willing to honestly reflect on your own intentions and actions, and be open to change your behaviour.

Regain Your Composure

When exposed to unkind behaviour, it can be hard for me not to lose my calm. But before responding to Jane and telling her what you think, stop and reflect. Become aware of how you are, how you are feeling. Are you disappointed, upset, or angry? If so, then that’s ok. But bear in mind that negative thoughts and emotions cloud your perception; they will make it difficult to have a constructive conversation with Jane.

What’s more, negativity affects your own wellbeing; it makes you unhappy. Holding on to anger, a wise man once said, is like grasping a hot coal with the intent of harming someone else: The only thing certain is that you will get burned. [3] Even if anger, fear, or worries seem to have a tight grip on you, they will weaken and go away if you do not feed them. Acknowledge them, but do not engage and identify with them.

Additionally, bring to mind the positive qualities of the difficult person. Jane surely can’t be all mean and evil. Think of moments when you saw Jane help others, make a constructive contribution, or commit other acts of kindness. Remind yourself that anybody who acts in unskilful ways must be unhappy deep inside. This will help you empathise with the difficult person and develop compassion, rather than villainising the individual and holding a grudge against her. Finally, tell yourself that as human beings, we have all acted in inappropriate ways and said unkind things; I’m certainly not perfect by any means.

Put Things into Perspective

Next, ask yourself why you perceive the person as difficult. What makes the individual so hard to deal with? Why did you respond in the way you did? Why did Jane’s remark make you feel angry or hurt, for example? Was it purely because of what Jane said, or has it something to do with you?

I notice that my own response to unskilful behaviour is particularly strong when deeply held opinions and beliefs are challenged. If I think of myself as someone who is decisive and knows what’s right for his product, then I am likely to be more affected by Jane’s remarks—independently of her intention. Similarly, I find that when I am stressed or tense, any wrongdoing I experience feels worse than when I am relaxed and content.

Finally, look at the data and calmly consider what actually happened. Jane’s remark might have felt like a slap in the face. But did she mean to be nasty? And did you contribute to the conflict in any way? Was there anything unhelpful you might have said or done to Jane, intentionally or unintentionally? This doesn’t excuse Jane’s behaviour, of course. But it helps put things into perspective and move on from blaming Jane to resolving the conflict.

Respond Skilfully

When you meet Jane to address the issue, approach the meeting with the intent to understand and reconcile, not to win. Be willing to attentively listen to her and understand her perspective. Conflict resolution is not about getting the better of the other person; it’s about developing a shared perspective on what happened, agreeing on the changes required, and rebuilding trust.

Share your perspective and experience in a constructive way, and be kind: Jane may not be (fully) aware of her actions or their impact on you. At the same time, be honest and firm. Use the I language; describe what you saw and heard, and how it affected you. For example, “I heard you challenge my ability to prioritise and make effective product decision; then I saw you leave without giving me time to respond. I consequently felt angry and disappointed.”

Separate the person from the issue. Don’t blame or attack the other person, don’t generalise (“that’s typical of you”), don’t talk about what other people may have said (“John says so too”), don’t speculate (“it’s probably because you didn’t get what you wanted in the previous meeting”). Listen with an open mind and try to suspend judgement. We all hold a piece of truth.

Offer a helping hand and make constructive suggestions for resolving the issue. Suggest changes that you are prepared make, such as, “I will invite you from now on to the product roadmapping workshops so you better understand the overall constraints we have to take into account when prioritising the product backlog,” or “I will listen more carefully to your suggestions so you no longer feel ignored and side-lined.”

State the positive changes that you wish for, for instance, “it would really help me if you tried to be more patient and understanding,” or “it would be great if you could let me know sooner if you feel your opinion is not heard.”

Remember: While you want to be kind and caring, you are not responsible for the other person’s thoughts and feelings. You can encourage another person to change. But you cannot make someone change her attitude and behaviour.

Move on

If everything works out well, you’ve made up with Jane and agreed on a way forward. What’s then left to do is strengthening the relationship and fully re-establishing the trust that might have been lost. This is achieved by working together as well as socialising, for example, having coffee or lunch together.

If the conversation didn’t go well, consider what the next steps are. Should you talk to Jane again? Should you involve someone who can mediate? Should you escalate the issue? Talking to your manager or Scrum Master / coach might help you choose the right action.

Notes

[1] Note that Jane is a fictitious character. I assume that the conflict can be resolved by the people involved unlike severe transgressions, such as violence or sexual harassment. If you are in doubt, talk to your line manager and involve human resources.

[2] Tuckman’s team building model, for example, suggests that people have to learn to handle conflicts to work together productively.

[3] This quote is often attributed to the Buddha, but it may actually be from Buddhaghosa.

Identify the Stakeholders

A stakeholder is anyone who has a stake in the product, who is affected by it, or who shows an interest in it. While this definition includes customers and users, it is commonly used to refer to the internal stakeholders. Note that some frameworks, such as Scrum, have their own stakeholder definition. In Scrum, the stakeholders are all interested parties apart from the product owner, the development team, and the ScrumMaster.

To identify the stakeholders, ask yourself whose help you need to develop, release, and provide the product. The answer to this question will be specific to your product and company. For a commercial product, the group is likely to include representatives from marketing, sales, support, and management. But it might also comprise legal, finance, and human resources. For an in-house product, your stakeholders may be operations, the affected business units, and management.

Analyse the Stakeholders

Once you have identified the stakeholders, take the next step and analyse them to understand how you should engage with them. This focuses your efforts, generates the desired buy-in,  and allows you to spend your time wisely.

A common stakeholder analysis technique is the power-interest grid, which was originally published by Colin Eden and Fran Ackermann in their book Making Strategy. As its name suggests, the grid assesses the stakeholders by taking into account their power and their interest. The grid assumes that stakeholders take a low or high interest in your product and that they have low or high power. A stakeholder is typically interested in the product if it noticeably affects the individual. Someone has a high power if the person can influence the product decisions, for instance, if or when a feature is implemented.

Taking into account low and high power and interest results in four quadrants and stakeholder groups, players, subjects, context setters, and crowd, as the following picture shows.

Each stakeholder group on the grid above requires a different engagement form, as I explain below.

Collaborate with the Players

Stakeholders with high interest and high power are called players. These individuals are important partners for you as the product manager or product owner. You should therefore collaborate with them closely, for instance, by inviting them to product strategy and roadmapping workshops and sprint review meetings. Aim to secure their buy-in, leverage their ideas and knowledge, and establish a close and trustful relationship with them.

Additionally, ensure that the individuals are involved with the product on a continued basis to avoid loss of knowledge and hand-offs. It is undesirable, for instance, that the marketing group sends a new representative every time a strategy workshop or review meeting takes place. Instead, one marketer should represent the group on a continued basis.

Bear in mind that collaboration requires leadership. You should be open and collaborative but decisive at the same time. Aim to build consensus with the players but don’t shy away from difficult conversations. Don’t settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved.

Involve the Subjects

Subjects are individuals with high interest but low power. They feel affected by the product and are keen to influence it but they can’t veto or change decisions. Subjects can make great allies who can help you secure understanding and buy-in for your product. Keep them engaged and involve them on a regular basis, for instance, by inviting them to sprint review meetings and encouraging them to share their feedback.

But don’t make the mistake to say yes to every idea and request subjects raise. Use the product strategy and roadmap to assess if an idea is helpful or not. If in doubt, consider running a brief and cheap experiment to find out if adding a feature would be beneficial, for example.

Consult the Context Setters

People with low interest but high power are called context setters or referees. They affect the product’s context but they take little interest in the product itself. An example is the person in charge of the development group: If the individual does not help staff the development team properly, then the success of the product may be at risk.

Make sure that the context setters feel that their opinions, concerns, and ideas are heard and understood. Regularly consult them, for instance, by having one-on-one meetings. This ensures that their ideas and concerns are heard and it helps avoid nasty surprises. Don’t let the context setters intimidate you and don’t allow them to dictate decisions. Be strong and have the courage to say no even if faced with a powerful and pushy stakeholder.

Inform the Crowd

The crowd are stakeholders with low interest and low power. As they are not very interested in your product and don’t have the power to influence product decisions, it’s usually sufficient to keep the individuals informed, for instance, by giving them access to the product’s wiki web or update them on important developments in form of a newsletter.

Summary

The following table summarises my recommendations on how to engage with the four different stakeholder groups.