Following on from my recent post “How do I know I’m an effective Scrum Master”, I have applied similar thinking to the role of the Product Owner in this sister post.
The article is an attempt to give the Product Owner role a fuller and more worthy definition. I describe the responsibilities and behaviours that I think are important. Some are straight from the Scrum Guide, or influenced heavily by it. Others are my own take on what is important.
From these responsibilities and behaviours I have derived some possible goals that Product Owners can set themselves to help demonstrate both their overall value and that they are on a continuous improvement path. It is vitally important that we can all understand how to be effective given the capacity we have in our particular role. This requires a way of measuring our effectiveness by ensuring we are carrying out our responsibilities and that we are achieving progress because of this.
Note this is not about “performance management”. This is about having a way of monitoring our own progress and that of our peers, and ensuring we are always trying to improve. The goals for each role must marry up and be congruent, such that everyone is pushing in the same direction.
Much like a burn up chart, individual performance management incorrectly focuses on output rather than outcomes. Efficiency over effectiveness. As systems aware, lean thinking knowledge workers, we are more interested in improving system (organisation) performance. A focus purely on individual performance is a local optimisation. But that is a post for another day
As ever, I’d really value your feedback, dear reader!
In a Scrum sense the Product Owner is a single person responsible for optimising the value of a product, iteratively improving it until it no longer requires or warrants further investment.
The reality in many organisation is that the Product Owners do not necessarily have full empowerment from this perspective. However, they provide a pivotal role in ensuring the needs of the business are being represented in a clear roadmap of solving customer problems through product strategy, and that the development teams are working on the right thing at the right time.
- Inspire the team and all stakeholders with your overarching vision on what you think needs to be delivered in order to accomplish the company’s strategic goals, and why you think this is the right approach
- Bring together disparate and competing priorities from all stakeholders into a clear, compelling roadmap for your team
- Optimise the value of the work your team performs
- Own and manage the Product Backlog
- Clearly express each Product Backlog item at the appropriate level of granularity, ideally in a way that concisely articulates the problem it is looking to solve or goal it is looking to achieve; use techniques such as acceptance criteria and story slicing to create this clarity of intent
- Identify and socialise fixed dates (deadlines) after which the value of Product Backlog items diminishes, such as customer commitments, regulatory requirements or key dates in the market
- Order the items in the Product Backlog to best achieve the company’s and its customers’ goals and missions, bearing in mind the impact of delaying items which have deadlines
- Ensure the Product Backlog is visible, its intention and how it was ordered is transparent and clear to all, and it shows what the team will work on next
- Ensure the team understands items in the Product Backlog to the level needed
- Ensure the team is focused on building the right thing at the right time
- Ensure the team has a safe environment in which to experiment, learn, collaborate and challenge ideas
- Be a customer champion, putting the customer at the centre of everything you do
- Be prepared to be wrong; Call out assumptions and test them with real customers as quickly as possible
- Collaborate with the team on each Sprint’s objectives and understanding the work involved, making trade-offs where necessary
- Negotiate scope and priorities with the team, both between Sprints and during them, as more is learned
- Monitor progress toward customer and business goals, ensuring the team’s progress toward these, and artefacts representing this progress, are visible and transparent to all stakeholders, at least in the Sprint Review; Remember that “Working software is the primary measure of progress”, and that “working software” is not just software that works but is “software that is doing work for a customer”
- Ensure that each “done” increment of product/service represents an end-to-end user scenario – something of value to an end user (e.g. a capability is given to a user that they didn’t have before) – and there is at least one acceptance test (preferably automated) that confirms the software does what the customer expects it to do
- Decide when to release the product/service as it stands (i.e. all “done” increments), negotiating with Product Managers and other stakeholders where necessary
- Deeply understand the customer and their needs, and form opinions on how your team can best serve these needs
- Continuously validate via customer/user conversations, testing, research and analytics that the team is on the right path, and be prepared to change tactics when appropriate
- Always be able to articulate the current customer need your team is trying to meet, what they are doing to accomplish that and what they intend to do next
- Employ an iterative and incremental approach to delivering solutions – in addition to upholding the three pillars of empiricism: transparency, inspection and adaptation – in order to optimise predictability and control risk
- Given constraints such as fixed cost, time or scope, look to generate options and defer commitment to one particular option as long as possible; Options have value
- Use collaborative approaches to understanding customer needs and evaluating solution options, such as workshopping, story mapping and story slicing (e.g. walking skeleton, elephant carpaccio, slicing heuristics, etc.)
- Continuously improve the way you and your peers work, such that shared goals can more effectively be met
- Understand and practice agility
- Foster and encourage face-to-face conversation and collaboration such as swarming, pairing, mobbing and workshopping
- Help the team evolve their “Definition of Ready” and “Definition of Done” to incrementally improve quality of customer outcomes and traceability to business outcomes
- Influence the team toward a continuous improvement and experimentation culture for both product and process, ensuring that each Sprint becomes more effective and enjoyable
- Work with other Product Owners to increase the effectiveness of product ownership and its application within the principles of Scrum/Agile in the organisation
—– ♢ —–
“Do right. Do your best. Treat others as you want to be treated.” ~ Lou Holtz
- Always listen and be present
- Show empathy and respect for people’s situation, role, ideas and needs
- Encourage simplicity over complexity
- Tell stories that inspire rather than treating the Product Backlog as a queue of tasks to be done
- Always have empathy and advocate for the customer, and help the team to have a similar focus
- Allow software craftsmanship to thrive; Never infer or imply that teams should sacrifice the quality of their solutions for a quick win
- Recognise that speed of progress is about choosing the right things, working in small increments of value, embracing feedback/learning and delivering with technical excellence rather than “increasing velocity”
- Be a “true North” for the team, but always value their input in how to move forward
—– ♢ —–
Effectiveness is the consistent achievement of goals. Manifesting responsibilities and behaviours into clear, measurable goals will help Product Owners on their improvement journey, which in turn will lead to the organisation becoming more effective. It will also demonstrate the immense value a Product Owner can bring to an organisation.
The goals should be congruent with the behaviour and responsibilities such that embracing these will naturally leads to achieving the goals.
Note: the term “user story” is used below to represent any work item that delivers end-to-end customer value – it does not prescribe the use of user stories.
- Product Owner NPS consistently over 50 (ask the team “How likely is it that you would recommend your Product Owner to another team?”)
- Customer NPS consistently over 50 for your products/services
- Reduce Lead Time (average time from a user story being added to the backlog to working software being used by a customer)
- Reduce Cycle Time (average time a user story is in process, aka elapsed time from work started to work completed)
- Current strategic and product goals, and progress toward them, are visible and can be clearly articulated
- Product Backlog is visible, ordered by value and this value can be clearly articulated
What about you? How do you know you’re an effective Product Owner, or that the Product Owners are effective in your organisation?