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:

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:

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:

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

The Head of Product Role

A head of product is someone who manages a group of product people—individuals who look after one or more products and who may be called product manager or product owner. Depending on the size and org structure of your company, the role might also be referred to as Director of Product Management, VP Product, or Chief Product Officer.[1]

As the head of product, you play a key part in developing the people on your team, creating an environment that helps them succeed, and improving the effectiveness of the product management function in the enterprise.[2]

The responsibilities I share below are based on my work with product leaders and product practitioners. To make the duties more accessible, I have grouped them into four sets: people management, processes and tools, business strategy and organisational development, and self-leadership. Note that I have kept the description of the responsibilities concise. To learn more, please follow the links in the text.

Be aware that there is no one right way to apply the head of product role or a golden standard for doing the job. You should therefore tailor my recommendations to your team and organisation. The best way to do this is to ask the people on the product management team how you can effectively support them.

People Management

• Create an environment where people feel valued and able to speak their minds. Genuinely care about the individuals on your team and show appreciation for their efforts. Practice active listening, empathise with the team members, speak and act with integrity, and build strong, trustful connections. Give people a choice about the products they work on, for example, by using self-selection. This increases motivation and it shows the team members that you value them.
• Ensure that the product management roles are well defined and understood by all team members. Clearly state the authority, responsibilities, and necessary skills of each role. Involve the team member in describing the roles. This leverages their expertise, creates a shared understanding, and shows them that you value their input.
• Make sure that the product people have the authority and autonomy they need to succeed in their jobs. Individuals who manage products should have full-stack ownership and be empowered to make not only tactical product decisions but also strategic ones. Additionally, ensure that the products are loosely coupled so that they can be effectively progressed and not held back by dependencies.
• Set clear expectations and agree on specific, measurable, and outcome-based goals. Having well-defined roles in place will help you with this, as I’ll discuss below.
• Hold people accountable to meet the agreed goals. Use, for example, the CEDAR model and appreciative inquiry techniques to offer feedback in the right way and help people get back on track.
• Develop the individuals on the team. Help them get better at product management and grow as product professionals. You might achieve this by having regular one-on-one meetings, mentoring and coaching the individuals as well as recommending suitable training courses. Don’t forget to capture the learning and development measures, for example, on a learning roadmap.
• Establish clear career paths to retain team members and show them how they can advance their careers. For instance, someone might start as an associate product manager, then move into a junior and subsequently into a senior product manager role, next become a portfolio manager and finally a head of product.
• Encourage a growth mindset and create a failure-tolerant environment where experiencing setbacks and making mistakes is seen as a necessary part of learning new skills as well as bringing new products and features to live. One way to do this is to share failure experiences from your career.
• Remove impediments the team members face and act as an escalation partner for problems the individual product people cannot solve. Examples are excessive red tape and the lack of qualified Scrum Masters.
• Help the team members practise sustainable pace so they don’t sacrifice their wellbeing but stay healthy and motivated. For example, encourage people to take regular breaks from work and don’t expect them to work extra hours, at least not on a regular basis.
• Grow the product management team. This includes creating job descriptions and interviewing candidates. A great way to develop the team is to organise around products, as I discuss in more detail in the article Tips for Growing a Product Management Team.

Processes and Tools

• Help establish the right product management processes. For example, agree with the team members on what goals should be used to manage the products, how the product strategy work is done, how often the product strategy and roadmap are reviewed, how the right KPIs are selected, and how product backlog refinement is carried out.
• Facilitate the selection of the right product management tools, for instance, to capture the product strategy, to describe the product roadmap, and to manage the product backlog.
• Help the people on your team continuously improve their way of working. Set some time aside once per quarter to collaboratively review the roles, processes, and tools, discuss any issues and improvement ideas, and adjust them accordingly.
• Ensure that the product portfolio—the group of products the team members look after—is effectively managed. This includes setting strategic goals for the portfolio, balancing the group of products, managing dependencies between products, and aligning release dates. As the head of product, you might be able to carry out this work, especially if the portfolio is not too large. If that’s not the case, hire a dedicated product portfolio manager who carries out the work.

Business Strategy and Organisational Development

