Should I Publicly Share a SaaS Startup's Product Roadmap?
Probably not! But there are other ways to get roadmap feedback.
TL;DR: You probably shouldn’t share B2B roadmaps publicly. Instead, try to share a list of priorities (in the order you expect to build them, but without dates attached) privately with trusted customers. Then collaborate with customers to both improve your roadmap and to make them feel invested in your success.
A question that came up from my post about handling B2B SaaS feature requests was whether SaaS startups should have a public “suggestion box” feature where users can suggest ideas and other users can publicly vote on them. Accepting feature suggestions is helpful, but if votes are public it may box you into a corner where you must ignore what the community wants (like faster horses) because it’s unstrategic. This can cause customer-relations challenges or PR problems. So I generally prefer to avoid publicly quantifiable feedback about roadmaps, because it limits your flexibility to do the right thing for your business.
But this discussion got me thinking about future-looking communication with customers in general, especially in public. So it’s a good time to write about how I handle the inevitable requests from customers, salespeople, press, and others to share a public product roadmap.
My advice: don’t do it!
Public roadmap sharing: what could go wrong?
In my experience, public sharing of roadmaps usually hurts more than it helps. Here are a few reasons why:
When (not if!) you change the roadmap it will annoy customers. Humans are more upset by unexpected losses than unexpected gains. Even if the feature list and priorities stay constant (which they won’t—see below!), the dates inevitably change because it’s hard to perfectly predict timing. So instead of customers being thrilled with great new functionality, they’re annoyed that you’re late or because you cancelled a feature they wanted.
Limits your flexibility to tweak roadmap to maximize revenue. In every B2B PM role I’ve ever held, I’d often tweak the roadmap in response to market conditions like beating a competitor to market, internal constraints like if an important employee quits, or tactical sales reasons like accelerating a feature to close a big deal or preventing churn by throwing a bone to a customer. Having a public roadmap makes these changes harder.
Sometimes you cancel features or proposed products. It’s very common that, as you learn more about a feature it will cost more and/or have less value for customers than you expected when you first put it on the roadmap. Having the flexibility to silently cancel a planned feature is very helpful. Nothing sucks more than having to ship a feature for one customer you promised it to when you already know that your other customers won’t use it, or if it costs 3x what you expected.
Your competitors will use it against you. Your competition will study your roadmap. They will have months of head-start in marketing messaging, sales tactics, etc. so that when you finally ship the features the competition has been trashing them among your prospective customers. Also, they’ll tweak their own (private) roadmap to try to beat you to market, to beef up areas of the product where you’re challenging, and to hone in on customer segments that your roadmap is neglecting.
Journalism. No topic is easier for tech writers than “Company X slips product Y by N months”. The story almost writes itself. Just add quotes from customers who are annoyed (see above) and hit publish. And then when you finally launch, the headlines go like this: “Long-Delayed Product Y Finally Ships”. The press has a way of turning good things (transparency, agility) into bad (delays, broken promises). Don’t make it easy for them.
Legal & accounting risks. When you don’t exactly deliver on your roadmap, customers can sue you! There’s a whole part of securities law and disclaimers designed to avoid these lawsuits. Even with the right weaselly disclaimer, there are accounting rules that may force you to defer recognizing part of the revenue from a deal if a customer has been promised features but they haven’t shipped yet. You *really* don’t want to be the person who caused your company to miss its quarterly numbers for dumb accounting reasons!
Of course there are always exceptions to the don’t-share-roadmaps rule. You can use a public roadmap to scare a competitor away from a space or to mislead competitors into a false sense of security. You can publicize a roadmap to generate buzz or to generate sales interest. And so on. But these are exceptions, not the rule.
Instead, privately share a prioritized list of possible features
Instead of sharing a roadmap, even with trusted customers, I’ve found that a better approach is to share a coarse-grained prioritized list of 10-15 proposed features. Then I ask the customer for feedback about the features and priorities, and use it as a jumping-off point to better understand their needs. I often say something like “Here’s a list of features that, based on feedback from you and other customers, our team is considering building.” and then I ask for feedback:
“Are these the right features for your business?”
“Are there things we should be working on sooner vs. later?”
“What’s missing from this list that matters a lot for your business?”
“Are there things on here that you think aren’t helpful for you?”
This backlog-feedback approach has a lot of the benefits of roadmap sharing without most of the downsides because you’re not actually committing to specific features nor dates. With our best customers, I like to repeat this exercise at least once per year. This gives us a chance to show off what we’ve shipped from last year’s list, to understand how the customer’s needs have changed, and to build a collaborative relationship where the customer feels bought into our future plans because they had a part in building those plans. By making a customer into a collaborator, everyone wins.
Doesn’t Sales need a roadmap to close deals?
Salespeople often worry—justifiably!—that your company’s current products and features are not sufficient to land the easiest or most profitable deals in their pipelines. They often ask to share roadmaps for many reasons, including: because SaaS deals take a long time to close so they want customers to know about the product they’ll have when the deal closes; because competitors are often sharing their own (usually untrustworthy) roadmaps; or because they believe that if we just commit to one specific feature then they can close a big deal.
What I’ve found after 10+ years working closely with many enterprise sales teams, is that it’s helpful to understand *why* sales prospects care about roadmaps, especially given that all intelligent customers will be understandably skeptical about future-looking marketing claims of tech companies. As I wrote in a previous post:
How you communicate with and relate with a customer often matters as much as what and when you deliver. An enterprise customer has often made a career-risking bet on your product. The biggest fear of your customer isn't that you'll be late. It's that you'll ignore them and *never* solve the problems you promised you would—just like every other B2B tech company since the dawn of time. If you can't solve the problem right now, at least spend the time with the customer so that they know that you understand the problem and really care about will solving it in the future. SaaS is not about today's tech, it's about the promise of a better future. Make them believe!
With that in mind, customers want to know what you’re planning, and want to believe that you’re competent enough and motivated enough to deliver it. They don’t need dates to believe this!
So I tend to push back on salespeople who say they need a roadmap in order to close deals. I’ll often walk them through the downsides of roadmap sharing discussed above, and ask the salesperson: do you want the customer to think in 12 months that you lied to them, because our plans will almost certainly change in the meantime? Most salespeople are savvy enough to realize that it’s in their best interest not to get caught selling the customer something that our company won’t deliver.
But if a deal is large enough, then I will volunteer to get on the phone with the salesperson and the prospect and run through a simplified version of the same process I note above: share a list of features things that “our team is considering building next” and asking the customer how these things align with their needs. This is almost always a productive conversation that builds our future-facing credibility more than a probably-vaporware roadmap that the competition provides.