Product Roadmaps

The idea that agile development discards long term planning may be the biggest myth since the Loch Ness Monster. A roadmap is every bit as important to an agile team as it is to a waterfall team because it provides context around the team’s every-day work, and responds to shifts in the competitive landscape. But unlike a certain legendary Scottish water beast, an agile roadmap done right is easy to find and easy to understand.

A product roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released. When used in agile development, a roadmap provides crucial context for the team’s everyday work, and should be responsive to shifts in the competitive landscape. Multiple agile teams may share a single product roadmap.

To build a roadmap, product owners take into account market trajectories, value propositions, and engineering constraints. Once these factors are reasonably well-understood, they are expressed in a roadmap as initiatives and timelines. Below is a very simple roadmap for a product team. The initiatives are in blue and timelines are indicated by the milestone-markers in red.

Once a roadmap is built, it needs to be shared with the entire product team so everyone understands the vision and direction. In many organizations, product owners create their roadmaps in PowerPoint and spreadsheets, and then email the slides and spreadsheets out to the team. While well-intentioned, this strategy is flawed from the start. Each team member has their own copy of the roadmap, and keeping everyone up to speed when and if the roadmap changes is cumbersome (to say the least).

So how can the product owner keep the team better informed? Simple.

Most collaboration tools built for this sort of thing will automatically notify all participants of a project letting them know the roadmap has changed. (If yours doesn’t, it may be time to go shopping.)

When adding an initiative to the roadmap, consider the following questions:

Before we talk about dynamic forecasting solutions, let’s talk about the steps to build a long-term agile plan using the metaphor of building a house:

• What are the relative priorities of each initiative?
• When do we intend to work on each initiative?
  • Are there particular dates the team needs to hit?
  • What dependencies does the program have–either internal, or on other teams
• Which teams are working on each initiative?
  • Do the current teams have availability in their schedules and enough capacity?
  • Can we keep the current agile teams stable?
    • If not…
      • How will teams be re-organized?
        • Are we accounting for ramping-up newly-formed teams in the project’s timeline?

It’s important to link your team’s work back to the roadmap so you get that whole “context” thing I mentioned above. A tried-and-true way of doing this is to break initiatives down into epics in the product backlog, then further decompose them into requirements and user stories. Tying it all together like that makes it easier for product owners and the development team to make near-term decisions that don’t compromise future work. Let’s look at an example to see how this plays out.

Say, for instance, that we roll out an extensive user profile feature on our website. If we find that our customers don’t engage with the feature, should we continue to invest in it? Maybe, maybe not. We need to understand why engagement is low before we make this decision. So instead of pressing forward, we might opt to implement some A/B tests in the hopes of gaining some insight on the low engagement rate–which may point us in a direction that would have been far more difficult (or impossible) had we simply plowed ahead adding more bells n’ whistles.

The ability to take a step back and research before we make a pivotal decision is the essence of an agile roadmap. It gives the team the ability to evolve features as they learn more about a product, and the market.

Waterfall projects require a huge upfront investment. As a result, team members become emotionally attached to the roadmap and sacrifice making the right decision because it’s too painful to undo the work they have done–a “human” sin, if ever there was one.

For it’s part, agile development runs into three different risks:

• The team may lose confidence in the ability of the leadership to make strategic decisions if the roadmap is updated too frequently.
• The product might arrive too late on the market and miss out on pent-up demand if the roadmap is not updated frequently enough.
• Long-term efforts can seem “too big and too difficult” for shorter iterations. The team over-compensates by breaking the work down into powder-fine granularity, and ends up focusing too heavily on short-term results.

To combat “thrashing”, staleness, and nearsightedness, keep the roadmap evenly focused on short-term tactics and strategic, long-term goals. A great way to do this is to review roadmaps quarterly, adjust as needed, and share. This works well in any size organization, but remember: a single roadmap can span multiple agile teams, so inspect, adapt, and communicate accordingly.