Take me to Scrumtown

Will Scrum Be The Death of Product Management?

It’s a great time for Agilists, especially those of the Scrum persuasion. The latest State of Scrum Report reports that half of all IT projects were Scrum-based in 2016, with 89% of the surveyed organizations applying Scrum to some extent.  Adding to the good news, consulting firm KPMG reports that a solid majority of CIOs favor Agile methodologies to improve organizational responsiveness. Hooray! Scrum has turned the corner to mainstream acceptability!

However, not everyone is popping champagne corks. Even as Scrum adoption grows more widespread, there are rumblings of discontent. Large implementations are running into roadblocks, leading to a panoply of frameworks for scaling up Agile. State of Scrum respondents identified “alignment with other projects in the portfolio” as one of the top three challenges they face. Boston Consulting Group even argues that Scrum’s Product Owner role is “Agile Development’s Biggest Failure Point.”

What accounts for these contrasting views? I believe a significant contributor is an “anti-pattern” we see too frequently: organizations moving to Scrum inadvertently abandon product management in the process.

“Wait,” you counter, “how can that be? Doesn’t every team have a Product Owner?”

Yes – at least if the Scrum prescriptions are being followed closely. And where do those POs come from? Often from a decision that sounds something like:

“Okay, the Scrum Guide tells us we need a Product Owner for each Development Team. Well, that’s simple enough. We already have Product Managers, who do basically the same job. Just have HR change their titles, and we’re done!”

…and so the seeds of failure are sown. Freshly re-labeled Product Owners begin feverishly recasting requirements documents into user stories, populating JIRA backlogs, attending daily Scrums, and refining acceptance requirements with their new teams. Usually there aren’t enough POs to go around, so some are assigned to two (or more) teams. After a few sprints, the Development teams begin to settle into the new cadence. As collaboration improves and throughput increases, backlogs are depleted at an accelerating rate.

The Product Owners find themselves fully occupied in their new roles:  drafting new stories, re-balancing priorities, resolving questions from their teams, joining in sprint rituals, and responding to newly engaged stakeholders. It turns out that keeping up with a productive Scrum team is no small task. As POs try to avoid becoming a bottleneck, they may begin to feel like slaves to a ravenous Scrum Machine.

And what about those tasks that used to fill their days as product managers?     Remember the forward-looking research, customer/user interviews, needs analysis, task mapping, usability testing, roadmap development, cross-department coordination and roll-out planning they used to do? That’s all becoming a distant memory. Who has the time, when there’s a backlog to fill?

In this all-too-common scenario, the demands of product ownership drive the practice of product management to the brink of extinction. Conscientious Product Owners, highly engaged with their teams, simply don’t have the bandwidth to do all that other “product stuff.” (At least not in a way that lets them “maintain a constant pace indefinitely,” as the Agile Manifesto advises.)

It may take some time for a company to feel the implications of this shift. At first, the POs and teams share enough institutional memory that their development efforts stay roughly aligned. But over time, each team tends to optimize locally. Each PO’s view of “business value” becomes more focused around the backlogs they own. Coordination among Product Owners is reduced to negotiating story dependencies between teams.

Eventually, leadership looks back on their Agile transformation and wonders…

“What happened? We followed the process, our development group is far more productive… but our stakeholders still aren’t happy with what we’re delivering. Some of our projects are still outright failures. Maybe the skeptics were right.”

Organizations can fall into this trap when they adopt the Scrum framework without understanding its limits. Scrum defines the Product Owner entirely in the context of the Development Team. The PO’s role is encapsulated as the person “responsible for managing the Product Backlog” and “maximizing value.” Beyond that, Scrum is mum on any activities that might determine customer needs, or design valuable products and services to meet those needs.

I don’t view this as a failure in the definition of Scrum. Sutherland and Schwaber (and many collaborators since) were trying to help us overcome the fundamental dysfunctions of waterfall development. I doubt they imagined that organizations would become so enamored with Scrum that every other useful practice would go out the window. As the Agile Manifesto reminds us, we favor certain approaches over others, not always instead of.

IT and software organizations need to remember that solid product management is still important to successful products. All those activities needed to investigate, define and validate a software solution are as important in an Agile context as they used to be in the waterfall era. Even with the improved feedback from shorter iterations and release cycles, someone needs to be taking a broader view than the Product Owner role usually allows.

Equally important, Agile organizations need to be realistic about the time demands of both jobs—Product Owner and Product Manager. Asking one person to fill both roles is simply infeasible for products of any significant scale. Forced to choose between urgent daily demands and longer-term strategic work, urgency usually prevails. (The alternative – when entrenched Product Managers short-change their PO activities – is equally damaging.)

Today this Product Owner/Manager dichotomy is being discussed more frequently as larger organizations expand their Agile adoption. Different solutions to the challenge are proposed by various camps. For example, the Scaled Agile Framework (SAFe) partitions the role of Product Management at the Release Train level, aligning backlogs across multiple teams. But regardless of the approach you choose, the first step toward recovery is to acknowledge the problem.

So, for the health of your company – and our industry – I implore you: The future is in your hands. Don’t let Scrum be the death of Product Management.

Leave a Comment



    Great insights. Thanks, Brad. I take issue with the description of Product Owner presented, though, but in-so-much that I am in agreement with the point you are making.

    The main responsibility of the Product Owner is to deliver a product his stakeholders want, need, and will use. If that means the product needs to interact with and be apart of the greater organization’s vision, it should be reflected in the User Stories and backlog (and product vision). Outside of daily scrum meetings and backlog grooming, PO’s should be doing all the activities you listed as former PM tasks (forward looking analysis, roadmap development, etc.) primarily. If not, how can they ensure they are the voice of the stakeholder?

    All that other “product stuff” mentioned is shared responsibility of the PO, dev lead, and Scrum Master. That follows the Agile Methodology of a shared ownership and team-first approach to Scrum. In fact, part of the Agile Manifesto is organizing a cross-functional team in order to cross-train both the development and business individuals for a deeper understanding on all levels. Think about it: What happens when a PO goes on vacation, or takes a sudden leave of absence? You don’t stop work or hire a backfill, the other members of the team lean in to pick up the responsibilities, reducing capacity, until the team member returns.