Daniel Markham thinks the Product Owner is “the perfect scam in the Agile community” and recommends getting rid of the role. This might work for highly functioning teams working in highly functioning organisations, but for not normal teams. For normal teams in normal organisations the Product Owner performs a valuable role as a facilitator and, if you are lucky, a leader.
Unnecessary overhead
Daniel Markham, in his post Your Product Owner Is An Imaginary Friend (And That’s Okay), says:
The Product Owner always seemed like the perfect scam in the Agile community. The basic idea was to take all the things that seemed boring and tough, and make one guy do them.
Markham views the product owner as an obstacle and/or bottleneck. Daniel explores several scenarios and explains why he doesn’t think the product owner adds value. Daniel recommends getting rid of the product owners in a:
- small startup because they are middle man between the team and the guy with money.
- small team helping out a small company to get something done because the team can just talk to the business users and figure out what they want, then deliver it.
- commercial software team working in a large corporation because the team needs to make decisions based on a technical understanding and comparison of the changes to be made that nobody else in the organization is capable of making.
- truly lean organization because the team should talk directly to the people getting value from the team’s work.
The summary is that for Markham the technical team doesn’t benefit from having a middle man between them and the business. I disagree. It is difficult for a committee to lead anything. And Markham’s suggestion of the development team interacting with the business without as intermediary it trying to do just that.
Facilitator
Product development involves lots of conversations. With customers, with other parts of the business, with the C-suite.
I think this gets confusing if different people, the members of the development team, are having these different conversations. Each member of the team will form a certain view of requirements and priorities, but they probably won’t align with the views of other members of the team, or with the people in the rest of the business.
Having one person facilitating those conversations ensures the development team doesn’t have to deal with those competing agendas. The team are more likely to have a common view on what needs doing.
Leader
Product ownership is, however, more than just facilitation. It is about leadership. Product leadership. The product owner has to point the way. They define the product vision and lead any product pivots based on customer feedback.
Specifically the product owner has overriding call on prioritisation. They say what happens in what order. In most organisations this responsibility for prioritisation will involve disappointing some stakeholders, saying:
- “no” when the stakeholder’s requirement won’t take the product forward.
- “not now” when the stakeholder is asking for something that will get done eventually but has to be deferred to let a higher priority item go first
References
Markham, D. (2013, 7 November). Your Product Owner Is An Imaginary Friend (And That’s Okay). Tiny Giant Books.