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 the audio version of this article:

Introduction

To discuss empowerment in product management, I find it helpful to distinguish three main levels of decision-making authority, product delivery, product discovery, and product strategy, as the model in Figure 1 shows.[1]

Level one represents the authority to decide how features are detailed and guide their implementation. Level two increases empowerment by adding the authority to determine the features and user experience the product should offer. Level three, finally, allows product people and teams to develop the product strategy including the value proposition and business goals.

Before I discuss the three levels in more detail, let me briefly explain why I wrote this article. My intention is to help you better understand your current level of empowerment, decide if it is appropriate, and determine how you might strengthen your authority. If you manage a group of product people, for example, as the head of product, I hope that the article will help you determine if the group’s empowerment is sufficient.

I certainly don’t intend to make anyone feel bad. At the same time, I believe that it is important to look at things the way they are. It’s the first step to bring about positive change.

Level 1: Product Delivery

If your job is to decide how features are implemented and if you work with one or two development teams to deliver them, then you are at level one. Here are four signs that this is the case:

• Stakeholders, management, or another, more strategic product role determine which features have to be provided and communicate them to you, for example, during a sprint review meeting or in the form of feature requests.[2]
• The product backlog, or one of its subsets, and the release plan are the main artefacts you work with.
• You spend a significant amount of your time refining product backlog items, writing user stories, tracking the development progress, and talking to development team members.
• You are not in a position to decline feature requests.

While the work you do at level one is valuable, your role is similar to a project or delivery manager. As you are not empowered to determine the product features, you are not in a position to manage the product and significantly impact the value it creates. To put it differently, level-one empowerment is not sufficient for being an effective product manager or Scrum product owner.[3]

Level 2: Product Discovery

Level-two empowerment means that you determine the product features and user experience. You are usually at this level if the following five criteria apply:

• You carry out product discovery activities including talking to users, detailing user needs, and deriving the right product features.
• You use an outcome-based product roadmap and/or an opportunity solution tree, personas, user journey maps, and the product backlog to capture and validate your decisions and guide the product delivery effort.
• You manage the stakeholders, for example, by inviting them to roadmapping workshops and sprint review meetings or by having regular one-on-ones with them.
• You work towards an overarching product strategy, which states the value the product should create for the users, customers, and business. The strategy may be developed by the head of product or another senior manager.
• You are empowered to decline a feature request if it does not meet the agreed strategic objectives.

At level two, you can actually manage the product and influence the value it creates. Consequently, this is the minimum level of empowerment product managers and Scrum product owners as well as product teams require.[4]

Level 3: Product Strategy

If you are authorised to determine not only the product features but also the product strategy, you experience level-three empowerment. Here are three signs that you are at this level:

• You engage in strategizing work, such as market discovery and market research, competitor research and competitive analysis, business modelling and financial forecasting, strategy validation, and selecting and applying the right key performance indicators (KPIs).
• You employ the following artefacts: product vision and product strategy, business model and business case (if applicable), and KPIs.
• You follow a business strategy and, if appropriate, a product portfolio strategy, which guide and constrain your decisions.

If you’re at this level, you have full-stack empowerment: You are authorised to make strategic decisions in addition to solution-focused ones. I generally recommend that product people and product teams have level-three empowerment. This allows them to innovate fast and maximise value creation.

If you are familiar with my work, this recommendation won’t be a surprise. I’ve advocated level-three empowerment for product managers and Scrum product owners for many years. For example, I write in my book Strategize: “As the person in charge of the product, you should own the product strategy (…), and you should be empowered to have the final say on strategic decisions.”[5]

It’s not uncommon, though, that the head of product—also referred to as Director of Product Management, VP of Product, and Chief Product Officer—determines the product strategy. Unfortunately, this can cause the head to be overworked, become a bottleneck, and slow down decision-making. Proactively developing the product strategy and carrying out continuous strategizing work requires a significant effort. Additionally, it prevents the contributors from adding as much value as possible, and it can lead to lower morale and productivity.

Instead of creating and evolving the strategies of individual products, the head of product should help the contributors make the right strategic decisions, for example, by mentoring and coaching them or by asking them to attend my strategy and roadmap training. Additionally, the individual should ensure that the overall product portfolio is effectively managed, as I explain in more detail in the article Should a Head of Product Make Strategic Product Decisions.

Levelling Up

It’s all good and well to understand your current level of empowerment. But how can you increase your empowerment and move up from level one to levels two and three? The brief answer is: By increasing your referent and expert power and by bringing about some organisational change, as Figure 2 shows.

Referent and expert power refer to your ability to influence others including management, stakeholders, and development teams.[6] The former is based on the respect and trust people have in you; the latter is founded on your expertise. The more people trust you and the more knowledgeable you are, the more they will listen to your advice and let you determine the product features and make strategic product decisions. It’s therefore desirable to grow both powers.

Developing Your Referent and Expert Power

A great way to develop your referent power is to empathise with people, practise active listening, speak and act with integrity, be accountable, and involve people in product decisions, as I explain in more detail in the video below.

To strengthen your expert power, acquire the necessary product management skills and the relevant knowledge about your product and its market. For example, developing your ability to understand user needs, create an effective product roadmap, determine the right product features, and prioritise the product backlog will help you step up to level two. Being able to do market and competitor research, perform competitive analysis, create, validate, and evolve a product strategy, carry out business modelling and come up with a financial forecast, as well as use the right KPIs will enable you to move up to level three.

Affecting Organisational Change

But as Figure 2 illustrates, growing expert and referent power may not be enough. Say that you find yourself at level one. You are then unlikely to achieve level-two empowerment without your role being adjusted and its authority and responsibility being changed. These changes will most certainly require the support of your boss. If there is a larger impact, however, for instance, on career paths, development programs, and employee selection criteria, then you are likely to require the involvement of HR and the backing of senior management.

