There’s a persistent myth out there that a Product Owner should only support one Scrum team. The idea behind this is that having more than one team will stretch the Product Owner too thin, leading to burnout and unnecessary stress. But that’s actually a huge misconception! If you limit a Product Owner to just one team, you’re setting them up to struggle with red tape and bottlenecks instead of focusing on what really matters: delivering value.
When there are too many Product Owners, they are stuck managing dependencies and fighting each other.
Hear me out. Imagine a product such as a consumer products website. Now imagine that there are 60 developers who support it. If we arbitrarily decide to break this into six Scrum teams of 10 each, with each one supported by a separate product Owner, we have created a whole lot of competing priorities and - of course - dependencies. Now every Product Owner is focusing on the needs of their own silo, and no one is looking at the big picture from the customer's point of view. Instead of focusing on the highest value work for the overall product, all of the Product Owners are stuck managing dependencies and fighting with each other. It's a recipe for frustration and - ironically - burnout.
So What’s the Alternative?
Instead of restricting the Product Owner to one team, why not empower them? When a Product Owner oversees multiple teams, yes, they may need some support – but that support shouldn’t mean clipping their wings. Instead, give them the ability to delegate some of the work.
For example, I once worked with a Product Owner who managed six Scrum Teams. She had a crystal-clear vision and strong goals, but she wasn’t writing every single Product Backlog item herself. Instead, she worked closely with developers on the Scrum teams who had business analysis skills. They helped her break down Product Backlog items, brainstorm next steps, and refine the work to keep everything moving forward.
When the Product Owner could focus on the vision and roadmap for the whole product - instead of just a small silo - everyone benefited. The teams knew what they were working toward, and the Product Owner wasn’t bogged down in the details of managing dependencies between isolated silos. Instead, she and her teams collaborated on how to maximize the value of the overall Product.
The Bottom Line
Limiting a Product Owner to one team on a large product doesn’t make things easier – it creates more bureaucracy. Instead of thinking about limiting, think about empowering! Let the Product Owner guide multiple teams when it makes sense, and give them the resources to delegate. That way, they stay focused on the vision, and the teams stay aligned on delivering value.
To learn more about how to manage communications when three or more Scrum teams support a single product, sign up for Rebel Scrum's Scaled Professional Scrum course.
To align your organization around products, contact Rebel Scrum or read more about our Product Definition workshop.
For more Scrum Myths, check out Mary Iqbal's new book, Illustrated Scrum Myths.
Комментарии