What is Agile Product Management?
Regardless of the methodologies employed or the environment where they work, the fundamentals of being a product manager shouldn’t really change. Product managers are responsible for creating a product strategy in collaboration with their stakeholders and securing organizational buy-in and alignment.
They then determine how to pursue that strategy and its related goals and objectives by prioritizing different initiatives, many of which they identify by using quantitative and qualitative research tactics. These elements of the product intend to delight customers, illustrate the product’s value, build loyalty, and generate revenue (or whichever other KPIs the organization values). They’re typically organized and presented to stakeholders in a product roadmap.
Agile or waterfall, the above, high-level view of the role doesn’t change. It’s what happens next where things diverge. 
Open to interpretation
In a traditional waterfall environment, product managers would then create detailed product requirements documents, listing out every parameter of the feature, use cases, acceptance criteria, and maybe even wireframes or mockups.
The modus operandi here is “build me exactly what I asked for.” UX and product development would grab the baton, get to work, and after weeks or months, pass it off to QA. Product releases are spread out, scheduled, and, in most cases, things don’t ship until they’re complete.
But in an Agile world, the organization follows a different path once everyone agrees on the strategy. Instead of being handed a paint-by-numbers picture of what to build, UX and product development instead play a more active role in determining what gets made.
Product management is still generating requirements, but these more often come in the form of user stories. “A current user can invite their friends to try the product” or “after purchasing something, a customer can review their purchase to inform other potential buyers.”
Sometimes there will be user personas attached to these stories, so now it’s “Bob” a 17-year-old gamer who spends time on Twitch and TikTok, or “Nancy” a 39-year-old suburban mother of three who volunteers at the food pantry.
Presented with these user stories and personas, the entire team determines the best approach to helping the “user” accomplish the task specified in the story. Product management doesn’t spell out in advance where reviews for each product listing will reside or the prompts for how purchasers can leave a review. That’s determined collaboratively during the actual development cycle.
Small steps vs. giant leaps
Another critical difference between Agile and waterfall is the inherently iterative nature of Agile development. In contrast, traditional product development was all about building a finished product before it hit the market, while Agile prizes incremental progress.
Agile product development typically breaks work out into sprints versus releases. Cadences may vary, but the basic idea is that you chunk work up into sprints, which typically span two-to-four weeks. Assuming that the output of the sprint is ready for prime time, the new code is released after passing acceptance testing.
This significantly reduces the time between when work commences and when users start seeing value. It also shortens the feedback loop, letting the team see what’s working and what doesn’t before factoring that into the next iteration of a given feature.
By investing smaller chunks of time and resources into an initial phase, organizations can be more reactive to market demands and competition while simultaneously creating a “finished” product that reflects what’s been learned from earlier releases. It also allows companies to “cut bait” if a particular endeavor isn’t panning out, allowing them to pursue a different approach or abandon that initiative altogether.
This approach creates a nimble and responsive approach to product development that is particularly well suited for software and web-based solutions. It’s easy to continually churn out updates that automatically install and are used by the majority of customers. Agile is less likely to experience the benefits of a feedback loop since no one is releasing a new version of hardware or major enterprise solutions every few weeks.
This expediency and efficiency have driven organizational adoption of Agile principles at record rates. Competitive pressures, accelerating growth, and maximizing revenue generation are worth shaking up the status quo.
The History of Agile and the Manifesto
Agile is an iterative product-development methodology. Teams work in brief, incremental “sprints,” frequently regrouping to review the work and make changes.
The Agile method encourages frequent feedback. It boasts the ability to switch focus and priority quickly in contrast to the more traditional, sequence-based, waterfall methodology. Long-term plans are split out into discrete phases for execution.
The Agile Software Manifesto was published in 2001, fresh on the heels of the dot-com boom. Startups began using the promise and potential of the Internet to disrupt established industries.
Investors poured billions into unproven concepts. Inexperienced leaders and freshly minted MBAs helmed companies. Revenue streams and profits took a backseat to growth and “eyeballs” as indicators of success. And then it all crashed.
But during those heady days before the fall, the disruptors figured out that even though “we’ll make it up in volume” wasn’t a winning business model, the old way of doing business didn’t work.
Top-down bureaucracy couldn’t react to changing market conditions. They couldn’t seize opportunities like the nimble teams assembled for specific projects then reconfigured as needed in the future. Five-year plans were pointless when you couldn’t predict what would happen next week. And innovation was being choked by process and procedure.
As organizations saw Agile teams outperforming their waterfall brethren, they hired Agile consultants and coaches. They were desperate to tap into the same ingenuity that led battlefield commanders to delegate decision-making to the actual teams in the field.
Agile has now been embraced by non-technical parts of organizations, as well. Nearly every industry has its examples of Agile transformation. They’re all seeking to more dynamically and efficiently address their challenges and needs.
What are Agile Principles?
There are 12 Agile principles. A dozen mantras to guide teams seeking increased responsiveness, productivity, and efficiency. Among this list of principles, the basic idea is:
- Satisfying customers by delivering value as quickly as possible.
- Acknowledging and embracing the ongoing changing dynamics of business and the need to adjust them rapidly.
- Speed, collaboration, and transparency are the secrets to meeting market demand.
- Simple-yet-well-designed solutions are crucial to continuous delivery and adaptation.
These principles are followed by:
- Breaking down large projects into smaller chunks.
- Leveraging self-organizing teams to address challenges.
- Relying on face-to-face communication (versus detailed specifications) to facilitate the rapid pace of innovation.
Agile Roadmapping vs. Waterfall
In a traditional waterfall environment, roadmaps lay out long-term plans and strategies in pretty specific terms. While things may change based on unforeseen developments, the general idea is that what’s spelled out for the next 12-24 months is what’s going to happen.
Those product roadmaps provide lots of value, as various departments can plan accordingly. Whether it’s plotting marketing campaigns, hiring staff with specific skills, or stocking up on a particular inventory, people can prepare for what’s coming.
But the predictable nature of waterfall-based product roadmaps is also what makes them so unpopular among the Agile crowd. When the guiding principles are speed, adaptation, and flexibility, a rigidly plotted course goes against the grain of that mindset.
This mantra has to lead many to wonder if Agile needs product roadmaps at all. But this is a mistaken belief, as product roadmaps are essential for conveying the product strategy (even when they’re light on exact dates and deliverables).
That’s why product roadmaps in an Agile setting are less prescriptive and concrete. It’s also why themes are their primary ingredient, not features.
These product roadmaps don’t define what to build and when. Instead, they guide the strategy and envision desired outcomes, but not the actual plan.
In Agile, the details and minutiae are relegated to the implementation phase. Agile product roadmaps alternatively serve as guiding documents rather than restrictive barriers to innovation. They’re still directional, but they don’t concentrate on the exact route or timetable.
Build your own agile roadmap with our free template ➜
Pros and Cons of Agile Product Management Roadmapping
Like anything else, Agile product roadmapping has both positive and negative aspects. Their value or deficiency depends on each particular situation.
Pros
- Alignment—In a fast-paced setting where independent teams race to deliver value, it’s easy for each group to miss the forest for the trees. Product roadmaps provide some broader guiding principles and objectives that everyone is aware of, reducing the chances of things going awry or not fitting together.
- Explaining the “why”—An Agile product roadmap doesn’t care how the product gets where it needs to go. But it does communicate why the selection of each outcome in the first place. Vision-first product roadmapping accurately shifts the emphasis away from features and onto outcomes. Agile product roadmaps also capture the narrative, crafting a cohesive story despite multiple teams simultaneously building different things.
- Executive visibility—Senior management doesn’t attend daily standups to get the details on each team’s projects. A product roadmap provides some big-picture connectivity and context around the team’s initiatives.
- Transparency—Agile thrives in an environment where everyone knows what’s happening. A product roadmap is an excellent way to share that widely and consistently.
Cons
- Yesterday’s news—When the Agile process is humming, teams are always taking action and making decisions. This nimbleness means a roadmap could get outdated pretty darn quick. If it’s too specific or detailed, an Agile roadmap becomes an “artifact” in a negative sense pretty fast without regular updates—another reason for including themes and goals versus particular features.
- Unfulfilled promises—The dynamic nature of Agile product management sometimes leads a product in such completely new directions that the product roadmap isn’t just outdated, but flat-out wrong. An incorrect product roadmap could lead to some grumpy customers and stakeholders if not managed well and updated and shared promptly.
- Undated by nature—Anyone expecting a product roadmap to inform them when to expect a feature or functionality to be available will be disappointed by an Agile roadmap. Squashing these expectations is a critical phase in transitioning to Agile.
- Resistance to long-term planning—Some misguided Agile adherents think being Agile is incompatible with having a long-term strategy, but that’s simply not true. A product roadmap spanning several quarters or years might irritate some diehards that don’t think anything should be set beyond the next sprint.
Build a Visual Product Roadmap ➜
Making the Transition from Waterfall to Agile
Agile transformation is not something that should be spearheaded by product management, but product managers have both a vital role to play and will feel a major impact by the switch.
Product roadmaps are another area where the transition from waterfall to Agile is extremely disruptive. The old ways of building product roadmaps don’t often translate well to this new world. Micromanagement and minutiae are replaced with broad themes and high-level goals.
However, the product roadmap in some ways is more important than ever in an Agile environment. It is a guide and reference point when so many other elements are in flux. Stakeholders and Agile teams alike will look to it for inspiration and direction, making their accuracy and accessibility a top priority.
At the same time, Agile brings an unprecedented level of uncertainty in the planning process. Organizations at least tell themselves in a waterfall environment what the future holds and how the product will address it.
Agile’s foundation is rooted in acknowledging that the future is largely unknown, so companies must be prepared to respond quickly and change course as needed. To match this, product roadmaps should have shorter time horizons and leverage themes to incorporate the learnings ascertained through increased customer and prospect feedback.
Product managers often find themselves gravitating toward Kanban-style roadmaps and tools versus linear ones, as they better fit the new decentralized, fluid approach to product development and innovation. Kanban tools also provide a quick reference for product managers when asked what’s happening with a particular initiative.
Making the most of each sprint
Short, frequent bursts of productivity should be a huge bonus for product managers eager to deliver value to new and existing users. Sprints cut the time between ideation and deployment while simultaneously enabling ongoing optimization, attributes prized by customer-centric product teams.
Sprints also shine a spotlight on the value (or lack thereof) of their contents. When 100% of the product development team dedicates time to a single initiative for one (or two or three) sprints, there’s even more urgency to determine the ROI of the endeavor. Unlike a big release with a jumble of features, that singular focus forces a reckoning of whether it’s worth it.
But maximizing the value of every sprint requires proper team composition, role assignment, and process structure. Product managers have an important part to play in this by clearing everyone’s plates of distractions and continually seeking improvement via sprint retrospectives to repeat what worked and change up what didn’t.
One technique valued by many Agile product managers is utilizing the Agile Planning Onion. By starting big with a Vision, then getting progressively more specific with a Product Roadmap, then a particular Release, then an Iteration, before finally reaching Daily activities, product management can bridge the gap between long-term ideals and day-to-day execution.
It also enables Agile Product Leaders not to immerse themselves in every detail and nuance of the product development cycle. While some may enjoy getting into the weeds, product leaders must remain focused on the big picture and keep an eye on the future.
Keeping up with continuous delivery
The end game for some organizations diving into Agile is continuous delivery. That means shipping code as soon as the bits are dry instead of ever waiting for a sprint to wrap up.
Continuous delivery and product roadmaps seem even less compatible than “regular” Agile, but the same truths apply. Code might always be shipping, and precise release dates hard to nail down, but coders aren’t operating entirely independently and following their random whims.
No matter how frequently a product is updated, those improvements should be driven by the themes, goals, outcomes, and KPIs that the organization has prioritized. So there’s still ample opportunity for product roadmaps to serve their intended purpose of aligning and guiding development activities. It just shortens the feedback loop even further to maximize the value of what folks are building.
Does Agile Conflate Project and Product Management?
Distinguishing between project management and product management shouldn’t be any more difficult in an Agile environment than anyplace else. Both roles have very different parts with minimal overlap, joining forces to bring the product vision to life.
By definition, product managers work on the “why” and “what” aspects of the problem. What’s the mission and reason for being? Why would someone want to use this product? What problems are they trying to solve? What does this product need to include to address market needs?
Project managers worry about the “who” and “when” and “how” parts of the equation. They know what they’re trying to accomplish (thanks to the product manager). They must juggle the available resources and schedule to make it all happen as fast as possible. In some ways, transitioning to Agile is far more disruptive to project managers, who relish predictability, routine, and schedules, more than product management.
These are two distinct roles, but in an Agile setting, there’s no formal handoff. Product managers don’t hand over a requirements document and walk away, leaving the rest up to the project manager.
In Agile, product managers remain very much involved throughout the process. They attend face-to-face meetings, give explanations, and provide feedback all along. Their availability and interactions with the rest of the team are essential to producing useful deliverables at a steady clip.
Of course, some organizations might misconstrue these jobs. They could ask a project manager for a strategy or a product manager to work on a schedule.
But in a setting with well-defined roles, the two work together with minimal overlap in responsibilities (although sometimes project managers do eventually switch to product).
Takeaways
If an organization hasn’t already begun dabbling in Agile, they likely will soon. It could just be adopting a few friendly concepts such as daily standups and shorter release cycles. Or maybe it will be a full-on embrace of all 12 principles.
As expectations for results grow, the demand for organizations to be more efficient and responsive will only increase. No one wants to stick with a plan for years just because “that was the plan.”
Agile may shake the foundations of long-tenured product managers used to a certain way of doing things. The routines, ceremonies, and cadences of Agile make some product managers feel that it makes things predictable.
