Product Teams in Scrum

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.