When customers want a product roadmap, do this instead

Product roadmaps suck.Roadmap

There, I said it. <exhales>

OK, let’s explain that. Roadmaps that are real, living documents representing what you will deliver…are awesome. But that may not be the case for you; it wasn’t for me. Instead, a product roadmap was at its core a sales document for a prospect call. A lot of effort, with various people weighing in on what should show up there. Ginning up dates over the next 24-36 months for when features will be delivered. A visually lickable timeline.

And it’s defunct as soon as it’s published. Poor roadmap, it never had a chance. If anyone actually remembers what was in the roadmap months later, you’re left explaining that, “um…yeah…things changed”.

To be fair, this happens more in industries where the level of uncertainty is high. You’re assembling the future, learning as you go along and making adjustments. Industries with stability can put a roadmap out there and stick to it. But if your industry has a lot of fluctuation in its future, roadmaps are an  exercise in futility.

Given this, what’s the point of creating them? For me, a better way to handle the inevitable roadmap requests was needed. Internally for client-facing peers; and with sales prospects and current clients. I took the view that the customer’s roadmap request was essentially about these three questions:

  1. Where will your development resources be focused over the 12-36 months?
  2. Does your view of what’s needed for successful outcomes matches mine?
  3. What are the core values of your platform philosophy?

In other words, knowing that X feature would be rolled out in 12 months wasn’t really what influenced the customer. It wasn’t as if they said, “Oh, that feature will be there in a year? I’ll pay $X for your platform today and begin to use it once that feature is ready.”

I wanted to find a better way. Answer the questions the customer has while avoiding unrealistic commitments and schedules.  So I developed a different approach to requests for a roadmap. It focuses on two core elements:

  • Product themes
  • How we’ll work with the client

Themes are the future the customer is buying. Work with the client describes the ongoing interactions around product design. Both are part of the decision calculus of the customer. Should I go forward with this company or not?

Product themes

Product themes are the core areas that are the means to the outcomes customers seek. When I worked at Spigit, I developed five core themes (conceptualized in below graphic):


Themes are the broad areas in which the platform needs to excel. They are selected because they are key to satisfying high-level jobs-to-be-done. They will vary by product. An accounting app might have themes around ‘accuracy’, ‘sync with GAAP’ and ‘integration with other apps’. A supplier of chemicals might need to concern itself with ‘potency of compounds’ and ‘safety’.

Themes are where an analytical approach meets a flair for artistry. Internally, they are great for organizing future release efforts. I would actually grade the platform on the themes, using the A to F scale, to help prioritize future effort.

For customers, themes provide a peek into what makes your platform special. You’re communicating a promise for what future releases will address. Customers develop a sense of the platform today, and the platform of the future.

Past + possible features = proof

For the themes, plan on doing more than stating them. Bring them to life by talking features. Yes, this sounds like the roadmap rat-hole. But it’s a different way to do that:

Theme + features

Past features are proof that you are focused on the themes, and they illustrate how you have approached enhancing the themes for clients thus far. They connect the experience of your product today to the themes.

Possible features are a source of excitement, and proof that you’re focused on the themes in future development. They’re not supposed to be a committed list of features over the next 3 years. Rather, they provide a sense for how you’re approaching fulfillment of customers’ jobs-to-be-done. This gives you the chance to talk about some of the ideas floating around in your organization while avoiding the farce of putting dates on when (and if) they’ll be delivered. When asked, I put it to them straight: “These are several ideas we currently have for this theme. What are your thoughts on them?”

Which leads nicely into the other major point to cover…

How we’ll work with the client

In the B2B market, customers want to have direct input into the product design process. Not so much in the consumer market, where we simply stop buying something if it doesn’t satisfy us. But the dollars and reputation that can be on the line in the corporate market translate into greater interest in where the product is going.

To address this desire, communicate how you will work with your customer in the product design process. I would talk about three areas:

Customer insight in product design

