The Scrum Product Owner Theses

The 56 product owner theses cover the concept of the product owner role, product discovery, how to deal with external and internal stakeholders, product roadmap planning, as well as the product backlog refinement. The theses also address the product owner’s part in Scrum ceremonies such as Sprint Planning, Sprint Review, and the Sprint Retrospective. 

Product Owner Theses: The Role of a Product Owner

This first set of theses addresses the product owner’s role in the Scrum process: 

• A product owner embraces, shares, and communicates the product vision. They represent both the customer and internal stakeholders. 


• On the process, a product owner is the gatekeeper of the product backlog, and thus “owns” the product on behalf of the organization as well as customers. 


• A product owner is responsible for maximizing the value that the product provides to both customers and the organization. 


• To maximize the value of a product, the product owner must be empowered to make all product-related decisions on behalf of the organization. 


• If a product “owner” is not empowered to “own” the product, they are not a product owner per se, and the organization is not practicing Scrum. 


• A product owner is the sole representative of the stakeholders, internal and external, insofar as the development team is concerned. 


• A product owner owns the “why,” and influences the “who” and “what,” but should never be concerned with the “how.” Progress in product development is always a collaborative, team effort. 


• A product owner must work closely with the core Scrum team, and particularly the Scrum Master or Agile Coach — their natural ally. 


• A product owner should actively participate in Scrum ceremonies, especially the product backlog refinement, Sprint Planning, and Sprint acceptance ceremonies. 


• A product owner needs to be co-located with the Scrum team to avoid delays, communication errors, and other problems caused by distance. 


• Contrary to popular belief, a product owner is neither a user story author nor a requirements engineer, but rather a communicator and facilitator between the stakeholders and the Scrum team. 

Product Owner Theses: Product Discovery and External Stakeholders

These theses concern what’s required of the product owner on product discovery and product management: 

• A product owner must have a holistic understanding of problems and opportunities in the market, those inherent to the product itself, with the organization and its strategy, and of concern to the various stakeholders. 


• The job of a product owner is to create value for both customers and the organization while mitigating risk. 


• A product owner creates value by embracing a continuous product discovery process built around learning and experimentation. 


• During the product discovery process, a product owner validates hypotheses by continuously running experiments. 


• Frameworks and methodologies suitable for the product discovery process include A/B testing, Business Model Canvasing, Continuous User Testing, Design Sprints, Design Thinking, Lean Startup, Lean UX, and Rapid Prototyping — to name just a few. 


• A product owner must be capable of thinking regarding systems to deal with complexity. 


• The earlier a product owner is involved in a product’s lifecycle, the more valuable that product owner will be to the organization. 

Product Owner Theses: Internal Stakeholder Management

The following theses concern specific aspects of the relationships between product owners and their internal stakeholders: 

• A product owner needs to gain the trust and mandate of all internal stakeholders. 


• A product owner must be able to explain to any internal stakeholder at any time how the stakeholder’s requirements are accommodated by the product vision. 


• Regular feedback from internal stakeholders is crucial to a product owner’s work being successful — specifically, their success with creating the hypotheses funnel that they use to run experiments. 


• Close cooperation between a product owner and their organization’s customer care and sales teams is particularly beneficial for product success. 


• A product owner must be empowered by the organization to say “No” to a stakeholder’s requests — no matter how powerful the stakeholder is. 


• A product owner’s communication with internal stakeholders needs to be transparent and regular to encourage these stakeholders to be engaged with the Scrum team. 


• The Scrum Master is a good ally for a product owner in the pursuit of internal stakeholder engagement. 


• Good opportunities for a product owner to engage internal stakeholders are Scrum ceremonies, like the Sprint acceptance (demo); workshops, such as user story mappings; or training sessions, whereby stakeholders are taught how to better communicate with the Scrum team. 


• Internal stakeholders make excellent members of customer development or user research teams, and a product owner should seek to secure their participation in these activities.

Product Owner Theses: Product Roadmap Planning

The theses in this set concern one of the most contentious topics in the profession: “How do we build Agile product roadmaps that work?” 

• A product owner’s role requires that they also act as a product manager, which means that they must define the product vision, perform strategy and market research, develop business models, manage the product lifecycle, and facilitate product portfolio and roadmap planning. (For more detail, refer to Roman Pichler’s The Scrum Product Owner Role on One Page.) 


• An Agile product roadmap is a high-level plan that describes how the product vision is likely to be accomplished. It should facilitate experimentation and learning. 


