Help Your Customers React the Way You Want with These Roadmap Options, Part 3

Help Your Customers React the Way You Want with These Roadmap Options, Part 3 Skip to content

In Part 1, I said that customers need a different kind of roadmap than teams do. Teams need the focusing details now and a way to look forward. But, depending on where your product is in the market, your customers might want or need different information. Let's start there.

One thing to remember: you might not need a customer-facing roadmap at all if you release often enough. The faster you regularly release, the fewer features you “must” release, and the less pressure anyone feels.

Few of us are in that situation. And, customers might want different information from the roadmap. In my experience, customers want insights based on where your product is in its product lifecycle.

Assess the State of Your Product with the Adoption Curve

This is Geoffrey Moore's technology adoption curve, with the chasm. In this image, I added what's important (about your product) to which customers when.

In the early part of the curve when you have fewer customers, the Enthusiasts and Visionaries want More Features Faster. They want to know about your plans because they want to know when you will solve their problems. The more often you can release, the less pressure the customers will put on you. Now you need to manage the “which features first” pressure.

Once you get to the Mainstream, customers want to make sure the product works. You have the Don't Break It and Add More Features problem. Customers pressure for you to keep the product quality high and then introduce more valuable features.

You can reduce that pressure with automation at all levels, especially for testing and releasing. That automation allows you to release fast and know you have not introduced defects. While this problem is not the same as More Features Faster, your customers might pressure you for More Fixes Faster. It might feel the same to you.

The Conservatives or Skeptics don't care what new features you offer. They might not even want those features. However, they care that you do not introduce defects if you add more features. I'm not going to address a roadmap for these folks, because they don't normally look at roadmaps.

Let's start with current or future customers as the audience for your roadmap who have the pressure of the More Features Faster or Don't Break It problems. In that case, I like a dateless roadmap that you might update every 4-6 weeks.

I've seen two kinds of dateless roadmaps: future-oriented and possibility-oriented.

The Future-Oriented Dateless Roadmap

A future-oriented roadmap allows you to offer the impression of commitment to your customers, without committing. Especially if you describe the problems you plan to address.

Instead of writing about features such as “secure login,” you'd write about the problems the customers want you to solve. That's because no one ever wants to log in. However, they do want security for their data. I'd rewrite “secure login” as “Secure customer data in search by creating a timeboxed login.”

Performance lends itself to these statements: “Improve current search performance from ten or so minutes to under a minute.”

These examples explain the problem we're solving for the customers.

Then, the more often you release to your customers, the less information you need in each box. That allows you to update the roadmap more frequently.

How far out is each of these dates? Consider In Progress to be the next 2-4 weeks. Soon might be what you start next month. Later is the month or so after that. And “We Know About These” means you and the company know about the problem, but you are not committing to a solution or when.

However, with a future-oriented roadmap, some customers think you are committing to dates. (The customers create those dates even though you haven't discussed the dates!) In that case, use a possibility-oriented roadmap.

The Possibility-Oriented Dateless Roadmap

The possibility-oriented roadmap starts on the left by looking into the future. What candidate problems do we want to tackle next? That's where the company will review the parking lot of ideas and customer requests. In a sense, the company might even ask for feedback on the Planning column. (I wouldn't, but some of you might want to.)

As you refine the ideas in the Planning column, you commit to a few of them, and add them to the Up Next. (I recommend a flow-based roadmap to decide what to commit to in the Up Next column.)

For years, I used the Future-oriented roadmap, but the customers always thought we somehow committed to Soon and Later in the next couple of months or quarters. That commitment perception put pressure on the teams to deliver faster. And not always better. I don't want the teams to feel pressure from anyone.  In my experience, when people and teams have an overarching goal, they “pressure” themselves in the best possible way to create a great product.

The possibility-oriented roadmap helps to reduce customer pressure.

However, I suspect many of you offer customers roadmaps with dates. I recommend you do not offer customers a roadmap with dates.

Why Not Offer Customers Roadmaps with Dates?

Most of us build relationships with some level of trust. It's the same with you and your customers.

The more you put dates into a roadmap, the more opportunities you have to break that trust with your customers. Either Something Happens and you need to fix it now. Or, you have audit findings and you need to fix it now. Or everyone on one team is out sick for a couple of weeks, and the feature you were sure you would have by now is still in development.

Things happen in product development. That's why I don't advocate date-based roadmaps for customers. Instead, consider dateless roadmaps that you update and release every four-six weeks. The more often you release, the more the customers trust you to release in the future. And the more often you update the roadmap, the more the customers believe your considerations for the future.

Is there a right roadmap for you? It depends.

Which Roadmap is Right For Your Product Now?

Because product tactics and strategies change depending on where your product is in its adoption curve, you might need to consider several kinds of roadmaps. The roadmap you choose will offer the customers various insights. Those insights will help them react the “right” way to the roadmap.

Consider these questions:

• What do you want your users to know about in advance?
• Do you want your customers to offer feedback on the product or the strategy?
• How much, or how little, do you want to commit to for the roadmap? (Do you think your product strategy will change?)

For customers, consider a form of the dateless roadmap. Maybe you have a better alternative than I've offered here. If so, please let me know in the comments. Thanks.

The Series: