Want to inject some energy into a dull product team meeting? Ask for opinions about whether or not your company should develop a customer-facing product roadmap. That’ll get people perked up and talking. But it could also get them shouting, maybe even hurtling obscenities. So use this tactic only if you’re stuck in a truly lifeless meeting and see no other option. For example, if you had to present your roadmap using Excel, and now everyone in the meeting is falling asleep.
The question of whether or not a product roadmap should be customer facing is the subject of serious debate. There are legitimate arguments on both sides. But for this post, we’re going to assume your team has already decided you want to make your roadmap public. With that in mind, we have some suggestions for you, including:
- A few things never to put on your customer-facing product roadmap, and why.
- What you can share on your public roadmap.
No. 1: Never Put Specific Dates on Your Customer-Facing Product Roadmap
Why Not?
When your team starts working on any complex project, the best you can do is make an educated guess about how long it will take to complete. Obstacles always appear along the way. It’s unlikely that development on your product will ever unfold exactly as you predict or hope, over the exact timeframe you’re aiming for.
This is why you do not want to put a date on your customer-facing product roadmap that tells the public exactly when they should expect something new. Doing so will set customer expectations that you might very well fail to live up to.
What Should You Do Instead?
You have a couple of options here. Rather than a specific date, you could include a broad timeframe for delivering something new. Maybe your public roadmap will show only a quarter or even half of the year in which people should expect your new functionality to be available.
If you want to play it even safer, you can publish your public roadmap with no timeframes at all. Instead, group your items only in relationship to each other —“up next,” for example, and “later.”
No. 2: Never Put Detailed Feature Documentation on a Public Roadmap
Why Not?
A few reasons for this. First, including too much feature detail on a publicly available product roadmap could give your competitors ideas they hadn’t thought of themselves. You should always assume your competitors will see everything you make available to the public.
Second, because circumstances change often during product development, including too much detail increases the chances you will make a promise that you aren’t able to fulfill. This could create problems for you, both in the market (with disappointed customers) and internally (with disappointed stakeholders).
What Should You Do Instead?
Keep the items on your customer-facing roadmap high level: the major product areas you’ll be improving, themes for new functionality, and solutions to common user problems your team is working on.
Your goal with a public roadmap should be to build anticipation and excitement about your product, as well as to create a sense of trust and transparency with your customers. You could undermine all of these goals if you offer too much detail and then fail to deliver on any of it.
No. 3: Never Discuss Your Planned Backend/Architectural Work on a Product Roadmap You Share Publicly
Why Not?
For one thing, customers don’t care how you improve your product. They just want to know those improvements are going to benefit them. This type of “behind-the-scenes” detail will only bore them and weaken the overall excitement factor you’re going for with your public roadmap.
Also, this could tip off your competitors about how your product team operates and some of the backend tools and processes that give your product its secret sauce.
What Should You Do Instead?
Keep your public roadmap focused only on the elements of the product that your customers will see and experience firsthand: interface, functionality, etc.
No. 4: Never Publish Details About Resources, Teams, or Other Internal Information on a Public Roadmap
Why Not?
Details about which team will be working on a given feature, or in what swim lane you’ve decided to categorize a set of projects, won’t mean anything to your customers.
This type of information will only add unnecessary clutter to the roadmap, making it more difficult to understand, and dulls the excitement you’re trying to create among users by publishing your roadmap in the first place.
What Should You Do Instead?
Limit your public roadmap to those details that actually give your customers a better understanding of what to expect next from your product, and why these things will help them.
No. 5: Never Make Promises With Your Customer-Facing Roadmap
Why Not?
If customers see anything they interpret as a promise or guarantee—either in your roadmap itself or in the message you publish alongside it—and you fall short of that promise, you will needlessly create disappointment and even distrust among many of those customers.
We say needlessly because there is no good reason to make a promise in a public roadmap. Promising anything to your user base weeks or months in advance just isn’t worth the risk. The best you can do is meet expectations. Worse, (and more likely) you’ll come up short.
What Should You Do Instead?
When you publish your customer-facing roadmap, present it as your company’s current plan, and an opportunity to increase transparency with your users.
Make it clear that you will be working diligently on bringing these new items to customers as quickly as you can—but that you cannot make any guarantees. If you meet your internal deadlines or estimates, then great. But if you don’t, you do not have to worry that you’ll upset your customers.
In other words, under-promise and over-deliver.
Conclusion
When is it smart to share your roadmap publicly? That’s an open question, one only your company can answer. But if you decide to create a customer-facing product roadmap, there are some guidelines that always apply, regardless of your company’s circumstances. Keep your roadmap’s details high level and customer-focused, don’t get too deep into the tactical details, and don’t make any promises.
If you can stick to those best practices, go ahead and build a customer-facing product roadmap.