• Contribute to the business strategy. Ensure that the plan is realistic and share it with the product people on your team. This will help them understand the direction the business is heading in and the strategic objectives the entire business is following.
• Represent the product management function on the leadership team (when you act as a Director of Product Management, VP Product, or Chief Product Officer), and build strong connections with the other heads, for instance, head of development, head of marketing, and head of sales.
• Lobby for the necessary organisational changes to fully establish an effective product management function, if required. This may include securing the necessary empowerment for the product people on your team and establishing a product-led way of working.

Self-Leadership

• Look after yourself. Ensure that your workload is sustainable and that you stay healthy and motivated. There is no point in doing an amazing job for your team and company but being constantly overworked. Cultivating mindfulness will help you spot early signs of stress so you can quickly respond and adjust your work. Developing self-compassion will help you being kind towards yourself. It avoids being overly self-critical and expecting too much of yourself.
• Take time to reflect on your own work. Identify ways to strengthen your skills, develop as a leader, and get better at guiding and supporting others. For instance, you might decide to address a lingering conflict, change your leadership style, or make a focused effort to practice active listening.
• Invest in your own career development and determine the measures that will help you take the next step.

Notes

[1] See Rich Mironov, “Hiring a Head of Product.”

[2] This approach is inspired by Esther Derby’s work, which builds on Kurt Lewin insight that the behaviour an individual shows is the result of the person and the environment, see “Skills Are Only Half the Equation for Success.”

Listen to this article:

Why the Scrum Team is Not Enough

Scrum is a popular agile framework. Its strength is, at least partly, based on its roles with the Scrum team being the fundamental unit. This team consists of a product owner, a Scrum Master, and several developers, which are also known as development team. Forming such a team connects the person in charge of the product—the product owner—with the people who design, architect, program, test, and document the solution—the developers. It encourages direct interaction and close collaboration between them.

But what Scrum lacks, in my mind, is a way to involve the key stakeholders, especially in strategic product decisions. That’s understandable, as the framework is focused on the development of complex products. But from a product management perspective, effectively engaging the stakeholders is crucial to achieving product success. Here is why:

• As the person in charge of the product, you typically require the stakeholders’ expertise to make the right product decisions. You might not know, for example, which marketing strategy is most appropriate or which sales channels are most effective. Consequently, you’ll benefit from the input of a marketer and a sales rep.
• You need the stakeholders’ support and contribution to successfully progress the product. The marketer might have to create or update the marketing strategy; the sales rep might have to adapt the sales channels, for instance.

As the Scrum product owner, you should therefore establish close and trustful connections with the key stakeholders, collaborate with them, and involve them in important product decisions on a regular basis.

Introducing the Product Team

A great way to achieve this is to form a product team, as shown in Figure 1.

The product team in Figure 1 consists of Scrum team members and key stakeholders. The latter are those business stakeholders whose expertise and buy-in you need to make the right product decisions and achieve product success, as I explain in the article Getting Stakeholder Engagement Right. For a commercial, revenue-generating product, the key stakeholders might include a marketer, sales rep, and customer service rep, for instance. Consequently, a product team is a cross-functional group that comprises everyone required to progress the product and achieve product success.

Forming such a team facilitates direct interaction and close communication between the product owner, the key stakeholders, the development team members, and the Scrum Master. Rather than talking to stakeholders on a one-on-one basis and possibly trying to negotiate a compromise between them, you literally bring the right people together and invite them to share their ideas and concerns with the entire group. This creates a shared understanding and a sense of togetherness, assuming that the group interactions are facilitated well.

Note that the term product team is used in different ways by different people—much like other product management expressions. Some fellow authors include the stakeholders, for instance, Steve Haines in his book The Product Manager’s Desk Reference, whereas others don’t, for example, Marty Cagan in his book Inspired. I believe that the first definition is more helpful, especially in an agile context.

Tips for Forming Effective Product Teams in Scrum

As the product team is meant to be a proper team, a group of people who work towards shared goals and who trust and support each other, you should carefully setup and guide such a team. The following six tips will help you with this.

