What is a Product Owner?

In previous posts I’ve written about Agile, Scrum and roles within Scrum. GOLDPoint Systems is in the process of migrating our dev teams over to Agile principles, using Scrum as the framework. The Product Owner is another fundamental role in a Scrum team. Even with all my research, I’m still not an Agile wizard or certified Scrum Master, so I got all my information from Scrum.org and the official Scrum Guide. Also, I may have gone a bit overboard with the Dilbert strips, but they fit into this article so well!

If you want to distill the Product Owner’s responsibilities into one idea, it’s to maximize value. Some companies might employ a product owner committee or include others in the process, which is great if it works, but it’s not Scrum. The Product Owner is a single person, who’s main objective is to maximize value.

The Product Owner needs to be empowered by their organization to manage the product backlog and make decisions about the product. The Product Owner is the only person who can tell the development team what to do. Anyone who wants to make changes to the product backlog can only do so by convincing the Product Owner to make the desired changes.

A Product Owner may have a team, or teams, that they work with, but the Product Owner is held responsible for delivering value. Product Owners have been known to also take on the role of Scrum Master, though one person shouldn’t try to do it all. A key tenet of the Scrum Guide is separating those two roles.

Looking at the screenshot below from Scrum.org, we can see the two main events for Product Owners in the Scrum framework. The Sprint Review comes at the end of the Sprint, where the Product Owner shows what they have for stakeholders, gather feedback, implement market conditions and figure out what to do next. This can also include backlog refinement, which is not an event, but more like an ancillary activity. Backlog refinement is important, and if it is implemented immediately after your Sprint Review, it can assist with Sprint Planning to improve and make better decisions.

The product owner is the only person responsible for managing the product backlog. This includes:

• Clearly expressing product backlog items.
• Ordering the items in the product backlog to best achieve goals and missions.
• Optimizing the value of work the development team performs.
• Ensuring that the product backlog is visible, transparent, clear and shows what the Scrum team will work on next.
• Ensuring the development team understands items in the product backlog to the level needed.

The other main event is Sprint Planning. Preparation for Sprint Planning is imperative. When preparing for Sprint Planning, the focus should be on delivering value. Looking at what’s ahead and deciding on the next valuable deliverable will help you prepare for Sprint Planning.

The most famous example of a Product Owner is probably Steve Jobs, who represented what product ownership really means. Jobs had a vision, he stubbornly drove his vision, made a lot of tough decisions. He jokingly described himself as being a god, and some Product Owners might even get treated that way with how much control they have. Like Steve Jobs, when a Product Owner needs to make a decision, they should do it. There’s no room for indecision in a Product Owner’s life. The mandates of the dev team and the Product Owner need to be balanced to come to a good decision.

A Product Owner needs to ask why the customer wants what they want. A little Socratic questioning goes a long way. How can a Product Owner deliver maximum value if they don’t understand why a product is being developed? Asking “why?” ensures there is a clear purpose behind product development and helps one avoid making reactive choices.

When a tech company goes through the process of adopting Agile principles, there can be some growing pains that accompany the transformation. Many companies have been operating with a waterfall-type mentality wherein responsibility is delegated away. In these situations, there’s not much, if any, accountability.

Product Owners need to be constantly answering three questions:

• How much will it cost?
• What will we get?
• When will it be ready?

The Product Owner needs to be able to work with the team to get the information necessary to answer these questions. Sprints are the empirical processes that allow one to continuously refine knowledge and continuously deliver observable value. They provide the necessary knowledge that better facilitates understanding those three questions.

Another way to view the Product Owner role is as a representative for the customer. A question that should guide the decisions of each Product Owner is: if this is delivered to the customer, will it provide the desired outcome from the customer, i.e., will the customer buy more? Product ownership can be a stressful balancing act at times. If a Product Owner wants to do their job correctly, they must have thick skin. One of the toughest challenges is that nobody likes the Product Owner because they’re saying “no” all the time. Learning how to say “no” without being annoying is key to a Product Owner’s success. It’s especially challenging to say “no” to intimidating stakeholders and customers. Being unable to say “no” can mean delivering to everyone but helping no one. Saying “no” can be difficult, especially when it feels like it’s happening all the time, but it’s an important skill to learn to be able to protect the product. Even the customer may not like the Product Owner at times. A funny example of this is a graph from Devrant.io, showing what drives devs crazy. Have a look for yourself:

Dave West, Product Owner and CEO of Scrum.org, breaks down the Product Owner’s areas of focus into four “worlds”:

• Market sensing, e.g., interviews, validation, competition, win/loss and secondary research.
• Inbound, e.g., business case, numbers, strategy, portfolio fit, roadmap and positioning.
• Planning, e.g., user personas, goals/themes, epics, requirements, prioritization, acceptance tests, release/spring planning and demo validation.
• Outbound, e.g., go to market, launch, thought leadership, collateral/tools and ongoing support.

A development team moving to Agile still has a need for requirements. The Product Owner provides the guardrails, but the whole Scrum team is responsible for defining and delivering the requirements. Rob Van Lanen of Prowareness views requirements as “desirements”, a series of things that need to be completed to deliver value. Requirements should be broken down into smaller blocks of value that can be articulated, tested and measured upon delivery. Backlog items should be outcome based, i.e., desirements, with clear measures of success.

As for guiding the team with the vision, there is not just one strict way to describe it. The vision should be continuously communicated, in various forms. At first, the vision may be clear and concise, but it can become complicated when feature requests come in from the customer, or when bugs and defects appear. Thinking of the vision as an elevator pitch can help teams stay focused on the end goal. Product Owners should be constantly questioning how their decisions help bring the vision to fruition. Regularly communicating the vision from the customer’s perspective is vital to keeping the team’s focus in the right direction. I know dev teams don't really like video games, but it might help any gamers reading this to think of it this way: it’s easy, even fun, to get distracted with all the side quests and details, but it’s of supreme importance to always remember the main objective.