Why full-stack product ownership may be your missing link

Getting back to “one voice”…and beyond.

I was shocked recently to find myself again facing a plea for role boundary definition and a step-by-step guide.

“We need to define all roles and responsibilities in detail. If we don’t do this, our people will not know how to behave, and they won’t know what they can and can’t do. We need a RACI. We need an explicit role definition for everyone!”

— A manager faced with fundamental change.

Traditionally minded companies who are new to the agile journey often make this type of ask. It’s a familiar pattern. I remember getting a similar request as a newly practicing agile coach over a decade ago and practically every year since.

Given the regularity of the situation, I’m uncertain why I was surprised to see this desire for rigidity rear its head again. But nonetheless, I was.

This recent incident involved a company facing a moment of truth. The organization had reached a tipping point and had to change or risk irrelevancy. Their silos were crippling their ability to achieve the right value, in the right way, at the right time.

We discussed aspects of descaling the barnacles that had built up over time. As we did this, some reached a point of desperation as they sensed their norms collapsing. In an attempt to find something familiar to hold on to, the above stern request was made.

This cry for help was in the context of product ownership. The organization had fanned out product responsibilities into many specialized roles. They had product managers, product owners, product analysts, and business analysts. These silos created a massive drag on the company’s delivery of value.

Their plea is understandable. When organizations face simplifying their long-lived, hardened structures and behaviors, fear sets in. Confronted with a restart, many will cry out for a return to the faux certainty of their current paradigm.

But a step-by-step guide is not what today’s organizations need. What they require is a fundamental shift away from boundaries and rules meant to keep people in their lanes. Instead, to move with agility, the lanes must be dissolved.

This new lane-free reality is especially crucial when it comes to product ownership.

The broken state of product ownership today

Let’s face it, the implementation of Scrum’s Product Owner in the wild is often broken and falls short of its intent.

From my experience, today’s Product Owner is watered down and provides limited value. We have fallen well short of the purpose of the Product Owner accountability.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

— The 2020 Scrum Guide

The intent of the Product Owner is to be the “one voice” guiding the team towards the highest value. Yet, this “one voice” is but one among many competing voices in today’s organizations. And teams have to deal with the fallout:

• High degrees of context-switching to serve the needs of all voices.
• Conflicting, externally set deadlines and competing priorities.
• Pressure to work at an unsustainable pace driven by clashing, urgent demands.

These effects are not easily solved. It requires a fundamental, systemic modification to the current patterns plaguing product ownership.

I have been experimenting with a promising solution to this broken pattern. This tactic returns to and goes beyond the “one voice” for value orientation. As this pattern has evolved, I have started to refer to it as full-stack product ownership.

But before we get to solutions, let’s first explore the issues at hand in more detail. Today’s watered-down version of product ownership results from four key factors:

1. The division of product responsibilities.
2. No decision-making authority.
3. Insufficient experience.
4. Disconnection of teams from value.

Problem №1: Many hats worn by different people

The splintering of Product Owner responsibilities among many individuals is a big problem.

Complex product development, increasing demands, and scale have led to this splitting of responsibilities. But when organizations go down this route, they hinder the flow of value. This division creates silos, confusion, and sluggish decision-making.

It spawns unnecessary, overly detailed, duplicative, and isolated elaboration. And as a result, decision-making has drastically slowed to a crawl.

Consider the various product roles surrounding today’s Scrum Teams:

• Product Managers doing strategic thinking, product-market fit, ideation, customer engagement, and stakeholder management.
• Business Analysts primarily focused on gathering and writing detailed product requirements.
• Product Analysts engaged in market analysis and end-user analytics.
• Team-level Product Owners (proxies) confined to translating instructions from Product Managers into “tickets”, feeding the team a recipe.

These roles often operate in isolation, aiming to optimize productivity. Inadvertently, they create confusion and delays. The team grapples with conflicting directions, uncertain about which path to follow. Obtaining answers to team questions becomes a convoluted chain of communication.

For instance, consider a team who has a query about a user story use case. The team approaches the team-level Product Owner. The Product Owner has limited insight and seeks help from the Product Manager. But unfamiliar with the details, the Product Manager redirects to the Business Analyst. And the chain may extend further to involve the Product Analyst to get data insights.

This convoluted process typically leads to significant delays. And the information obtained may be wrong, necessitating further clarification. It is a wicked loop.

Clearly, this fragmented approach stifles effectiveness and burdens teams. It impedes their ability to deliver effectively. But despite this, teams today consistently suffer through this burdensome reality.

Problem №2: The power to do very little

In many organizations, Product Owners are backlog administrators, and that’s it. Their reach and influence get severely stunted.