1. Organise around a product. A product team is best formed around a product . This supports a product-led approach, and it makes it more likely that the team has the necessary autonomy to effectively progress the product.
2. Form the product team early on, ideally when you are about to carry out the initial product strategy work for a new product. The team members should stay together for an extended period, preferably for the entire product life cycle. This creates stability and continuity. It allows people to get to know each other, build trust, and work together effectively; and it avoids costly handoffs and loss of knowledge.
3. Bring the members together on a regular basis, be it online or onsite. Invite the individuals to product strategy review meetings and sprint reviews. This ensures that the members are involved in strategic and tactical product decisions and have a holistic understanding of how the product is evolving.
4. Invest in team building. This does not necessarily have to involve big days out. Having coffee or lunch together and checking-in at the beginning of meetings can be effective ways to help people get to know each other. Without sufficient trust, people will struggle to work together well.
5. Align the product team members through shared goals. Use a product vision; a product strategy with user needs and business goals; and a product roadmap with product goals (aka. outcomes). Involve the team members in setting, reviewing, and adapting the plans and goals. Finally, don’t forget to hold people accountable for meeting them, assuming that they have agreed to them.
6. Ask the Scrum Master to support you. This includes facilitating joint meetings and helping you address issues that might arise such as disagreements and conflicts.

Product Teams in Scaled Environments

If you work on a large product that is developed by several teams, you can form a product team by involving representatives from each development team as well as the other product people who manage the product together with you. Figure 2 illustrates this approach.

The product team in Figure 2 includes two feature owners and representatives from the development teams in addition to the overall product owner, stakeholders, and Scrum Master. As a rule of thumb, involve two people from each dev team who are nominated by their peers. This avoids the risk that the product team grows too big and that working together and practising collaborative decision-making becomes too challenging.

If you find that you still end up with a product team that is significantly larger than twelve people, then investigate if all stakeholders on the team are truly players and if there is an opportunity to de-scale, to reduce the size of the product and the corresponding product team, for example, by unbundling features or creating product variants, which are techniques that I explain in my book Strategize.

Listen to this article:

What the Scrum Master Should Do

While the role is discussed in many books and articles, I find that it is still not always correctly understood. What’s more, it’s not uncommon in my experience that product owners have to do their job without the support of a Scrum Master or agile coach.

So why is the role important? I view the Scrum Master as someone who takes care of process, collaboration, and organisational change issues. This includes the following six duties:

• Roles: Ensure that the right roles are in place and their authority and responsibilities are clear to everyone. This includes product roles such as product owner and feature owner.
• Staffing: Help find people who have the right skills and are motivated to work on the product and who can fill the roles. For example, I’ve seen organisations where the Scrum Masters work with HR and the development teams to recruit new team members.
• Process and collaboration: Teach agile values, principles, and practises to the product owners, development teams, stakeholders, and management. Help people use the right processes in the right way; help them discover ways to improve their work, for instance, in the form of sprint retrospectives.
• Productive work environment: Help set up an environment that is conducive to creative teamwork and encourage people to practice sustainable pace—to do a great job without getting overworked, losing motivation, and falling ill. Ensure that people have the infrastructure and tools they need to do a good job. This includes laptops, tablets, phones, and software tools; but it may also include having access to a kitchen and a coffee machine.
• Organisational change and empowerment: Work with senior management, HR, and other business groups to implement the necessary organisational changes required to fully empower product people and leverage agile practises.
• Meetings: Prepare and facilitate meetings. This includes sprint planning, Daily Scrum, sprint review, and sprint retrospective, as well as product strategy and product roadmap workshops. Establish ground rules and ensure that everyone is heard, and that nobody dominates.

Having an effective Scrum Master allows you to focus on your job—to maximise the value the product create. It avoids that you get too involved with people, process, and organisational issues. A Scrum Master can also be a sparring partner for you—someone who you can discuss concerns with and who offers helpful feedback.

You can think of the product owner and Scrum Master as two complementary roles in Scrum: the former is responsible for product success and the latter for process success. And without the right processes in place, it is hard to maximise value creation on a continued basis.

What the Scrum Master Should NOT Do

In theory, your Scrum Master should focus on providing people and process leadership. In practice, however, Scrum Masters sometimes take on duties that do not belong to the role, including the following three ones:

