Join the Mastering Agility Discord community!
This blog is meant to gather your thoughts on this topic. Please feel invited to share your thoughts either below this article or through a direct message to me on LinkedIn.
Product Ownership is not a straightforward job. Accountable for maximizing the value derived from the product, Product Owners have to balance their options continuously, decide what to do, and maybe even more importantly, what not to do. In their daily work, they talk to hordes of people, look at piles of data, and try to satisfy everyone’s needs (preferably yesterday). Supporting the empirical challenge of a Product Owner, certain choices could be made to pave the way forward.
Decide: the entire organization must respect the choices made by the Product Owner. The Product Owner is empowered with the decision-making authority on all aspects of the product, including the release schedule, budget, order of the backlog, architecture, and technology.
Expected outcome: a single voice of informed decision, cutting time on overthinking and creating overall consensus. The organization must respect the decisions of the Product Owner, without overruling these.
Delegate: Product Owners may decide to delegate certain choices to others in the Scrum Team in order for them to focus on more urgent matters. For instance ordering the Product Backlog, or deployment choices. Would it be a good idea to delegate budgetary or release schedule decisions? Probably not. Ultimately, the Product Owner is still accountable for the effects of delegating.
Expected outcome: deeper insights and (quicker) maximization of potential derived value of the product due to lessened time spent on low-impact work that can be decided and done by others.
Inspire: understanding why the work being performed matters, and what direction the Scrum Team is heading in. What kind of goals are we trying to achieve? Product Owners need to make sure everyone involved understands where we’re going and why it’s important.
Expected outcome: People involved in the development feel inspired, and they understand why their contribution is valuable. They enjoy being a part of this journey.
Clarify: substantiating certain choices or bringing the right amount of information on Product Backlog Items to the developers is key for ensuring valuable, useful Increments are being built. Lack of details only brings a longer cycle time, confusion, and frustration.
Expected outcome: an optimized flow of work throughout the Sprint, as an adequate level of information of readily available.
Research: researching (potentially new) markets, personas, and technology for your product to thrive. What are the pains and gains of our target audience? Could we use this product in different areas? How could new technology like Chat GPT impact our product? The results of this research can be used for decision-making.
Expected outcome: new areas to invest in, hypotheses to verify, insights (in user demographic, technology, ROI, etc).
Analyze: our product generates tons of data, both direct (usage index, ROI, cycle time) and indirect (employee happiness, customer satisfaction). Analyzing this data and extracting learnings from this is vital in the empirical approach to product development.
Expected outcome: support for empirical decision-making. As empiricism states that knowledge comes from experience and conducting experiments, Product Owners need data to rule out or acknowledge the direction of the product.
Facilitate: hold on, didn’t we just see this at the Scrum Master’s choices? Correct! That doesn’t mean that the Scrum Master is the only one that should be able to facilitate. We would argue that facilitation skills for Product Owners are equally important. Facilitating Sprint Reviews, problem-solving workshops, or experimentation events can bring valuable insights.
Expected outcome: valuable events, supporting the empirical nature of Scrum. Events are engaging, collaborative, and positive. Note that facilitation is not meant to make everyone agree all the time. If it happens, wonderful. If it doesn't, not the end of the world. Also, I would personally be freaked out if people agreed all the time.
Engage: engaging with stakeholders or people that could support your product smoothens the process to value delivery. Navigating the political landscape, or gathering investors, requires a high level of people smarts and proficiency in the domain of the product.
Expected outcome: people who should be participating and whose voice is important (to any degree), are present and available when they need to be. Product development is not a Scrum Team show - the voice of the stakeholders is key for the success of the product.
Note that these are not the six stances of a Product Owner created by my dear colleagues, nor are these intended to replace them. These are more activities that are carried out on a day-to-day basis.