Software development

What is a Product Owner?

Product Owner

To me, the Product Owner (PO) is the person with real business responsibility. They must be able to evaluate, and have authority over, the value delivered by various possible development ideas. That person must also have authority over the budget and its use. All other functions are of secondary importance. If the development team is building the wrong thing (or something that is not financially feasible), nothing else matters. Or, using a metaphor: it doesn't matter how fast the car is moving if it's going in the wrong direction - you still never reach your destination.

Working together

While the ultimate responsibility is the PO's to carry alone, luckily they should not have to work alone.

The development team is there to help, in whatever way they can. Sometimes, the team may have a lot of insight into market needs. Or they can help gathering information from users and stakeholders. They can certainly help in demonstrating ideas and collecting feedback about them. And they provide insight into dependencies, opportunities and cost of implementing the solution, all of which help determine the relative worth of various possible features. Smart POs use the development team as much as they can.

Stakeholders can help, too. They can be asked for ideas, the ideas' relative worth, how much money they would be willing to part with for the solution, etc. They can be observed while using the product under construction in order to gather unstated requirements and understand their use of the product. Do remember that also internal management is a stakeholder and can support the PO in many ways.

There also exists a special type of stakeholders that can be called "PO staff", "subject matter experts", "problem team" (as opposed to development team being the "solution team"), or "business team". These people are not team members, but are very closely linked to the product development effort. They support the PO by, for example, providing details for requirements, providing feedback for prioritisation, and working with stakeholders. In some projects, the majority of requirements gathering work is be done by these individuals. In these cases, the PO is clearly the prioritiser, not the clarifier.

Things the PO can't outsource

While a lot of the work related to improving the details of the requirements can be outsourced, the following things cannot be:

  • The PO must personally talk to customers and stakeholders to really understand their motivations.
  • The PO must personally convey the vision, release plan, business needs, and priorities to the development team. The PO must be sufficiently available to answer clarifying questions and discuss business acceptance criteria. The PO can defer details to defined sources, or authorise the team to decide certain elements.
  • The PO must balance the investment into the product with expected (or realized) return. If insufficient return-on-investment (including non-financial benefits) is expected, the PO is expected to redirect the work or cancel the effort.

Unfortunately, a lot of organisations don't have good POs. There may be no clear accountability, or the POs in the organisation lack sufficient authority or political clout. Many POs don't have sufficient business experience or insight. Organisations transitioning to Agile often realize this only after the development teams start performing.

The Product Owner and the Development Team

Can the PO be a member of the development team? To me, not really. At least not in the same way as an actual member of the team. The development team members are united by their commitments to deliver outcomes, and the PO is not part of that commitment. The PO has different commitments - to the team, to stakeholders, to users. It is this greater responsibility that sets the PO apart.

But if the PO and the team are not aligned to a shared goal, we have a huge problem. In that very real sense, they are in the same boat; either they get to their destination together, or they sink together. Honest and respectful collaboration between the PO and the development team is crucially important.

How much time would I expect a full-time PO to spend with the development team? Typically, 20-50%. The rest of the time is spent on understanding customer needs, business priorities and communicating with stakeholders. On the other hand, I've come across great POs who spend 90% of their time building customers and have very little direct time with the team. So, it all depends on the context.