• Project management: The Scrum Master is not a project manager, even though that’s a common misunderstanding. The individual should neither identify and assign tasks nor create reports like a release burndown chart, for example. Instead, the person should teach the Scrum product owner and development team how to how to proactively manage a sprint and a release, respectively.
• Product backlog work: Keeping the product backlog up to date is a responsibility the Scrum product owner and development team share. But it’s not the job of the Scrum Master. You should therefore not expect that your Scrum Master refines the backlog for you. The individual is not a product backlog manager or a user story writer. The same is true for setting product goals. An effective Scrum Master will remind you to select product goals, but the individual won’t do it for you.
• Team management: The Scrum Master should not manage the development team. Instead, the individual should help the team practise self-management so that the members learn to make realistic commitments and work together effectively.

You can view the Scrum Master as an enabler or a coach, as someone who helps others understand how they can create a valuable product rather than doing the work for them.

Dealing with a Non-existent or Ineffective Scrum Master

As I mentioned earlier, it’s not uncommon in my experience that there is no Scrum Master at all or that the role is not effectively applied. But as the Scrum Master work is important, someone else usually steps up and takes on the duties. Often, that’s you, the person in charge of the product. While it’s great to care about the development team and the process, taking on Scrum Master duties in addition to your other work is a bad idea for the following three reasons:

1. Taking on more duties is likely to cause you to be overworked or to neglect some of your product management responsibilities. In the first case, your creativity and health will suffer. You are more prone to make mistakes and choose wrong product decisions. In the second case, non-urgent but important work like continuous discovery and strategizing is often scarified. Sadly, this usually creates more work for you in the future. You might even have to deal with an emergency, as you desperately try to catch up with competitors or adjust to new trends, which you had missed.
2. It takes time to acquire the necessary Scrum Master skills, such as facilitating organisational change or building productive teams. It’s usually not something you can learn within a few days or by attending a single training course. Consequently, I prefer to work with professional, full-time Scrum Masters who carry out their jobs for an extended period, who are able to deepen their skills and develop the necessary expertise.
3. If you seem to be able to take on the Scrum Master role, then there is little need for your company to hire or develop Scrum Masters. Think about it: If management sees that you apparently cope without a Scrum Master, then why should they change anything? Trying to help might therefore mask a systemic problem and organisational impediment, rather than making it obvious.

Therefore, if you don’t have a Scrum Master or if the individual is not able to do an effective job, then don’t take on the role—certainly on for an extended period. Instead, address the problem and its causes. In the first case, consider how you can help the decision makers in your company understand that Scrum Masters are not optional but mandatory to foster an agile way of working and to support product people and their development teams.

That’s not only true during an agile transition, but it also applies to organisations that have used agile practises for some time. This ensures that product owners, development teams, and stakeholders receive support on a continued basis. Personally, I find it simply unfair to ask someone to be a Scrum product owner without ensuring that the individual has an effective Scrum Master to partner with.

If you have a Scrum Master, but the individual’s work is ineffective, then explore the causes. For example, the Scrum Master might be stretched and does not have enough time to do a good job; the person might lack the skills to be effective; or there might be conflict between the Scrum Master and the development team members or yourself.

Whatever the cause might be, talk to the Scrum Master. Share your observations as objectively as possible without judgement or blame, and actively listen to the Scrum Master. This will allow you to understand their perspective and empathise with them. Offer your help when possible and be willing to change when that’s necessary. If the Scrum Master is not willing to adjust their behaviour, though, then it might be best to find another person who can play the role and is more effective at supporting the dev team, product owner, stakeholders, and the wider organisation.

Listen to this article:

Overview of the Learning Roadmap

Like a modern product roadmap, a learning roadmap states the specific outcomes or benefits you’d like to achieve to become a more competent product person, and it captures them in form of learning goals. These help you direct your learning efforts, track progress, and measure how much you have learnt. To make these ideas more concrete, let’s look at a sample learning roadmap.

The roadmap in figure 1 is based on my GO product roadmap template. It contains the following four rows: [1]

