58 Product Owner Theses

author imageStefan Wolpers December 9, 2020

TL;DR: The Scrum Product Owner in 58 Theses

The following 58 Product Owner theses describe the PO role from a holistic product creation perspective.

They cover the concept of the Product Owner role, product discovery, how to deal with external and internal stakeholders, product portfolio and product roadmap planning, and the Product Backlog refinement. The Product Owner theses also address the Product Owner’s part in Scrum events from Sprint Planning to Sprint Review to Sprint Retrospective, and the Daily Scrum.

58 Product Owner Theses | DeviceDaily.com

The Product Owner Theses

A Product Owner is an innovator at heart and thus a value creator for customers and organizations if given a chance to work in an agile manner. The Product Owner is also the most vulnerable Scrum role. Turn them into a [fill-in a ticket-system of your choice] monkey or deprive them of the ability to say ‘no’—as in being the guardian of the Product Backlog—, and the Product Owner quickly becomes the Achilles heel of any agile organization.

The Product Owner role depends on the size of an organization, the industry it is operating in, its culture, and the lifecycle stage of that organization’s product(s). Lastly, there is an overlap with the product manager role. (Spoiler alert: they aren’t identical.)

The following Product Owner theses attempt to provide an overview of a successful Product Owner’s responsibilities and competencies.

Role of the Product Owner

This category of the Product Owner theses addresses the meta-level of the Product Owner role and the Scrum process:

  1. The Product Owner embraces, shares, and communicates the product vision, representing the customer voice and internal stakeholders.
  2. Process-wise, the Product Owner is accountable for effectively managing the Product Backlog, thus “owning” the product on behalf of the organization.
  3. The Product Owner is accountable for maximizing the value— resulting from the Scrum Team’s work—that the product is providing to customers and the organization.
  4. To achieve this, the Product Owner is empowered to make all necessary product-related decisions on behalf of the organization.
  5. If “Product Owners” are not empowered to do so, they are no Product Owner per se, and the organization is not practicing Scrum.
  6. The Product Owner thus acts as the single representative of all stakeholders—internal and external—toward the Developers.
  7. The Product Owner owns the “why” and influences the “what” and “who,” but never the “how.” Therefore, any product progress is always a collaborative effort of the Scrum Team.
  8. The Product Owner needs to work closely with the Scrum Team members, particularly with the Scrum Master. Those two are natural allies.
  9. The Product Owner shall actively participate in Scrum events. Additionally, there is the Product Backlog refinement as a continuous process.
  10. Therefore, the Product Owner needs to be with the rest of the Scrum Team—co-located or distributed—to avoid delays, communication errors, and other forms of waste.
  11. Contrary to popular perception, the Product Owner is neither a user story author nor a requirements engineer, but a communicator, a storyteller, and facilitator among all stakeholders.

Product Discovery and External Stakeholders

This category of the Product Owner theses is branching out into the areas of product discovery and product management:

  1. The Product Owner has a holistic understanding of problems and opportunities in a market, the product itself, the organization and its strategy, and its various stakeholders.
  2. The main accountability of the Product Owner is driving value for customers and the organization while mitigating risk at the same time.
  3. The Product Owner lives up to these responsibilities by embracing a continuous product discovery process designed around learning and experimentation.
  4. In this process, the Scrum Team validates hypotheses continuously through experiments.
  5. Suitable frameworks and practices for this kind of product discovery process are, for example, Lean Startup, Lean UX, Design Thinking, Design Sprints, or the Business Model Canvas. Also, user story mapping, continuous user testing, rapid prototyping, or A/B testing have proven helpful.
  6. The Product Owner is capable of thinking in systems to deal with complexity and uncertainty.

Product Owner Theses: Internal Stakeholder Management

This category deals with specific aspects of relationships of Product Owners with internal stakeholders:

  1. The Product Owner needs to gain the trust and mandate of internal stakeholders.
  2. The Product Owner can explain to any stakeholders how their requirements fit into the plan of how to achieve the product vision.
  3. Regular feedback from internal stakeholders is crucial to the Product Owner’s successful work, namely providing input to the hypotheses funnel to run experiments.
  4. Close cooperation with customer care and sales has proven to be particularly relevant for product success.
  5. The Product Owner has to be empowered to say “no” to requests no matter how influential the stakeholder is.
  6. Communication with stakeholders needs to be transparent and regular to encourage their engagement with the Scrum Team.
  7. The Scrum Master proves to be a good ally in the pursuit of stakeholder engagement.
  8. Good opportunities to engage stakeholders are Scrum events like the Sprint Review, workshops such as user story mappings, or training team members of stakeholders to better communicate with the Scrum Team in general.
  9. Stakeholders make excellent members of the customer development or user research team.

Product Portfolio, Product Goal, and Roadmap Planning