Jobs-to-be-done: Ongoing learning about the different things customers seek to accomplish, what they rank as most important and their level of satisfaction with achieving those goals. This is a deeper dive into motivations, how outcomes will be measured and current pain points.

Ideas: As the most active users of your product (often more than you), customers will see opportunities for improvement.  Maintain a site for ongoing suggestions as they occur, and run targeted ideation campaigns for specific areas of development.

Design feedback: Prior to committing to production of a product, run several designs by them. The designs will emphasize different functions and looks, and customers give an early read on how they will be received.

The combination of themes and the ways you’ll work with customers answers the key questions they have. It actually goes way beyond the normal roadmap, providing philosophical underpinnings for your product.  And for the product manager, it’s something you can discuss with integrity and enjoyment.

I’m @bhc3 on Twitter.


About Hutch Carpenter
Chief Scientist Revolution Credit

8 Responses to When customers want a product roadmap, do this instead

  1. John Peltier says:

    Good post, Hutch!

    I have observed that by industry, company maturity, and product maturity, there are varying levels of pressure around roadmap precision. Sales-driven org’s are harder to rally around themes if they’re used to prioritizing based on the latest squeaky wheel, but this is definitely a useful going-in position.

    I have been thinking of formalizing our feedback relationship. Even the activities don’t change, just putting a bow around the value you already planned to provide, and giving it a fancy name implies a little prestige. And, of course, it establishes an accountability factor for your product team to actually solicit their input regularly.

    What happened when you encountered a prospect who won’t sign a deal unless X feature is committed for a prescribed time frame….Were you forced to make exceptions? Did you decline the deal? Or did your approach convince them to be less precise about their need?

  2. nilsdavis says:

    Hutch – This is a great methodology. It’s essentially what I would do off-the-cuff when possible, but made much more concrete. The biggest problem with roadmaps is that they predict the future, a notoriously hard problem. So the less detailed you can be, the better.

    And I’ve also found, as I think you’re implying, that customers are often actually more interested in the theme than the specific features, especially if you have delivered value to them in the past at a theme level. You want the customers to believe that you can create value around a theme in innovative ways that are better than what they would have done themselves.

  3. Scott Gilbert says:

    Totally agree with this approach. I moved to theme / problem centric roadmap for use with customers and even internal sales education convwrsations. Still have a detailed execution roadmap for driving development and cross functional team collaboration. Great post.

  4. Very nice post Hutch. Threading the needle of being responsive to client and prospect roadmap requests while being realistic is something we all face.

    Let me add a few other points to factor in here from my experience with enterprise B2B s/w:

    – Prospects are often asking for multi year (3-5 sometimes) roadmaps because they want confidence that they will be investing, sometimes significant resources, on a product with life. Meaning they want to see investment on our end to justify getting locked in to their choice.

    – Clients who have invested substantially and continue to expect more than just big fixes over time. If they are asking for a feature and spending 500K/yr maintenance fees it seems very reasonable to them to expect us to commit to a small enhancement 1 year off. (Then these pile up over time of course)

    – The Sponsor & Champion at a long term existing client has to show they made the right bet to the end-users and other stakeholders.

    – Not only do roadmap expectations differ for B2B versus B2C but also on-premise versus cloud. Then, as another commenter stated, also across industries and product areas.

    Keep up the great posting!

  5. Anonymous says:

    Very practical approach, yet sometimes it is very difficult for stakeholders to accept. I see this approach as real and living compared to old school Roadmap.

  6. I took a similar route several years ago when working as a Product Manager at an Enterprise software company. As a public traded company they decided to apply CAAP rules strictly and put Biz controls in place that prevented us from discussing any future with customers. This was a relief in some ways as it effectively made the roadmap redundant as the sales team were no longer allowed to use it.

    Here I used themes, without referring specifically to any features. As you say most customers are more interested in themes any how. Here I would show progress on current and previous theme, then talk about what the future themes would mean to them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: