Why are product managers still using agile?

Ah, Agile—the buzzword that just won’t quit. It’s been the darling of software development for years, promising flexibility, speed, and a better way to build products. But here’s a cheeky thought: Why are product managers still using Agile?

Don’t get me wrong; agility is essential. But sometimes, it feels like we’re trying to fit a square peg into a round hole, especially when it comes to product management. We continue to attempt to fit a delivery focused methodology into outcome-based work… and we seem to never learn our lesson.

The limitations for agile are prevalent for discovery, an overlooked part of product management for many years. How does agile help to support a workstream that is primarily focused on research? Can it? Read on to find out.

Agile vs. agility: What’s the difference?

Let’s start with the first problem here: Agile is not the same as agility.

Agile is a methodology that focuses on small iterations. Instead of waiting for something to reach its ‘done’ state, you release things little by little and start gathering feedback as you see how people respond. It’s about breaking down the work into manageable chunks and iterating based on feedback.

Agility, on the other hand, is how quickly you get those things out the door. It’s about speed and responsiveness—the ability to adapt swiftly to changes, whether they’re from customer feedback, market shifts, or new strategic insights.

In other words, Agile is about output (and possibly how agile a team can be within that environment), whereas product management is about outcomes.

And that’s where things get a bit messy for product managers. But let’s proceed.

Agile in product management vs. delivery

When Agile methodologies first emerged, they were primarily designed with software development teams in mind. The Agile Manifesto, crafted by developers, focused on improving the efficiency and adaptability of delivery processes. It emphasized principles like customer collaboration, responding to change, and delivering working software quickly. However, it didn’t explicitly incorporate product management into its framework.

Product management is all about understanding and solving customer problems, defining the product strategy, and ensuring that the product delivers value to both the customer and the business. In Agile environments, the product owner role is often considered a subset of the product management role. The product owner is responsible for representing stakeholders and defining the product backlog—the prioritized list of features and requirements that the development team will work on.

Because Agile didn’t account for product management roles, product managers often struggle to align their discovery and strategic activities with the development team’s Agile processes. This can lead to misalignment between what’s being built and what customers actually need.

Of course, as we know, the product owner role is still widely misunderstood, and often still exists in non-Scrum environments. Sometimes there is no product owner, and the product manager ends up having to pick up those responsibilities.

So can product management actually coexist with Agile?

Including product management in Agile

Even though product management wasn’t originally part of Agile, it’s possible to integrate it.

Do product managers need Agile? Well, no.

Again, Agile is a delivery framework… but it doesn’t hurt to be more aligned to what engineers are working on and keep the ship sailing smoothly, so to speak.

Below are a few ways to help product teams be a bit more Agile:

Dual-Track Agile

Dual-track Agile is a new methodology that provides a discovery track that runs parallel to the delivery track and focuses on product discovery activities. Product managers, designers, and user researchers collaborate to explore customer needs, validate ideas, and prototype solutions. This track is flexible and doesn’t operate on the same sprint cycles as development.

Once ideas are validated in the discovery track, they’re handed off to the development team in the delivery track to be built and shipped using Agile methodologies.

Dual-Track Agile allows product teams to remain agile in their strategic planning and discovery while ensuring that development teams can maintain their Agile delivery processes. It bridges the gap by acknowledging that discovery and delivery have different rhythms and requirements but need to stay aligned.

This image, and one of our favorite articles we've found on this topic is entitled 'dual track development', by Jeff Patton associates.

Stay tuned!! Our own take on the dual-track agile methodology is coming soon.

Continuous Discovery

Another approach is continuous discovery, which emphasizes making customer research an ongoing part of the product management process rather than a one-time effort. Continuous discovery involves regularly conducting interviews, running experiments, and gathering feedback to inform product decisions.

This practice aligns with the Agile principle of responding to change by allowing product managers to adjust the product vision and roadmap based on real-time insights. By continuously feeding new, validated ideas into the delivery pipeline, product managers ensure that the development team is always working on the most valuable features.

Automating discovery