To bring about the necessary changes, try to influence the decision-makers and help them understand why product people require at least level-two empowerment—preferably after you have worked on your referent and expert power.[7] But if this fails, you are faced with two options: accept the status quo or look elsewhere for a product management job that offers the right level of empowerment.

Notes

[1] The model in Figure 1 takes advantage of the strategy, discovery, and delivery distinction described in Marty Cagan’s book Inspired, 2^nd ed. Note that the model defines empowerment as having the necessary decision-making authority and having ownership of the product or at least some aspects of it.

[2] I use the term feature to refer to a product capability, for example, commenting on this article.

[3] In an agile, Scrum-based process, the project management work is collaboratively performed by the Scrum product owner and the development team with the latter taking on most of the work. In the scaling framework SAFe, however, the SAFe product owner has level-one empowerment, as far as I can tell.

[4] Marty Cagan calls teams, which lack level-two empowerment, “feature teams”.

[5] I continue by saying: “But this does not mean that you should create the strategy and roadmap on your own, hand the finished plans to the stakeholders and development teams, and expect them to put them into action. No matter how well thought-out your product strategy and roadmap are, they are worthless if the stakeholders and development teams do not buy into them. You should therefore involve them in creating and updating the plans, preferably in the form of collaborative workshops.” Strategize, 2^nd ed., p. 20.

[6] Referent and expert power were first described by French and Raven in their paper The Basis of Social Power. They are also referred to as personal power to distinguish them from positional power, which is derived from a position in the org chart. See also my article Decoding Product Leadership for more information.

[7] If you have qualified coaches in your organisation, ask them to support you. A Scrum Master, for example, is meant to address organisational impediments and help bring about the changes necessary to establish an effective way of working. This includes increasing the empowerment of the product people.

Listen to the audio version of this article:

Leading as the Person in Charge of the Product

When you hear the term leadership, you might first and foremost think of a senior manager like the head of product, Director of Product Management, VP of Product, or Chief Product Officer.[1] In fact, some people argue that product leadership can only be exercised by a management role. But in my mind, that’s a misunderstanding of what it means to lead. Leadership is present when an individual guides a group of people to achieve a desired outcome.

Leadership can therefore be exercised without being a boss. You don’t have to be a line manager to lead others. Consequently, a product manager and a Scrum product owner are leaders, too. They guide the stakeholders, development teams, and in the case of large products, other product people, to meet the agreed product goals, create the desired outcomes, and achieve product success, as Figure 1 shows.

The best product managers and product owners I have seen were great at aligning and guiding people. The opposite is also true: I’ve seen product people who were excellent at product management, had amazing market insights and great product ideas, but underachieved, as they lacked the right leadership skills.

Leading as the person in charge of the product, however, is far from being easy. As the individual is a peer and not the boss, they cannot tell people what to do and they are usually not in a position to offer rewards like a promotion. The leadership they exercise is called emergent or lateral leadership.[2] It does not derive from a position on the org chart. Instead, it must be earned. The followers—the product team members in Figure 1—must support the person in charge of the product and be willing to follow their lead. This is achieved by gaining the trust of the individuals: exhibiting the right expertise, showing empathy, speaking and acting with integrity, and being reliable and accountable, as I explain in more detail in the article Leading without Being the Boss and the video shown below.

Despite the necessity to practise emergent leadership, the person in charge of the product must be sufficiently empowered. This means that the individual has the final say on tactical and strategic product decisions if no agreement can be reached within the product team. If that’s not the case, leading the stakeholders and dev teams can feel like a Sisyphus job—you work very hard but achieve very little.

Leading as the Head of Product

A head of product is someone who manages a group of product people, individuals who look after a product or a product part—like an end-user-facing feature—and who might be called product managers or product owners. A head of product is responsible for developing the individuals and growing the product management team. This usually includes hiring people, coaching and supporting them, conducting performance reviews, offering promotions, and in some cases, terminating the employment contract, as I explain in more detail in the article What Should a Head of Product Do?. To put it differently, the head of product is the boss of the people on the product management team, and the team members report to the head.

The individual’s power consequently originates from their position. The leadership they exercise has been assigned or granted by the CEO or another executive. It is therefore called assigned leadership.[3]

But great heads of product do not rely on the power that comes with their role. They don’t exclusively practise assigned leadership, and they certainly don’t act as “product dictators.” Instead, they also take advantage of emergent leadership, as Figure 3 shows.

There are two reasons why effective heads practise emergent leadership. First, it helps them build strong, trustful connections with the product team members and create an environment of trust and support. This increases motivation, creativity, and productivity. To put it differently, it’s hard to innovate and have the courage to make and learn from mistakes if you don’t believe that your boss is supportive and understanding.

Second, succeeding as the head of product does not only require the ability to lead the people on the product management team. The individual also has to be able to influence the CEO and the other heads, like the heads of development, sales, and marketing, as Figure 3 shows. This is necessary, for example, to establish an effective product management function and to secure the necessary level of empowerment for the product people as well as to resolve cross-departmental issues—think of sales reps who routinely promise features to customers without first consulting the appropriate product managers.

Cultivating the Right Leadership Skills

As emergent leadership plays a key role in product management, it’s important to develop the skills that allow you to effectively exercise it. These include the following seven capabilities, which I teach in my Product Leadership Training and describe in my book How to Lead in Product Management:

