Summary
In theory, the product owner is one person. But in practice, managing a larger, complex product is usually a shared effort. But how can product ownership be split without resulting in decisions by committee and creating a weak or even inconsistent product? In this post, I discuss different techniques to help you scale the product owner role successfully and I explain when each technique should be applied.
Scaling and the Product Life Cycle
To understand if and when the product owner role should be scaled, I find it helpful to consider the product’s life cycle stage. As long as a product is young and hasn’t reached product-market fit—or is close to achieving it—I recommend having a single person in charge of the product. Here is why: Young products tend to require a significant amount of experimentation and rework in order to get the product launched, adapt it to the feedback of the early market, and get it ready for product-market fit. At this stage, effective decision-making is paramount. Having a single product owner in place supports this: if no consensus can be achieved about what to do next, the product owner decides. Having one person in charge of the product is viable, as it is usually comparatively small and only a small number of development teams—one or two—are likely to develop it at this stage.
But once the product is becoming more successful and start growing, once it attracts more features and becomes richer and requires more teams to develop it, a single person can usually no longer manage the product—without being overworked or neglecting some responsibilities. What’s more, the product now changes less frequently and radically, which makes it easier to share responsibilities amongst a group of product people, as the picture below shows.
Scaling Option 1: Feature and Component Owners
Once you’ve achieved product-market fit and entered the growth stage, you should consider sharing the product work by asking other people to own product features and / or components. I view a feature as a product capability, such as, the ability to search for a product on a website, and a component as an architecture building block, for instance, the data access layer. (I discuss the difference between products, features, and components in more detail in my post What is a Digital Product?)
The initial product owner should be in charge of the overall product, take care of the product strategy and roadmap, and manage the stakeholders, but still be involved in managing the product backlog and making prioritisation decisions. The feature and component owners manage their assets: they capture new ideas and requirements, test them using feedback and data, and collaborate with the teams developing the features and components. The following picture illustrates this approach.
Scaling Option 2: Unbundling and Product Variants
The alternative to sharing the responsibility of managing a product is to break up the latter. A common technique to do this is unbundling a feature and releasing it as a separate product—like Facebook did with the Messenger app in 2004. This reduces the scope of the original product and it creates a brand-new one, managed by a new product owner and developed by its own team(s).
Another technique is creating product variants—think of iPod shuffle and iPod Touch, for example. Applying this technique avoids feature bloat of the original product; and similarly, to unbundling, it introduces new offerings that are looked after by their own product owners and built by their own teams, as the picture below illustrates.
You can, of course, combine option one and two, and first introduce feature owners in addition to an overall product owner and then spin-off features or create variants.
Scaling Option 3: Strategic and Tactical Product Roles
The third option to scale product ownership is to introduce a strategic and a tactical product role. The strategic role is often called product manager and the tactical one is referred to as product owner. The product manager
Frameworks like SAFe use this option as a default, but I recommend you apply it carefully: Splitting product responsibilities along the strategic-tactical dimension works well if a tight integration of strategic and tactical decisions is not required. This is typically the case when the product has entered maturity: it is now incrementally enhanced to defend market share and maximise its business benefits; bigger changes are unlikely to occur—unless you decide to extend its life cycle, for instance, by taking to a new market or segment.
If you use this scaling option at an earlier life cycle stage, then you face the risk of strategic decisions not effectively guiding tactical ones, as well as tactical insights, such as user feedback on specific features or a slower than anticipated development progress, not informing the strategic decisions, particularly when several people take on tactical duties and / or the individuals responsible for strategic and tactical decisions don’t work together very closely.
Comparing the Options
How do the three scaling options compare? The following table summarises my recommendations about when they should be used.
| Option | When to Use it |
| Single product owner | Before product-market fit |
| Product and feature owners | From close to product-market fit to reaching maturity |
| Product variants and unbundling | |
| Strategic and tactical product roles | When the product is mature |
As the table above shows, you should not rely on one scaling technique. Instead, consider the life cycle stage of your product and select the technique that’s most likely to help you achieve or sustain product success.
Learn More
You can learn more about scaling the product owner role by:
- Attending my Certified Scrum Product Owner training course;
- Reading my book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age; the book explains the product life cycle model including product-market fit and the practices unbundling and creating variants.
| Reference: | Scaling the Product Owner Role from our JCG partner Roman Pichler at the Pichler’s blog blog. |
