Photo courtesy of Pexels

Product Leadership in Scrum

Published on 8th May 2018

Product owners can take on too many responsibilities, become too tactical and inward-focused, and lose sight of their main job: maximising the value a product creates. Instead of managing the team or establishing the right process, product owner should manage the product and exercise product leadership, as I explain in this article.

Three Types of Leadership

Scrum is a simple framework with three roles: product owner, development team, and Scrum Master. Each role provides a distinct type of leadership. As the product owner, you lead the product and are responsible for its overall success. The cross-functional development team makes the design and technology decisions; and the Scrum Master guides process and organisational change, as the following picture shows.

Product Leadership in Scrum

While the three roles exercise different leadership, the people involved must effectively collaborate to achieve product success and align product strategy, roadmap, backlog, design and technology, and process decisions—without losing focus of their respective core responsibility. [1]


Lead the Product

As the product owner, you should lead the product and guide the development effort by providing an inspiring vision; a validated product strategy that clearly communicates the product’s value proposition, target group, stand-out features, and business goals; an actionable product roadmap that details the strategy and states how the product is likely to evolve; a prioritised product backlog that captures the functionality required; and by engaging the stakeholders in the right way, for example, inviting them to product strategy and roadmap workshops and sprint review meetings.

While I’d like to encourage you to involve development team members and key stakeholders in the visioning, strategising, and roadmapping work, you should lead these activities with the aim to maximise the value your product creates. This may mean making tough decisions and saying no to some ideas and requests, while trying to be an effective, balanced leader—avoiding the pitfalls of being too authoritarian and not assertive enough.

Providing the right product leadership is demanding; it requires a specific skills set and usually your full attention as the person in charge of the product. Consider all the things you have to do: be in contact with the users to understand their needs and validate ideas; manage the internal stakeholders and keep them in the loop; regularly review the product strategy and roadmap thereby considering market trends and the competition; work with the development team on the product backlog and answer questions that arise in the sprint; attend the sprint events—and the list goes on. [2]

Nevertheless, product owners often step in and take on additional responsibilities, such as looking after the development team and resolving conflicts in the team, or making design decisions, when the Scrum Master or dev team do not provide the necessary leadership—be it that they lack the time or skills, or that there is no Scrum Master at all. As a consequence, product owners can become too tactical and inward-focused, too concerned with team and process issues, and neglect the strategic product work.

This risks no longer seeing the wood for the trees. In the worst case, the strategy is no longer valid, but you do everything you can to steam ahead, asking the team to push out more and more features. On a personal level, taking on additional responsibilities is unhealthy and unsustainable: You will end up overworked if you try and keep up all the product work and take on dev team or Scrum Master duties.


Do the Right Thing

As the product owner, you are not responsible that the team members collaborate and manage their work effectively, that the right user experience (UX) is created, that the right software architecture is used, and that the right technology decisions are made. That’s the job of the development team.

You are also not responsible that the right process and methods are used, that impediments are removed, that stakeholders and management understand agile principles and practices, or that the necessary organisational changes are made—be it establishing an effective product management group, adjusting roles and responsibilities, or providing the team with an environment that is conducive to creative work. That’s the responsibility of the Scrum Master.

While it’s great to care, you should refrain from taking on additional responsibilities, as this will only stabilise an ineffective setup: If you can carry out Scrum Master work and look after the team, then why would it be necessary to hire a dedicated, qualified Scrum Master? If you can do the UX design, then why hire a designer?

As hard as it may be, say no, provide the right leadership, and focus on your job—achieving product success, not managing the development team or the process.


Notes

[1] I have placed user research, sprint goal selection, and product backlog refinement between the product owner and development team in the picture above, as these responsibilities are shared by the two roles in Scrum. You should therefore involve development team members in carrying out user research activities like observing users and listen to their feedback on prototypes and product increments. The same is true for choosing the goal of the next sprint, and making changes to the product backlog including analysing the data, breaking larger items into smaller ones, and getting them ready. This allows you to leverage the knowledge and creativity of the team; and it helps the development team members understand the user needs and make the right design and implementation decisions.

[2] When you manage a larger or more complex product, carrying out the necessary product work as a single product owner is often impossible. Consequently, you will have to share product leadership amongst a group of people, as I discuss in my article “Scaling the Product Owner Role“. Whatever scaling approach you choose, the basic division of labour stays the same: The product people lead the product, but not the team or process. 

Post a Comment or Ask a Question

14 Comments

  • Wim Hoogenraad says:

    Team formation of SCRUM teams can be disappointing sometimes. Bruce Tuckman described 4 phases of team formation: Forming, Storming, Norming and Performing. We cannot expect a new SCRUM team to perform as well as it has just been put together. It takes more to get a team to perform well. What do you suggest?

    • Roman Pichler Roman Pichler says:

      Thanks for your comment Wim. As I point out in the article, it’s the ScrumMaster’s responsibility to help the development team members work together well and be aware of group dynamics and team building process. But as the product owner, there are a number of things you can do to ensure that you have an effective and trustful relationship with the team. Please see my articles “8 Tips for Collaborating with Development Teams” and “Stable Agile Teams” for more information. Hope this helps!

  • Nadine Rochester says:

    A very distinct and helpful article Roman. It seems logical that todays inspired yet complex project/ product management techniques necessitate an evolved leadership blueprint to fully enable an organisation.

  • Ashish Pathak says:

    What are the things that Product Managers and Product Owners NOT get into? What should they NOT worry about?

    • Roman Pichler Roman Pichler says:

      Thanks for sharing your questions Ashish. I think it is great when product people are interested in the work others do. But they should neither feel responsible for design and technology decisions nor for addressing process and people management concerns. Similarly, product people should refrain from taking on work that stakeholders own, for example, creating a marketing strategy or determining the marketing mix. That’s the job of a marketer. Hope this helps!

  • Giancarlo Girardi says:

    Hi Roman,

    thanks for the clear and well explained explanation of the roles. As you say, I often see product owners too focused on improving the performance of the team. Thanks for sharing this!

    Giancarlo

  • Matt says:

    This resonates with me. I am a Product Owner for two teams and there is no Scrum Master so on top of everything else there is the constant overhead of facilitation and ensuring team members and stakeholders understand the principles of agile when people start slipping into scrummerfall…

    Talented natural leaders on the development teams can help share this burden but it’s then just an additional distraction for them. Can’t understate the value of an EFFECTIVE (not all are) Scrum Master.

  • Andy says:

    ” […] you are not responsible […] that the right user experience (UX) is provided […] ”

    Nevertheless, the Product Owner is responsible for the product, and the user experience is an essential part of a product, so in that sense, the Product Owner responsible is for the right UX (…and event for the right architecture if a bad architecture causes a product to work improperly).

    • Roman Pichler Roman Pichler says:

      Thank you for your comment Andy and for pointing out that the product’s user experience influences how well it solves a problem for the users. While I believe it is important for product people to understand this and have some UX-related skills, I view it as the job of the development team to design the right UX, just like choosing the right software architecture and technologies.

      I recommend, though, that the product owner involves the team members in user research activities and in creating personas. This helps the team members acquire the necessary knowledge to get the UX design right.

      Hope this helps!

  • Javier Torres says:

    What about the Product Manager? Where do they fit in?

Leave a Reply to Wim Hoogenraad Cancel reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.