• The first row describes when the learning goals should be met for the next 12 months. I’ve chosen quarters in the sample roadmap above, but you can use shorter time frames, of course, if you can meet your learning goals more quickly.
• The second line names the skills areas the learning goals belong to, which I’ll cover in more detail in the next section. For the first two quarters, the area is strategy; for the last two, it is leadership.
• The third row contains the most important information. It lists the learning goals you want to achieve. The first goal is about creating a new strategy, the second one talks about the product life cycle model, the third one covers decision-making, and the last one addresses active listening.
• The fourth and final line states how you intend to meet the learning goals. In the roadmap in figure 1, I listed the key topics to be addressed and the learning measures that will be used to acquire and deepen the skills. Note that you may want to make the measures as specific as you can and state, for instance, the title of the books you intend to read.

A learning roadmap like the one above offers four benefits: First and foremost, it gives you a goal-directed plan that focuses your learning efforts. Many learning plans I have seen were lists of learning measures. They lacked clear, achievable learning goals that built on each other and described a meaningful learning journey. Second, a learning roadmap allows you to leverage your product roadmapping skills and use them to create an actionable learning plan. For example, the guidelines I have developed for the GO product roadmap template directly apply to the roadmap in figure 1. Third, capturing the plan as a roadmap concisely describes the learning path you want to take and nicely visualises it. Fourth, a goal-oriented, outcome-based roadmap is compatible with OKRs. You can view the goals as objectives and the dates, topics, and learning measures as key results. This can help you tie individual learning goals to team and department goals.

Creating the Learning Roadmap

To build a learning roadmap, take the following three steps. First, reflect on your current product management skills and determine any gaps and shortcomings in your current skill set. Second, identify the right learning opportunities. Third, derive the right learning goals, put them on your learning roadmap and add the additional information. Let’s look at these steps in more detail.

➤ Step 1: Understand the strengths and weaknesses in your product management skill set

To analyse your current product management skills, I recommend using the following three subsets: Tactical skills, strategic skills, and leadership skills, as the following picture shows.

The tactical skills in figure 2 include the ability to create user models and personas; stock, prioritise, update, and refine the product backlog; capture user stories; apply the right solution validation techniques, for example, product demo, usability test, and early release; and have a rough understanding of how the product is designed and architected.

The strategic skills comprise the capabilities to create, validate, and evolve an effective product strategy; develop, review, and update an actionable product roadmap; use the right KPIs; choose the right business model and create a financial forecast.

The leadership skills, finally, include the ability to empathise even with seemingly difficult users and stakeholders; earn people’s trust and build strong connections; to actively listen to users, stakeholders, and development team members; to set the right goals—from the product vision to individual sprint goals; to resolve disagreement and conflict; and to effectively involve stakeholders and dev team members in product decisions.

As (digital) product management is a diverse and comparatively young profession, it is completely normal to have gaps or shortcomings in your product management knowledge and skill set. You might find, for instance, that you know what information an effective product strategy should contain but that you are not able to create such a plan on your own. If that’s the case, then don’t feel bad. Instead, recognise that you’ve just discovered a learning opportunity that will help you become an even better product professional.

➤ Step 2: Select the right learning opportunities

Once you understand your current skills, decide which learning opportunities you want to take. While I generally believe that it is helpful to acquire a balanced product management skill set and cultivate tactical, strategic, and leadership capabilities, I recommend that you use your current job as well as any career progression plans you might have to determine the right learning goals. Identify the skills that will help you be even more successful in your current job and/or allow you to take on a new role. For instance, if you want to move into a more senior role, you are likely to benefit from strengthening your strategy and leadership skills. Then compare the desired skills to your actual ones; select those learning opportunities that will help you be more successful in your current or new role or in the new one.

➤ Step 3: Create the learning roadmap

Finally, formulate specific and realistic learning goals, based on the learning opportunities identified. Don’t be over ambitious: You should be able to achieve the learning goals if no unforeseen events unfold. Add the goals to your learning roadmap and order them so that they build on each other and a clear learning path becomes visible. Then determine time frames, topics, and learning measures and include them on the plan. You are now ready to embark on your new learning journey.

Putting the Plan into Action

“Unless commitment is made, there are only promises and hopes; but no plans,” Peter Drucker once said. Having a plan is all well and good. But if you don’t follow it, it is useless.

