The Product Management @Scale game: How can Product Owners scale their role?

Now that many organisations are scaling their agile process one way or the other, Product Owners are faced with the challenge of scaling their already busy role. The agile product management @scale game helps Product Owners identify how to focus on the essential product management activities while making sure that other product management activities will be handed over to other members of their team.


The purpose of the game is to make transparent which product management challenges an organisation faces when scaling the role of the Product Owner role. This is done by facilitating a conversation about:

  • Which of the activities relating to product management activities should still be primarily taken care of by the Product Owner, even after scaling the role?;
  • What can a Product Owner do to help others in the Development Team take on activities related to product management?;
  • What skills in the Development Team are we currently missing when activities related to Product Management are shared with them?;
  • Which skills cannot be added to the development team due to contextual constraints, and what can a Product Owner do in this case?;


The exercise takes about 40 minutes.


  • Print a deck of cards with one product management activity on each of them. Download my deck here;
  • Prepare a large card for each of these roles: Product Owner, Development Team and Product Team;

Round 1

  • Put the Product Owner and the Development Team card next to each other on the floor with some space between them.
  • With 10 participants I would advise to split up into 2 groups. Give each group a part of the deck of product management activity cards.
  • Explain that they are Product Owner for 1 Scrum Team. Ask them to discuss which product management activities they would assign to the Product Owner and which to the Development Team and put those under the right card on the floor. Wait until all activities are placed on the floor.
  • Now do a quick check: does anyone want to change something? Do you as a facilitator see something that catches your eye? Briefly discuss the most interesting ones and then continue to round 2. Explain that more discussion can take place after the last round in case participants want to continue the conversation.
Participants discuss activities and place them on the floor where they feel it should be

Round 2

Explain that you are scaling the Product Owner role from 1 Scrum Team to 3 Scrum Teams. Now ask the group to discuss which activities that are currently under the Product Owner should move to the Development Team.

Tip: ask the group to do this 1 by 1 and to say out loud which card they move so that everyone is able to learn from the moving cards. Allow some discussion, but try to keep it short by explaining that there will be one more round with more room for discussion.

Round 3

  • Explain that you are scaling the Product Owner role further from 3 Scrum Teams to 5 Scrum Teams.
  • Introduce the Product Team card and explain what this means (see the section ‘about the Product Team’ below).
  • Ask the group to review the activities once more. Which activities would they like the help of the Product Team for? Tell the participants to move these to the Product Team, the same way as they did in step 2.
  • You can help participants understanding which activities to move to the Product Team by asking the following questions: which activities still under the Product Owner role do no longer fit his schedule now that he supports 5 Scrum Teams? Can they move towards the development team? If other skills are needed, can these be added to the development team? If the answer is “no”, move the activity to the Product Team.
  • Once done, walk through the result and see where discussion arises in the group. These could be the activities that are not going well in their current way of working. Try to get the group to name specific activities, roles, departments etc in their organisation so that there is a clear connection to their current way of working. Having a discussion around improving these activities probably provides valuable ideas for their organisation’s next steps.

About the Product Team

Ideally, everyone involved in developing a product is part of a Scrum Team. But sometimes, product development is so complex that it involves people who have a specialism that is not required on a frequent-enough basis to make them part of the Development Team. For them, it can be helpful to form a ‘Product Team’: a group of people who support the Product Owner and the Scrum Teams in defining product strategy. Some examples:

  • Proposition marketeer
  • Legal expert
  • Sales specialist
  • UX researcher
  • Operations/support expert
  • Chief Product Officer
  • Hardware purchaser
  • BI specialist

The Product Team supports the Product Owner and Scrum Teams in finding ways to build better products. I would strongly encourage to add required skills to the Development Team wherever possible before considering to start a Product Team. Only start a Product Team when that is not possible, and make sure that members act as (temporary) Scrum Team members as much as possible. Pay special attention to waiting time between the Development Team and the Product Team as members of the Product Team might have more on their plate then only supporting your Scrum Team.

The Product Team is NOT a:

  • Reason for the Development Team to detach from product strategy creation;
  • Additional role in the Scrum Team: it is a way to help scale the role of the Product Owner;
  • Department with its own agenda and priorities;

Picture. Participants moving activities to the Product Team

Some patterns observed during the game

After playing the game in a recent workshop, we noticed some interesting patterns:

  • At some point, a lot of tasks were moved from the Product Owner to the Development Teams. But how much can they handle in reality? How mature are the development teams? Which skills are in the development teams? How many team members? It might not be realistic to move all activities to the Development Teams;
  • Some unpopular administrative tasks like making financial reports first went to the Development Teams. But a participant rightfully recognised his Development Teams being one of his stakeholders too: shifting too many unpopular tasks to them might demotivate and takes the time that they cannot spend developing the product.
  • The Product Team is sometimes confused with external departments that are mostly out of the Product Owner’s control. This results in participants being hesitant to move activities to the Product Team. It is important to make sure the participants understand the definition of a Product Team (see above for my definition of the Product Team);
Picture. Only the most essential activities to ensure value is maximised remain with the Product Owner


The most important rule of the game is that there is no right or wrong. Product management activities will be different for every organisation. Also, who performs the activities can be very different depending on the experience and composition of the Scrum Team and available Product Team members.

Often there are no explicit agreements about these activities though, leading to all kind of problems and frustrations. The product Management @Scale game helps to make this transparent and get a shared understanding of how product management activities are embedded in an organisation and how this can be improved.

Feel free to use this game for your own organisation or in a training/workshop. Or contact me via in case you would like me to support you with this. Hope it helps you get your (organisation’s) Product Ownership to the next level!