One Product Owner Is Not Enough
I’ve been meaning to launch a series of articles on all things product ownership and product owners, and it looks like the time is right, finally. And, I’m not going to frame this series into a numbered sequence of posts as was done with Becoming a Leader and Who Is A Software Architect?, for a number of reasons. One reason being: you never know how to embrace the enormity of the subject, limiting all the nuances, insights, and implications to a series with *preferably* a single digit count of stories. It just depends which perspective begs to be highlighted at this or that point of time, or of a team’s journey, and it looks to me that a non-binding non-series format would fit the purpose better.
For starters, let me reference an article which provides an introduction to the kinds of challenges that any product owner might experience in their work (as a side note, I have this link handy because it was my job to quick-polish the spelling and grammar:) Briefly, the article describes the implications of a product development team switching from single product ownership to the multiple product owners mode. I’m sure that many teams have been facing similar challenges, so these insights can be used as lessons learned, out-of-the-box.
And, I’d like to go more in-depth from this “base article” looking into the signs on when having a single product owner might not be enough for one product, let alone for many products. You might want to watch for those signs in your teams, and act as needed. Another point: with several product owners, not only the quality of product ownership as such is improved. The “multiple product owners” practice 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 shall we look for the signs that a single product owner is not enough? You guessed it right. It’s about communication. I have no doubt that thousands of teams in the world have pinned communication as their to-be-improved point — “to-be-improved point” just sounds soo much nicer than “point-of-failure“:) — and I’m less certain as to whether those teams have used visualization to identify the communication bottlenecks. So, here’s how a visual sketch/diagram can be used to highlight that a product owner is extremely overloaded with various kinds of communication, both within the tech/dev team and with the non-tech stakeholders:
This sketch showcases just 2 teams, and one can only imagine what life is like for this Product Owner if there are not just 2 teams, but 5, 6, or 8 teams! With the communication patterns being the same for each of them! Dotted and solid links in the image represent weak and intense communication streams respectively.
Obviously, the interactions break down into 2 networks. In the top network, the non-tech people mingle. In the bottom network, feature teams swirl with activity. *“Top” and “bottom”, meaning image-wise. And, we can see it straight away in the diagram that 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 they have to do a lot of reporting work, for instance — 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:
The second sketch still reveals the communication gap between tech and non-tech stakeholders. And, I’ve used those two sketches just to provide an example as to how a team visualized their specific work dynamics. Each team has their specifics, and the terms for stakeholders might vary, while a certain dynamics might be similar. Likewise, teams are free to choose the means with which to cover for the communication gaps… and this would be a subject for another article : )
Related:
Visualization: Understated or Overrated?
Further reading:
This article is based on an earlier story.