• An Agile product roadmap is based on objectives and is usually theme- or goal-oriented. 


• An Agile product roadmap is not a prioritized list of features with fixed shipping dates for months to come. (For more detail, refer to my 7 Best Practices on How to Build a Product Roadmap.) 


• Usually, product roadmap planning in larger organizations with several products requires that each product owner aligns his or her efforts with other product owners to synchronize product development. 


• A product roadmap addresses strategic aspects of product planning. A product backlog addresses technical development issues. 


• Roadmap planning is, like product backlog refinement, a continuous effort — just at an increased cadence. 


• Product owners communicate “big product pictures” by using techniques like user story mapping. (For more detail, refer to Jeff Patton’s User Story Mapping.) 


• A product owner needs to be familiar with the five levels of Agile planning: defining the product vision, defining the product roadmap, release planning, Sprint planning, and accounting for the outcome of daily scrums. 


• Relying on a committee of stakeholders for product discovery and portfolio management is the most common reason that Agile product delivery initiatives fail. 

Product Owner Theses: The Product Backlog and User Story Creation

The theses in this section concern a product owner’s home turf: the product backlog, and user story creation. 

Product Backlog

• A product owner is much more than the “project manager of the product backlog,” and must do more than churning out user stories on behalf of stakeholders. (a.k.a. “ticket monkey syndrome”). 


• Product backlog refinement is a continuous process that needs to be in sync with the product discovery process. 


• Typically, a Scrum team will collaboratively refine product backlog items for the upcoming two or three Sprints.

User Story Creation

• Creating user stories does not equal breaking down requirements documents received from stakeholders into smaller chunks. 


• Writing user stories is a collaborative effort involving the entire Scrum team. The process should create a shared understanding of what will be built, and for what reasons. 


• Because it’s a collaborative effort, a user story is a subject of discussion for the Scrum team. This might take up to 10% of the team’s availability during a Sprint. 


• A product owner will need to come to an agreement with their team as to what standards user stories need to achieve before being considered suitable for the Sprint backlog (i.e. defining and achieving the “Definition of Ready”). 


• Planning poker — the process of estimating user stories — is, most importantly, knowledge transfer. It supports the creation of a shared understanding within the Scrum team of what needs to be built. 


• User story estimation is a critical part of the risk mitigation strategy for the Scrum team. 


• With respect to the “Definition of Ready”: a candidate for the role of product owner should have heard of Bill Wake’s INVEST acronym (from the article INVEST in Good Stories and SMART Tasks). 

Product Owner Theses: Sprint Planning, Reviews, and Retrospectives

The final set of theses concern product delivery: the Sprint itself. 

• A product owner defines the scope of upcoming Sprints by identifying and prioritizing the most valuable user stories in the product backlog. 


• A product owner should participate in all Scrum ceremonies related to Sprints. 


• The product owner is the person responsible for defining a Sprint’s goal. 


• A product owner understands that, in addition to user stories, technical tasks, bugs, and research need to be addressed in every Sprint. (For more detail, refer to Barry Overeem’s The Backlog Prioritisation Quadrant.) 


• A product owner should be available on short notice to clarify any questions that the Scrum team may have during a Sprint. 


• A product owner is responsible for accepting user stories into each Sprint, and for deferring user stories that require additional work to meet the ‘Definition of Ready’ standard. This does not apply to user stories that are related to technical or refactoring tasks. The decision on those is the prerogative of the Scrum team. 


• A product owner is responsible for deciding whether to release a product increment at the end of each Sprint. 


• A product owner should host the Sprint review, which is an event meant to provide the Scrum team an opportunity to demo the outcome of each Sprint to the product’s stakeholders. 


• A product owner must embrace the Sprint review as a vital inspect and adapt feedback loop — for both the development team and the product’s external and internal stakeholders. 

Conclusion: The Product Owner Theses—Scrum From Product Discovery to Delivery

I believe that the Scrum product owner role is the most demanding of all three Scrum roles. It covers a lot of ground, from product discovery, politics, and stakeholder management to systems thinking, and maximizing the return on investment for his or her team. 

It is also the Scrum role that the dark side can misuse easier than the two other roles. 

Am I missing product owner theses to describe the Scrum product owner correctly? Please share with me in the comments. 

Download Our 42 Product Owner Interview Questions Ebook

The “Scrum 42 Product Owner Interview Questions” PDF contain 42 questions plus answers that will help your hiring process.

Related Posts

Scrum: 19 Sprint Planning Anti-Patterns.

28 Product Backlog and Refinement Anti-Patterns