ampersand Nevertheless

Product Owner is not a job

The fact that Product Owner is still used as a job title shows at best an immature product culture, and at worst a fundamental misunderstanding of modern product development. A rant.

Posted by Alexandra on (about a 6 minute read).

This talk has been years in the making. You could say it’s the sequel to my “Developers, start designing!” talk. When I was looking around for a new job last autumn, I had the “pleasure” to read enough job ads to become irritated.

What is a Product Owner?

Product Owner is a role on a Scrum team. The product owner is responsible for maintaining and sustaining the content and priority of the product backlog. The most important aspect of executing this role well is creating backlog visibility inside the scrum team and across the organisation. Scrum is not prescriptive in who should take on this role; Ken Schwaber describes it as highly dependent on the organisation and the product. It can be a domain expert, a project manager, a department head or anyone else who is ultimately responsible for the value created by the team. Think of it as the organisational sponsor.

You could argue that I’m splitting hairs here and that it’s semantics. And that might be true if the title Product Owner didn’t show up in job ads and descriptions with a distinct set of tasks and responsibilities based mainly on Scrum rituals and artefacts.

Scrum is about delivering the best possible solution.

Scrum (and other agile frameworks) is all about the smooth, efficient, and incremental delivery of software solutions. They allow us to create value for our customers, users, and businesses. They help us continuously assess if our solution is useful and avoid wasting a lot of money.

We have delivery down.

The world has changed a lot in the 20 years since the inception of Scrum, and so have our creation and delivery practices. We have incorporated UX design to make sure our solutions are not only useful but also useable. Our digital design practices have evolved to support incremental progress; we have design systems and CI/CD. Although not all of us in this room might currently employ these techniques in practice, we have the process down. We’re optimising.

Delivery is about output.

Every time we think about optimising our delivery, we think about how we can best ship products. We want to create valuable and useable solutions, and we want to do it with as little waste as possible. We are concerned with what we deliver, with what our output is. We want to make sure our work flows as nicely as possible through all necessary steps to our users where it creates value for them and our business.

Agile teams in delivery mode remain in the solution space.

Agile software delivery is about discovering the right solution. Even if we practice it as intended—which we often don’t, but that is a different talk—teams refine and deepen their understanding of requirements and needs within the boundaries of the chosen solution. We always chase a local maximum. This is by design because it enables teams to be focused and efficient in executing towards goals. It’s just not all there is to developing software products.

Who decides which business problem to tackle?

Let’s take a look at a specific example. A team is asked to develop a chatbot for an online retailer. Usually, this type of request comes with a list of expected functionality. Who decided that what was needed was a chatbot? Is a chatbot the only way or even the best one? What is the desired outcome of delivering it? In this scenario, it’s left to the team to find out how to create a chatbot that meets expectations but not if the team should deliver a chatbot in the first place.

Scrum doesn’t help us figure out which problem we should solve. It assumes the problem is identified and deliberately black boxes the process. It’s simply none of its concern.

The symptom: the PO as the “backlog janitor.”

Suppose all we consider is our agile delivery framework of choice. We will likely end up in situations where product owners are reduced to being the interface between the backlog and the business, gathering requirements on one side and reporting progress on the other. It’s not a good place to be in, and needless to say, it’s not what the role was intended to be either.

The missing piece: problem discovery

We need to extend the box we’re operating in to include discovering the right problem before we move on to finding the right solution. There are plenty of ways how to do that. There is the lean startup movement, design thinking methods, jobs-to-be-done. Plenty of books have been written about this topic. We have all this knowledge available to us. I don’t want to go further into the details here; that is another talk.

My point here is different: we need to stop treating problem discovery as someone else’s job simply because Agile isn’t talking about it. We can and should do both in the same team. Let us own the desired business outcome as a team, and trust us to figure out the best way to get there.

Conclusion

Too many product companies still consider Scrum or any other agile development framework as all there is to product development. Their mental models are still defined by the deliberately black-boxed model that these frameworks present. As long as there is no change, teams will be stuck in an output focused mindset. It is hard to break out of this habit and go after the real opportunities in this context. When solutions are handed to us to deliver, all we can excel at is delivery. That’s why we’re so good at it!

Sadly, we leave a lot of value on the table when we operate like this. Our teams do not take full ownership of the business outcome, we don’t know what we’re aiming for, and ultimately, it’s close to impossible to hold us accountable for any high-value goal. Job ads that call for product owners instead of product managers are only one symptom of this limiting approach and only so happen to irritate me enough to send proposals to conferences about it.

Special thanks to Sofia and Georg for feedback and proof reading.