Behind which door do you find the Product Owner candidate?

OK, so you have decided to form agile teams in your organization and after talking to HR, you learn that they don’t have a bunch of Product Owners laying around on a shelf somewhere. And since your plan for this agile stuff didn’t include hiring any new people (which it probably should have), you start looking at who could potentially transition into this new role.

I would like to offer my thoughts on this but before I do, please let me just state very clearly that I don’t believe in one right way that universally is more correct than any other approach. However, there might be some ways that are more likely to work well than others. I will convey my thoughts through a few principles and some examples.

Principle 1:

In order to quickly be able to respond to change, we need to move decision power to where the information is and not the other way around. In other words, the Product Owner needs to have the mandate to conduct actual ownership of the product.

Principle 2:

Delivering as much value as early as possible is the core principle behind ordering the Product Backlog (prioritizing the items in such a way that they are in an unambiguous sequence). This requires the Product Owner to understand what is valuable, what is a business requirement and what is neither even though it might be communicated, disguised or perceived as being such.

Principle 3:

Being a Product Owner is a fine balance of making hard decisions based on what is best for the product and creating mutual empathy while doing so. It doesn’t matter if a Product Owner objectively makes all the right decisions — if everyone disagrees with the decisions, the Product Owner will be short-lived.

Principle 4:

‍Being a Product Owner is also about seeing one’s product in the context of what the organization is striving for. This, of course, requires the product vision to align with other organizational visions but it also requires Product Owners, whose products depend on each other, to communicate closely in order to understand how to best order their individual Product Backlogs to support each other in the joint pursuit of organizational goals.

And now for a couple of real-world examples:

• Some IT departments have Product Owners from the business side of their organizations. These Product Owners tend to have a very good foundation for living up to principles 2 and 4. However, IT management can have a really hard time delegating a proper mandate (principle 1) to someone from outside of their department as they feel ultimately accountable.
• Having a small board of stakeholders attached to a given product to help the Product Owner live up to principles 2 and 4, especially if the Product Owner lacks domain insight, can be very valuable. However, some power-hungry stakeholders flock to such boards because they perceive them as steering committees. If an organization allows such a dynamic, principles 1 and 3 go poof.
• While I would always advise against it, I must admit that I have seen one or two managers take on the Product Owner role with reasonable success. While principle 1 usually isn’t a problem, the other principles can struggle unless we are talking about a person that really “gets it” — I’m talking about both Agile, servant-leadership and the willingness to sacrifice career points for the benefit of one’s product.
• As a member of a small team with an absent Product Owner, I have experienced “product ownership by committee”. While it somewhat worked for a period, we ended up struggling with all principles. I think committees can work in highly evolved cultures, but it requires a better decision-making process than simply trying to reach consensus, e.g. something like the Advice Process.
• However, the most widespread Product Owner setup in IT departments is finding a candidate within the IT organization itself. A visionary with domain insight who talks to people and doesn’t scare easily. In this case, living up to principles 2 and 4 usually requires a mindset shift, as IT people traditionally have an inside-out, project execution perspective. This doesn’t work with Agile. At all.

As you can see from this small selection of examples, there are many ways organizations find and support their Product Owners. Depending on organizational culture and individual, personal competencies, I believe there can be many ways to do this with success — and probably equally many ways to have it go completely off the rails. The important part is to keep an eye on the principles and continuously improve. Like everything else in Agile.

Bon voyage!

Curious about agile? Never miss a post!
Sign up for our newsletter (in Danish) right here 👉🏻 syndicate.dk/backstage

‍

‍