The issue is, of course, that as the person in charge of the product, you have plenty of other tasks besides meeting your learning goals. There is a product that has to be managed, sales and support queries that have to be answered, a product roadmap and a product backlog that have to be updated, questions form development team members that have to be addressed, and stakeholder requests that have to be dealt with, to name just a few other common duties. It’s therefore easy to de-prioritise or neglect your learning goals in order to make time for other, more urgent tasks. Don’t make this mistake. You’ll hamper your own professional development and most likely be a less productive and effective product person in the future.

Instead, block time in your calendar to carry out the relevant learning tasks, especially when they involve some form of self-study like reading a book or a blog post and watching a video. I recommend setting aside at least one hour per week. Ringfence this time and only sacrifice it in truly exceptional circumstances.

Additionally, reflect on your learning progress at least once per month. Review how much headway you’ve made towards the current learning goal and update the learning roadmap if that’s required. This will help you successfully complete your learning journey and become an even better product professional.

[1] If you’ve used the GO product roadmap template before, you might notice that the learning roadmap in figure 1 does not state any metrics. If you would like to use them, then simply add a fifth row to your learning roadmap and capture the measurements that allow you to tell if a learning goal has been met.

Listen to this article:

Be Prepared to Look after People, Not Products

When you become a head of product, you move into a management position. Consequently, your focus shifts from looking after a product to leading the product people on your team and helping them to do a great job.

Instead of creating, for example, product strategies and roadmaps and tracking KPIs, you should help the people on your team acquire the right knowledge and develop the right skills so that they can carry out the relevant work on their own. This will allow them to take full ownership of and responsibility for their products, and it will increase their motivation, productivity, and job satisfaction. A great way to do this is to mentor and coach people. For instance, you might show the individuals how they can make effective strategic product decisions, create an actionable product roadmap, and effectively use the right KPIs.

Another key aspect to support the people on your team succeed is to create the right environment for people to succeed. This includes establishing psychological safety, fostering collaboration and trust amongst the product people, establishing clear roles and expectations, which I’ll discuss below, and ensuring that everyone has the right infrastructure and tools available.

Becoming the head of product therefore requires you to let go of your role as a practicing and presumably successful product person and to step away from the many joys and challenges of managing a product. For some people, that’s straightforward. But others find it hard to no longer be actively involved in making product decisions, regularly talking to users, engaging the stakeholders, and working with development teams.

Additionally, being an effective leader requires you to cultivate a genuine caring attitude for the people you want to lead, whether you like them or not. It means that you’ll have to deal with people issues on a regular basis, help and support the individuals who are on your team, constructively address problems and offer advice. To put it differently, to lead means to serve and support others.

If it’s hard for you to let go of being actively involved in managing a product or if you don’t find it rewarding to help and support a group of product people, then becoming a head of product is probably not right for you, at least not at this point in time.

Grow Your Leadership Skills

To be able to effectively lead and support a group of product people, you will benefit from having developed strong leadership and people skills, including the following ones:

• Empathy: You are able to reach out with warm-heartedness even to individuals who you don’t agree with and who you find not likeable, value their perspectives, and take a genuine interest in their needs.
• Trust, integrity, and respect: You can earn the trust of others, speak and act with integrity, and create an environment where people feel safe and respected.
• Active listening: You are used to listening to others with the intention to understand, not to answer. You give the other person your full attention, and you keep an open mind whilst hearing what the individual has to say.
• Feedback: You are able to offer constructive feedback so that the other person can receive it and benefit from it. You are also able to skilfully deal with difficult feedback and criticism that others share with you.
• Goal setting: You can lead others through shared goals that create a common purpose and give the individuals the autonomy they need to do a great job.
• Decision-making: You understand how groups can effectively make decisions, and you are able to secure strong buy-in to important product decisions from others, including the stakeholders and development teams.
• Conflict: You can constructively deal with disagreements and conflicts rather than ignoring or suppressing them, or ending up with damaged relationships, bad feelings, and mistrust.
• Time management: You have learnt to effectively manage your time, and you are able to practice sustainable pace.
• Group dynamics: You know what it takes for a group of people to effectively work together, and you are able to help a group of individuals jell.

