Show all posts
4 years ago

When One Product Owner Is Not Enough

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:

communications_network_1While 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.

Here's how the solution to the overloaded hub would look. A dedicated product owner for each feature team:
communications_network_2This 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.

  • Niel Modi

    Actually customer is a king, you have to satisfy your customer, Now developer, designer, and QA all are facing problems when the work load rises when they have to work simultaneously on two three projects. What we can do is make division of team’s in which there can be two developers, two designers and two QA which will decrease their workload and they will have less burden. Monthly 2-3 projects are enough from all the teams. What you think.

  • indigo777

    thanks for sharing your thoughts, Niel. I’d say it’s all very contextual. it depends on what and how soon this feature team has to ship.

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy