This is a list of 10 questions a Scrum Master may ask a Product Owner, in order to help coach them in their role. Not all questions may apply, based on context. Not all Product Owners (PO) have the same definition of success, work in the same way, have identical Dev Teams, etc - you’ll likely need to adjust these questions, or throw them all away!

• Tell me who your stakeholders are!
• What have you done past 5 sprints, to increase the chances of delivering high-value product?
• How do you know if your product is successful and delivers high value?
• Would you be content, letting the Dev Team(s) 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 Development Team?
• Where do you want the product to be, in a year? What’s your top concern it won’t? 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 be?
• What features should be removed from the product? How do know, or how can you tell 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.

Name your stakeholders

Not knowing who your stakeholders are, severely limits your chances of knowing how to mean market demand, the needs of the stakeholders and generally being able to deliver high-value product! It may be two people the PO knows by name, it may be a set of target audiences around the world. Whatever it is, the PO should know this.

You may also ask which stakeholders the PO is targetting/focusing on right now, and how he/she came to that conclusion.

What have you done past 5 sprints, to increase the chances of delivering high-value product?

Does the Dev Team have access to stakeholders as needed? Does the PO involved stakeholders frequently? How are different needs from different stakeholders balanced? How does the PO track profit and loss? 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 content, letting the Dev Team(s) run the next two Sprints without talking to you?

Does the PO express their vision of the product sufficiently? Is the product backlog up to date, ordered and contains enough Ready items for the Dev Team to work on their own while the PO focuses on meeting clients, probing the market, etc? Does the Dev Team understand the Product Backlog Items well enough to produce high-value product without constant - or even occational - access to the PO (perhaps not for ever, 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)?

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? Only high-value features in the product? Decreasing code base?

Anyone can cram things in, endlessly building things that may proove useful. A successfull PO needs to know how to validate their business assumptions, or at least have an idea (put into practice) on how to make a good enough job about it.

What have you done lately to increase the value of the Development Team’s work?

The PO is a value maximizer - value in the product, and value from the work the dev team is engaging. Investing in teaching the Dev Team about the domain, the vision, clients and/or users - all this increases the likelyhood of the Dev Team 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 top concern it won’t? What’s your part in helping the Scrum Team achieve that goal?

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, ordering responsibilities/work too). Is the Dev Team left on their own, building things clients doesn’t want? Should the PO work more or less close to the Dev Team or stakeholders?

Given what you know today - if you could send a message through time, back to yourself 12 months back, what would that be?

Another “are you improving your own work” and “doing the most important thing, helping your Dev Team and product to win” question.

What features should be removed from the product? How do know, or how can you tell 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. Understanding what features are really needed, and how slim we can make them, is a critical skill for increasing 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”. What can be delegated? What can be directed? Where can you get help becoming effective at X, Y or Z …

Additional Resources

Lare Lekman’s example checklist is another great starting point for having a conversation with a PO.