• Trust-building: Be able to earn the trust of others, including senior stakeholders and managers, and use it to influence and guide people.
• Empathising: Understand other people’s feelings and needs and take the perspective of another person even if you dislike or disagree with them.
• Communication: Be able to effectively practise active listening and offer honest but constructive feedback to help people meet agreed goals.
• Goal setting: Determine the right outcomes and capture them in the right way. For example, to set product-related goals you might choose to use my goal-setting framework and my strategy and roadmap templates. Hold people accountable for meeting agreed goals.
• Collaborative decision-making: Leverage people’s collective expertise and secure their buy-in. Know when to delegate.
• Conflict resolution: Successfully address disagreements, resolve conflicts, and repair relationships.
• Self-leadership: Develop a growth mindset, effectively manage your time and energy levels, and look after yourself.

If you want to succeed at leading others, I strongly recommend that you develop these skills. To do so, attend my Product Leadership Training and read or listen to my book How to Lead in Product Management.

Notes

1. I follow Rich Mironov in viewing the four terms as synonyms.

2. See Peter G. Northouse, Leadership: Theory and Practice for more information on the term emergent leadership and see, for example, Tim Herbig, Lateral Leadership: A Practical Guide for Agile Product Managers for the use of the term lateral.

3. See Peter G. Northouse, Leadership: Theory and Practice. Assigned leadership is also called hierarchical leadership.

Listen to the audio version of this article:

Organise the Team around a Product

As the name suggests, a product team is focused on a product. This sounds simple enough. But in practice, organising teams around products can be challenging, especially when a company lacks a clear understanding of what a (digital) product is and if it does not embrace a product-led way of working.

A first step to form effective product teams is therefore to identify the products in your organisation. But what is a product? I view it as an entity that creates tangible value for users and possibly customers as well as the business. The former is achieved by solving a problem or by providing a specific benefit. Think of Google Search, which addresses the challenge of finding information online, and Flickr, which allows people to share photos.

Creating value for the business can be accomplished in three ways: First, by directly generating revenue, like Adobe Premier Pro does, for example; second, by helping promote or sell other products or services, as an online store such as Amazon.com does; and third, by increasing productivity and reducing cost—something an internal software platform achieves, for instance.

Once you’ve identified and selected a specific product, you can take the next step and determine the people who are required to create or progress it and generate the desired user and business benefits.

Involve the Right People

For a team to succeed, it is crucial to have the right people on board. To effectively staff the product team, I recommend including the people shown in Figure 1.[1]

Let’s look at the product team members in Figure 1 in more detail starting with the person in charge of the product. This individual leads the product team, not by being the boss but by exercising emergent leadership. They achieve this by earning the trust of the team members and by embracing the right leadership styles: being a visionary, inclusive, and affiliative leader who empathises with the team members and practises active listening, as I discuss in more detail in my article Leading without Being the Boss.

Additionally, the person in charge of the product must have the necessary expertise. This includes a sound understanding of the market, the user and customer needs, and the competition as well as solid product management skills such as the ability to develop an effective product strategy and an actionable product roadmap (as I explain in more detail in the article The T-Shaped Product Professional).

Finally, the individual must be empowered to decide if no agreement can be reached within the product team. If you are familiar with my work, you’ll know that I am a big fan of collaborative decision-making—finding decisions that everyone can support. However, if the product team members cannot agree, then the person in charge of the product has to have the authority to decide. This avoids that the team is trapped in endless arguments and product decisions are delayed.

The key stakeholders in Figure 1 are representatives from different business units who are required to make the right decisions and effectively implement them. For a commercial product, they might include a marketer, a sales rep, and a customer support team member, as I explain in more detail in the article Getting Stakeholder Engagement Right.

To do a great job, each key stakeholder requires the necessary expertise, authority, and availability to work on the product team. For example, the marketer must be able to create the right marketing strategy for the product. Additionally, the stakeholders must be willing to act as team players, no matter how senior they might be.

Note that including stakeholders on the product team replaces a traditional stakeholder management approach with a much more collaborative one. Instead of sending status reports to stakeholders or having steering committee meetings, the individuals are now actively involved in progressing the product and they actively contribute to its success.

The development team representatives are members of one or more cross-functional development teams. It’s important that they have the right skills to spot and evaluate design and technology opportunities and to develop a rough understanding of the likely effort required to implement product decisions. The skills typically include architecture, programming, testing, and if the product is end-user facing, UX design capabilities.

If the product is too big to be managed by a single person, then the other product people who work with the person in charge of the product should also be on the product team. This ensures that their knowledge is leveraged and that their concerns are addressed. It also maximises the chances that everyone involved in managing the product has the same understanding.

Last but not least, the product team should include a coach who might be an experienced Scrum Master, agile coach, or product coach. Having this individual on board is beneficial, as the product team, as I have described it, is cross-functional and self-managing. It contains people with different roles and skills, and it lacks a manager who tells people what to do. Instead, the team members jointly identify and organise the work required.

All self-managing teams I have worked with greatly benefited from an experienced coach. Conversely, when the role was not properly filled, the teams either took longer to become self-managing or failed to do so altogether. This shows how important the role is. The specific tasks the coach should carry out include helping the team members collaborate, for example, by using a Kanban board, facilitating meetings, and removing blockers and impediments.[2]

Use the Right Goals

A team is, by definition, a group of individuals who work together on the same goal. As Henry Ford once said, “If everyone is moving forward together, then success takes care of itself.” It’s therefore important that you align the product team members by setting the right goals. To help you with this, I’ve created the framework shown in Figure 2.

The goal-setting framework shown in Figure 2 suggests that a product team needs four different objectives: a product vision, user and business goals, product goals, and sprint goals. Let’s take a look at them. The vision describes the ultimate purpose for creating the product and the positive change it should bring about. The user and business goals describe the value the product should create for the people using it and the company providing it.

