Joshua Kerievsky wrote a LinkedIn post in July entitled Eliminating the Product Owner Role. As of December 3, 2018, it had received 766 likes and 162 comments on LinkedIn.
https://www.linkedin.com/pulse/eliminating-product-owner-role-joshua-kerievsky/
The opening premise of Joshua’s article is here:
Before I get into who or what would replace the PO role, let me offer a bit of background on this group. Three coaches, including myself, had assessed this group prior to beginning work with them. Our findings were typical:
Too much technical debt was slowing development to a crawl
There was insufficient clarity on what needed to be built
The developers spent little time with their Product Owner
The team was scattered around a building, not co-located
etc.
When you perform numerous assessments of teams or departments in many industries, you tend to see patterns. The above issues are common. We've worked out solutions to these problems eons ago. The challenge is whether people want to embrace change and actually solve their problems. This group apparently was hungry enough to want change.
So, springing from this problem statement, Josh makes the point that if you:
Co-locate the team
Charter the project/product work
Allow planning to be guided by the charter
Have the charter establish a community that drive the products evolution (customer)
It would resolve this problem and that there is no need for a product owner. It essentially becomes Product Ownership by community with the team playing a strong part in collaborating with the customer.
My issue with Josh’s article is not to challenge each of his corrective actions. For example, I’ve been a fan of chartering projects and teams for decades, before and after the emergence of agile approaches.
I’m also a fan of the team partnering with the Product Owner and customer to deliver high-value applications. And co-located teams, if and where possible, has always resulted in improved results in my own experience.
A Leap!
But I think it’s quite a leap to go from the problem statement to removing the Product Owner altogether!
All of the aspects in the problem statement were simple team or role dysfunctions. And I don’t agree with the leap he makes to turn things into Product Ownership by group. We could apply this same logic to the ScrumMaster role for a ScrumMaster who is struggling a bit with aspects of their job.
I’d rather help the product owner by providing some coaching than generalize the role and escort them to the door. And why not allow the retrospective and continuous improvement efforts deal with some of these challenges at a team level?
Warning – Baggage Will Robinson
And there’s another concern I have with what Joshua recommends. I think he makes a HUGE coaching mistake in his story. It’s related to this statement:
When you perform numerous assessments of teams or departments in many industries, you tend to see patterns. The above issues are common. We've worked out solutions to these problems eons ago.
I think Joshua has fallen into a trap here where he allows his experience, incredible as it is, to skew his observations and coaching advice for a unique client. It’s a trap I’ve fallen into myself. One where your experience, valuable as it might be, can also be your worst enemy as a coach.
Because it sometimes presents itself as baggage. Baggage that skews your vision when you’re looking at a client situation. Makes you assume that the situation is exactly like previous ones and dictates a cookie cutter reaction. One that might be valid, but that might be totally invalid given the context.
As coaches, we need to be very careful that we treat each client situation as the unique, wonderful, and perhaps challenging opportunity that they are.
Wrapping Up
I’ve been a long-standing fan of Joshua and his work at Industrial Logic. And his introduction of Modern Agile has brought a refreshing “back to the basics” focus to all of us who are practicing agile software development.
That being said, we can’t all be right all of the time. And I don’t think Joshua got it right with this post. Perhaps for one unique context or experience. But as general advice, I think the article is misleading and perhaps even dangerous.
Product Ownership is a craft that is best done by someone with experience, accountability, skills, and organizational trust. It’s not a teamthink or groupthink role.
One of the things that agile has done is sort of marginalized the roles within Product Management to that of a “Product Owner”. Instead of marginalization, I think we should be amplifying the importance and scope of Product Management (and Product Ownership) in agile contexts.
Stay agile my friends,
Bob.