The term “owner” loses its meaning as their accountability gets diluted. This dilution of the Product Owner role can be attributed to several factors:

• Responsibilities of product ownership get divided among many individuals, as mentioned earlier.
• Decision-making power on the product direction remains with executives or other stakeholders.
• Command-and-control hierarchical structures hinder the delegation of genuine product ownership.
• The role is perceived as tactical, lacking a seat at the strategic table.
• The environment is not supportive of product emergence through experimentation and learning.
• Traditional behaviors shape the Product Owner’s responsibilities to mimic project management.
• The true extent of ownership intended for the Product Owner is widely misunderstood.
• Project managers or business analysts get simply rebranded as Product Owners.

Today’s Product Owners get a list of solutions and a fixed deadline to deliver them. Often, left to their own devices, they break down and order the backlog alone. They input tickets into a backlog tool and hand them off to one or more teams for implementation.

Interactions with customers and stakeholders are typically nonexistent, and team collaboration is minimal. It becomes a lonely and transactional slog, devoid of meaningful engagement.

Problem №3: Inexperience and ineffective guidance

From my experience, the craft of product ownership has become lost in many of today’s organizations.

Companies struggle to embrace the modern beliefs and tools of effective product teams. The Product Owner role gets approached with caution. Organizations define and confine the role within their established patterns.

And many new Product Owners lack the experience and capabilities to fulfill the role. Exacerbating the situation, they get minimal preparation and support in their new journey. After basic training and certification, they are left without mentors or coaches.

Coming from backgrounds in project management or business analysis, much unlearning is needed. These incoming behaviors are often opposite to what enables effective product ownership.

As a result, Product Owners face significant challenges in establishing themselves. Maximizing their Scrum Teams’ value is a far cry from a slam dunk. The gap between their assigned responsibilities and their actual capabilities remains wide.

Problem №4: Team severance from value

The Product Owner isn’t alone; Scrum Teams are also disempowered from owning value.

Many organizations fall prey to focusing a Scrum Team solely on delivery work. They assume the team is unconcerned with strategy, solution ideation, and user research. Or they may desire to keep developers focused, building software with minimal distractions.

So, the result is teams following a recipe who don’t know their customer and have lost connection to value. Their purpose becomes merely to churn out features. They get treated more like factory workers rather than empowered problem-solvers.

Removing the focus on value diminishes the team’s sense of purpose and lowers autonomy. They yearn for mastery of a craft that makes a difference.

This reality represents a lost opportunity to channel all team minds in the pursuit of value.

A better path: the shift to full-stack product ownership

Full-stack is a term often attributed to modern software developers. But it can also apply to a better state of product ownership.

A full-stack developer can work across the full technology stack and isn’t specialized. These types of developers can own and deliver all aspects of a software solution.

Full-stack product ownership runs along a similar vein. It aims to remove the division of responsibility and silos invading today’s reality.

Let’s explore what this means. At first, you may assume full-stack product ownership is simply a return to a “one voice” Product Owner. But as you will see, the full-stack concept extends well beyond this behavior pattern.

Should we return to “one voice?”

A return to the “one voice” would get us back to one set of vocal cords when it comes to maximizing product value. But this alone is not enough.

Early in my practice of Scrum, the idea of the Product Owner being the “one voice” to focus the team was commonplace. The Product Owner turned many voices into one ordered backlog for the Scrum Team.

This worked best when the Product Owner was not a “manager” of the team. The Product Owner was not a dictator, but a facilitator. The team, stakeholders, and users were consulted on the next highest priority.

All voices got heard and considered. But the ultimate decision was on the Product Owner. The best Product Owners considered input from all voices and decided on the next best step to take.

Then, after the step was complete, the results were inspected. The Product Owner would then restart the process of collaborating on the next step.

One set of vocal cords works quite well and has many benefits:

• Clarity of purpose and aligned team focus.
• Fewer interruptions and context-switching cost to deal with the fire of the moment.
• A more sustainable pace due to the absence of clashing, urgent demands.
• Rapid communication.

But it also has some faults, as it only addresses part of the problem. It does put all the hats back on one person and assigns this person decision-making authority. This is a solid step forward, but several problems remain:

• The entire, complex value burden rests on one person’s shoulders who may not have the requisite experience.
• Decisions become siloed to the Product Owner, creating unnecessary hand-offs and bias.
• Hierarchy barriers can develop between the “one voice” who can decide on value and those that can’t.

The “one voice” reduces many silos by collapsing many roles back into one, but it is incomplete. Some silos remain, and these can dampen value achievement.

Beyond the “one voice”

