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.
Greg Prickril says
While I believe in being as non-committal as possible with a roadmap, in my experience, I never had the luxury of not being specific. I was in the B2B space as well and had to align my roadmap with other product groups in the company and had to make fairly specific commitments to customers and prospects. I actually did know most of what I would be doing in a year or two because the backlog of “no-brainer” investments (including internal requirements like technical debt) would have taken me 5 years to complete. That meant my job as PM consistently included finding creative ways of getting a few exciting, even innovative features out with each release with very little discretion about the rest. This has been the case so consistently, I assumed it was normal.
The Clever PM says
There’s nothing inherently wrong with that, it’s just not an agile way to plan or execute. Not every business is agile, nor do they necessarily need to be (though I think in most cases the benefits far outweigh the costs). But if you claim to be agile, you shouldn’t have a strongly committed roadmap at the feature level — the two approaches are practically contradictory.
Joseph Draschil says
We are a B2B2C platform and while we could make a 2 year product backlog based on what clients have asked for and our product vision, the reality is that most of what the clients ask for is not really what they want (won’t drive the outcome they’re actually wanting to achieve). Even on our own feature ideas, we’re often wrong about what the right solution is without customer validation and iteration. Or, our planned ideas are no longer the right things to be working on now.
We’re moving to a model like the one you described above. As advocated by Marty Cagan and Jeff Patton, we actually call the thematic roadmap an “opportunity backlog”, which fuels our discovery/research/testing/validation efforts (think customer development and lean startup principles). This naming further separates it from feature-level promises in the minds of everyone.
Execs and stakeholders don’t get detail- and date-specific prioritized feature lists until after discovery when we’re ready to build production-quality software. This is the product backlog that feeds the agile development phase. Because execs can’t let go of the phrase, this is what we’ve started referring to as the “product roadmap”. It is feature-level, defined enough for estimation, validated enough to make sure it is the right thing to build, and fresh enough that we still know it is the right priority/importance. For that last reason, the roadmap/backlog is never “written in pen” any more than 30 days out. The spoilage of features is too great beyond 30 days to allow sales, marketing or client support to make date-related promises. Any more than 60 days and you don’t even get “written in pencil.”
As mentioned in the article, proper understanding and education of stakeholders is crucial to protecting a truly agile product design and development process.
James Lillian (@JamesLillian123) says
really great post, thanks! love to make agile product roadmaps with https://craft.io/