Product Owners Should Wear Their PARKA

As a former Product Owner (PO) with years of experience training and working with Product Owners around the world, I’m often asked, ‘What makes a good Product Owner?’ And my answer isn’t a list of skills, it’s a description of behaviors and qualities—a good Product Owner doesn’t necessarily need years of experience, but they do need the right behavioral competencies.

And a great way to summarize and remember these behaviors is by using the acronym PARKA, standing for:

• Passion
• Authority
• Responsibility
• Knowledge
• Availability

Let’s discuss each of these in detail…

Passion

For me, there are two aspects of the word ‘Passion.’ Firstly, there is passion for the product—or, more specifically, the value that the product creates for the customer and the business. A Product Owner should be the guiding light for the organization and the team when it comes to the ‘Why’ and the ‘What’ of the product they’re building.

And to get that passion for the product, they—secondly—need a passion for the customer. After all, the Product Owner is the proxy for the customer as far as the business and Scrum Team are concerned. So the PO must know the customer intimately—have empathy, walk in their shoes, understand their needs. This will lead to passion for the product, and allow them to make key decisions about the product. Which leads me onto…

Authority

Authority is not about the Product Owner being a dictator, telling the developers what to build with no room for negotiation—it’s more about being the decision maker for the product.

According to the Scrum Guide, the Product Owner has the delegated authority from the business to maximize “the value of the product resulting from the work of the Scrum team.” To achieve this, the PO leverages data—about the customer, about the product’s potential, about the capabilities of the team and the business—and is accountable for the resulting Product Backlog and </font color=”ed1b52″>Product Goal.

This work requires input from the team, stakeholders, researchers, analysts, designers, etc. But ultimately, utilizing the knowledge gained through these interactions, the Product Owner decides the order of work to achieve the Product Goal. That requires a respect for the authority given to the Product Owner. They can negotiate, they can be influenced, but ultimately they make the decision on what they build next, and why, and they are accountable for it.

Sometimes this will mean saying ‘No.’

Responsibility

And with authority comes responsibility. I’ve already covered what some of the key responsibilities are—managing and ordering the Product Backlog, understanding the customers’ needs through research and analysis, etc.

If the Product Owner represents the customer and their desire for the future state of the product, then they are responsible for providing clarity on what that future state is. So we add to this list:

• Clear communication to provide alignment to the product vision and goal, and
• Being a liaison between the business and the Scrum Team in order to provide that translation between ‘build the right thing’ and ‘build the thing right.’

Long-lived products require long-lived Product Owners. It then makes sense that the Product Owner has a long-lived responsibility for the outcomes of the product. The Product Owner should be held responsible for the delivery of these outcomes.

Knowledge

Again, knowledge should not be conflated with power. The Product Owner does not need to know everything about the creation of a product—they are part of a team, and other members of that team (The Scrum Team) will have more knowledge on the ‘how.’

The main domain of knowledge the Product Owner must have, or acquire, is knowledge around value:

• • What is valuable to the customers?
  • What is valuable to the business?
  • What does the market look like right now?
  • What are the key demands from customers for our products?
  • Do these demands change over time due to seasonality or other factors?

This knowledge is utilized to manage the Product Backlog and craft the Product Goal.

If the Product Owner does not know what is valuable to the customers and business, then the Product owner needs to have the knowledge of where to go to find out.

In summary, the Product Owner needs to have great product knowledge, and great business stakeholder knowledge.

Availability

For me, availability is a key factor. One of the key factors to whether a Scrum Team is effective or not comes down to how available the Product Owner is to the team. So often I see Product Owners acting as business people, not product people, who liaise remotely with teams only to change direction with the product, or to throw in a last minute demand from the stakeholders.

A good Product Owner should be a Scrum Team member first, and a ‘business person’ second. A Scrum Team is a fantastic asset for any organization, but it is squandered if they don’t fully understand what they are building and why—and this is the accountability of the Product Owner.

From sprint to sprint, the Product Owner is working with the team to learn—about the product, how they develop it, and the feedback they get from delivering incremental improvements to it. That learning, as much as the strategic intent, is crucial to the process of backlog management and the ongoing development of the product. Equally, the presence of the PO within the team builds trust, and provides clarity to the teams as to why they exist, and what their business purpose is. Lose that, and the team often drifts and loses focus, ultimately delivering what they feel is right—and clashing with the Product Owner’s vision and intentions.

So, for me a great Product Owner will exhibit these qualities—they’ve got their PARKA on!