Agile product management might be the “new kid on the block” compared to linear, waterfall development, but the Agile Manifesto was published two decades ago. Since then, Agile has infiltrated not just software development but many other industries.
Its appeal is apparent—shortening timelines, maximizing productivity, empowering agile decision making, and creating autonomy—yet it comes with tradeoffs. There’s something comfortable and reassuring about the old way and its command-and-control, predictable nature of product development.
But the ability to rapidly respond to shifting market conditions and quickly incorporating new technology has made Agile too tempting to resist for many. Combined with increased experienced Agile practitioners eager to transplant their favored methodologies to new workplaces, along with consultants and coaches ready to ease the transformation, Agile has become a certainty in most industries.
While this Agile wave has shaken up the status quo for many disciplines, product managers have been uniquely impacted by Agile overtaking their corporate cultures. The role’s processes, artifacts, and traditions have been upended, with old-timers scrambling to adapt while newcomers see Agile as how business gets done.
Agile product management comes with new rules, new tools, and new expectations. The learning curve isn’t quite as steep as it may seem for both newcomers and veterans.
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 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 using quantitative and qualitative research tactics. These product elements intend to delight customers, illustrate the product’s value, build loyalty, and generate revenue (or 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 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 pass it off to QA after weeks or months. Product releases tend to get 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 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 about building a finished product before it hit the market 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.
Sprints 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 things 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.
The 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 most 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.
The 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.
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. Teams split out long-term plans into discrete phases for execution
The History of Agile and the Manifesto
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.
12 Agile Principles
There are 12 Agile principles. A dozen mantras 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 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. People can prepare for what’s coming, whether it’s plotting marketing campaigns, hiring staff with specific skills, or stocking up on a particular inventory.
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 relegate 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.
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.
- 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 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.
- Yesterday’s news—When the Agile process is humming, teams always take action and make 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 grumpy customers and stakeholders if not managed well, updated, and promptly shared.
- 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 not true. A product roadmap spanning several quarters or years might irritate some diehards that don’t think beyond the next sprint.
Making the Transition from Waterfall to Agile
Agile transformation should not 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 highly disruptive. The old ways of building product roadmaps don’t often translate well to this new world. High-level goals replace micromanagement and minutiae.
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 what the future holds and how the product will address it in a waterfall environment.
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. Product roadmaps should shorten their time horizons and leverage themes to incorporate the learnings ascertained through increased customer and prospect feedback.
Product managers often gravitate 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 mission 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. These sprints attributes are 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, the singular focus forces a reckoning of whether it’s worth it or not.
But maximizing the value of every sprint requires proper team composition, role assignment, and process structure. Product managers have an essential 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 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 are hard to nail down, but coders aren’t operating independently and following their random whims.
No matter how frequently a product is updated, those improvements should drive 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.
Misconceptions of Agile Product Management
Agile’s widespread adoption and disruptive nature have created some false narratives and confusion for Agile product management. This confusion is sometimes the case even among Agile’s biggest proponents. Here are a few common fallacies easily dispelled:
- Agile is just for software—It’s where Agile started. It’s particularly well-suited for digital-versus-physical product development. But all sorts of organizations use Agile. NPR uses it to develop their programming, and the legal team at Lonely Planet used it to streamline their workload.
- Agile is only for startups and small companies—Agile is a perfect fit for creating compelling MVPs and quickly tweaking early versions based on customer feedback. However, some of the biggest, oldest companies in the world are also now using Agile. GE uses it, Philips uses it, IBM uses it. Yes, even giant multinational firms can reap its benefits. It’s a great way to shake up stale processes and break down silos to drive innovation at the enterprise level.
- Agile means there’s no plan—Agile is useless without a long-range plan and goals. Agile merely breaks significant initiatives down into smaller components, completing those as efficiently as possible.
- Agile means there’s no documentation—When things move fast, there’s no time to write anything down. There’s no shortage of documentation in an Agile environment. Because team membership itself is dynamic, someone needs to drop into a situation and be productive immediately. That is often impossible without documentation. There may not be a laminated user’s manual since there’s always new functionality appearing, but there’s still room for (and a need for) documenting things.
- Agile = scrum—Scrum is a byproduct of Lean and eXtreme Programming. It is one particular project management approach but is by no means a set requirement of adopting Agile.
- Agile means everyone does what they want—Traditional top-down management can coexist with an Agile approach. The line of demarcation is dictating the implementation. Designated and defined roles remain, and projects get supervised. But there’s less command-and-control-style management of the individual teams, who are largely left alone to convert user stories and other prerequisites into functional components.
- Agile sacrifices quality for speed—If organizations value quality, Agile doesn’t eliminate that. QA, beta testing, and the like can operate throughout the Agile process. And Agile-built products still must keep on top of technical debt before it becomes a significant blocker.
- Agile doesn’t work when there’s a hard deadline—The reactive and responsive nature of Agile doesn’t preclude working towards specific dates. It can help organizations hit those dates by being dynamic in its approach to resourcing and problem-solving.
- Agile projects never end—Teams can certainly keep churning out additional releases. But after meeting objectives and reaching goals, there’s no rule against shutting things down. Agile gives organizations the ability to wrap things up faster. There’s always an imminent release that can be designated the “last one.” Freeing up those resources for different projects.
It’s all or nothing— People may discuss Agile like it’s a religion. But there are no hard-and-fast rules against partial adoption or integrating it with new processes and approaches.
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 within 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, 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, explain things, and provide feedback all along. Their availability and interactions with the rest of the team are essential to producing valuable 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 eventually switch to product).
Leading an Agile Team
Managing product teams in an Agile environment is different from more traditional product development environments in several key ways. Savvy product leaders recognize this and can position their team members—and themselves—for success with an intentional, thoughtful approach.
One significant difference between waterfall settings and Agile workplaces is the pace. There was once time and space for lengthy reviews and iterations of documents and specifications, with change requests shopped around for signature approval and no one deviating from extremely detailed instructions without good reason and discussion.
That isn’t an option in an Agile environment, where entire sprints may only last a couple of weeks, and developers and engineers need answers and clarifications ASAP to get their deliverables included in the next release. The option doesn’t mesh well with top-down, command-and-control management styles.
Instead, product leaders must empower their team members to become decisive subject matter experts to interact directly with product development to hash out issues and reach a consensus without incurring delays. The process requires both trust and clear communication and alignment within the product team itself.
Product leaders must have confidence that their lieutenants will accurately and correctly assess situations and make prudent recommendations and decisions based on their sound understanding of the product strategy, goals, and roadmap. The findings require strategic alignment at all levels and an objective-based product strategy that stakeholders of all ilks fully understand. When the engineers and product management are both on the same page regarding the product’s strategic direction, it’s easier for them to hash out minor details on the fly.
Delegating and entrusting team members to handle things independently may be uncomfortable, but it’s essential to creating a high-performing Agile product team. There isn’t the time or bandwidth for every decision to run up the chain of command to the department head, nor is that efficient use of everyone’s time. Giving teams frameworks such as DACI can help them navigate which decisions to make and when they must defer and escalate.
However, there should be an ongoing dialogue between product leaders and their team members. An open conversation will create awareness of those downstream decisions and ensure the entire team remains unified and aligned behind the current strategic goals and desired outcomes while keeping customer centricity top of mind. Creating this culture and hiring candidates capable of operating independently can dictate how successful an Agile product leader can be.
Agile Implementation at Product-Led Organizations
Product-led organizations thrive on a continual feedback loop. There may be projects, and those projects may be “done” at some point, but the products themselves are living, continually evolving entities. Accepting this reality and the understanding that there will always be another change, more capabilities to create, and additional customer challenges to solve is a must.
In addition, this extends far beyond the product development organization. It’s not about whether they’re building software in two-week sprints or three-month chunks. It’s about embracing lifetime learning and ongoing growth and change in what the product does, the use, customer, and sometimes even how it’s packaged and sold.
You must have a healthy appetite for uncertainty and change, which isn’t always well received by stakeholders throughout the organization. However, this isn’t surprising because it’s going to make their jobs harder. A lack of concrete plans for months and years to come makes it harder to budget, allocate resources, and anticipate the future, which can be uncomfortable and frustrating for people who cherish predictability.
But in a product-led organization operating in an Agile environment, there must be room to learn, grow, and adapt.
Agile also requires product management to divide and conquer. Once the product is large enough to have multiple development teams working independently, each team needs a product management counterpart as their point person.
While a product manager may be able to work with multiple teams at once, asking them to handle too many creates a scalability issue that might cause delays for implementation or inspire frustrated technologists to simple “go rogue” when they can’t get an answer quickly enough or if they don’t view product management as an engaged partner.
Product teams need to appoint individuals staffed appropriately so projects don’t fester while waiting for input or go astray. Thanks to a lack of regular interaction with product management. Collaborative tools in the product stack can also streamline things and create a more responsive and open environment.
Equally essential is a shared mental model for the product. The vision, goals, themes, objectives, customer personas, and optimal outcomes can’t solely “live” in product management. Product development needs to stay in the loop. They must be invested partners in this endeavor and share a standard view of where the product needs to go.
Hand-in-hand with that common mindset is the acceptance of the unknown. There’s no way to know how customers will react to new products and changes, nor any way to fully anticipate how their needs and situations will evolve.
Product leaders must navigate this ambiguity, appeasing wary stakeholders who prefer concrete plans and certainties over-educated guesses and caveated predictions. Relying on theme-based visual roadmaps is one way to shift the conversation and expectations from precise details and minutiae to the big-picture objectives, which are less likely to vary in the near term.
Integrating Agile at Every Point in the Product Life Cycle
Commonly, the term Agile refers to startups and technology-driven companies where engineers are the rock stars. But this mischaracterization does an injustice to the benefits Agile can bring to products at any stage.
For new products, the primary goals are establishing product-market fit and generating demand. This stage of the product life cycle often gets imbued with lots of trial-and-error and experimentation. This stage is an area where Agile brings a lot of value to the table.
Rapid iterations and build-learn-adjust cycles are imperative to finding the sweet spot for a new product, so devoting multiple sprints to this effort after introducing an MVP can cut down on time spent fiddling with user experience branding, and growth.
It’s all about seeing what sticks and then building on that, which is where Agile can facilitate the rapid expansion of customer value to make the product more appealing to a broader set of potential customers.
Once the product has some traction, it’s time to generate those hockey-stick growth curves senior leadership adores so much—most product organizations in this phase concentrate on increasing usage, conquering new markets, and generating revenue.
Agile’s short development cycles can facilitate a steady stream of minor improvements, whether it’s optimized user experiences, quashed bugs, or streamlined processes and performance. Each tweak can reduce friction, increase customer delight, and augment the value proposition that marketing and sales package for current and new markets.
There’s still a lot of learning as new users come aboard with their own unique set of circumstances and problems to be solved. At the same time, the product’s growing pains and shortcomings can be addressed. In short order as well.
When growth plateaus, products must shift focus once again, this time to efficiency. It’s all about reducing costs and maximizing profits from a relatively static user base while still throwing them enough bones to keep them engaged and putting out the fires that could cause them to jump ship.
Beyond optimization, new enhancements are selectively added to the product to keep loyal customers happy and increase usage within the established footprint and market the product has carved out. At the same time, defensive maneuvers need implementation as the competition looks to poach customers as the market becomes more of a zero-sum game.
Agile’s attributes are once again a benefit. Even though the technical resources dedicated to a mature product may shrink to customer-specific work, Agile product development teams can take on projects designed to maintain market share and address emerging issues.
Since the development cycles are short and most of these initiatives can squeeze into a sprint or two, product leaders can still ensure their top needs are getting some attention. If they can’t command the same army of engineers, they had at their disposal during those heady days of growth.
All things must end at some point, and products are certainly no exception. But Agile can help keep products afloat a little longer by squeezing out important releases via a relative skeleton crew that may not be 100% dedicated to the product.
They achieve this often by releasing functionality that stems the tide of churn and wins back a portion of the defectors by doing things like supporting new platforms or integrations that weren’t part of the landscape when the product was in its heyday. These precision moves can usually happen quickly. Updated and with minimal resources as Agile teams working on more promising products make a guest appearance.
Occasionally, a declining product may attempt to pivot to a more promising market or repurpose its technology and functionality to solve a new problem. In these cases, Agile’s ability to facilitate rapid experimentation and trial is once again a valuable asset to see if such a late-stage shift has the legs to succeed.
Preparing For and Embracing the Inevitable
Preparing For and Embracing the Inevitable
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.