The product goals communicate the specific outcomes a product should offer, such as acquiring more users, increasing engagement, and generating revenue. Each product goal should help you make progress towards a user or business goal. In a way, the product goal is the most important objective for a product team to achieve strong alignment and effectively progress the product. All product team members should work on the same product goal at a given point in time. This aligns everyone and ensures that the various deliverables and outputs—for instance, the source code, the end-user documentation, the marketing collateral, and the training materials—fit together.

The final goal in the framework in Figure 2 is the sprint goal, which directs the work of the development team members. It is derived from the product goal, and it describes the outcome of the next sprint. Meeting this goal should therefore be a step towards achieving the product goal. You can learn more about my goal-setting framework by reading the article Leading through Shared Goals.

Empower the Product Team

With the right people on board and the right goals in place, we’ve addressed two building blocks of effective product teams. But to become a high-performing team, the group must be properly empowered. Rather than being handed a vision and being assigned user, business, and product goals, I recommend that the product team has the authority to determine the goals—within the boundaries set by the business strategy and, if applicable, the product portfolio strategy. [3] Figure 3 illustrates the team’s ownership of the goals. Additionally, the team should have ownership of the plans that contain the goals: the product strategy and the product roadmap, as shown in Figure 2 above.[4]

If the product team has this level of empowerment, then there are three consequences: First, the team members will have to carry out the necessary work to determine the right goals and develop the right product strategy and roadmap as well as to regularly review and update the goals. This is best done by having regular, collaborative strategy workshops as well as attending sprint review meetings. The latter ensures that the team members have a shared understanding of the development progress and its potential impact on achieving the product, user, and business goals.

Second, the team members should determine the goals together. This is best achieved by using collaborative decision-making techniques including the selection of the right decision rule, for example, using unanimous agreement or consent, as I explain in more detail in my article Making Effective Product Decisions.

The final consequence is that the product team members are collectively responsible for meeting the goals—with great power also comes great responsibility, as all Spiderman fans will know. It’s the job of the product portfolio manager or the senior management sponsor to hold the product team accountable for meeting the goals with the person in charge of the product being the primary point of contact.

Build Trust and Create Psychological Safety

An effective team is not a loose collection of individuals who happen to share a work assignment. It’s a tightly-knit group whose members trust each other. To achieve this, give the product team members the opportunity to get to know each other, for example, by (partly) collocating the team and by carrying out team-building activities. This is especially helpful when the team is new or when its composition has changed. Additionally, as the person in charge of the product, you should lead by example and be willing to trust the other team members. This includes supporting and empowering the individuals, empathising with and actively listening to them.

In addition to trust, a high-performing product team requires psychological safety. People have to know that they won’t be penalised when they make a mistake. That’s particularly crucial when innovation is present, as this requires the ability to experiment, fail, and learn. As Albert Einstein said, “A person who’s never made a mistake has never tried anything new.”

To create psychological safety, be willing to admit mistakes and share stories of your own failures. Additionally, hold people accountable for meeting agreed goals. But don’t lay blame or accuse but empathise with the team members when a goal is not met. Then look into the causes and explore how you can correct the situation and avoid the same issue from recurring, for example, by using my feedback framework.

If you find it challenging to build trust and create psychological safety, consult the product team coach who should be able to advise and support you.

Form the Team Early on and Keep it Stable

The only constant is change, and product teams do change over time. But if the team composition changes too frequently—for example, a new sales rep or marketer shows up every other month—then the team is likely to experience low productivity, handoffs, and loss of knowledge. As pointed out earlier, effective teams rely on trust, and building trust and becoming a closely-knit unit does take time.

You should therefore aim to keep the product team stable. Ensure that the team members understand that they’ll be working on the team for an extended period—months and years rather than days and weeks.

Additionally, form a product team early on in the product life cycle. The team should be assembled in time to carry out the initial discovery and strategizing work. It should continue to exist until the product is discontinued. This fosters long-term thinking and gives the team members the opportunity to develop a deep understanding of the market and user needs, the competitive landscape, and the underlying business model.

Notes

[1] The product team composition shown is influenced by Steven Haines‘ and Marty Cagan’s work as well as team concepts made popular by agile frameworks like Scrum including self-managing and cross-functional teams who are empowered and practise collective ownership. Additionally, it is based on my leadership work, especially my book How to Lead in Product Management.

[2] If you are interested in how a product team as I have characterised it and a Scrum team relate, refer to my article Product Teams in Scrum.

[3] Note that the following list does not contain the sprint goal, as it should be set by the person in charge of the product together with the development team(s), assuming that a Scrum-based process is used.

[4] As you may have noticed I didn’t list the product backlog. Here is why: I find it most helpful to view the backlog as a tool that directs product delivery and that is jointly owned by the person in charge of the product—as well as the other product people on the team in the case of a large product—and the development teams. But I recommend that you connect your backlog to the roadmap by copying the next goal on the next product goal on the roadmap into the backlog, as I explain in more detail in the article The Product Roadmap and the Product Backlog.

Listen to the audio version of this article:

“No Matter How it Looks at First, it’s Always a People Problem”

This quote from Gerald Weinberg nicely summarises a core challenge we face as product people: Our profession is called product management, but the product part can be the easy one compared to the people challenges we sometimes face. Here are four examples:

• Joe, the sales rep, has promised a feature to an important customer without first talking to you—the person in charge of the product.
• Sue, the Scrum Master, wanted to help the development team get better at sprint planning. But the team still over-commits and under-delivers.
• Pete, the marketer, agreed to rework the marketing strategy to support the next major release. To your surprise, you discover that he has hardly made any progress even though the release is only a few weeks away.
• Cindy who helps you manage the product started to come late to meetings. Recently she even missed one without telling you in advance.

It can be tempting to ignore people issues and focus on product-related tasks like reviewing the product strategy, updating the product roadmap, and refining the product backlog. But this is hardly a recipe for success. Problems like the ones mentioned above will hardly go away on their own. Instead, they may even get worse. Consequently, you’ll have to deal with more unsolicited feature requests, poor development team performance, an ineffective marketing strategy, and meetings that are poorly attended—to stay with the examples from above.

It is therefore important that you exercise leadership and address the people issues you are encountering even if this can be challenging and require courage at times. On the positive side, when done correctly, it will not only remove the problems. It will help the individuals involved grow and strengthen your connections with them.

Framework Overview

To help you successfully tackle people issues, structure difficult conversations, and offer constructive feedback, I have developed the framework shown in the picture below. You can download the infographic by clicking on it.

While my framework integrates elements from the CEDAR model, the Situation-Behavior-Impact (SBI) model, and Non-Violent Communication (NVC), I’ve specifically designed it for a product management context where you lead others without necessarily being their boss. The following sections explain how you can apply the framework.

Before You Start

Before you share your feedback, reflect on your intention. Ensure that you want to improve the situation and help the other person rather than acting out of frustration or the desire to retaliate. It would be wrong to label or judge the individual, for instance, thinking of Joe—the sales rep introduced earlier—as a selfish and pushy sales guy who needs to be put in his place. Instead, separate the person from the problem, and focus on the latter.

Additionally, choose the right time and place for giving feedback. Allocate enough time—at least 30 minutes as a rule of thumb. If you find that the issue has triggered difficult emotions like frustration or anger in you, then wait for them to reside before offering your feedback. Finally, consider if it is feasible to meet onsite. If you meet online, make sure that the cameras are switched on and that you can clearly see each other.

Step 1: Connection

Prior to discussing the issue, take some time to check in with the other person. Ask them how they are and what’s going on for them. This allows you to empathise and build trust with the individual. This, in turn, will have a positive impact on the conversation, and it will make it easier to share difficult feedback.

You might say, for example: Hi Joe, it’s been a while. How are you doing? Have you been travelling lately?

Step 2: Objective

Describe the desired outcome of the meeting and state the context in which the issue occurred.

You might say: Thanks for making time to meet with me, Joe. I want to talk to you about the feature request you recently raised and the impact it’s had. I also want to discuss with you how we can improve the way we handle feature requests in the future.

Step 3: Issue

Next, address the issue. But rather than telling the other person what’s wrong and what you want them to do differently, ask them to share their perspective. What did they observe? What is their version of what happened? And how are they feeling about the issue? Listen attentively with the intention to understand. This shows the other person that you are interested in what they have to say, and it ensures that you take in all the information.

You might ask Joe: How did the feature request come about Joe? How did you experience the conversation with the customer and the following interaction with me?

Then describe your observations. Stick to the facts. Don’t judge, blame, or accuse. Be kind but frank. Don’t generalise, sugar-coat, or exaggerate. State the impact that the issue has had including the feelings it has triggered in you.

You might say: Thanks for sharing your perspective, Joe. I was very surprised and a bit shocked, to be honest, when I heard that you had told the customer that we would offer the feature in the next release. I can still feel some frustration now when I think about it. It put me in a very difficult situation. As we could not afford to disappoint the customer, I had to change the agreed product goal and consequently deal with complaints from the dev teams and some of the other stakeholders.

Step 4: Causes

Once you’ve shared observations, determine the issue’s underlying causes. Create a shared understanding of why the problem occurred. Find out what caused the other person to act the way they did, and what drove their behaviour. What were their underlying goals and needs?

You might say: Joe, you regularly talk to our major customers. Is there a reason why you weren’t aware that the customer wanted this feature when we met to agree on the outcome of the next release and the functionality it should provide?

Step 5: Actions

Determine the actions required to address the causes and improve the situation. Encourage the other person to come up with suggestions rather than telling them what to do. You might ask questions like “What needs to be done to stop the issue from recurring?” and “What will you do differently in the future?” Additionally, clearly state the actions that you want them to take and share the changes you are willing to make. The latter shows that you are willing to contribute to solving the issue and change your own behaviour if necessary.

You might say: I’d like to ask you to stop mentioning feature ideas to customers and instead, focus on their needs when you talk to them about future product versions. I’d also like to ask you to always talk to me first before you promise something to a customer. I’ll do my best from now on to schedule the product planning meetings so that you can attend them and share your insights from customer meetings, and I’ll explicitly check with you and the other attendees that you agree with the decisions.

Step 6: Closure

Wrap up the conversation and close the meeting. Ask the other person how the conversation went for them, how they are feeling right now, and if the meeting was helpful. This allows you to get better at offering constructive feedback in the future.

You might say: Thanks for the open and constructive conversation, Joe. I am glad that we sorted things out, and I am pleased with the actions we’ve agreed on. How did the meeting go for you? 

If you did not manage to develop a shared understanding of the causes and if you failed to agree on actions, then you are likely to experience conflict—a serious disagreement with an element of adversary. If this is the case, I recommend recognising what’s happening and scheduling a follow-up meeting to resolve the conflict.

You might say to Joe: It seems to me that we can’t agree on what happened and why it happened. It’s important to me that we address the disagreement. But it would be too much to do now. Let’s please schedule a follow-up meeting.

Listen to the audio version of this article:

The Head of Product Role in a Nutshell

A head of product manages a group of product people—individuals who look after one or more products and who may be called product managers or product owners. Depending on the company size and org structure, the role might also be referred to as Director of Product Management, VP Product, and Chief Product Officer. Working as a head of product includes the following three duties, as I discuss in more detail in the article What Should a Head of Product Do?

