This is a list of 10 questions a Scrum Master may ask a Product Owner, in order to help coach them in their role. Of course, not all questions may apply based on your specific context. Not all Product Owners (PO) have the same definition of success, work in the same way, have identical Developers, etc - you'll likely need to adjust these questions, or throw some away!
- Who are your product stakeholders? Who are the key stakeholders?
- What have you done in the past 5 sprints, to increase the chances of delivering a high-value product?
- How do you know if your product is successful and delivers high value?
- Would you be calm, letting the Developers run the next two Sprints without talking to you?
- How do you know if you're doing a good job?
- What have you done lately to increase the value of the Developers?
- Where do you want the product to be, in a year? What's your top concern that it won't be where you want it to be? What's your part in helping the Scrum Team achieve that goal?
- Given what you know today - if you could send a message through time, back to yourself 12 months back, what would that message be?
- What features should be removed from the product? How do you know they should be removed? How can you tell that you can't remove a feature?
- In what ways are you a bottleneck for the software development supporting this product? How can you mitigate slowing down the product's development?
And now with some details added to each question.
Who are your product stakeholders? Who are the key stakeholders?
Not knowing who your stakeholders are severely limits your chances of knowing how to meet market demand, meet the needs of the stakeholders, and generally being able to deliver a high-value product! It may be two people the PO knows by name, or it may be a set of target audiences around the world. Whatever it is, the PO should know this. In addition, the PO should do everything in their power to involve key stakeholders in Sprint Reviews to increase feedback and chances of always working on the most valuable things.
You may also ask which stakeholders the PO is targeting/focusing on right now, and how he/she came to that conclusion.
What have you done in the past 5 sprints, to increase the chances of delivering a high-value product?
Do the Developers have access to stakeholders as needed? Does the PO engage with stakeholders frequently? Does the PO act as a matchmaker between the Developers and stakeholders rather than a bottleneck? How are different needs from different stakeholders balanced? How does the PO track profit and loss? Does the PO ensure that user or stakeholder satisfaction is measured regularly? Does the PO keep a burn-up chart of "value points" delivered per Sprint, or is there some other way to guess or measure delivered value?
How do you know if your product is successful and delivers high value?
Interviews? Metrics in the product? Alexa index? More money from stakeholders? Happier employees? Satisfied customers? Competition going out of business?
Would you be calm with letting the Developers run the next two Sprints without talking to you?
Does the PO clearly express their vision of the product, in a sufficient way for the Developers to do "the right things" themselves? Is the product backlog up to date, ordered and contains enough Ready items to have the Developers work on their own for two Sprints while the PO focuses on meeting clients, probing the market, etc? Would the Developers know which stakeholders to talk to about particular domain areas? Does the Developers understand the Product Backlog Items well enough to produce high-value product without constant - or even occasional - access to the PO (perhaps not forever, but at least for two Sprints)? Is the PO working reactively (short-term only) or proactively (long-term vision being played out through the ordering of the PBIs in the PBL)? Can the PO motivate short-term vs long-term focus, ie which is the right thing to aim for now?
How do you know if you're doing a good job?
Does the PO have any metrics to look at? How are they relevant? Money in the bank? More users? More leads? Fewer bugs (reported from in-production systems)? Only high-value features in the product? Decreasing code base?
Anyone can cram things into a backlog and a product, endlessly building things that may prove useful or valuable (or not). A successful PO needs to know how to validate their business assumptions, or at least have an idea (put into practice) on how to do a quick and easy validation of business assumptions.
What have you done lately to increase the value of the Developers' work?
The PO is the value maximizer - value in the product, and value from the work the Developers are engaging. Investing in teaching the Developers about the domain, the vision, clients and/or users - all of this increases the likelihood of the Developers building product that is "successful" and with little to no waste.
Where do you want the product to be, in a year? What's your part in helping the Scrum Team achieve that goal? What's your top concern that the product won't be where you want it to be?
Is the PO doing, or focusing on, the most important thing(s)? Out of all things the PO can do, are they focusing on the right things (like ordering PBIs, clarifying vision, involving the right people, making connections, learning about product perception in the market, etc). Are the Developers left on their own, ending up building things clients don't want? Should the PO work more or less closely with the Developers or stakeholders?
Given what you know today - if you could send a message through time, back to yourself 12 months back, what would that message be?
Another "are you improving your own work" and "doing the most important thing, helping your Developers and product to win" question.
What features should be removed from the product? How do you know they should be removed? How can you tell that you can't remove a feature?
Simplicity - the art of maximizing the amount of work not done, is essential. It is important to NOT build things which are not needed, but it's also important to remove features that have a negative ROI. Understanding what features are really needed, and how slim we can make them, is a critical skill for increasing product agility. However, understanding what features need to be removed is also a critical skill for product agility.
In what ways are you a bottleneck for the software development effort supporting this product? How can you mitigate slowing down the product's development?
The PO is a bottleneck position by design, at least if you interpret "being accountable for" to also mean "do the work" (which is a misconception of the PO role, by the way). What can you delegate? What can you direct? What other business side people can you get help from? Where can you get help becoming effective at X, Y or Z? Are you acting as a matchmaker between stakeholders and the Developers, or as a bottleneck and proxy conveying (and most likely accidentally distorting the understanding and intent of) messages going back and forth?
Additional Resources
If your PO is starting out from scratch, Lare Lekman's example checklist is a quick starting point to get some concrete action points from. In order to better understand the PO role, I suggest looking at Charles Bradley's The New New Product Owner article (there's also a video there where he covers most of the content, should you prefer listening instead of reading).
What do you think is missing?
These questions were just some that popped up during an exercise in a Scrum Master class of mine. In your context and work, what would you like to add or remove?