Essentially, it’s a blueprint that provides insights into your product strategy – the upcoming developments, enhancements, and major milestones. It gives viewers a clear picture of what they can expect from your product going forward.
“But is a public roadmap different from a product roadmap?”, I hear you ask. Well, in a way, no. A public roadmap is the version of your product roadmap that you are making public. Version<\/strong> is the key word here. Your public roadmap will often be a tailored version of your product roadmap – including the information that external stakeholders will care about, and keeping back the stuff they don\u2019t care about and don\u2019t need to see. But we\u2019ll cover this more in a bit.<\/p>\n\n\n\n
Why do you need a public roadmap?<\/h2>\n\n\n\n
There are a whole host of reasons why having a public roadmap is advantageous. The benefits definitely outweigh the risks (but we\u2019ll come to the risks later). For now, it\u2019s all about the upside. And the upside is significant.
The benefits of having a public roadmap are: <\/p>\n\n\n\n
Building trust<\/h3>\n\n\n\n
Having a public roadmap is the ultimate demonstration of transparency. And we probably don\u2019t need to tell you that being open and transparent builds trust.
When a team, company, or brand is confidently transparent about their strategy and plans, it creates open communication between them and their customer base. When customers see you happily sharing what you\u2019re working on, it builds trust. Trust in your honesty and trust in your product and its future.
Also, if you include a view of the roadmap items you have completed, you\u2019ll be demonstrating that you can deliver and evidencing how you can be trusted to solve customer problems. <\/p>\n\n\n\n
Engaging customers & fostering loyalty <\/h3>\n\n\n\n
Having a public roadmap that your customers can see and engage with is a great way of generating a bit of excitement and anticipation with your user base. When customers can see what you\u2019re working on and why, it can spark discussion and encourage customers to share feedback or ideas, boosting engagement.
And when customers are engaged and excited, they\u2019re more likely to stick around. If you make customers feel involved in the process – invested through their feedback – you\u2019ll find them becoming truly loyal.<\/p>\n\n\n\n
Promoting your product<\/h3>\n\n\n\n
Your public roadmap can also serve as a powerful marketing tool, highlighting your product’s direction and showing how it differentiates.
Whether it\u2019s published to your website and discoverable by anyone evaluating your offering, or being used by your sales team as collateral to help convert prospects and close deals, your public roadmap is a great tool for engaging potential new customers. It can be used to showcase the unique value your product offers and to paint a reassuring picture of continuous improvement and innovation.<\/p>\n\n\n\n
Driving accountability<\/h3>\n\n\n\n
A public roadmap is one of the most effective ways of driving accountability across the team. When the strategy is communicated externally, with public statements made about the problems you are working to solve, there\u2019s that extra incentive to deliver. After all, if a promise is being made publicly, with your name on it (since you\u2019re the team behind the product), then you\u2019re going to make sure it gets done.
Making commitments – even high-level ones – publicly, makes you and your team accountable for delivering on that promise. And that accountability is great for driving focus and efficiency. <\/p>\n\n\n\n
Validating your ideas <\/strong><\/h3>\n\n\n\nWe\u2019ve saved the best till last here. This has got to be the numero uno benefit of a public roadmap. A public roadmap provides you with a way to check the assumptions and hypotheses you\u2019re making about the direction you\u2019re taking the product. A public roadmap can be an invaluable tool when it comes to discovery and validation.
Done right, a product roadmap shouldn\u2019t be the exact<\/strong> plan of what you\u2019re going to do. It\u2019s not a delivery or release plan after all – it\u2019s further upstream than that. A roadmap isn\u2019t the place for exact dates and precise features (you can read more about why timeline roadmaps are a bad idea here<\/a>). Your roadmap should outline your best guesses about the steps you should take in order to meet your product vision and deliver the value your customers want.
Once you have those best guesses down on your roadmap, you need to check those assumptions and validate your ideas. And the public roadmap gives you a great way of doing just that!
The best way to validate the ideas on your roadmap is to share it far and wide. To push it out externally and get feedback from your customers. They will see what you plan to do and can tell you if what you\u2019ve assumed is their most pressing problem, is indeed their most pressing problem. If you find lots of customers saying the same thing, then you can act on it.
Having a public roadmap is the perfect way to get critical feedback on your product strategy before you start building. In this way, a roadmap is similar to a prototype – it’s a prototype of your strategy. In the same way you would build a prototype of a product, put it in front of people and get feedback, so your public roadmap is the prototype for your strategy which you are laying out and getting feedback on. <\/p>\n\n\n\nPros and cons of having a public roadmap<\/h2>\n\n\n\n
It\u2019s fair to say we\u2019ve probably covered the pros of having a public roadmap already (you have been paying attention, right?). But what are the cons? Are there downsides or risks associated with having a public roadmap?
Yes, there are a few things you need to be aware of. Mainly so you can mitigate against these risks and to help you field any objections you get from the team or leadership when you declare you want to set up a public roadmap. Because let\u2019s face it… it might make some people nervous.
The risks associated with having a public roadmap are:<\/p>\n\n\n\n
Managing customer expectations<\/h3>\n\n\n\n
When you publish a public roadmap you are giving your customers a window into your product strategy and plans. You are making a statement about how you plan to develop the product. That will inevitably create a degree of expectations within your customer base. The risk here is that if expectations are not met, you\u2019re going to have disappointed customers on your hands.
Luckily, this is an easy one to fix. Don\u2019t put dates on your public roadmap and don\u2019t be feature-specific! It comes down to ensuring you\u2019re communicating a strategy<\/em>, not making firm promises.
Don\u2019t fall into the trap of overcommitting to dates and exact features. This leaves you no flexibility to work in a lean way and experiment, learn and adapt. If you make commitments to dates and functionality but your discovery suggests a better way of solving that same problem, you\u2019ll likely miss that date and not deliver that exact feature. Suddenly your public roadmap goes from a force for good to a noose around your neck, restricting your ability to pivot and deliver the best solution.
The best way to manage expectations and avoid disappointing customers is to use an outcome-based roadmap format for your public roadmap. One that shows time horizons and problems to solve, rather than timelines and features. The Now-Next-Later roadmap<\/a> is one such format. <\/p>\n\n\n\nPressure and fear in the team<\/h3>\n\n\n\n
The other risk that goes alongside making a public declaration of your product plan is the sense of pressure the team might feel. You don\u2019t want a public roadmap turning your happy team into a bunch of highly stressed and fearful people who are terrified of missing deadlines and feeling the wrath of important customers.
But again, this risk is easily mitigated if your public roadmap uses time horizons and not timelines, and focuses on themes and goals and not exact features.
Then, your public roadmap becomes a positive thing for team morale – a source of pride and celebration of what they\u2019re working on and the innovation they are driving.
If you get the balance right and don\u2019t overcommit on your public roadmap, it will drive positive accountability rather than fear and stress. <\/p>\n\n\n\n
Giving insights to competitors <\/strong><\/h3>\n\n\n\nYou might find that this is the biggest objection you get from people within your business – the fear that a public roadmap will reveal all your secrets to your competitors. You\u2019ll be making it super easy for your competitors to know your plan and steal your ideas!
But seriously, competitors are gonna compete. Try not to sweat it too much. Remember, winners watch the line, losers watch the competition \ud83d\ude1c .
Let\u2019s be honest, most companies aren\u2019t Apple and aren\u2019t doing super secret launches. How crucial is it that your competitors know nothing about your plans? Like, really<\/em>? In most cases, the competition is busy building their own stuff. At worst they\u2019ll be copying what you\u2019ve already built and shipped, rather than what you have on your roadmap.
The benefit you\u2019re going to see from sharing your roadmap with the most people possible and validating what you\u2019re doing, will almost always outweigh the risk of competitors acting on what they\u2019re seeing on your public roadmap.
Plus, you can mitigate the risk by structuring your public roadmap around the \u2018problems to solve\u2019 rather than exact features or designs. That way the competition won\u2019t know exactly what you\u2019re planning to do – just the themes you\u2019re exploring.
And remember, you don\u2019t have to put things on your roadmap if they don\u2019t need validation from your customers. So if anything is sensitive for any reason, leave it off the public view of your roadmap. But, just try not to pass up the opportunity to get validation on as much as you can. <\/p>\n\n\n\nKeeping it up-to-date<\/h3>\n\n\n\n
There\u2019s a final, minor risk to having a public roadmap, and that\u2019s the risk of forgetting to update it and having a stagnant-looking roadmap out in the world.
It doesn\u2019t look good if roadmap initiatives aren\u2019t moving, nothing new is being added and your completed pile remains static.
So, if you\u2019re going to have a public roadmap – and we hope we\u2019ve convinced you that you should – you either need to be disciplined with your updates, or, better yet, use a roadmapping tool that means your public roadmap is powered by your underlying roadmap so updates are dynamic. More on that soon\u2026<\/p>\n\n\n\n
What to include on a public roadmap (and what to leave out)<\/h2>\n\n\n\n
When it comes to a public roadmap, you need to think as much about what you don\u2019t put on there, as what you do. You need to consider the audience and tailor the message. If you want your public roadmap to really hit home, you need to make sure the content is relevant and the level of detail is appropriate for an external, customer audience.
Here\u2019s a quick chart to give you a sense of the level of detail, and the type of initiatives you\u2019re going to want to have for all your possible stakeholders. When it comes to your public roadmap, you\u2019re thinking about the folks in the top right corner. <\/p>\n\n\n\n![\"A](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/08\/Stakeholder-roadmap-views-2-1024x683.png\")
<\/figure>\n\n\n\nWhat to include<\/h3>\n\n\n\n
Here are our top suggestions for what you should include on your public roadmap: <\/p>\n\n\n\n
The problems you want to solve<\/strong><\/h4>\n\n\n\nLabel your roadmap maps with the \u2018problem to solve\u2019. Specific feature functionality is less important than a clear benefit statement about why a customer should care and how it will improve their lives (working or otherwise).<\/p>\n\n\n\n
What\u2019s recently launched<\/strong><\/h4>\n\n\n\nAlongside your future plans, make sure to include a view of the roadmap initiatives that you\u2019ve recently completed. Not only does this help customers see stuff they might have missed, but it helps demonstrate that you have a track record of executing your strategy.<\/p>\n\n\n\n
What to avoid<\/h3>\n\n\n\n
Here\u2019s what you\u2019ll want to avoid adding to your public roadmap:<\/p>\n\n\n\n
Too much content<\/strong><\/h4>\n\n\n\nYou don\u2019t want to overwhelm people. Make sure your public roadmap is easily digestible and not overfull. If your public roadmap is nicely streamlined, and not full of things that you\u2019re not going to get to in a while, you\u2019ll have a faster cadence with items progressing through.
That\u2019s better than throwing everything at the roadmap right away and having a bunch of roadmap cards that just sit there going stale. If you keep it lean and show an appropriate amount of things for the velocity of your team you\u2019ll have a more active, dynamic roadmap. <\/p>\n\n\n\n
Jargon<\/strong><\/h4>\n\n\n\nRemember your audience. Don\u2019t get over technical, or use internal terminology and jargon that could obscure your message. If people don\u2019t understand what they\u2019re reading, they\u2019ll switch off. <\/p>\n\n\n\n
Specific features and designs<\/strong><\/h4>\n\n\n\nYou\u2019ll want to think about how granular to go on your public roadmap. It\u2019s better to keep the roadmap items as the themes you are exploring or problems you\u2019re working to solve. This way you aren\u2019t committing to specific features, but instead making a promise to solve a particular problem. You then have the flexibility to experiment, validate, measure, and adapt the eventual solution you deliver.
This way, rather than delivering something because you declared you would many months ago, you\u2019ll be delivering something that actually solves the problems and achieves your objectives. <\/p>\n\n\n\n
Dates<\/strong><\/h4>\n\n\n\nWe\u2019ve talked about the pitfalls of including dates on your public roadmap already. You\u2019ll be signing yourself up for less flexibility, less discovery and experimentation, disappointed customers, and stressed-out teams.
Avoid the danger of committing to dates and choose an agile roadmap format like the Now-Next-Later roadmap. <\/p>\n\n\n\n
Internally-focused initiatives<\/strong><\/h4>\n\n\n\nYou need to think, \u2018Is this roadmap initiative solving a customer problem?\u2019 If it isn\u2019t, leave it for your internal roadmap only. That could be because the problem being solved is more of a commercial, business problem – like growing revenue – or because it\u2019s just plain irrelevant for customers – like technical infrastructure changes. If there\u2019s value in getting something validated by your customers, add it to the public roadmap. If not, leave it off.
And look, while we don\u2019t want to blow our own trumpet, you really should take a look at our own public roadmap<\/a> – that\u2019ll give you an idea of what to include, and what to keep back. <\/p>\n\n\n\nHow to publish a public roadmap<\/h2>\n\n\n\n
This is all about the tool you use. You need to consider both the user experience of finding and viewing your roadmap, and your workload in terms of updating it.
Different roadmap tools will support different roadmap formats. What\u2019s important is choosing one that gives you a public roadmap that not only looks good but can be easily understood. Simplicity is key.
If you use ProdPad for the job<\/a> (which you definitely should \ud83d\ude09) then you\u2019ll be able to communicate your roadmap in an outcome-focused way, using broad time horizons.
The beauty of using a roadmapping tool that allows you to build and publish a tailored public view is that your public roadmap will be dynamic and you won\u2019t have the overhead of having to manually update the public version of your roadmap, wherever it lives.
You don\u2019t want to have to double your efforts, creating and updating your internal product roadmap and then having to duplicate and create a lot of that same content for your public roadmap.
With ProdPad, you simply decide which roadmap items should be kept internal and which are good for the public roadmap, and tag them accordingly. You\u2019ll then automatically feed your public roadmap with the relevant items.
Next, you need to think about where to put your public roadmap. Our public roadmap is loud and proud on our website, but some people add it to their customer portal. It’s worth bearing in mind that your roadmap can support customer acquisition just as much as existing customer engagement, so having it on your public website has its advantages. Here again, you\u2019ll want a tool that allows you to easily embed your roadmap on your website.
Finally, you should include a feedback capture facility on your public roadmap, so you can take advantage of the opportunity to validate your assumptions and test your ideas. <\/p>\n\n\n\nExample of a public roadmap<\/h2>\n\n\n\n
Here’s an example of a public roadmap (published using ProdPad) from BleachCyber<\/a>, a cyber security software product. Their public roadmap is super simple to understand. It’s clean and clear and gives their customers just enough information to get an understanding of the areas they’re working on Now, Next and Later. <\/p>\n\n\n\n![\"Example](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/08\/bleach_public_roadmap_in_prodpad.png\")
<\/figure>\n\n\n\nHow often should I update my public roadmap?<\/h2>\n\n\n\n
You should update your public roadmap as often as you update your regular roadmap. That might be monthly, every couple of weeks – it depends on the cadence of your team. Just be careful that you don\u2019t forget about the public version of your roadmap. There\u2019s nothing worse than a stagnant roadmap.<\/p>\n\n\n\n
How to use a public roadmap for gathering feedback<\/h2>\n\n\n\n
Again, this is about having the right tools at your disposal. You\u2019ll need to add a feedback facility to your public roadmap which explicitly asks viewers for their thoughts and comments.
Here at ProdPad we\u2019ve added our Feedback Widget<\/a> to our public roadmap and enjoy a constant stream of comments, input, and ideas from our wonderful customers and awesome community. <\/p>\n\n\n\n![\"The](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/08\/Updated-Feedback-Public-Roadmap-Image-1-1024x518.png\")
<\/figure>\n\n\n\nThen, all you need to do is make sure you\u2019re doing something with that feedback. After all, this is the big advantage of having a public roadmap – getting that validation for your strategy. Testing it out before you start building. <\/p>\n\n\n\n
So go on, go public!<\/h2>\n\n\n\n
We\u2019ve had a public roadmap from the very start<\/a> and we\u2019ve never regretted it. We promise you won\u2019t either. Start a cheeky free trial of ProdPad<\/a> and have a go at building a public roadmap now, while it’s all fresh in your mind.
Get one out there as soon as you can – you won\u2019t regret it. <\/p>\n\n\n
Done right, a product roadmap shouldn\u2019t be the exact<\/strong> plan of what you\u2019re going to do. It\u2019s not a delivery or release plan after all – it\u2019s further upstream than that. A roadmap isn\u2019t the place for exact dates and precise features (you can read more about why timeline roadmaps are a bad idea here<\/a>). Your roadmap should outline your best guesses about the steps you should take in order to meet your product vision and deliver the value your customers want.
Once you have those best guesses down on your roadmap, you need to check those assumptions and validate your ideas. And the public roadmap gives you a great way of doing just that!
The best way to validate the ideas on your roadmap is to share it far and wide. To push it out externally and get feedback from your customers. They will see what you plan to do and can tell you if what you\u2019ve assumed is their most pressing problem, is indeed their most pressing problem. If you find lots of customers saying the same thing, then you can act on it.
Having a public roadmap is the perfect way to get critical feedback on your product strategy before you start building. In this way, a roadmap is similar to a prototype – it’s a prototype of your strategy. In the same way you would build a prototype of a product, put it in front of people and get feedback, so your public roadmap is the prototype for your strategy which you are laying out and getting feedback on. <\/p>\n\n\n\n
Pros and cons of having a public roadmap<\/h2>\n\n\n\n
It\u2019s fair to say we\u2019ve probably covered the pros of having a public roadmap already (you have been paying attention, right?). But what are the cons? Are there downsides or risks associated with having a public roadmap?
Yes, there are a few things you need to be aware of. Mainly so you can mitigate against these risks and to help you field any objections you get from the team or leadership when you declare you want to set up a public roadmap. Because let\u2019s face it… it might make some people nervous.
The risks associated with having a public roadmap are:<\/p>\n\n\n\n
Managing customer expectations<\/h3>\n\n\n\n
When you publish a public roadmap you are giving your customers a window into your product strategy and plans. You are making a statement about how you plan to develop the product. That will inevitably create a degree of expectations within your customer base. The risk here is that if expectations are not met, you\u2019re going to have disappointed customers on your hands. The other risk that goes alongside making a public declaration of your product plan is the sense of pressure the team might feel. You don\u2019t want a public roadmap turning your happy team into a bunch of highly stressed and fearful people who are terrified of missing deadlines and feeling the wrath of important customers. You might find that this is the biggest objection you get from people within your business – the fear that a public roadmap will reveal all your secrets to your competitors. You\u2019ll be making it super easy for your competitors to know your plan and steal your ideas! There\u2019s a final, minor risk to having a public roadmap, and that\u2019s the risk of forgetting to update it and having a stagnant-looking roadmap out in the world. When it comes to a public roadmap, you need to think as much about what you don\u2019t put on there, as what you do. You need to consider the audience and tailor the message. If you want your public roadmap to really hit home, you need to make sure the content is relevant and the level of detail is appropriate for an external, customer audience. Here are our top suggestions for what you should include on your public roadmap: <\/p>\n\n\n\n Label your roadmap maps with the \u2018problem to solve\u2019. Specific feature functionality is less important than a clear benefit statement about why a customer should care and how it will improve their lives (working or otherwise).<\/p>\n\n\n\n Alongside your future plans, make sure to include a view of the roadmap initiatives that you\u2019ve recently completed. Not only does this help customers see stuff they might have missed, but it helps demonstrate that you have a track record of executing your strategy.<\/p>\n\n\n\n Here\u2019s what you\u2019ll want to avoid adding to your public roadmap:<\/p>\n\n\n\n You don\u2019t want to overwhelm people. Make sure your public roadmap is easily digestible and not overfull. If your public roadmap is nicely streamlined, and not full of things that you\u2019re not going to get to in a while, you\u2019ll have a faster cadence with items progressing through. Remember your audience. Don\u2019t get over technical, or use internal terminology and jargon that could obscure your message. If people don\u2019t understand what they\u2019re reading, they\u2019ll switch off. <\/p>\n\n\n\n You\u2019ll want to think about how granular to go on your public roadmap. It\u2019s better to keep the roadmap items as the themes you are exploring or problems you\u2019re working to solve. This way you aren\u2019t committing to specific features, but instead making a promise to solve a particular problem. You then have the flexibility to experiment, validate, measure, and adapt the eventual solution you deliver. We\u2019ve talked about the pitfalls of including dates on your public roadmap already. You\u2019ll be signing yourself up for less flexibility, less discovery and experimentation, disappointed customers, and stressed-out teams. You need to think, \u2018Is this roadmap initiative solving a customer problem?\u2019 If it isn\u2019t, leave it for your internal roadmap only. That could be because the problem being solved is more of a commercial, business problem – like growing revenue – or because it\u2019s just plain irrelevant for customers – like technical infrastructure changes. If there\u2019s value in getting something validated by your customers, add it to the public roadmap. If not, leave it off. This is all about the tool you use. You need to consider both the user experience of finding and viewing your roadmap, and your workload in terms of updating it. Here’s an example of a public roadmap (published using ProdPad) from BleachCyber<\/a>, a cyber security software product. Their public roadmap is super simple to understand. It’s clean and clear and gives their customers just enough information to get an understanding of the areas they’re working on Now, Next and Later. <\/p>\n\n\n\n You should update your public roadmap as often as you update your regular roadmap. That might be monthly, every couple of weeks – it depends on the cadence of your team. Just be careful that you don\u2019t forget about the public version of your roadmap. There\u2019s nothing worse than a stagnant roadmap.<\/p>\n\n\n\n Again, this is about having the right tools at your disposal. You\u2019ll need to add a feedback facility to your public roadmap which explicitly asks viewers for their thoughts and comments. Then, all you need to do is make sure you\u2019re doing something with that feedback. After all, this is the big advantage of having a public roadmap – getting that validation for your strategy. Testing it out before you start building. <\/p>\n\n\n\n We\u2019ve had a public roadmap from the very start<\/a> and we\u2019ve never regretted it. We promise you won\u2019t either. Start a cheeky free trial of ProdPad<\/a> and have a go at building a public roadmap now, while it’s all fresh in your mind.
Luckily, this is an easy one to fix. Don\u2019t put dates on your public roadmap and don\u2019t be feature-specific! It comes down to ensuring you\u2019re communicating a strategy<\/em>, not making firm promises.
Don\u2019t fall into the trap of overcommitting to dates and exact features. This leaves you no flexibility to work in a lean way and experiment, learn and adapt. If you make commitments to dates and functionality but your discovery suggests a better way of solving that same problem, you\u2019ll likely miss that date and not deliver that exact feature. Suddenly your public roadmap goes from a force for good to a noose around your neck, restricting your ability to pivot and deliver the best solution.
The best way to manage expectations and avoid disappointing customers is to use an outcome-based roadmap format for your public roadmap. One that shows time horizons and problems to solve, rather than timelines and features. The Now-Next-Later roadmap<\/a> is one such format. <\/p>\n\n\n\nPressure and fear in the team<\/h3>\n\n\n\n
But again, this risk is easily mitigated if your public roadmap uses time horizons and not timelines, and focuses on themes and goals and not exact features.
Then, your public roadmap becomes a positive thing for team morale – a source of pride and celebration of what they\u2019re working on and the innovation they are driving.
If you get the balance right and don\u2019t overcommit on your public roadmap, it will drive positive accountability rather than fear and stress. <\/p>\n\n\n\nGiving insights to competitors <\/strong><\/h3>\n\n\n\n
But seriously, competitors are gonna compete. Try not to sweat it too much. Remember, winners watch the line, losers watch the competition \ud83d\ude1c .
Let\u2019s be honest, most companies aren\u2019t Apple and aren\u2019t doing super secret launches. How crucial is it that your competitors know nothing about your plans? Like, really<\/em>? In most cases, the competition is busy building their own stuff. At worst they\u2019ll be copying what you\u2019ve already built and shipped, rather than what you have on your roadmap.
The benefit you\u2019re going to see from sharing your roadmap with the most people possible and validating what you\u2019re doing, will almost always outweigh the risk of competitors acting on what they\u2019re seeing on your public roadmap.
Plus, you can mitigate the risk by structuring your public roadmap around the \u2018problems to solve\u2019 rather than exact features or designs. That way the competition won\u2019t know exactly what you\u2019re planning to do – just the themes you\u2019re exploring.
And remember, you don\u2019t have to put things on your roadmap if they don\u2019t need validation from your customers. So if anything is sensitive for any reason, leave it off the public view of your roadmap. But, just try not to pass up the opportunity to get validation on as much as you can. <\/p>\n\n\n\nKeeping it up-to-date<\/h3>\n\n\n\n
It doesn\u2019t look good if roadmap initiatives aren\u2019t moving, nothing new is being added and your completed pile remains static.
So, if you\u2019re going to have a public roadmap – and we hope we\u2019ve convinced you that you should – you either need to be disciplined with your updates, or, better yet, use a roadmapping tool that means your public roadmap is powered by your underlying roadmap so updates are dynamic. More on that soon\u2026<\/p>\n\n\n\nWhat to include on a public roadmap (and what to leave out)<\/h2>\n\n\n\n
Here\u2019s a quick chart to give you a sense of the level of detail, and the type of initiatives you\u2019re going to want to have for all your possible stakeholders. When it comes to your public roadmap, you\u2019re thinking about the folks in the top right corner. <\/p>\n\n\n\n<\/figure>\n\n\n\nWhat to include<\/h3>\n\n\n\n
The problems you want to solve<\/strong><\/h4>\n\n\n\n
What\u2019s recently launched<\/strong><\/h4>\n\n\n\n
What to avoid<\/h3>\n\n\n\n
Too much content<\/strong><\/h4>\n\n\n\n
That\u2019s better than throwing everything at the roadmap right away and having a bunch of roadmap cards that just sit there going stale. If you keep it lean and show an appropriate amount of things for the velocity of your team you\u2019ll have a more active, dynamic roadmap. <\/p>\n\n\n\nJargon<\/strong><\/h4>\n\n\n\n
Specific features and designs<\/strong><\/h4>\n\n\n\n
This way, rather than delivering something because you declared you would many months ago, you\u2019ll be delivering something that actually solves the problems and achieves your objectives. <\/p>\n\n\n\nDates<\/strong><\/h4>\n\n\n\n
Avoid the danger of committing to dates and choose an agile roadmap format like the Now-Next-Later roadmap. <\/p>\n\n\n\nInternally-focused initiatives<\/strong><\/h4>\n\n\n\n
And look, while we don\u2019t want to blow our own trumpet, you really should take a look at our own public roadmap<\/a> – that\u2019ll give you an idea of what to include, and what to keep back. <\/p>\n\n\n\nHow to publish a public roadmap<\/h2>\n\n\n\n
Different roadmap tools will support different roadmap formats. What\u2019s important is choosing one that gives you a public roadmap that not only looks good but can be easily understood. Simplicity is key.
If you use ProdPad for the job<\/a> (which you definitely should \ud83d\ude09) then you\u2019ll be able to communicate your roadmap in an outcome-focused way, using broad time horizons.
The beauty of using a roadmapping tool that allows you to build and publish a tailored public view is that your public roadmap will be dynamic and you won\u2019t have the overhead of having to manually update the public version of your roadmap, wherever it lives.
You don\u2019t want to have to double your efforts, creating and updating your internal product roadmap and then having to duplicate and create a lot of that same content for your public roadmap.
With ProdPad, you simply decide which roadmap items should be kept internal and which are good for the public roadmap, and tag them accordingly. You\u2019ll then automatically feed your public roadmap with the relevant items.
Next, you need to think about where to put your public roadmap. Our public roadmap is loud and proud on our website, but some people add it to their customer portal. It’s worth bearing in mind that your roadmap can support customer acquisition just as much as existing customer engagement, so having it on your public website has its advantages. Here again, you\u2019ll want a tool that allows you to easily embed your roadmap on your website.
Finally, you should include a feedback capture facility on your public roadmap, so you can take advantage of the opportunity to validate your assumptions and test your ideas. <\/p>\n\n\n\nExample of a public roadmap<\/h2>\n\n\n\n
<\/figure>\n\n\n\nHow often should I update my public roadmap?<\/h2>\n\n\n\n
How to use a public roadmap for gathering feedback<\/h2>\n\n\n\n
Here at ProdPad we\u2019ve added our Feedback Widget<\/a> to our public roadmap and enjoy a constant stream of comments, input, and ideas from our wonderful customers and awesome community. <\/p>\n\n\n\n<\/figure>\n\n\n\nSo go on, go public!<\/h2>\n\n\n\n
Get one out there as soon as you can – you won\u2019t regret it. <\/p>\n\n\n