First, develop the individual product people. For example, ensure that the individual’s role and responsibilities are clear; help the person grow as a product professional, be it by coaching and mentoring them or by encouraging them to attend training courses; offer clear and helpful feedback and hold them accountable for meeting agreed goals.

Second, develop the product management team. For instance, help the members collaborate, establish shared standards including product management processes, methods, tools, and templates; communicate strategic business objectives; and hire new product people.

Third, develop the organisation. For example, ensure that the individual product people are sufficiently empowered to succeed in their roles and establish a product-led way of working.

What Happens When the Head of Product Determines the Product Strategy?

As you might have noticed, the list above does not mention determining the product strategy. Here is why: When a head of product determines the product strategy on a regular basis, then this is likely to cause the following two issues.

First, the product people don’t have full ownership of their products. Instead, they are focused on the tactics/delivery. In the worst case, they are product backlog managers and user story scribes. This can lead not only to low motivation and high turnover. It can also give rise to what I call a strategy-delivery chasm: Strategic decisions are not effectively translated into tactical ones, and insights from the delivery work are not used to evolve the strategy.

Second, the head of product turns into a bottleneck and/or becomes overworked. As the products grow and as new people are added to the product management group, the workload of the individual rises. But there is only so much work someone can cope with, and being overworked for an extended period of time leads to low productivity, mistakes, and health issues.

There is, however, a situation when it makes sense for the head of product to determine the product strategy: when the individual is a contributor who manages a product in addition to leading the product management team. This can be an effective short-term fix, for example, to compensate for the lack of experienced product people on the team. But as a permanent solution, this approach is not advisable: It is likely to cause the second of the two issues mentioned earlier.

How the Head of Product Can Help Achieve Product Success

If a head of product should avoid making strategic product decisions, how can the individual then ensure that a product creates as much value as possible? Here is my answer: By enabling and empowering the product people to own the strategies of their products. The following four measures will help with this:

First, develop the individual product people through training, mentoring, or coaching. This includes securing the necessary training budget and selecting the right training courses, as well as creating a training-on-the-job program, attending product strategy workshops as a stakeholder, and acting as a sparring partner for strategy-related questions. Note that this assumes that the head of product has the expertise required to offer the right advice—which I regard as a prerequisite for taking on the role.

Second, help create shared standards to facilitate collaboration amongst the product team members. Agree on how a product strategy is described and in which tool is it captured; how it is validated; how often it is reviewed; and to which extent stakeholders and development team members are involved in the process. You might decide, for example, to follow my approach, use the product vision board to describe the product strategy, iteratively validate an initial strategy, review the plan at least every three months, and carry out the work collaboratively by involving the key stakeholders and dev team representatives.

Additionally, decide how products are managed that require more than a single product person. For instance, you might choose to have one overall product manager/owner and additional product people who look after product parts like end-user facing product capabilities/features.

Third, make sure that the product portfolio is proactively managed, that the individual product strategies and product roadmaps are harmonised, that major releases are coordinated, and that dependencies and conflicts between the products are addressed. For smaller portfolios, the head of product can typically carry out the portfolio management work. For larger ones, a dedicated product portfolio manager should do the work, join the product management team, and report to the head of product. This avoids the risk that the head of product becomes a bottleneck or overworked.

Finally, ensure that the product people are aware of and understand the business strategy together with the overarching business objectives that constrain the strategic product decisions. To do this, participate in creating, reviewing, and updating the business strategy as part of the leadership/executive team and communicate the plan to the product management team.

Summary

As the head of product, avoid determining the strategy for an individual product on a permanent basis. Instead, empower the product people you lead to make the strategic product decisions. Offer advice and feedback. But let the individuals own the product strategy and hold them accountable for maximising the value of their products. Additionally, ensure that the product portfolio is managed, and that the business strategy is clear to everyone on the product management team. This way you’ll support the individuals and help them do a great job.

Listen to the audio version of this article:

The Need for Guidance and the Lack of Transactional Power

Product success is not something you can achieve on your own as a product manager or Scrum product owner. Instead, you rely on the contributions and the support of the key stakeholders, the development team members, and possibly other product people who help you manage a large product. For example, a marketer has to create the marketing strategy, and the development teams have to design and build the product.

What’s more, all deliverables must fit together to achieve the desired outcome. For instance, the marketing strategy, the user experience (UX) design and technology choices have to align to successfully acquire new users, increase conversion, or meet another product goal. Consequently, the stakeholders, development teams, and product people require guidance and alignment—they must all move together in the same direction and work on the same overarching goals, as the picture below illustrates.

On top of everything, you are usually not the boss, and the individuals in the picture above don’t report to you. You therefore lack transactional power: You cannot tell people what to do and make them follow your decisions, and you typically cannot offer a bonus, pay raise, or other incentive. To make things worse, some of the stakeholders might be more senior than you. How can you then effectively guide and align them?

Influence and Trust as Leadership Building Blocks

Effectively leading others requires that they trust you. To trust someone means to have faith in the person, believe that their intentions are good, feel safe in their presence, and be comfortable to speak one’s mind.

Once you have earned someone’s trust, the person will be open to your suggestions and advice. This, in turn, enables you to influence the individual and help them achieve the desired product outcome.

If the opposite is true, and someone doesn’t trust you, then they are unlikely to follow your lead. They will be inclined to do what they believe is right. This may result in people moving into different directions and producing deliverables that don’t create the desired value. Gaining the trust of the stakeholders, dev teams, and other product people is therefore vital so you can effectively align and guide them and achieve the desired outcomes.