A great way to develop these skills is to manage a larger product together with a group of product people who you lead—without being their boss. But even if this option is not available to you, guiding a group of stakeholders and one or more development teams will allow you to practice the skills listed above.

Ensure that Your Core Product Management Skills are Strong

Being able to effectively lead others is great. But I find that it usually not enough. To be able to guide, mentor, and coach other product people, you should ensure that your own product management “hard” skills are strong and that you don’t have any major gaps in your product management knowledge. This includes the following ten capabilities:

• Formulating an inspiring vision for a product.
• Carrying out the relevant product strategy work and taking into account product ethics.
• Creating and validating a product strategy including market and user research.
• Developing a product roadmap and setting realistic product goals/outcomes.
• Selecting the right KPIs, tracking product performance, and updating the product strategy and roadmap.
• Creating and adapting a business model and generating a financial forecast.
• Creating user models like personas (based on first-hand knowledge of the users and customers).
• Working with the product backlog: Stocking, prioritising, refining, and updating a backlog; capturing product backlog items as user stories.
• Validating solution ideas: Using, for example, product demos, usability tests, and A/B tests.
• Working with data: Selecting data samples, analysing them, and drawing the right conclusions.

As you might have noticed, the list above includes strategic and tactical product management skills. Both are necessary in my experience to effectively support the members of a product management team, understand the challenges they are struggling with, and offer helpful feedback and guidance. What’s more, having solid product management skills shows the people on your team that you are a competent product person. This is likely to increase their respect and trust for you.

Gain Experience in Managing Different Products

Having successfully managed different products will put you in a great position to advise and support the product people who work for you. Ideally, you should have managed revenue-generating and supporting products across multiple life cycle stages and events, including launch, product-market fit, and retirement.

The experience of working for different companies can also be an advantage, as this will have exposed you to different company cultures and different ways of practicing product management. I personally benefited a lot from working for Intel as a focused, high-paced tech company in the late 1990ies as well as for Siemens as a much larger and diverse business with different product portfolios and different product management processes.

One of the things I learnt from my time at the two companies is that there is no one right way to practice product management. But I also realised that there are a number of common approaches and techniques that tend to be helpful even in seemingly very different environments.

Understand Different Product Roles and Responsibilities

A group of product people will find it hard to work together if roles and responsibilities are not clear. What’s more, it will be difficult for you as the head of product to offer effective feedback and help the individuals develop and grow if it is not clear what’s expected of them. To make things worse, few companies I have worked with had clearly defined product roles. Chances are that you will have to create or improve the relevant role descriptions when you become the head of product.

It is therefore important that you understand common product management roles and responsibilities and that you know how a group of product people can collaboratively manage a larger product. You should understand, for example, what the role of a Scrum product owner is, how it differs from a SAFe product owner, how it compares to a traditional product manager, and which skills an individual requires to be an effective Scrum product owner.

Know Your Industry

To be an effective head of product, I find it helpful to understand the industry the company is in. This includes the following four factors:

• The market with the user and customer needs;
• The major players and competitors;
• The dominant business models and revenue sources;
• The main trends that affect the industry.

Having this knowledge tends to make it easier to be a first-time head of product. It means that you don’t have to worry about getting up to speed with new markets, competitors, and products. Having said that, I consider industry knowledge as a plus but not mandatory: You can typically acquire the relevant knowledge comparatively quickly.

Carefully Plan the Career Step

As with any bigger career step, it’s helpful to develop a realistic outlook of when you will be ready to apply for a head of product position. To get started, assess your current skill set. Then identify and prioritise any bigger shortcomings that you need to address, and determine the right learning and development measures.

For example, you might decide that as an intermediate step, you aim to manage a larger product and use this opportunity to develop your leadership skills and understanding of product roles. You might also decide to carry out some self-study and read articles and books on (product) leadership or attend a product leadership workshop.

Whatever you do, give yourself the time you need to get ready for the career move. There is no point in rushing into a head of product position and quickly finding yourself out of your depth in the new role. I might put the bar quite high, but recommend at least three to five years’ experience before becoming a head of product and being able to successfully lead a product management team.