Hello,
So I’m wondering ig it’s really important to have a public roadmap that your customer can see if they want to keep using your product.
Also from the product owner perspective, doesn’t this put a lot of pressure on you? Also in case you are unable to deliver on a feature, how will it affect your reputation if you move on to something else in the future.
Let’s hear your thought.
I wouldn’t do that. I know the competitors always track other services, so they can borrow your ideas and implement on their own. (Of course they will do it anyway but it’s much better to allow them to steal your ideas after you implement them).
What really keep users using your product is great quality, great support, and other parameters like: easiness to use, how fast they learn to use, how clear is help etc.
I too advise against it.
There’s little to gain by publicly promising features and even worse to put a date on those promises.
There’s much more to loose when you inevitably fail to do something on time. Users will get angry.
Underpromise and overdeliver is my motto.
Thanks for these. I think it’s go to always work behind the scene to please the customer instead of promising and not delivering.
Hello, I have both public and private roadmaps. There are no deadlines. I feel no pressure, only positive effect. But it is hard to estimate the effect of the roadmap. My website is startrinity.com
putting something into the roadmap does not mean “promising”, you don’t have to put deadlines there. It is like a “your vision of your product”, and if you publish it, it can give you more credibility
Agree 100% with this.
Let’s not confuse a roadmap with your task list. A roadmap is not an issues tracker. It’s not a formal project plan with due dates, estimated launch dates, est effort, est hours, assigned resources, and so on.
It’s just a roadmap. Features (in the form of user stories, ideally), ideas, feedback, all categorized very loosely into what you are doing, what you may do soon, what you’re mulling over doing someday. That’s it.
No matter if you keep just a high-level list on a physical notepad, a bulleted list in a Google doc, a Trello board (public or private), or if you use a super fancy tool like Roadmap.space or Aha!, I hope we all agree it’s important to put your vision for your product out in the world, not necessarily “public”, but definitely somewhere besides only living between your ears.
The act of creating the roadmap shouldn’t be up for debate, obviously. Just by prioritizing things on a basic level—from pie in the sky nice-to-have ideas, to ideas from customers, to things you absolutely must do to reach product-market-fit—you’ll give yourself enough clarity to confidently march forward.
So back to the original questions: Is it important to make this roadmap document public? And, does having a public roadmap reduce churn?
The answer to both depends on your specific product and your specific customers.
For B2C products, a public-facing roadmap can give buyers the confidence to be an early adopter, because they can feel a sense of synergy with your overall vision. This can turn a fence-sitter into a buyer.
Public roadmaps can be invaluable when you’re attempting to pre-sell something before you’ve actually made the thing. For example, most Kickstarter campaigns are often little more than a public roadmap and an impassioned sales pitch.
Public roadmaps can definitely assist pre-sell campaigns for B2B products as well. Especially in less-competitive niches where your product is either truly revolutionary, or evolutionary by a large margin (10x better or more than the leader of the space). A public roadmap won’t add any benefit to selling a late-entry, me-too product in a crowded, competitive niche.
In highly competitive product spaces, or with products where the customer pain is high (B2B or B2C alike), public-facing roadmaps are a lot less helpful.
For example, a business customer isn’t going to switch to your B2B invoicing app (and a trial user isn’t going to convert to paid) simply because you have a compelling roadmap. They need to send invoices today, not whenever you get around to it, and there are just too many “good enough” options in that product space where they will simply go elsewhere, roadmap or not.
It’s important to remember that a roadmap is always of more value to the product owner/team, and always of limited value to the customer.
While a public roadmap can perhaps motivate a potential customer into becoming an early adopter or motivate a trial customer to wait a bit longer to see if the feature they are interested in becomes a reality, it’s often at such a low frequency as to be moot.
So, let’s turn the question around: can it hurt to have a public-facing roadmap?
There’s been a trend (or fad) lately of being transparent with all things. Build in the open! Publish your numbers! Blog/vlog/podcast about your journey! Publish all your employee’s salaries! Publish every tidbit of source code and business operating documents in the open in a Github repo!
Cons for these kinds of transparency efforts are many. Just remember that just because someone else is doing it doesn’t mean its a viable tactic for your business.
Public revenue dashboards can affect funding opportunities and can affect the types of offers you get if you go to sell your company. Just because Pat Flynn can publish his eye-popping prior month’s earnings figures on his homepage doesn’t mean it’s the right choice for you and your business.
Decisions like whether or not to open source your assets (code, SOPs, etc) can affect funding opportunities and can affect the types of offers you get if you go to sell your company.
Public employee stats on salary and benefits can impact future job applicants and future hiring negotiations. Just because Buffer does it, doesn’t mean its right for you.
Specifically for public roadmaps:
Public roadmaps can assist your competitors in keeping up with you, and they can highlight gaps in your product strategy, which observant competitors can use to pre-emptively fill the gaps.
Public roadmaps can make bad clients even worse if they start trying to coerce you into moving a requested feature higher in priority on your roadmap, no matter if its the right business decision for you or not.
Public roadmaps with far-reaching, expansive product growth goals can be indicators of future dilution of expertise. For example, if I’m looking to use your product because it is the very best tool for this one thing, but your roadmap shows that you are working for exponential growth in a ton of other, dubiously-related areas, I may worry that the portion of the product that I really care about will eventually suffer from lack of attention or lack of focus from the product team. Lack of focus in your roadmap can be as discouraging as too little imagination, so don’t entertain shiny object fantasies in your roadmap.
Public-facing roadmaps can impact funding opportunities (for those of you seeking outside funding) if they aren’t aligned with your pitch deck, or if they highlight risks not discussed in your pitch.
No, it just publicizes the pressure you should already be feeling.
Every entrepreneur, founder, product person, or maker (whatever you call yourself) puts intense pressure on themselves to deliver the best product they can to serve their customer’s need. Speaking personally, the pressure I put on myself is a few orders of magnitude greater than any pressure anyone else can ever put on me. Pulling product goals out of my brain and prioritizing them according to feedback from customers is almost literally the least pressure-causing thing I can do in my business, no matter if I make that list public or not.
Hope this helps!
putting something into the roadmap does not mean “promising”,
Unfortunately, you don’t get to control how other people interpret your actions.
For vast majority of your users, if they see a roadmap with “implement feature X”, they will expect that you’ll implement feature X, and sooner than later.
If you do put a date, when you miss the deadline, they’ll be like “X was supposed to be done. What’s up with that?”
If you don’t put a date, they’ll use every channel available (forum, support email, twitter) and keep asking “when will feature X be available. it’s on your roadmap”.
This is not a theory.
I work on SumatraPDF, which is popular and hence has users, and I’ve learned that the only way to manage expectations is to not create them in the first place.
When users ask (and they often do in forum) “when will you implement X”, the only response I ever give is “I can’t promise when or if”.
Because I really can’t, which is another unfortunate truth of software engineering.
I might have the best intentions to do something by X, but X might turn out to be more difficult than I thought or I might have a dip in productivity or I might need to spend time on other things or maybe Y became higher priority and took time from implementing X.
I see. there can be an explicit statement in beginning of the ‘roadmap’ about the deadlines - ‘there are no deadlines, it is just a plan for development’. we can make it clear for users
Ibuprofen will help. It’s still a better idea not to hit yourself with a hammer.
People don’t read as attentively as you might think.
When they do read, they still form expectations despite you explicitly telling them “don’t have any expectations”.
Not to mention that it’s no longer a roadmap. You can’t have it both ways.
You can’t get the positive effects of a roadmap (i.e. selling the users on the future of your product, not just the present) but disclaim any responsibility for not fulfilling your promises.
@kjk, there are many types of users. they will react to the public development plan in different way. stupid people can become angry, yes. but clever people will appreciate the roadmap. @Ken has explained it well. do you know percentage of ‘stupid’ and ‘clever’ people? also, do you think it is fair for the users to get angry on you if there is no clear contract for paid development of new features?
That is, of course, a matter of reference point. However, in general, that argument alone would advocate having no public roadmap.
the ‘roadmap’ can be extended to something like this: https://www.uservoice.com/ - I see they have successful business based on sharing the roadmaps with the users and letting them create new feature requests. here is example for visual studio: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide
Was thinking the same - that Feature Upvote (for one) is a thing similar to a roadmap.
However, it is less organized (doesn’t look like an orderly plan), so as a user I do not know what to expect.
More importantly, it doesn’t solve the problem of “stupid people” 
demanding their favourite changes ASAP.
Yes, but I don’t think that these ‘stupid’ people are really important. From my experience - I try to let them go away from the very beginning.
A needed disclaimer I think, I’m the founder at Roadmap mentioned in @Ken reply.
Lots of valid points especially the competitors concerns. The goal of public roadmap is to communicate the mid and long term vision of the company / product to their users and potential customers.
I always reply to this with: If your competitors are in need to watch your public roadmap to innovate their product you actually already won. Not publishing a roadmap would not prevent these type of people from opening account and checking your product, even starting conversation to discover what’s coming next.
Focusing on what your competitors might be doing is, in my opinion, not a good use of your time. I would suggest focusing on your customers feedback instead :). And publishing a product roadmap is a transparent and open way of saying here’s what we’re thinking our product will look like in 2 years, join the conversation and let’s build a better product all together.
A product roadmap is a living thing, it changes frequently and something that is planned today can have a totally different meaning in 6-12 months from now. It is OK to change things around.
As your product evolve and your customer base grows you’ll start to get different types of feedback. New ideas that were just not relevant before.
Creating theme based roadmap items vs. feature based is also a better way to communicate your intention and objectives to your users. This help eliminating some negative points above like “when are you going to ship feature X”. Your roadmap talks about achieving goals for your users like “Improving our Slack integration” instead of talking about feature you talk about problems and solutions.
To answer the question of: How important a public roadmap is to churn rate.
I’d say not high. A public roadmap would not prevent churn. It would improve the communication you have with your customers and would, when using a tool like Roadmap, increase how you’re handling customer feedback and how you’re keeping everyone interested in X in sync with your status.
It can help retain customers that are waiting for something, but I would not base the decision of publishing a roadmap on the fact that it will help your churn rate. It could help, but there’s way better action to do that would have better impact.
I have a lot of experience in promising features and not delivering them in a timely manner or not delivering them at all 
It’s not that I do it deliberately, it’s just I overestimate my possibilities, or I simply decide that some feature doesn’t fit the product idea/philosophy (while it seemed OK when I promised it). Sometimes an unexpected bug may appear, or idea for a killer feature pops up so I decide to postpone whatever was planned. It does not seem to affect reputation. There are features that were in the queue for some 5-6 years before being implemented. Anyway, people still see most of the requested features being added, and every version has a long list of new features.
I don’t think publishing a roadmap is a good idea though. It’ll just be a unnecessary commitment. If people already pay for the product and use it, it means that they are more or less OK with the current feature set.
I wouldn’t do a public roadmap because I often remove features from the roadmap after a half a year or so. My understanding of the product’s “jobs to be done” is constantly improving and some past ideas start looking unnecessary.