This category covers one of the most controversially discussed topics: how to build product roadmaps that work for a Scrum Team?

  1. Product definition: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” (Source: Scrum Guide 2020.)
  2. Product Goal definition: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. [The Scrum Team] is a cohesive unit of professionals focused on one objective at a time, the Product Goal.” (Source: Scrum Guide 2020.)
  3. The role requires that Product Owners act like product managers.
  4. The Product Owner is familiar with the six levels of agile planning: product vision, product strategy, product roadmap, release planning, Sprint Planning, and Daily Scrum.
  5. Acting like a product manager includes working on the product vision, strategy and market research, business models, lifecycle management, and product portfolio and roadmap planning. (See also Roman Pichler’s “The Scrum Product Owner Role on One Page.”)
  6. Generally, portfolio planning in larger organizations with several products requires each Product Owner to align with other Product Owners to synchronize development efforts.
  7. While the product roadmap addresses strategic aspects of product planning, the Product Backlog addresses tactical and technical development issues.
  8. Roadmap planning is—like Product Backlog refinement—a continuous effort, just at an extended cadence.
  9. An agile product roadmap is a high-level plan that describes how the product vision is likely to be accomplished, facilitating experimentation and learning at the same time.
  10. Agile roadmaps are based on objectives and are usually theme- or goal-oriented.
  11. However, an agile roadmap is not a mere list of prioritized features with a fixed shipping date for months to come. (See also: “Product Roadmap First Principles.”)
  12. Product Owners communicate the “big product pictures,” for example, by utilizing user story mapping techniques. (See also Jeff Patton’s “User Story mapping.”)
  13. Having a committee of stakeholders deciding on product discovery and portfolio management is the most critical reason for agile product delivery initiatives’ failure.

Product Owner Theses: Product Backlog, Refinement, Work Items, Forecasts, and Estimations

This category covers the Product Owner’s home turf: the Product Backlog, its refinement, and user story work item creation:

  1. The Product Owner is not the primary author of the Product Backlog, churning out work items on behalf of stakeholders. (Ticket application monkey syndrome.)
  2. All user stories are work items, but not all work items are user stories.
  3. Creating user stories does not equal breaking down requirement documents from stakeholders into smaller chunks.
  4. Writing user stories is a collaborative effort with the whole Scrum Team to create a shared understanding of what shall be built for what reason for whom.
  5. Hence, a user story is a token for discussion, which is why refining the Product Backlog may take up to 10% of the Scrum Team’s availability during the Sprint.
  6. Product backlog refinement is a continuous process and needs to be synchronized with the product discovery process.
  7. Creating an actionable Product Backlog requires the Scrum Team to work collaboratively on Product Backlog items for two to three Sprints in parallel.
  8. The Scrum Team needs to agree on what standards work items need to match before the Developers can choose them as work items in a Sprint.
  9. The most crucial purpose of the estimation poker is knowledge transfer and supporting the creation of a shared understanding among all members of the Scrum Team on what needs to be built.
  10. Estimations also allow forecasting a window of availability for work items.
  11. Estimations are a crucial part of the risk mitigation strategy of the Scrum Team.
  12. Product Owners should be familiar with Ron Jeffries’ Three-Cs—Card, Conversation, Confirmation and Bill Wake’s INVEST principle.

Sprint Planning, Sprint, Sprint Review, and Retrospective

The Product Owner theses’ sixth category addresses Scrum events from Sprint Planning to the Sprint Retrospective and a PO’s responsibilities during the Sprint:

  1. The Product Owner sketches the upcoming Sprint’s potential scope by identifying the most valuable Product Backlog items.
  2. The Product Owner defines the business objective the upcoming Sprint shall accomplish.
  3. The Scrum Team creates the Sprint Goal during Sprint Planning.
  4. The Product Owner understands that next to user stories, technical or refactoring tasks, bugs, and research need to be addressed in each Sprint.
  5. The Product Owner is available on short notice to clarify questions of the Developers during the Sprint.
  6. The Scrum Team decides on the release of a Product Increment.
  7. The Product Owner hosts the Sprint Review to “inspect the outcome of the Sprint and determine future adaptations” of the Product Backlog.
  8. The Product Owner embraces the Sprint Review as a vital inspection and adaption feedback loop with the Scrum Team, external and internal stakeholders.

Conclusion: Product Owner Theses

Scrum has always been a pragmatic business, and to succeed in this mindset, Product Owners need to have a passion for getting their hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas, to continuously deliver value by creating a great product is challenging. The larger the organization is, the more management level there are, the more likely failure in one of its many forms is lurking around the corner.

Which relevant Product Owner theses are missing to describe the role in a better way? Please share your thoughts with us in the comments.

Business & Finance Articles on Business 2 Community

Author: Stefan Wolpers

View full profile ›

(7)