Finding participants for user research can be time-consuming, but automating your participant backlog can streamline the process significantly. Start by leveraging your team members who are already in touch with customers, like sales teams that interact with prospects daily and can identify potential participants. Marketing teams have access to customer demographics and engagement metrics, making it easier to target the right audience. Customer Success teams know which customers are most engaged or facing issues, providing valuable insights for user research.

In addition to internal resources, use recruitment panels like TestingTime, Respondent.io, and Wynter. These platforms help you connect with a broad range of participants quickly, whether you’re looking for general users or specific professional profiles. There are also analytics tools such as Segment, Userpilot, and Sprig that can help you identify user behavior patterns and engage users directly within your product. This data-informed approach allows you to gather feedback at scale without excessive manual effort.

Adopt Agile-like ceremonies

While traditional Agile ceremonies are geared towards development, you can adapt them for discovery to product in order to create collaboration and maintain momentum. Begin with effective planning sessions to set clear objectives for your discovery efforts, defining what you want to learn in each cycle. By time-boxing activities, you create a sense of urgency and focus, ensuring that the team remains engaged and productive. (I myself prefer to timebox how long discovery or measuring data will go on for, in order to maintain a certain baseline.)

Regular retrospectives are also valuable in the discovery phase. They provide an opportunity to reflect on what you’ve learned, assess the effectiveness of your methods, and adjust your strategy accordingly. This promotes continuous improvement and helps the team stay aligned with overarching goals.

Embrace the notion of Squads

Breaking down silos is essential for any successful team – output or outcome focused. Form cross-functional squads that include product managers, designers, engineers, marketing, and sales. This multidisciplinary approach ensures diverse perspectives and fosters collaboration, accelerating the discovery process. Teresa Torres, for example, has suggested the product trio to maintain the product team more aligned. If I’m allowed a brief opinion, I think that should be extended to a quadruple, and include your product marketer in any strategy-focused work.

Including the right people means you’re more likely to identify valuable opportunities and potential pitfalls early on. It also ensures that everyone is on the same page, reducing misunderstandings and streamlining decision-making.

Embrace hypothesis-driven development

Formulating clear hypotheses for new features or product ideas provides a focused approach to product discovery. By stating what you believe will happen, you create a benchmark for success. Collect data from experiments and user feedback to test said hypothesis. If the data doesn’t support your hypothesis, be prepared to adjust your approach. Now you’ve got both Agile and agility rolled up into one. Bazinga.

How Agile has affected the tools we use

Let’s be honest—many of the tools we use are designed with delivery in mind, not product management. Tools like Jira are great for tracking development tasks but are not ideal for deep product discovery. Even attempts to bolt on discovery modules, like Jira Product Discovery, often feel like afterthoughts. Sorry, not sorry.

This mismatch means we’re trying to fit our discovery processes into tools that weren’t built for them, which can hamper our ability to do the job right. It’s like trying to use a hammer when you really need a screwdriver. Many have tried, very few, in my opinion, have gotten anywhere near a level of success.

The solution is to embrace tools tailored for discovery. And yet there is the problem, product managers cannot be entirely disconnected from the delivery process. We still need to understand what is happening, why, and dare I say, when. We have features to build, sometimes even deadlines to hit, and most certainly stakeholders to build relationships with.

Conclusion

So, why are product managers still using Agile? Maybe it’s out of habit, or perhaps we’re just creatures of comfort clinging to familiar frameworks. But as we’ve explored, Agile methodologies weren’t designed with product managers in mind. They focus on output and efficiency—great for developers, not always so great for those of us steering the product ship toward meaningful outcomes.

Remember, being agile doesn’t mean strictly adhering to Agile. It’s about staying responsive, adaptable, and focused on delivering real value to our customers. Let’s use the tools and practices that empower us to do just that—even if it means stepping outside the traditional Agile playbook.

After all, our goal isn’t just to build products faster; it’s to build the right products that make a real impact. So let’s be agile in a way that makes sense for us as product managers. Who knows? Maybe it’s time we wrote our own manifesto.

LOL, jk.