Agile is Dead and How AI Can Fix It
The step-by-step guide to change how your team builds software with AI
“AI is making PMs more important than ever” - Christopher Payne, President of Doordash, former CEO of Tinder and creator of Bing
We recently sat down with Chris to learn more about his experience as a legendary product builder and discussed our shared vision for a world where AI enables new ways of building software that empower users and builders like never before.
Why Agile Has to Go
Agile has long been the “industry standard” practice for building software but, despite its widespread popularity, it never truly worked at scale. Everyone agreed with the spirit of Agile, where values like listening to customers, “working software over comprehensive documentation”, and iterating quickly were championed, but the actual playbook that Agile prescribed broke down pretty quickly when it came out in TWO THOUSAND AND ONE and definitely doesn’t fit today’s evolving model.
Despite the fact that they run daily Scrum meetings, many large tech companies prioritize feature builds using quarterly planning cycles, yearly operational reviews and approval processes that break definitively away from the spirit of Agile. Agile was also all about “empowered teams” that uplift product managers, scrum masters and developers as equal partners, but if you talk to most big tech engineers they feel more like modern-day factory workers than key decision makers.
What Worked and What Didn’t
So why did Agile fail? In short, the process was both not robust enough and overbearing at the same time.
There is a real problem in software called the “gulf of evaluation”, where requirements are misunderstood and miscommunicated continuously, creating products that don’t truly solve the user’s needs (best described by the photo below).
The issue is that scrum solves for this by adding more meetings to discuss requirements because everyone’s definition of what “good” looks like only exists in their heads. Development teams rely on lengthy, time-consuming Product Requirement Documents (PRDs) to clarify requirements, which then need to be translated into UX wireframes, which then don’t accurately capture how a user will interact with the platform. Agile champions “working software over comprehensive documentation”, but ironically hinges on fully-fledged PRDs to actually build anything.
Lastly, although Agile has solid prioritization frameworks like MoSCoW and RICE, these aren’t robust enough for enterprise-level prioritization across teams. This is a topic of its own that we’ll cover another day, but for now just know that the problem exists.
How To Use AI Tooling to Fix It
If you work in tech (or want to), by now you know that AI is changing the world and so I’ll spare you the platitudes about how the technology is revolutionary. Instead, this will be a specific set of steps that you can use to bring your software practices to the 21st century. This is intended both to be for individual contributors who are part of the team and for team managers who are looking to build faster, better and more useful software.
Step 1: Empower Your PMs to Become “User Evangelists”
“AI is making PMs more important than ever” - Christopher Payne, President of Doordash, former CEO of Tinder and creator of Bing
The definition of products has always started and stopped with the product manager, but with AI they now have more control, and thus more responsibility, over their vision than ever before. Prototyping and low-code software like Cursor, Bolt, Replit and v0 enable Product Managers to close the gulf of evaluation by creating real versions of their ideas that customers can actually interact with and that the rest of the design and engineering team can truly visualize and understand.
PM leaders should be able to test their hypotheses by creating versions of products people can test. This can work with tools that create full products off of individual prompts like Bolt, but works best when PMs have enough technical ability to work with IDE-based AI tools like Cursor and Cline because you can achieve a higher degree of specificity in how you lay out the user experience with these tools. We’ll be releasing more detailed guides on how to use these tools as well.
Step 2: Test With Growth and UX
Agile talks loosely about the concept of customer validation, but doesn’t talk in too much detail about how to actually do this. We’re going to take this a step further by actually combining customer validation with go-to-market strategy in a controlled fashion that enables you to get true feedback.
The actual implementation of this can vary significantly based on both the products and the types of teams you work on, but we’ll cover some broad topics and methodologies. At a high-level, product managers should act almost like UX researchers, especially in teams where they don’t have dedicated UX resources, which is surprisingly almost all of them.
But how do you get the users to conduct research with? For B2C environments, you’ll want to try and get actual consumers who are within your ICP and can benefit from your product. Friends and family work, but you’re more likely to get the right feedback if you get users who don’t know you personally through real acquisition channels. The fastest way to do this is going to be through social media and content. Creating content enables you to reach people at scale and establish authority in a way that can then get you their good graces. Even if you have to run a small Facebook ad campaign or TikTok influencer campaign, the money will be well spent if you can get engaged users who are willing to be part of the user study group.
For B2B, ideally your company already has contracted users who are willing to use your products, but you can generally incentivize them by telling them you’re doing this to make their jobs easier.
In both cases, you should probably offer something in exchange for their time because usually the potential of your software helping them down the line isn’t enough to sway them. At Nayru, we’ve regularly offered people free resume reviews in exchange for their time.
When you can get these people into a room to use your prototypes, you’ll want to observe their behavior. What do they click on? Where do they go wrong in the user flow? Where do they want more information or help? These insights serve as enough lightweight UX research to get better insights on where your product works or doesn’t.
Step 3: From Prototype to Design
Now that the team has a working prototype that actually matches their product vision and has been tested by real users, they can loop in design resources to be able to turn this vision into high-fidelity. You might be asking, if we have prototypes already, why do we still need to do design? The purpose is to make the build process as clear as possible for the engineers.
Designers can now take detailed user feedback from the study you’ve done and make it beautiful. Companies or teams often have specific design libraries they leverage, so incorporating design after user validation and growth enables the team to move forward with the clearest vision possible.
Step 4: Build and Release
Traditionally, engineering teams have often needed to wait until the PM finishes the PRD to begin creating the actual product. However, now because prototyping software enables PMs to create visuals in minutes and hours instead of weeks, engineers have enough detail to start building basic backend components for the software so that, by the time the UX is aligned upon, a lot of the platform’s base infrastructure is finished. It’s important to keep clear communication to avoid engineering teams from getting too far ahead or building in the wrong direction, but base components like databases and scaling architecture can be built as soon as there is an understanding of who the product is for.
Closing Notes
It’s clear that Agile needs a refresh, and we’re looking for teams to partner with to help improve this new model. Whether you have suggestions for improvements, horror stories about Agile or you like what you’re reading, we want to hear your thoughts. Feel free to shoot me a message in our PM community below and let’s chat:
Nice write up, Nabeel.
Check out https://zentrik.ai/ to see how we have put that theory to work!
Maybe I'm totally missing the point here, so feel free to tell me if I'm nuts …
I try not to get wrapped up in frameworks or project management in general, but there are just so many gross misunderstandings in this article. I think you'd be better off asking Claude to explain how Agile and GenAI relate.
Agile is a project management framework for the development process. It has little to do with prioritization. It is not a product management methodology at all. And, by design, it's not concerned with user testing or GTM.
PRDs are not part of Agile and never have been. That's a mash-up of waterfall and agile that I lovingly refer to as Fragile. Frankly, I don't think PRDs have a place in Product Management either.
"… but works best when PMs have enough technical ability to work with IDE-based AI tools like Cursor and Cline because you can achieve a higher degree of specificity …"
Why would the PM spend their time on technical specifications? Better to work on the strategy, business viability, and job stories. Why bother dictating things that your Eng counterparts can better solve?
"Agile talks loosely about the concept of customer validation, but doesn’t talk in too much detail about how to actually do this."
That's because Agile isn't a methodology for user research. It's a system for dealing with the incremental changes that are logically a part of the process when someone else is covering user testing.
"Now that the team has a working prototype that actually matches their product vision and has been tested by real users, they can loop in design resources to be able to turn this vision into high-fidelity."
"Traditionally, engineering teams have often needed to wait until the PM finishes the PRD to begin creating the actual product."
You've been working in some very broken product development environments. Yes, those things happen all the time in companies all over the globe, but they are certainly not best practice and no experienced practitioner would advise you to take that waterfall-style path.
The explosion of AI services is absolutely changing the Product landscape, but not in the murky way you've outlined here.
Spend some time reading up on Lean Product and Continuous Discovery. People like Marty Cagan and Dan Olsen wrote the book on this stuff long ago. And a new generation of leaders is building on their legacy, like Leah Tharin, Teresa Torres, and John Cutler (among many others). With a deep understanding of Product methodologies and GenAI's capabilities, it will become obvious how to leverage new tools as multipliers.
I'd tell you to read up on Agile but, unfortunately, the internet is littered with articles like this.