Should Stakeholders Be on the Product Team?
A product team is a cross-functional group whose members work together to achieve product success. Most people would agree that the person in charge of the product, a UX designer, and one or more developers should be on the team. But if stakeholders should be included, is less clear. In this article, I discuss two types of product teams, core and extended ones. I explore the benefits and challenges of using a larger team that includes the key stakeholders, and I share practical tips to help you apply this approach.
🎧 You can listen to the audio version of this article on my podcast: https://www.romanpichler.com/podcast/
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 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 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 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.
Learn More
You can learn more about forming effective product teams and managing stakeholders by attending my Product Leadership Training and reading or listening to my book How to Lead in Product Management.
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.
This article was first published on romanpichler.com.
