User Tools

Site Tools


What is the Role of a Product Owner? - SSA

The Product Owner (PO) is a member of the Agile Team. He / she is the representative of all stakeholders. His / her focus is the business side of the product. He / she carries the product vision to the team. He / she formalizes a specific, measurable and reasonable Team (Product) Backlog and prioritizes it by business value.

Why Do We Have the Role of Product Owner?

The Product Owner role was created to address challenges that (development) Teams had with multiple, conflicting directions, or no direction at all with respect to what to build. This single source of “the need, in priority order” keeps the Team focused and reduces churn which is the result of waiting for answers, or conflicting priorities.

Without a Product Owner organizations often have a number of problems:

  • All priorities are consider “No 1” which, as a Team member cannot work on more than one thing at a time, results in the Team member choosing the top priority
  • Team members (developers) don’t have a clear understanding of what is the most important thing to work on and make the decision to work on something based on their perception of the priorities which may or may not be correct.
  • Interruptions to the work happens as stakeholders (managers, support, etc.) go directly to Team members to get their issue addressed
  • Teams do not appear to meet commitments they have made, as the interruptions and lack of priority result in work churn
  • Throughput of value delivered decreases while the time it takes to deliver an individual item (cycle time) increases on average reducing the effectiveness and efficiency of the Team

→


What Are the Responsibilities of a Product Owner?

The main responsibilities of a Product Owner are:

  • Responsible for maximizing the value delivered by the Team
  • Content Authority for the Team
    • Owns Team Backlog
    • Prioritizes the Team Backlog
    • Maintains the Team Backlog
  • Accepts stories when they have been validated
  • Participates in reviewing and contributing to the vision and roadmap
  • Works with team to prioritize technical Enablers
  • Makes the hard calls on scope and content
    • Pivot, Preserve, or Stop
    • Adjusts the Team Backlog based on feedback from customers and stakeholders
    • Adjusts based on on current conditions (e.g. changing business conditions, changing Team capacity)
  • Ensure Team has clarity on the requirement
  • Coordinates with other POs and stakeholders to identify dependencies
  • Balances between delivering new functionality and reducing technical debt
  • Works with the Team to refine work Backlog items
  • Work with Scrum Master to adjust execution plans, priorities, etc.

What Are The Characteristics of a Great Product Owner?

The basic answer is that the person is Business oriented person that can provide leadership for the team(s). Characteristics include:

  • Communication and Negotiation: The Product Owner is charged with stakeholder management and communication. The Product Owner must straddle two worlds: The Team world and the customer world. He / she must prioritize the customer’s interests and represent them within the Team. Similarly, he has to represent the Team’s needs within the customer community - a sort of ‘devil’s advocate’ for both the Team and the customer. He /she is articulate.
  • Knowledgeable and Customer Focused: The Product Owner has extensive industry experience / knowledge of our solutions and deeply understands the voice of the customer. He / she spends a significant amount of time talking to actual users using both informal and structured interviews, focus groups, and conceptual layouts. He / she uses his / her findings to sell the project priorities to senior management and uses the stories to motivate the team.
  • Respectful of the team and of the process … and properly blunt. He / she does not take things at face value. Instead, he / she engages the team in genuine conversation, treating them as professionals. He / she is unafraid to speak bluntly about his / her frustrations. When it came to matters about this new Agile process, he / she is willing to defer to others (Scrum Masters, external consultants), demonstrating that it is OK to learn.
  • Makes decisions: When he / she have to decide, they decide. The Product Owner often accepts that there is no “perfect” answer and will make the decisions, the “dirty compromises” required. Once a decision is made he / she will stand up and fight for his decisions and not cave in at the first disgruntled user. Further, Product Owners need to be comfortable making decisions on how to do less, not more. There is a need for this sort of self-confidence and strength of character; it will be tested often when executing a project.
  • Presence: The Product Owner makes it powerfully clear how important the planning is by being present at every session. He / she re-schedules other meetings, sits in the room or is on video conference with the Team, and does not check e-mails or phone messages during the sessions. In other words, he / she backs his / her words with his / her actions.
  • “Just ask me.” The Product Owner knows how to marshal resources and is unafraid to break organizational rules when necessary. Every time the team gets hung up on some obstacle, he / she keeps reminding them, “Just ask me for help. Tell me what you need” and will help work the issue.
  • Focused on the behavior and outcomes he wants and on customer value. Let’s say the Team is excited about the possibility of using some new technology, for example. The Product Owner helps to straighten this out. “When I talked to you, I didn’t talk about a particular technology. So, let’s be clear: I expect that every technical decision you make must support the business value. And I expect you to show me several alternatives, simple to complex.”
  • Not just another project on his plate. The Product Owner needs to tell the the team that he / she is committed to seeing this project through to completion. He / she is not planning to move on to something else after kicking this off. He committed to the success of the product.
  • Motivational: The Product Owner engages with the Team in a way that really motivates the team. We want teams that are excited about the work they are doing and this is an important part of the Product Owner’s role.
  • Works to understand everything that is required to release to product. He / she does not just worry about the new features but is interested in whatever it takes to get the release to the customer. In particular the Product Owner is interested in prioritizing issues appropriately where the Team is telling him / her that they can improve their work process and quality of the product.
  • Anthropological-attitude: The Product Owner needs to work closely with the customer but there is a nuance with this. The idea here is that the Product Owner must not just hear what the customer says he wants, but also needs to discover what the customer actually wants.
  • Clarifiers: Great Product Owners are clarifiers, not confusers. They need to be able to take complexity and distill out what really matters.
  • Wants, and understands, the role: Many organizations assign the role of Product Owner. Many Product Owner become the role without really understanding the role. And as a result, many Product Owners fall back on to their old comfort zone rather than really embrace the role. So, for example, is the Product Owner used to be a supervisor, then they fall back to assigning work to the team rather than collaborate with customers and the Team to really help how to deliver maximal value. So the Product Owner should understand the role and more importantly wants the role.

