Roughly fifty percent of the organizations I visit who are “going Agile” struggle with the Product Owner role. I regularly encounter questions like:

• Do we really need a Product Owner per team?
• Why can’t our Scrum Masters also serve as the Product Owner?
• Since our Product Managers are way too busy, why can’t we simply make our Business Analysts the Product Owner?
• Can’t the team simply create its own work? Especially since they’re self-directed.

The first hurdle these organizations are encountering is the investment it takes to provide adequate vision and clarity for their technical teams operating in an Agile/Scrum environment. Often they want to describe things very early on (traditional software requirements) and then walk away until the team delivers exactly what they asked for or need.

And they want a minimal level of interruptions from the team. Since their Product Managers (Owners) are customer and stakeholder facing, with simply no time to engage the team as they work. Simply put—the teams need to correctly interpret the requirements, as defined, and get on with building the products. Continuous collaboration, while it sounds good theoretically, is not possible given their real world constraints.

This role trivialization and denial surrounding the engagement and importance of the Product Owner role pervades many of these organizations. They’re constantly looking for short cuts and workarounds so as to minimize team contact. For the life of me, I don’t understand why.

In this two-part article I want to discuss the organizational posture surrounding effective support of Scrum and the Product Owner role. I might go as far as to say that if you’re unwilling to make these investments, then don’t bother “going Agile or Scrum” as your results will certainly suffer.

My goal is to explain how many organizations should invest in their adaptation towards Scrum Product Ownership. But in the end, each organization must be willing to “pay the price” of agility done well…

Where do Product Owners come from?

I think this is the first question you should be asking when you’re contemplating moving to Scrum. As part of forming your Scrum teams you’ll need to find one Product Owner for each of your teams. Where in your ranks do they come from? Well, typically I see them as part of your Product Organization, so Product Managers become Product Owners. Other team members in Product Marketing and Product Management organization are ‘converted’ as well.

In some organizations, the Product Organization is “lagging behind” the Technical Organizations’ agile adoption. In these cases, the technical organization often provides the Scrum roles of Scrum Master and Product Owner. I’ve seen Business Analysts and other requirement facing designers tapped as Product Owners. Also, architects and testers are selected because of their breadth of understanding of the product functionality and customer landscape.

All of these individuals can BE a Product Owner as long as they have the requisite skills for the role. We’ll explore the 4 quadrants of the role next to illustrate the skill set.

However, beyond skills, there’s an important connection when the Product Owner is not in the Product Organization proper. They need to be strongly empowered and connected to that organization. You can’t be a decisive, empowered Product Owner when you always have to ask permission or run something by another organization for every decision. It simply doesn’t work.

So strong “dotted lines” for communication, inclusion in strategy & tactics, and empowered trust are important aspects of the Product Organization extending towards these liaison Product Owners.  And beyond this, I view this as a temporary state. At some point in your strategy, the Product Organization needs to be finding, staffing, and directly guiding the Scrum Product Owners.

In a phrase, they need to have “skin in the game” in the agile transformation; and the sooner the better.

Skills Sets

In a previous article, a 2-part series actually, I explained the as a way of identifying the core skill areas for the role. I’ll briefly run over them here, but I would recommend you read that series.

There are four critical skill areas for the Scrum Product Owner, including:

1. They are part Product Manager, in the Pragmatic Marketing sense
2. They are part Project Manager, in the PMI sense
3. They are part Leader, in the Leader vs. Manager sense
4. And they are part Business Analyst, in the IIBA sense

The first thing you should notice is the breadth of skill required for effective product ownership. The Product Manager, Project Manager, and Business Analyst are all common, full-time positions in regular teams. So, the amount of work a Product Owner is responsible for may exceed one person’s capabilities to deliver. Often Product Owners only have some of these skills and it’s up to the Product Organization to supplement them in some way, but more on that later.

Now I want to move into the core of this series. Let’s explore some patterns that surround agile product organizations.

Agile Product Organizational Patterns

Next I want to explore a few successful patterns that I’ve seen emerge from organizations that understand the proper balance between the technology and product organizations when they’re implementing Agile / Scrum. Mostly these apply to larger scale or distributed organizations, but many of them apply equally well to smaller organizations or start-ups. And while they aren’t guarantees for success, they certainly improve your odds of a successful agile transformation.

Supplementing Product Owners

It’s an often assumed position that there can be only one Product Owner per team. The logic goes that there needs to be a single deciding voice guiding each Product Backlog and therefore team. I agree on the ‘voice’ part, but I think it’s incredibly difficult to find an individual that can meet all of the requirements of the 4 Quadrants. In my experience, it’s virtually impossible. So then, how do we fill the role?

I’d say in aggregate. We need to have a lead Product Owner for each team, but we can certainly complement their skill areas where necessary. A common complement is to attach a Business Analyst to Product Owners (actually they’re part of the team) to help them in crafting User Stories for their Backlogs. Now the BA might be ‘shared’ across multiple Product Owners, but the effect is to create more consistent and better backlogs.

I’ve seen the same approach taken when augmenting the planning aspects of the Backlog, with either the Scrum Master helping out or assigning a ‘shared’ Project Manager across a set of Product Owners. Typically, the alignment revolves around multiple teams working on a singular product or project. Where cross team integration and planning, across the Backlogs and the team, can be a challenge.

The key is for the Product organization to supplement their Product Owner skills so that they can actively support their teams across the 4 Quadrants. Making this investment important is a hallmark of this pattern.

It’s a Full-time Role

Effective Product Ownership is a craft, a profession, and a discipline. It’s not a part-time, do it when I feel like it, role. I believe it starts with crafting job descriptions for the Product Owner role. That’s why I wrote the 4 Quadrants in the first place, to help describe the broad nuance of the role. Effective organizations look at their current product management and marketing roles and hierarchy and then craft a new role for the Product Owner.

In many cases, this means you’ll need to go out into the market place and hire some experienced Product Owners to complement your existing staff. It also means you’ll work with the technical organization to identify others to serve in a supplemental role as I described earlier. Often these folks are Business Analysts, Designers, and Project Managers.

And it means that by and large, you’ll have one Product Owner per Scrum team. I’ve successfully overloaded the role to two teams, but carefully and with the permission of the Product Owners. A prime directive for the successful Product Owner is to “feed their team well”, and they need the time and skills to do so.

The core of this pattern is honoring the complexity and importance of the role and remembering that it’s full-time!

Outward – Product Manager vs. Inward – Product Owner

At iContact we tried several variations of organizing our Product Owner team over time. When we first implemented Scrum, we simply “converted” our Product Managers to Product Owner roles. We didn’t reframe any of their responsibilities, so they quickly became overloaded—essentially with two distinct jobs.

We initially handled this overload by supplementing them with “help”. For example, giving them Business Analyst or Project Management help, so that they had more bandwidth to do all of the requisite aspects of their roles. This worked relatively well, but they were still quite overloaded, which affected their focus.

After a few years we hit on a recipe that seemed to work best for us. I’ve also seen it as an increasing pattern in many other organizations. We split up our Product organization into Product Owners, who faced the team, and Product Managers, who faced the organization and the customer. We created a reporting relationship where:

• A Chief Product Owner would own many Products or Product Lines.
• A Product Manager would own a Product Line or Product; Product Managers would focus primarily on roadmaps, product strategy, external communication, and release planning.
• One or several Product Owners would “report to” each Product Manager; Product Owners would focus on their Product Backlogs at they supported the Roadmaps and cross-team dependency management.
• Teams would be aligned around Product Owners; then to each Product

This allowed us the focus we needed between the internal and external demands of the agile product organization. It also allowed us to create better “career paths” for our product managers & owners. While on the surface this may seem “wasteful” from a headcount investment perspective, please don’t look at it that way. It turned out to drive great products and solid growth, so it was an investment well spent.

Wrapping Up

I began this article talking about my frustrations with organizations trivializing the Product Owner role and Product Organization restructuring needs when adopting agile. In my experience, this is probably one of the “Top 3” problems I encounter while coaching.

Often the excuses flow when discussing this part of the transformation; from we have no additional headcount to we’re too busy to work closely with our technical teams to we want to write everything down because we’re the only ones who know what to do. Many of these connect back to an inherent resistance to change.

I want to challenge these excuses. The Product Owner role is crucial to your agile transformation. It’s central to the team and to the organizational. It’s the “glue” that binds high level strategy to low level execution. To short-shrift it, is to undermine your very goals.

In the second part of this series, we’ll explore more organizational scaling patterns for how the Product organization should respond to agile at-scale.

Stay agile my friends,

Bob.