As companies transition from traditional, more waterfall-oriented approaches to their products, they often struggle with understanding how agile practices fundamentally change the ways in which they need to plan and develop their product roadmaps, both for internal use as well as for discussion with key customers and market prospects.  The old-school method of assigning specific features on a quarterly basis just fails the smell test when you’re claiming to be agile — the whole concept behind being “agile” is that you’re accepting that you aren’t some Oracle of Delphi, and that you really can’t predict the future with any certainty.

This doesn’t mean, however, that you can’t create a strategic plan that involves a product roadmap to put your investors, teams, and customers at ease.  It just has to look different and to focus on the things that you can know, while allowing for the flexibility necessary to truly be agile and market/customer-driven.

First, Let’s Kill All the “Features”

The most important thing to do when starting to plan out a Product Roadmap under an agile approach is to outlaw any and all discussion of “features”.  They cannot exist in the world of agile roadmap planning, and need to be barred from the discussion entirely.  The reason should seem obvious to anyone familiar with agile principles — but often you’ll need to sell this to your stakeholders and management team.  And the best approach that I’ve found in doing so is a two-pronged approach: (1) ask them just how many times a specific feature has been dropped somewhere on the roadmap and then not delivered — much to the embarrassment of the team, and to the consternation of the customers who were expecting or depending on it; and (2) ask them why they want to tie themselves to specific deliverables that may or may not matter as the market and the customers shift around underneath you — why should a company in this day and age handcuff itself to a set of features that they’ve discerned to be the future, when we all know that things change as you progress into the future.

Feature-level roadmaps provide a false sense of security — both for internal stakeholders and for external customers or investors.  It’s pretty easy in nearly any organization to take an series of old roadmaps and find the things that either never became reality or that constantly got “pushed out” because other things became more important.  Most companies actually are more agile than they appear or than they act — when something comes up that’s more important than the roadmap, very few successful organizations point to the roadmap and say, “Nope – that’s not on the roadmap.”  Rather, they shuffle resources and priorities to make that new thing happen, because it’s the right thing to do.  Find these things, focus on them, point them out, and make the people in the room with the influence to change the culture realize that they’re already doing this, they’re just keeping hold of their security blanket like Linus in the Peanuts cartoons.

Set Some Thematic Goals

“If we’re not focusing on features, then what are we focusing on?”

That’s the first question you’re going to hear once people start to internalize the fact that feature promises are false hopes.  And the good thing is that there’s really a simple answer — rather than focus on the specific features, let’s identify the thematic areas that we want to focus on over a specific period of time.  These themes should be specific enough that you can measure whether or not you’re actually addressing them — otherwise they’re useless fluff; prioritizing against planned themes is an essential component of agile roadmap planning and execution.  At the same time, they should be broad enough that you and the organization have the flexibility to determine the specific things that will be done to meet the thematic goal when the time comes for actual execution. Themes could be anything from scalability and stability to customer satisfaction to new market growth to training and support.  The point is to separate out the thematic goals that you want to accomplish in a given time-frame from the functional things that you’re going to do or build in order to satisfy the customer — because you cannot know what problems your customers may have in 6 months, 9 months, or 12 months.

While it’s ideal to focus on a single theme for a specified period of time — it absolutely makes prioritization so much easier — there will be certain times that you’ll need to overlap themes.  For example, it’s often problematic for Marketing, Sales, or even your CEO to see a specific thematic allotment for “customer satisfaction” as they may feel that it sends a message that you only care about customer sat during that time (which is absolutely false — but perception is reality).  When this happens, make sure that any overlapping themes are prioritized within the roadmap, so that people who are referring to that roadmap can understand that some themes will be more important than others when it comes time to plan the execution of the roadmap.  And, if you can, avoid that “always on” themes that many executive teams like to see — having “customer support” or “customer experience” running from one side of the map to the other really doesn’t add a lot of value — if your exec team or customers are concerned that you’re not listening to and resolving issues in a timely fashion, putting those on the roadmap isn’t going to actually reassure them — it’s just another “security blanket” that we don’t need cluttering our thematic plan.

Understand Uncertainty and Plan For It

Roadmaps have a tendency to give people a false sense of certainty about the future — and while shifting the focus from features to themes is a step in the right direction, I like to also make sure that when presenting a roadmap to any executive team, management team, stakeholder group, or customer, I’m explicit about how certain the varying time frames are that are displayed in the product roadmap.  I generally use a breakdown similar to the following:

• Certain — We know exactly what we’ll be working on in the next 3 months, and know specific features in a 1-month timeframe.
• Planned — We know roughly the right features to meet the thematic goal for the 3-6 month range.
• Researching — We know the themes for the 6-9 month range, and are collecting input and data to make specific plans for execution.
• Strategy — We have plotted a course for themes in the 9-12 month range based on our product/company strategy.
• Aspiration — Anything further than 12 months in the future reflect aspirational goals that are based on our overlying vision and strategic plans.

I’ve even been known to use these keywords in the headings at the top of my roadmaps, so that people have the context available to them when reviewing that product roadmap.  It helps manage expectations with your stakeholders when you’re explicit about what is known, what is unknown, and what the progression from uncertainty to certainty looks like — as we move closer to those 12+ month aspirations, they’ll slide into strategy, then research, then plan, and finally hit certainty.  People understand progression — so make it as streamlined and obvious as possible.

Iterate, Iterate, Iterate!

A modern Product Roadmap is not a static artifact.  Rather, it’s always subject to review, revision, and updating.  As things move up the certainty chain, you’ll find out new information about your market and your customers, and you need to ensure that your Product Roadmap reflects this new information.  You should do monthly reviews of the Product Roadmap with your primary stakeholders and executive team, and at least quarterly update sessions to ensure that there’s general understanding and comprehension of what the plan is, how it may have changed, and what might need to shift, flex, or drop entirely for the next iteration of the Product Roadmap.

Grooming and maintaining a good Product Roadmap is as important to the upward management required of a Product Manager as grooming and maintaining the Product Backlog is for downward management and influence on your execution teams.  As such, you need to make sure that you’re making the right decisions based on the information available to you at the time, that you’re raising up concerns or issues regarding some uncertainty, and that you’re providing a plan that you can execute to drive that uncertainty out and make the end result as crystal clear to everyone around  you as possible.  The Product Roadmap is just one of many tools that a great Product Manager will use to manage expectations across an organization and to balance the signal::noise ratio of input that we deal with on a daily basis.  The more clear and transparent your thematic Product Roadmap is, the easier it will be for you to justify and to rationalize your prioritization decisions in the hearts and minds of those around you.