Product People’s Agile Reckoning

Three key forces behind the growing refactor taking place in response to agile transformation.

By Roland Smart

This month, I find myself working on two manifestos. I am contributing to both the Product Manifesto through Product School, and as a long-time agile marketer, to the latest iteration of the Agile Marketing Manifesto. Given this, I’ve been doing a lot of reading and discussing why these manifestos are imperative right now. I’ve concluded that we’re in the midst of a significant refactor taking place in response to agile transformation. 

Within the last month, a number of influential voices in the product community have commented on the limits of the agile approach, specifically the:

1. Risks of conflating Product Owners with Product Managers

2. Scaling challenges within large organizations 

3. How traditional UX is compromised in the face of iteration

There are signs that the product community is recognizing the limits of the agile paradigm, and refactoring how the craft of product management must relate to it.

Let’s look at each of these three and what they mean for the manifesto initiatives underway in 2021.

Conflating Product Owners and Managers

Last month, Marty Cagen, a partner at Silicon Valley Product Group and author of the highly-praised book INSPIRED: How to Create Products Customers Love, wrote a blog post entitled The CSPO Pathology (Certified Scrum Product Owner). He cautions against the conflation of agile’s Product Owner with that of the Product Manager, saying:

The fastest growing pathology I see, especially outside the US, is people confusing a product owner (the role on an Agile delivery team) with a product manager (one of the three critical competencies on a true product team).

Marty is pointing out the critical distinction between these roles that should not be underestimated. 

Product Owners are focused on delivery (ie getting the project done on time and on budget). Product Managers are focused on making sure the right thing is being shipped (ie does it solve a customer problem, enable companies to grow revenues, etc). They must maintain a wide-lens view of the overall business, driving not just user stories and sprint cycles but strategic leadership. This requires fundamentally different skills.

While being trained as a Product Owner is certainly an asset for any Product Manager, such training is not sufficient to be a fully-fledged PM. Following this, the curriculum at product management training and certification companies like Product School is unique and distinct from agile certification. It prepares PMs in strategy, design thinking, product-market fit, and even how to gain executive buy-in. 

Organizations that conflate these roles mistakenly assume they have all the skills needed to set product teams up for success. Marty summed it up beautifully:

Sending Product Managers to a CSPO course is fine, but it is not in any way a substitute for training as a Product Manager.

Agile Doesn’t Scale Well to Large Organizations

The agile approach has been ascendant for over twenty years as adopters [discovered its value as an approach that shortens the path to Product/market fit. Although originally drafted by software developers, it spread into product management as a shared process that facilitated collaboration. It was also brought in by developers who wanted to write less code by pursuing business-oriented roles. 

Meanwhile, product management grew as a discipline and the function gained significant independence in many companies. Since then it’s arguably become the most influential function within the world’s most innovative companies. Such companies have leveraged agile in the service of “product-led growth”. And product management leaders have embraced agile as an optimization in the face of pressure to scale up.

The problem is many simply appended the agile framework to product management and left it unquestioned. 

Today, Agile (with a capital A) is considered to be a dominant way of working in Silicon Valley and beyond. Cross-fertilization has even brought it into marketing as well as other organizations. As the approach has gained traction, it’s been implemented with larger and larger teams. This introduced new challenges because agile is fundamentally an approach that empowers small cross-functional teams. The original agile manifesto says nothing about scaling the approach, so practitioners have developed various frameworks to coordinate such teams at scale.

Even with such frameworks, larger organizations often struggle with the cultural changes required to embrace agility. This can be due to a lack of executive buy-in or due to a failure in the transformation process. In addition, such frameworks necessarily add overhead and complexity. 

I’ve hosted numerous conversations about scaling agile in the marketing context on The Marketing Agility Podcast, in writing my book, and as someone passionate about this topic. I’ve come to the conclusion that there is no single or reliable framework to scale agile. Period. Furthermore, some of the popular scaling frameworks can actually undermine the value proposition of agile. Given this, additional principles are needed to empower agile product teams, really any agile team, that is working in a scaled environment. 

Unforeseen Consequences for UX

Also last month, one of my former managers Jesse James Garret, co-founder of the UX consultancy Adaptive Path and author of the book The Elements of User Experience, wrote an article in FastCompany lamenting the state of UX as a discipline. His related LinkedIn post served as a venue for a pile-on of support from a who’s who of UX leaders. A common theme from the article, and in the comments, is that UX has fallen victim to the agile approach because agile doesn’t allow space for UX with its focus on “shipping” iteratively. Jesse writes:

One such agenda is that of “agile transformation,” which promises to remake organizations to optimize their processes for developer efficiency. This is a win for developers tired of businesses that can’t articulate what they want, but, perhaps more important, it’s a win for businesses trying to wring maximum productivity out of their growing armies of engineers. However, in the rush toward transformation, something has been lost.

What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.

I have also been witness to how an exuberance for agile, and its desire to ship iteratively, has compromised the influence of UX practitioners. I’d go further than Jesse to extend the issue beyond how UX interacts with software development teams because agile transformation is much broader than that. 

That said, I’d propose that agile doesn’t have to be antithetical to the value of UX that  Jesse is calling out here. On some basic level, agile requires an alternative approach to UX that zeroes in on great user experiences through iteration rather than through foundational research and analysis. These inevitably come into tension and can compromise UX best practices, especially those in the mode practiced and preached by Adaptive Path.

Undeniably, agile has impacted UX as a discipline. However, I believe that UX practices and methods can be integrated into ways that deliver significant benefits. 

How should contemporary UX practitioners do this? Well, Jesse Anton commented on the LinkedIn post to call UX practitioners to join him in authoring a “UX Manifesto” at this 24 hours of UX event. That makes three manifestos actively rethinking agile today.

Breaking an Agile Anti-Pattern

It feels like there is a pattern here. Both Marty and Jesse are calling out ways in which the adoption of the agile approach has negatively impacted product and product people. And right now strands of the product community--from product management to marketing to UX--are each organizing to refactor their guiding values and principles. 

The community is recognizing that Agile has had unexpected and unforeseen consequences that must be addressed. For marketers, who are earlier on in their journey with agile, the situation is a little different because it’s more obvious why the agile manifesto must be adapted for a more distant discipline. For Product Management, the situation is even more urgent due to the ascendance of the function and responsibility for growth and innovation. Ultimately the whole point of agile is to empower small cross-functional teams… which often include Marketers, Product Managers, UX practitioners, and Software Developers. All stakeholders need principles beyond those originally drafted for software development, that are scalable to any type of organization. 

In my book, I proselytized agile as a shared operating system that could help align organizations… what I didn’t understand at the time was that agile had the potential to undermine key aspects of each function in ways that would cause those disciplines to evolve and adapt. I believe that’s exactly what leaders across Product, Marketing, and UX, are trying to address with their manifestos. 

The next few months may be pivotal to Product People everywhere as each of these manifestos take shape. Let’s see how the community chooses to steer this refactor and what principles lead us forward.