It’s important for me to point out that effective leadership must be based on the intention to support the people you want to lead, not on the desire to control or manipulate anyone. The influence you exercise should therefore be a positive one, see my article Should Product People be Servant-Leaders?

What’s more, there is not one right way to lead. For example, groups that haven’t worked together require a different leadership approach compared to those that have developed into a closely knit unit, as I discuss in more detail in the article How to Choose the Right Product Management Leadership Style.

Measures to Build Trust with Stakeholders, Dev Teams, and Other Product People

As trust is crucial to lead without being the boss, it’s important that you take the right steps to earn the trust of the stakeholders, the development team members, and other product people. The following nine measures will help you with this.

Empathise

Take a kind and warm-hearted interest in the people you want to lead, their views, feelings, and needs, as well as the goals they want to achieve. This allows you to better understand them, and it shows the individuals that you care about them, which encourages them to trust you. Attentively listening to people with an open mind and getting to know them will help you empathise, as I discuss below. You can find more guidance on empathy in my article Empathy in Product Management.

Get to know people

Learn about the individuals’ job role with its specific demands and challenges, their backgrounds, family situations, and interests to better understand why somebody thinks and acts in certain ways. This, in turn, increases your ability to empathise and to earn the trust of the person. There are many ways how you can get to know people and build effective relationships. These include having informal chats over a cup of coffee or at lunch as well as organising team building activities.

Practise active listening

Give people your full attention and listen with the intention to understand when you are in a conversation with the stakeholders, development team members, and your product management colleagues. This makes people feel valued, and it encourages them to be open and trustful with you. You can find more guidance on active listening in my article Listening Practices for Product People.

Cultivate an open mind

Be respectfully curious and open-minded. Don’t prematurely judge an idea or reject an individual’s concern. Be grateful for someone’s contribution, even if you disagree. This shows people that you value their ideas and that you are interested in their views and needs. Additionally, it makes it more likely that you’ll receive everything that is being said instead of suffering from confirmation bias and ignoring information that does support your views and ideas.

Speak and act with integrity

Be truthful and do what you say. Honour your commitments and don’t make promises you cannot keep. Admit if you are wrong. This tells people that you are honest, reliable, and trustworthy.

Involve people in product decisions

You might do this, for example, by running collaborative product strategy reviews. Be transparent, share the relevant information, and appreciate the individuals’ suggestions—without making the mistake of saying yes to every idea. Practising collaborative decision-making shows that you value people’s input and care about their views and needs. Additionally, it increases their commitment to implement the decisions, as I discuss in more detail in the article Making Effective Product Decisions.

Be supportive and offer help

Whenever that’s possible and appropriate. For example, make time during the sprint to answer urgent questions from the development team members. Ensure, though, that you help people become self-sufficient as quickly as possible, address any underlying issues, and don’t take on additional roles.

It would be a mistake, for instance, to keep answering questions during the sprint instead of involving the team members in the product backlog refinement work and helping them acquire the appropriate knowledge. Similarly, it would be wrong to fill a vacant Scrum Master role and carry out the role’s tasks like organising sprint meetings and coaching the development teams.

Deepen your expertise

The better you are at product management and the more you know about the market and users of your product, the greater the chances are that people will agree with your suggestions, trust your advice, and follow your lead. Becoming a t-shaped product professional and using a learning roadmap to develop your skills will help you with this.

Secure the right management backing

When management supports and trusts you, others are more likely to do the same. Conversely, it’ll be harder to lead the stakeholders and development team members when you lack management sponsorship. If that’s the case for you, explore how you can earn management’s trust. The measures discussed above should help you with this.

Additionally, consider asking your Scrum Master to help you address the issue, especially if product management is new to the organisation or if its maturity is low. Remove impediments and facilitating organisational change should be part of the Scrum Master’s job, as I discuss in more detail in the article Why Product Owners Need Effective Scrum Masters.

Listen to this article:

What is Empathy and What is It Not?

Empathy is our capacity to understand other people’s feelings and needs, to take the perspective of another person. Empathy entails a warm-hearted, open, and kind attitude. This does not mean, though, that you must like the other person and that you must be happy and smiley all the time—nor does it mean sugar-coating messages, only telling people what they want to hear, and putting up with issues. The opposite is true: You can empathically address unhelpful and inappropriate behaviour, as the following example shows.

Imagine that John is a sales rep and a key stakeholder who hardly ever attends the product strategy workshops you’ve invited him to. Instead, he requests product roadmap changes by talking directly to you. You should then consider asking John to change his behaviour and attend the strategy sessions to share his change requests. But act in an empathic way: Find out first what’s going on with John and try to understand why he missed the meetings. It might be that he is overworked and short of time or that there is an ongoing conflict with one of the other stakeholders that makes it difficult for him to participate in the workshops. At the same time, be frank. Don’t beat around the bush but make a clear and specific request once you’ve found out what drives John’s behaviour.

Note that it’s easy to confuse projection with empathy: The former means making assumptions about what the person should feel according to some preconceived ideas—for example, believing that someone who speaks loudly wants to dominate and take over a meeting. Empathy, however, implies developing an understanding of what is really going on for the other person. In the example just mentioned, the individual might have an odd communication habit and a general tendency to speak loudly, or the person might raise their voice because the individual is upset, not because they want to dominate.

Why is Empathy Important in Product Management?

While empathy is a fundamental human quality, there are three reasons that make it particularly valuable for product people. First, empathy is the foundation for effective leadership. It creates trust and psychological safety, and it allows you to influence others and encourage change. That’s key for product people who lack transactional power, who are not the boss of the stakeholders and development teams, but still have to guide and align the individuals to achieve product success.