Note: A lot of this text was developed by reading other web sites but it was done a long time ago and so I have lost the references. If you can provide information on sources I would be happy to attribute.

→


What Team Events is the Product Owner Involved In?

The Product Owner is involved in the following events:

  • Leads
    • Team Planning
    • Backlog Refinement
    • Team Demonstration
    • Prioritization meetings (if used)
  • Participates In
    • All Team events

Note: “Leads” does not mean Product Owner has to be the facilitator. Often the Scrum Master will facilitate the session freeing up the Product Owner to focus on the work of the meeting and results needed.

→


Where Do We Find Product Owners?

The Product Owner is typically sourced from a discipline that has a level of domain expertise for the Product they are working. Potential sources include:

  • Someone directly from the industry
  • Senior support person
  • Senior marketing person
  • Senior technical person on the Team

If the domain expertise is not available then the person needs to have “Domain curiosity”; a willingness to dig in deeply to understand the (potential) customers.

In general, it is easier to train someone with domain experience how to be a Product Owner than it is to teach a generic Product Owner the domain.

→


What Tips Do You Have for a Product Owner?

Here are some tips and tricks to help you become a successful Product Owner:

  • Focus on feedback. For anything thing you deliver to the customer, make sure you understand how you will determine whether you are heading in the right direction, or not.
  • Work to understand how to observe and capture what the customer wants. The basis of this work is “Design Thinking”. Specific tools that can be used include, Story boards, Story maps, Empathy maps, and Personas.
  • Become proficient at capturing needs as User Stories in user voice format (“as a” … “I want” … “so that” ..) and acceptance criteria as Behavior Driven Development (BDD) for (“given” … “when” … then” …) so you can communicate clearly with both the Team and the customers.
  • Go to the “Gemba”. Gemba (現場) is a japanese term meaning “the real place.” For Product Owners, the use is that you have to actually go and see what customers in order to truly understand their needs.
  • Work hard to build trust with Teams, stakeholders, and customers. This means you must lead by example, develop your empathy for others, and be authentic in your interactions and meet your commitments with all parties.
  • Leverage decentralized decision making and trust (but verify) others to do their job. When your expectation is not met, be clear about your expectation.
  • Leverage, and expect, metrics that help you understand upcoming coming work, what is possible, and current projects. Tools include velocity history, cumulative flow diagrams (CFD), and burn-down charts.
  • Expect that you have to explain both the vision over an over again. You cannot over-communicate this! And it is important to reinforcement.
  • Step into your role as a leader. This means you will need to need to both be a continuous learner yourself, and be prepared to share your knowledge to coach and mentor others.
  • Ignore “sunk cost” (the amount of money you have already spent on something) as you determine what to do next. You cannot change the past, but you can decide what is best to do going forward - the best return on your investment.
  • Be conscious of the cost of Teams. A typical fully burdened agile Team in the US costs about $1.2M per year. This means you are making investment decisions of $50,000 every 2 week iteration. Are you getting return on that investment?

How Do We Know a Product Owner is Being Successful?

A Product Owner is operating successfully when:

  • Customers are delighted with the products being delivered
  • Company is happy with the return they have on the investments made
  • Teams are increasing their understanding of customer’s requirements
  • Team Backlog always reflects priority of work and there is sufficient backlog that is ready for implementation
  • Interruption to Team work are controlled
  • Teams are able to regularly make and meet commitments

What Do We Not Want to See in a Product Owner?

A Product Owner is not operating successful we when they:

  • Are a glorified order taker: The Product Owner works against a concept of where the Product is going to. They do not just accept requirements because someone important asked for it.
  • Commit on behalf of Team: The Product Owner defines what needs to be done and the priority; the Team decides how it will be implemented and how much they can work on.
  • Make technical decisions for the Team: Again, Product Owner does not worry about “how”.
  • Estimate Stories for the Team: The people doing the work should estimate the work.
  • Are not available to the Team: If the Product Owner is not available then the original reason for setting up this role is not being addressed.
  • Assigns work to Team members or otherwise tries to manage the Team: Team members determine how to execute the work.
  • Focus only on new functionality at the expense of ignoring the health of the product / solution: The Product is not just the result of new features; there is a significant on-going set of work associated with the health of the Product.
  • De-focuses the Team with latest break-in: While break-ins are expected, if this becomes a normal condition, then it is hard for Teams to make and meet commitments.
  • Create all User Stories: While Product Owners are often the initial source of requirements, Story creation and maintenance is a collaborative exercise with the Team.
  • Play favorites. Product Owners need to be able to balance the competing interests of stakeholders and have a transparent decision-making process.
  • Are not willing to make hard choices during the Iteration (Sprint) Planning meeting.
  • Are not available to the Team.

Want to Know More?

/home/hpsamios/ · Last modified: 2022/03/07 16:54 by hans