Be more efficient and deliver what customers really want — that is the promise of adopting an agile development approach. Agile’s iterative, incremental methodology appeals to organizations that want to deliver value quickly to customers. Companies practicing agile want to gain valuable customer feedback with each iteration. Then they integrate that feedback into their agile product roadmaps to build better products.
So how do product managers build an agile roadmap to support agile development? The first step is to understand the purpose of an agile roadmap, and how it is different from a product roadmap developed by an organization using more traditional waterfall development methods.
A waterfall product roadmap communicates a long-term commitment to building specific features on a set timeline. However, an agile roadmap accommodates inevitable changes while still committing to getting meaningful work done. It communicates a short-term plan for achieving product goals, with the flexibility to adjust that plan according to customer value.
Here are some key ways that agile and waterfall roadmaps differ:
|Waterfall roadmap||Agile roadmap|
|Planning horizon||Years||Months or quarters|
|Resource / capacity planning||By major project||By small team|
Goals: Waterfall organizations often set business-centric goals, measured by financial KPIs. Agile organizations often set customer-centric goals, such as user growth and customer delight.
Planning horizon: A waterfall product roadmap reflects commitments to a longer-term timeline — typically a year or two. And an agile roadmap reflects quarterly (or even monthly) commitments.
Planning cadence: Waterfall organizations commonly do annual strategy and product planning. Agile organizations usually do it much more regularly in quarterly strategy and product planning cycles.
Resource / capacity planning: A waterfall roadmap reflects heavy upfront dedication of resources, which are allocated by project. An agile roadmap considers the sprint team the resource unit and can allocate by sprint velocity or team capacity.
Investment: Waterfall-driven products receive funding according to the organization’s annual planning cadence. These funds are committed for the year and are often based on the previous year. By contrast, agile-driven products can be funded incrementally as the organization adjusts its portfolio based on customer feedback and data.
Collaboration: In a waterfall organization, work is sequential and segmented — with one department’s phase typically unable to advance until the previous one is completed. In an agile organization, teams collaborate on a plan and work cross-functionally and concurrently.
Flexibility: Because of how work is planned and funded, waterfall roadmaps have limited flexibility. Agile roadmaps accommodate extensive flexibility. This can create its own set of challenges because teams need to be careful that unlimited flexibility does not lead to unnecessary pivots in development and resources.
Now that you know how an agile roadmap is different from a waterfall roadmap, you are ready to build one. Here are seven steps to building an agile roadmap.
An agile roadmap begins with a firm strategy that includes your product’s vision and goals. A strong vision articulates the problem you are solving for customers. And goals define what you want the product to achieve in the next quarter(s), with a clear metrics for achievement. Defining strategy is key for all teams — even ones that want to move quickly. Without well-defined vision and goals, fast-moving teams are at risk of making iterative decisions that lead them off course.
Initiatives (also called epics by some teams) define the broad strategic themes for the work that will help you achieve your goals. Initiatives are broken down into features and user stories, often spanning multiple releases.
Defining strategic initiatives defines the high-level work that is necessary to accomplish the goals. They help you clearly communicate the roadmap strategy to stakeholders without having to get into all the details. If your team does need to change course, you should start by reevaluating and changing (if necessary) the strategic initiatives before defining new features to work on.
Building agile roadmaps requires frequent communication and collaboration between business and development groups, and between the organization and its customers. For example, it is critical for you to build the roadmap with development input, so that realistic estimations of value and effort result in a feasible plan. In addition, an agile roadmap requires harnessing the effort of all the departments — design, testing, marketing, and sales — whose work is crucial for planning and delivering a Complete Product Experience.
Many agile practitioners also find they need to work with traditionally non-agile groups — such as budget offices and the legal team — that require longer timelines. In this case, an agile roadmap can be especially helpful in collaborating on parallel, multiple work streams.
The product vision, goals, and initiatives defined for an agile roadmap give product managers a prioritization guide for decomposing large themes of work into features. Development teams can then break down features into technical requirements, estimate scope, and help organize them into sprints. The result is a backlog of features and user stories — with a clear connection to product strategy — on which teams can quickly execute.
You can steer the agile roadmap by frequently assessing their strategy — if the goals change, the work that is prioritized should change too. But frequent change raises the risk that goals may shift prematurely. Mapping the work against a clear product vision can show you where your team needs to make adjustments (versus where you should stick to the plan).
An agile release delivers an increment of product value to customers in a defined timebox. It differs from a sprint or iteration in that it delivers a new customer experience (rather than just shipping code) and encompasses cross-functional work (like QA, marketing, and sales training). As a product manager, you are responsible for helping to optimize the entire new customer experience. A release also reflects important milestones — such as a market launch or architecture upgrades — and shares visibility into dependencies across the work and teams.
Releases represent all the touchpoints where customers will interact with a new product experience and are defined by the cross-functional work necessary to deliver this experience. The releases on an agile roadmap communicate to customers approximately what they should expect to see and when.
Customer delight is a core tenet of agile approaches. Gauging whether customers are happy requires collecting their feedback. And that can be done via user experience interviews, ideas portal submissions, usability testing, and usage data.
After you have collected customer ideas for improving the product, they need to score and prioritize those ideas for a future release backlog. Customer ideas — along with the product’s vision and goals — should drive prioritization of what to build next.
Companies practicing agile measure progress towards their strategic goals, review development metrics around predictability and velocity, and evaluate the business impact of new feature ideas. When you take this approach, you may review and adjust your product roadmaps on a quarterly or monthly basis. Inspecting the agile roadmap and adapting plans with customer and stakeholder feedback can help you accommodate short-term change, while continuing progress towards your product’s long-term vision and goals.
If you are building and executing on an agile roadmap, the following questions will help you pave the way:
With clear strategy, frequent releases, fast feedback, and adaptive prioritization, an agile roadmap can help organizations deliver customer value — faster — with reduced risk and waste.