To put it differently, becoming more sensitive to other people’s feelings and needs will increase your ability to lead them. Note, though, that the empathy you show must be authentic. If you pretend to care or if you empathise only to get someone to do something, people will sooner or later realise what is going on and they are likely to lose trust in you.

Second, empathising with users and customers helps you develop a deeper understanding of their needs. While we have more data and more powerful analytics tools available today than ever before, I find that reaching out to selected users and customers with respectful curiosity and genuine warm-heartedness—for example, by observing how they get a job done and talking to them about their experience—is crucial to truly understand what they want and need. This, in turn, enables you to make the right product decisions, which makes it more likely to offer a successful and ethical product.

Third, showing empathy towards yourself and cultivating self-compassion helps you be a happier person. It strengthens your ability to empathise with others, and it avoids the risk of overlooking your own needs and, for instance, regularly working too hard—which is an easy mistake to make, given that most product people have a demanding job. But being overworked and stressed is counterproductive. It can lead to a drop in productivity and motivation, and it can harm your mental health. Practised correctly, self-compassion will help you balance your own needs and the needs of others so that neither are neglected.

How Can You Strengthen Your Empathy?

We all have the ability to empathise. But how strong it is, varies significantly. Not everyone we meet is a highly empathic person. What’s more, it is easy to empathise with someone we like and who we agree with. But if we are dealing with a “difficult” stakeholder, customer, or team members, developing an open, warm-hearted attitude can be challenging. The following four techniques will help you increase your capacity to empathise with others.

Practise Active Listening

Listening is not only crucial to have a successful conversation. It is key to understand someone’s feelings and underlying needs. To achieve this, listening has to take on an active, engaging quality. You have to listen with the intention to understand the other person, no matter if you like or dislike the individual and if you agree or disagree with their views. This requires you to give your full attention to them, develop a genuine interest in what they have to say, be respectfully curious, and cultivate an open mind—which I’ll discuss in the next section in more detail.

What’s more, you should listen not only to what is being said, but also pay attention to the body language including voice pitch and volume, facial expressions, and gestures. These often reveal the person’s feelings, for example, if someone speaks loudly and has a red face, they are upset or excited, no matter how carefully they mince their words. Feelings, in turn, are gateways to the underlying needs, interests, and motives. To discover them, consider using open-ended, non-directive questions. You might say, for instance, “Can you please tell me why this is important to you?” You can find more guidance on how to listen effectively in my article Listening Practices for Product People and in my book How to Lead in Product Management.

Cultivate Curiosity and Open-mindedness

Attentively listening to someone and empathising with them is difficult if you are strongly attached to preconceived ideas and beliefs. For example, if John, the sales rep mentioned earlier, has come up with unhelpful suggestions for product roadmap changes in the past, then it is easy to label him as incompetent and annoying and to no longer pay full attention to what he says.

But this does not only reduce your ability to understand and connect with the individual. It also risks ignoring a suggestion that might turn out to be a good idea. It is therefore helpful to develop an open, curious mind and take a real interest in what the other person has to say, how the other person is feeling, and what their underlying needs are. This does not mean, of course, that you cannot or should not have any opinions. But do hold your views lightly and be willing to challenge them.

Walk in the Other Person’s Shoes

Empathising with someone requires the ability to take the perspective of the other person, to see things through their eyes. You can achieve this by walking in the individual’s shoes and sharing their experience.

You might, for instance, shadow users to better understand how they get a job done and what they might be struggling with; you might visit selected customers with John, the sales rep mentioned earlier, to learn more about his job and the challenges and pressures he is facing—as well as the customers you visit; or you might pair with one of the product people on your team to find out why they struggle to select the right KPIs for their product and how you can best help them.

Sharing someone’s experience can truly be an eye opener. It can help you cultivate an open, receptive mind and better understand people’s feelings and needs.

Practise Self-compassion

It’s hard to empathise with others and cultivate an open, warm-hearted attitude if you are not kind to yourself. To be more self-compassionate, follow these four recommendations:

First, don’t expect to always succeed and get everything right. Don’t beat yourself up when you make a mistake; don’t be overly self-critical and have unrealistic expectations of yourself. Recognise that mistakes and failure are part of developing new skills as well as bringing new products and features to life. As Albert Einstein said, “A person who never made a mistake never tried anything new.” Look at yourself with kindness without being complacent and ignoring any shortcomings you might have.

Second, don’t sacrifice your own needs but look after yourself at work. Practise sustainable pace, stick to standard working hours, and take regular breaks. Consider delegating some tasks. For example, ask the development team members to refine (some of) the user stories and carefully choose the meetings you attend. Additionally, focus on your product role and don’t take on responsibilities that are not part of your job, such as, coaching a development team or teaching Scrum to the stakeholders. Make sure that you get the support you need and that you have, for instance, an effective Scrum Master at your side. Otherwise you are likely to become overworked or neglect important, non-urgent duties such as product strategy work—neither of which is desirable.

Third, make regular reflection part of your work. Allocate thirty minutes in your calendar towards the end of each work week and ask yourself the following three questions, which are based on my book How to Lead in Product Management:

• What did I get done this week? Which challenges and difficulties did I encounter? What did I learn?
• How am I feeling right now? How did my moods and energy levels develop during the week?
• What changes do I want to make next week so I can be more productive and happier at work?

Fourth, consider meditating to develop a heightened awareness of how you are feeling. For example, are you relaxed and content, or are you tense and stressed? If you find that you are getting increasingly tense, then this allows you to investigate why this is and make the necessary changes, for example, stop working extra hours. Noticing your mental states without judgement and blame will not only help you understand yourself better and be more effective at work. It will also increase your self-compassion and mental wellbeing.