At ProductPlan, I frequently get questions about agile roadmap planning. How should you balance long-term strategic planning with short-term agility?

This was an especially hot topic on a recent webinar we hosted. I thought I’d elaborate on some of my answers in this post. Here are 3 questions on that topic I’d like to highlight.

1. How do you balance agile uncertainty with roadmap planning at a growing small or medium-sized company?

It’s important for product managers to not make the mistake of thinking that because they have a roadmap, they’re not agile. Those two concepts actually work in tandem. You need a roadmap to set the strategic goals for your company, but you still have a lot of freedom to move things around within those goals.

There are a couple of points that I’ll make around this:

The first is that you should be doing continuous customer discovery and customer interviews. You should always be engaging with customers in order to find the big problems worth solving. And when you match customer problems up with the strategic goals that you’ve set for your organization, it will point you in the right direction in terms of which features to build.

It’s important to remember that you’re not necessarily putting narrow features and tasks on the roadmap. Instead, you’re bubbling those up to make the roadmap very high-level.

You need to be looking at big themes that will help you move the needle in problem areas that your customers have. Think about the jobs your customers need to get done. When you keep your roadmap high-level, you maintain a lot of flexibility as a product manager to move features in and out of the backlog in order to accomplish your goals.

The second point I want to make is that you should be reprioritizing all the time. Reprioritize your backlog and your roadmap, especially in the long-term, because things change and different competitive pressures come up. Don’t lock in timelines that are too long, or your stakeholders will feel like you’re making commitments and they’ll expect you to deliver.

I think those two points are really important — doing continuous customer discovery and constantly reprioritizing features. That way you can ensure your agile process is really working for you. You don’t want to find yourself in a position where you’re throwing features into the development queue that were decided on twelve months ago. Those features may or may not be the right things to do today.

And there’s one more thing I want to touch on — this idea of using a Kanban-style roadmap. The Kanban methodology has become pretty popular because it lets you organize the roadmap into a different buckets — planned, doing, done, etc. — without committing to specific deadlines.

With a Kanban roadmap, you can designate things that you might want to be doing in the future, but you’re not quite sure about yet. You can distinguish the things that are a little bit fuzzy from the things that you’ve already committed to for the short term.

I think that in a small or mid-size organization, Kanban is a great way to avoid making the mistake of locking in an inflexible,12-month roadmap that may or may not end up being the right course of action. And, of course, it should also be mixed in with continuous customer discovery and reprioritization.

2. How far out should plan your roadmap? How do you properly set expectations with stakeholders that plans will change?

I think it depends. The appropriate timeframe for your roadmap depends on the kind of organization you have, the type of product you have, and where your product is in its lifecycle. If it’s an early stage product, your roadmap needs to be very short term. You simply don’t have enough insight into what the right things to build are, so your roadmap needs to be very flexible.

On the other hand, if you have a product that is five or six years into its lifecycle, your planning horizon needs to be much longer. So, again, it really depends on product and company maturity, but at ProductPlan, the most common roadmap time horizon our customers use is about a year.

Many organizations are moving to an agile planning approach, and that makes it less likely that the things you’re putting on your roadmap for six or nine months from now are solid — and that presents challenges for product managers.

We hear from a lot of product managers who feel that creating a one-year roadmap means setting unreasonable expectations among their stakeholders. And that’s really a caveat here — you have to communicate to your stakeholders that the roadmap will change.

One of the ways that you can do that is by bringing your roadmap up a level. Again, the roadmap should not be simply a list of features or a backlog. The roadmap should be tied to strategic themes. So rather than listing out specific features or tasks that need to be accomplished, roll those up into larger themes and communicate the roadmap at the theme level.

A theme ties back to strategy. For example, if your product is an e-commerce product and you want to reduce the rate of shopping cart abandonment — i.e. you want to improve the number of customers who are actually making purchases — that could become a theme. Now, the exact features that you create in order to accomplish that goal, or that theme, may change.

You also may not really know the effort level behind the features you’re considering. As you get closer to building them and you estimate the stories, it will become more clear what that effort level is. Then you can make trade-off decisions about which items will best accomplish your goals.

So those are my recommendations — that you manage stakeholder expectations that the plan will change, and that you bring the roadmap up a level. As a product manager, you have a lot flexibility in what you can accomplish as long as you don’t get locked into building a specific feature set.

3. How do you adjust when you have roadmaps for a racehorse but realize you’re actually riding a mule?

I love that question! I think a lot of us have been there, and I think it’s just the nature of things.

As product managers, we know what the path is — we have the vision for the product. But sometimes things don’t move as quickly as we want them to. I think setting up those longer-term strategic goals is the right way to safeguard against unexpected bumps in the road.

And there’s no quick fix here other than to just stay on the path. As long as the path fits in with those strategic goals, you’ll eventually get there. Having that long-term strategic perspective will make it easier to say, “Yes, we are going to do that, just not yet.”

I also think that this is where the concept of an MVP comes into play. Not every feature is important, and a lot of the things that you have on your roadmap, especially if you thought them up in the conference room, may not be the right things to build in the first place.

I’ve found that I can often satisfy customers and give them a lot of value by building only 50% of what I thought they needed to have — and I’m constantly surprised by that. If you’re solving one key problem for them, they’ll buy and they’ll be happy, even though you may not have given them everything that was on the initial roadmap.

Post Comments


  • stefan jazdzejewski
    September 12, 2016 at 1:55 am

    hi jim,
    great article. fully agree to what you´re saying. after some “inspect&adapt” ups and downs – over the last 12 months – we now have found our way how to use and work with roadmaps. and this one is very similar to your approach.
    i have one question though: Reg. customers discovery – do you think there is a significant difference between B2C and B2B business?
    best, stefan

    • Jim Semick
      September 12, 2016 at 4:27 pm

      Thanks for your comment Stefan! Yes, I think there are some differences in how you should approach customer development for a B2C versus a B2B product. In my experience, customer development for a B2C product is focused so much on the customer experience and UI. The user is often the buyer, so you can speak with a single person to hear their insight. You are also more able to conduct objective A/B tests because you’re dealing with so many more potential customers.

      On the other hand, in customer development for a B2B product you are engaging with far fewer customers. So their feedback is subjective. You have the opportunity to dive deeper into their problems and potential solutions. The UI matters to business customers, but not as much in my experience. Especially if the economic buyer is different than the user. Features are often tied to the Return on Investment for your product (e.g. dollars saved or made).

      Of course, customer development is so important for any product, and your product needs to solve real problems that are high priorities for your customers. These are the features that should wind up on the roadmap 🙂

  • Thomas Johansson
    September 16, 2016 at 3:18 pm

    Good and pragmatic!
    I do have a question on the Roadmap vs stakeholder expectation:
    It is not uncommon for Sales & Marketing functions to rely on the roadmap for creating business and interest among customers, it might even be the “Sales” driving Product Management here.
    How would you tackle the possible loss of concrete items when a Product Manager “moves the roadmap up a level”?
    Best Regards,

    • Jim Semick
      September 16, 2016 at 3:57 pm

      Thanks for your nice comment Thomas! My suggestion for balancing the “high level” with the concrete items is to use Themes. I like to think of Themes as groupings of similar features that describe customer value – how you’ll help them accomplish a job. In ProductPlan our customers use our Containers feature to show the theme of a release or releases. They then open the Container to show the individual features that are included in the theme. This way they can balance showing the big picture with the specific features their customers will be receiving. Themes give product managers flexibility in moving features in and out of a theme without completely up-ending the roadmap.

Leave a Comment

Your email address will not be published.