When it comes down to it, “one voice” is not enough to handle the complexities of today’s products. The burden is too large for one person to carry. This is likely why many organizations have splintered the role into specialized sub-elements.

So, how do we amplify the “one voice” and achieve full-stack product ownership? We do it in two ways — 1) by engaging the entire team in the pursuit of value, and 2) through community co-creation.

1) Collective team ownership of value

To make better product decisions, we need all minds and voices on the Scrum Team to be in play.

A diverse set of perspectives will feed better product decisions.

Nothing in the Scrum Guide prevents the entire Scrum Team from owning the product. In fact, it encourages end-to-end ownership of product value.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.

— The 2020 Scrum Guide

The Guide also says:

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Sure, the Product Owner has specific responsibilities tied to the product, including:

• Developing and explicitly communicating the Product Goal.
• Creating and clearly communicating Product Backlog items.
• Ordering Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible, and understood.

Nothing says the Product Owner can’t involve the entire team in these responsibilities. To effectively own end-to-end value, collective team ownership can be a powerful enabler. You don’t want any silos or hierarchies within the team to impede this collective ownership goal.

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

— The 2020 Scrum Guide

Effective Scrum Teams define value targets and deliver solutions to achieve their value. This end-to-end accountability gets amplified by attaining a state of collective ownership. Many minds focused on value will outperform the one, isolated mind of a Product Owner every time.

In short, full-stack product ownership is a team sport. No boundaries exist. The team moves as one toward its value. But even with the entire Scrum Team focused on value, a piece of the full-stack is still missing — the product community.

2) Collective community ownership of value

You want a product community owning value in lock-step with the Scrum Team. Only then, can you have full-stack product ownership.

The product community is interested in the Scrum Team’s output, outcomes, and impact. This is typically a cross-section of stakeholders, end-users, subject-matter experts, and other teams. The community morphs based on the current focus of the team.

Keeping the product community isolated from the Scrum Team is a recipe for mistrust. A community in the dark will resort to mechanisms that thwart the pursuit of value. For instance, you might see the following undesirable behaviors:

• Stakeholders setting deadlines to create “urgency.”
• Mandates for detailed plans and status to ensure visibility into “progress.”
• The implementation of heavy governance and progress gates to gain control.

These attempts to gain visibility and add predictive control take the focus off of value. Instead, output becomes the focus.

Rather than fall into this trap, full-stack product ownership avoids it through co-creation. It instead involves the product community in the pursuit of value. It keeps the community close, not at arms-length.

This feat is accomplished through many continuous mechanisms of involvement. The Scrum team pulls the community into the product discovery and delivery loop. This joins the community and Scrum Team minds to focus on value — a powerful force multiplier.

When a product community joins in before, during, and after value creation, trust goes up. The need for deadlines, detailed plans, status reports, and heavy governance evaporates.

A Scrum Team who joins forces with its product community completes the full-stack ownership formula. It shifts the collective focus on value into overdrive.

A note about scale

The good news: full stack product ownership works at scale as well as it does with one Scrum Team.

Usually, someone asks me how this pattern works at scale. Scale presents extra sprawling complexities into the product effort. It‘s a common reason the responsibilities for product ownership split out into silos.

In the spirit of nailing it before scaling it, I recommend you practice full-stack product ownership first with one Scrum Team. Only when the pattern is habitual, and if deemed necessary, should you add teams to focus on the same product.

Many companies find significant momentum in a single team focused intently on a product vision. You might realize scale is unnecessary once it is working well with one team.

But where scale is necessary, you can form groupings of up to four Scrum Teams focused on a product area. Each of these teams will have a common Product Owner. And these teams, along with their product area community, practice the full-stack pattern.

This works quite well, and it is simple. It avoids the the pitfalls of hierarchy and silos. You will not need to create many roles to oversee value at scale. All minds at scale focused on value will be all the oversight you need.

Net, net

Full-stack product ownership ultimately maximizes the value of Scrum Teams’ efforts. It improves decisions and reduces silos by involving all minds in the pursuit of value. The team (or set of teams) and product community move together to achieve greater heights.

You could argue full-stack product ownership still dilutes the Product Owner role. On the surface, it seems as if product ownership is being spread too broad and too thin.

But in fact, this pattern concentrates product ownership. It achieves this through an intense, aligned focus on value. The value focus is amplified by the team and its product community — all led by an enabling Product Owner.

This pattern morphs the Product Owner into a value conduit, connecting all to aim at value. Having no silos equals no dilution.

The responsibility for value is great. In this full-stack product ownership pattern, it is shouldered by many. I would bet on this configuration any day over one set of shoulders. Would you?

For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.

Related Reads

If you liked this article, read related posts by the author below.