Value is on everyone’s agenda. Business value creation commonly drives every decision, from developing products to hiring new talents, implementing or improving capabilities, growing support functions, deploying change, etc. Maximizing value creation has long been the duty of the Product Manager and its counterpart role per the Scrum Guide, the Product Owner. There are certain overlaps as well as modus operandi differences between the two roles; also, for more complex initiatives, certain delivery models prone that the two roles should coexist to maximize business value management.
Putting this aside, with small teams the Product Owner is typically acting as the business relationship manager, the guardian of the vision and protector of the voice of the customer. This individual is the content authority, prioritizing requirement delivery, influencing the business on making value-driven decisions and driving delivery of the relevant solutions.
In this post, I elaborate on typical day-to-day activities of the Product Owner, expending on why these activities are critical to focus business value and what is expected from this role.
As part of the SAFe methodology, Scaled Agile defines the Product Owner role as follows:
The Product Owner is the member of the Agile team who serves as the customer proxy responsible for working with Product Management and other stakeholders (…) to define and prioritize stories in the team backlog.
—Scaled Agile Framework
Characteristics of the Product Owner
The Product Owner is an active product champion, central to agile development lifecycle; owning product strategy to design, deployment planning and value realization on behalf of the business.
This role typically encompasses 5 core characteristics:
- Business relationship and primary liaison: how to derive business requirements and align stakeholders
- Value maximization: ongoing business case refinement, budget and cost management: how to measure value and budget for delivery
- Vision and value alignment: facilitating decision making: what to include in the backlog
- Development work prioritization, backlog management and delivery / release planning (what and when): what to deliver in each release and sprint (ongoing planning)
- Acceptance criteria definition and tracking: how to measure success
The Product Owner focuses on value-driven scope (what to build), whereas the build team focuses on developing the solution (how to build). It is critical in reducing ambiguity, providing alignment and direction, and helping the organization learn as the solution matures.
The Product Owner sets direction towards the vision, communicates about the value, product requirements and key features, maintains the roadmap and value targets as expected by the business, and drives change implementation.
Day in the Life of the Product Owner
The daily activities of the Product Owners can be summarized across 4 themes: 1) communication, 2) alignment, 3) planning, and 4) tracking.
In a nutshell, the Product Owner typically operates on a daily basis per the following schedule of work. Contrary to the perception, agile development requires significant amount of planning for the current and next sprint, current and next release, and ongoing update of the delivery roadmap. As per any planning practice, short-term work is planned in detailed, whereas less and less details are required for medium- and long-term plans.
| Duration (*) | Core activities |
| 30 minutes | Daily morning stand-up (or alike meeting) to review progress made by the implementation team, review open issues and dependencies with the current sprint, discuss the work planned for the day, answer open questions, etc. |
| 30 minutes | Review daily priorities based on the stand-up meeting. |
| 60 minutes | Give feedback to the team based on ‘in-flight’ user stories and relevant storyboards. |
| 60 minutes | Review priorities and any new input from the business which might be considered for adding to the backlog. |
| 60 minutes | Discuss progress on the current sprint with the delivery team, including acceptance criteria and the minimum viable product (MVP) to realize business value. |
| 30 minutes | Review recent testing feedback with the business and share relevant update with the delivery team. |
| 60 minutes | Review value statements and priorities with the business, update storyboards, use cases and user stories as required; focusing on detailed requirements for the current and next sprint, and the requirement for detailed experimentation as required. |
| 30 minutes | Update backlog, current and future release plans accordingly. |
| 60 minutes | Refine plan for next sprint and review release / roadmap dependencies based on new findings, requirements, dependencies and priorities. |
(*) Note that the highlighted durations are somewhat arbitrary but suggest a balance between current, next and future.
Indirectly, the Product Owner owns the scope / requirements, business facing plans, acceptance and success criteria—but this is not for him or her to manage delivery. The Product Owner is accountable for value realization and cost management, hence the need to maintain and adjust the business case on any ongoing basis and as a framework to make decisions. This allow for ongoing experimentation, driving value-based adjustment, providing flexibility as detailed requirements are decomposed within the given scope and timeframe boundaries.
In a subsequent post, I will expand on the 9 core activities of the Product Owner as introduced in this post; and discuss how these relate to other different stakeholders when implementing PLM solutions.
What are your thoughts?
References:
- The Scrum Guide (2017) [last accessed: 22 October 2020]
- SAFe Methodology: Product Owner [last accessed: 22 October 2020]
This post was originally published on Momentum-PLM on 27 October 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
