Product managers in the insurance industry need to angle their roadmaps to focus on the maintenance as well as the enhancement of their existing products. More →…
What is Agile Product Management?
If you’re unfamiliar with Agile product management, it can seem overwhelming and intimidating. Linear, waterfall development approaches have been the norm for a long time. There is such a strong legacy of this practice that shaking things up seems unthinkable.
But organizations have been adopting Agile in droves because they can’t afford to wait two years to see if their plans are winners and won’t wait nine months to respond to customer requests. They can’t wait three months to roll out a competitive feature and won’t wait six weeks to deploy a couple of bug fixes and tweaks that address burning pain points.
Agile product management may not be perfect, but it has permanently changed how organizations approach product development and going to market. Along the way, customer expectations have changed with it. But what does Agile mean in practice? Here’s a decoder ring to cut through the hype and into the meaning.
Agile is an iterative product-development methodology. Teams work in brief, incremental “sprints.” They frequently regroup 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. In those cases, product managers set long-term plans in discrete phases for development teams to execute.
What’s 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 had figured out that even though “we’ll make it up in volume” wasn’t a winning strategy, 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 and 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 looking to become more responsive, productive, and efficient. We won’t reprint the entire list here, but 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.
What Makes Agile Roadmapping Different from the Waterfall Approach?
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 agile 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 clearly prepare for what’s coming.
But the predictable nature of waterfall roadmaps is also what makes them so unpopular among the Agile crowd. When your guiding mantra is speed, adaptation, and flexibility, a rigidly plotted course goes against the grain of that mindset.
This mantra has lead many to wonder if you need an Agile roadmap at all (spoiler alert: you do). That’s why roadmaps in an Agile setting are less prescriptive and concrete. It’s why themes are the primary ingredient instead of features. They don’t define what to build and when. Instead, these roadmaps guide the strategy and envision desired outcomes.
Leave the details and minutiae to the implementation phase. Agile roadmaps then serve as guiding documents instead of restrictive barriers to innovation. They’re still directional, but they don’t worry so much about how you’ll get there.
Pros and Cons for Agile Product Management and Roadmapping
Like anything else, there are positive and negative aspects of Agile roadmapping. Their value depends on each particular situation.
- Alignment—In a fast-paced setting where independent teams are racing to deliver value, it’s easy for each group to miss the forest for the trees. With some broader guiding principles and objectives that everyone is aware of, there’s less chance of things going awry or not fitting together.
- Explaining the “why”—An Agile roadmap doesn’t care how the product gets where it needs to go. But it does communicate why you’re trying to get there in the first place. Vision-first roadmapping accurately shifts the emphasis away from features and onto outcomes. Agile roadmaps also capture the narrative, crafting a cohesive story despite multiple teams simultaneously building different things.
- Executive visibility—Senior management isn’t going to be attending daily standups to get the details on each team’s projects. A roadmap can provide some big-picture connectivity and context around the team’s initiatives.
- Transparency—Agile thrives in an environment where everyone knows what’s happening. A roadmap is a pretty good way to share that widely and consistently.
- 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.
- Unfulfilled promises—The dynamic nature of Agile product management can sometimes lead a product in such new directions the roadmap isn’t just outdated, but flat-out wrong. If your roadmap is wrong it could lead to some grumpy customers and stakeholders if not managed well.
- Undated by nature—Anyone that expects a roadmap to inform them when to expect a feature or functionality to be available, they’ll be disappointed by an Agile roadmap.
- Resistance to long-term planning—Some misguided Agile adherents think you can’t be Agile and have a long-term strategy. That’s not true. A roadmap might, however, irritate some diehards that don’t think you should set anything beyond the next sprint.
Does Agile Conflate Project and Product Management?
Short answer: No. Longer answer: It shouldn’t.
By definition, product managers work on the “why” and “what” aspects of the problem. What’s our 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 are worrying about the “who” and “when” and “how” parts of the equation. They know what they’re trying to accomplish. They must juggle the available resources and schedule to make it all happen as fast as possible.
These are two distinct roles, but in an Agile setting, there’s no formal handoff. The product manager is still very much involved throughout the process. They attend face-to-face meetings, explain things, and provide feedback all along.
Of course, some organizations might misconstrue these roles. 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).
Misconceptions of Agile Product Management
Agile’s widespread adoption and disruptive nature has created some false narratives and confusion for agile product management. This confusion is sometimes the case even among those who have embraced it. Here are a few common fallacies we can dispel:
- 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—Although it’s excellent for those settings, some of the biggest, oldest companies in the world are using Agile. GE uses it, Philips uses it, IBM uses it. Yes, even giant multinational firms can reap its benefits. It’s a great method for shaking up stale processes and breaking down silos.
- Agile means there’s no plan—Agile is useless without a long-range plan and goals. It breaks it down into smaller components and completes those as efficiently as possible.
- Agile means there’s no documentation—If you’re moving fast, there’s no time to write anything down, right? Actually, there’s no shortage of documentation in an Agile environment. Because team membership itself is dynamic, someone must be able to drop into a situation and be productive immediately. That is often impossible without great documentation. There may not be a laminated user’s manual since it’s always introducing new functionality 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. They can’t dictate implementation. Everyone still gets a designated and defined role, and projects get supervised. But there’s less command-and-control-style management of the individual teams.
- Agile sacrifices quality for speed—If the organization values quality, Agile doesn’t make it go away. You can incorporate QA, beta testing, and the like throughout the Agile process.
- Agile doesn’t work when there’s a hard deadline—The reactive and responsive nature of Agile doesn’t preclude working towards specific dates. In fact, 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 when they meet their objectives and reach their goals, there’s no rule against shutting things down. Agile gives organizations the ability to shut things down faster, in fact. There’s always an imminent release that can be designated the “last one.” They can then reallocate those resources to other Agile teams for different projects.
- It’s all or nothing— People may talk about Agile like it’s a religion. There are no hard-and-fast rules against adopting only parts of it or integrating it with new processes and approaches.
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.”