When One Product Owner is Not Enough
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
If you’ve followed our Edge of Chaos blog for quite a while, you might recall the Product Owner Retires post. Briefly, it describes the implications of a product development team switching from single product ownership to multiple product owners. For sure, not only our team has been facing such challenges, so these insights can be used as lessons learned, out-of-the-box.
Today I want to share some more details on when it is potentially not enough to have one product owner. You might want to watch for those signs in your teams, and then act as needed. A point to note: with several product owners, not only the quality of product ownership as such is improved. This works as a field training for people, the aspiring product owners, who then mature and become more competent, thus enhancing the shared team expertise, which surely is an asset if one is looking to develop more products, or product features in the future.
So, where should we look for the signs that one product owner is not enough? You guessed it right. It’s about communication. Here’s how it had looked in our team before we decided to switch to multiple product owners:
While we have 2+ feature teams, there’s no need to show more, as the communication patterns are about the same for each of them. On the upper part of the image one can see that customers are in contact with the sales, support and product specialists, and the product owner (some). Dotted and solid links represent weak and intensive streams respectively.
Obviously, the interactions break down into 2 networks. In the upper network, customers, sales, support people and product specialists mingle. In the lower network, feature teams swirl with activity. Those two networks are connected just loosely. For example, the support might need help from developers. Product specialists pass feedback from customers to the product owner. There you go: a single product owner is the bottleneck. This person appears to be a busy hub where all the interactions overlap. Besides, if a product owner has some other responsibilities, not exactly related to product ownership (if he happens to be a CEO as well, for example), then the plot thickens even more.
This second sketch still reveals the communication gap between marketing and production. This gap is currently covered, to some extent. We’ve introduced decision-making boards, and we share knowledge in internal blogs (the UX blog, the product specialist blog and the support blog) and in group Skype chats. I hope to write more on that some other time.