Eliminating the Product Owner Role
“The Product Owner role no longer exists” I recently announced to an entire department in a large company. A few POs looked a bit shocked and concerned. What would they do instead?
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.
Since everyone worked out of the same physical office, the first change was to have everyone on a team work together in the same room. A typical team now had a product person (no longer assuming the role of Product Owner), a UX-person, a tester and several developers all occupying a single room.
Co-location is awesome. If you can do it, by all means do it. Collaboration immediately improved simply by co-locating these teams.
Next up was chartering. Chartering is a vital skill I learned from a software industry legend named III. It helps teams and organizations figure out what outcome they’d like to achieve, how they would know they achieved it and who is necessary to help achieve it. It’s an invaluable alignment activity that includes a broad community of people, from executives and managers, to subject-matter experts and sales/marketing staff to the people who are focused on crafting the product.
While co-location enables better collaboration, chartering enables better planning, focus and alignment. Once a community has done the hard work of articulating a clear vision, mission and objectives, and the charter has been approved by the people funding the work, the community knows why it exists and what it needs to achieve. Given any piece of work, people in the community can ask, “Does this further the work of achieving our charter?”
The question of what to build or how to build it is now owned by the community. The words of the charter, co-authored by the people in the community, now cover the walls of the co-located space, clearly visible (in large letters) to everyone engaged in the work. Product management has a voice in this community, but they don’t “own” prioritization or planning. Developers and testers and UX people also have a voice in planning and prioritization. The collective minds of this community work together to further the work of the charter.
Planning is guided by the charter. The charter may have external objectives (e.g. Eliminate all manual steps in the new customer sign-up process by October 15th) or internal objectives (e.g. Remove all level 1 or 2 security vulnerabilities by August 30th). These objectives exist to help achieve a stated mission, which exists to help achieve the community’s vision.
There’s a great deal more I could say about the benefits and joy and challenges of chartering. I’ll skip that for now so we can get back to our main topic. What happened to the PO?
The community that is producing the product is now co-located and guided by a charter. They are encouraged to change their physical space to improve collaboration and they are encouraged to re-charter (it’s called charterING, because it’s an on-going activity) as they learn more.
The team (a portion of the larger community involved in the charter) is now thoroughly focused on doing the work to achieve the charter. Everyone is encouraged to be as creative as possible in helping get the work done with quick, easy grace. The team decides together how to add the most value and what level of quality is required for the work. Could this feature begin life as very basic to start? Do we need a robust solution for that piece of functionality? How will we know if we built what customers love? What would be valuable to measure?
The team is actively encouraged to spend time with actual customers to learn more about their needs. This isn’t the role of one person. A developer may spend time observing real users and come away with brilliant insight into what is most needed. A UX person may discover a key flaw in a workflow or a quality issue with a feature. A product person may find a key strategic need that isn’t being offered today or they may uncover a terrible bug. A tester may be the one who penned the inspiring words of the community’s vision or they may have deep insights into the needs of customers. Everyone collaborates together on producing an awesome outcome.
What about team disagreements? Ultimately, the gold owners (the people funding the work) get to decide what needs to be done in case of a disagreement. One team that we worked with had a fundamental disagreement on which segment of the customer base they were serving. Was it just new customers or also existing customers? Through the chartering process, a clear decision was made: we are only focused on new customers.
If you observe a team that shares ownership of planning and prioritization, you’ll be delighted to see that everyone is continuously paying attention to and discussing what is most important to do and how to spend the time wisely. Without chartering, this work can get messy. Chartering is crucial to eliminating a product owner role. Yet chartering isn’t a silver bullet. Good risk management is always essential. The team must go after the highest value work, while managing the key risks. This was true in the days of waterfall and it remains true today.
I have no personal vendetta against the PO role. Plenty of people will say that what I’ve described here is exactly how their PO functions. In that case, I would say that “Product Owner” is no longer their role. When a team works together to achieve an important outcome, they co-own the work. When that happens, you have replaced product owners with communities that collectively own the work of achieving inspiring outcomes. I find that is far superior to having a Product Owner. If you are intrigued by this idea, consider giving it a try and please report back on what you experienced.
