Product roadmaps—whether they’re internal or public—are a great asset for any SaaS company.
They are the single source of information for everyone involved in product planning.
Product roadmaps help you:
- Organize development work within the organization
- Sync up with other departments and get their perspective on product plans
- Keep stakeholders and customers informed and excited
But, they’re only truly helpful if you’re following a few basic product roadmap best practices.
Today, we’re going to talk about the five best practices for effective and informative roadmapping. These tips apply to both internal and public roadmaps. It’s easiest to use a product roadmap tool, too, but there are lots of ways to create a roadmap.
Product roadmapping is extremely valuable if done correctly, so don’t let your hard work setting up a roadmap go to waste.
5 product roadmap best practices to follow
1. Keep your roadmap updated
Product roadmaps—like any widely used source of information—are only useful if they’re kept updated.
Internally, not keeping the roadmap updated means misinformation and disorganization. Your product team will be lost, and other departments will be even more confused.
Externally, an-out-of-date roadmap is useless to stakeholders—investors, customers, and so on.
They won’t get any useful information about what’s coming. In the worst-case scenario, they get a completely wrong idea about what’s being worked on. Cue a lot of disappointment and anger.
The cadence of updating your roadmap depends on the stage your company and product are in.
This amazing guide to product roadmaps by Department of Product illustrates this:
In the early stage, there are two main ways to make sure your roadmap is always updated:
Review regularly
The product team should review the roadmap often, even if they’re not currently adding to or changing it.
Weekly, monthly, whatever—how often you want to do it is up to you. As long as you go over it regularly to make sure everything is where it’s supposed to be, you’re good.
Make it a logical conclusion to add things to the roadmap
Make sure all action items decided upon in meetings, documents, and so on are always added immediately after. It should become second nature to add any hard conclusions to your roadmap.
It’s easy to let things slip your mind. If other departments or customers are looking at your roadmap too, every missed item causes confusion.
Making it a clear and regular practice to keep the roadmap updated will eliminate confusion and make sure things don’t fall through the cracks.
2. Don’t overpromise on your roadmap
Putting things into a roadmap is fun.
For product managers and developers, it’s almost a pride thing. You put items into the roadmap, and everyone will be excited to see it.
However, we’ve talked before about underpromising and overdelivering. Just like with keeping it updated, a product roadmap is only useful if it’s realistic.
Remember: Customers and team members will be excited to see the plans you’ve made. However, they won’t be excited when things start being late or not happening at all.
People will lose trust with you if you keep letting them down. You don’t want that.
It’s always better to underpromise and overdeliver than vice versa.
3. Make sure you have a place for feedback
Your product roadmap is ideally built based on both customer feedback and requests, as well as internal feedback from other departments.
However, you shouldn’t close off all feedback options once the roadmap has been put together. It’s normal to want to reach “closure” with your roadmap and lock it up after it’s been built.
But, especially in software, roadmaps are never set in stone. Plans change based on new information and requests. Different things end up being prioritized.
Furthermore, roadmaps tend to not be super-detailed. This means that people who aren’t directly involved with product planning can have additional questions or input. You might need to update your roadmap as a result.
So, it’s important to establish an easy way to give feedback on (and ask questions about) your roadmap at all times.
Both internally and publicly, that means:
- Providing a place to have a discussion over the product plans
- Setting up an easy way to contact whoever is in charge of informing the roadmap
- Clarifying how to contact the whole company about their roadmap if needed
For example, our Canny roadmap allows for discussion and comments over any roadmap entry:
Remember—additional feedback and input is always a good thing. It’ll make your roadmap more diverse and adaptable to changes outside your product.
4. Make ownership clear
Especially with internal product roadmaps, it’s extremely important to make it very clear who’s in charge of any given item.
This way, if there’s an issue or a question, everyone knows who to reach out to. Otherwise, the general product manager will be bombarded with questions and problems they’ll have to reassign.
Plus, clear and visible ownership within the roadmap will make the people directly responsible more aware, involved, and proud of the work they’re doing.
If you want to make it even more clearer (and fun!) you can do something like Buffer (our tool of choice for social media scheduling!) does with their Batman-Robin system:
“In one of my 1:1s with Kevan awhile ago we spoke about kicking off a marketing podcast, and he said, ‘Brian is going to be Batman for the podcast. How would you like to be Robin?’
This was such a simple metaphor, I immediately understood what he meant. Brian was taking the lead and needed some support; that’s where I had some bandwidth to come in and help out.”
Assigning both your Batmen and Robins (or just Batmen if you’d like) to all tasks will reduce confusion and direct communication.
5. Keep the format consistent
It doesn’t matter whether you keep your product roadmap in Canny, Trello, or somewhere else. (Though of course, we’d recommend using a tool like Canny, which has a product roadmap tool built into it. We love Trello, but it wasn’t designed as a roadmapping tool.)
The important thing is to have a conversation around the format of your roadmap and the entries in it. Everyone who has permission to change the roadmap should agree on a common “way” to do it.
This is a simple consistency issue. Not enough consistency in the format of your roadmap entries can cause a lot of confusion.
Being consistent with your entries doesn’t necessarily mean always adding more stuff, either.
Depending on how your teams work, it can be an issue of either a lack or excess of information:
- A lack of information causes communication issues and information gaps
- An excess of information causes noise and confusion
Whatever format you agree on when it comes to adding things to the roadmap, it should always look the same, and have the same level of information.
Need some ideas? Check out our list of public product roadmap examples.
Put constant work and thought into your product roadmap
Product roadmaps, whether used internally or publicly, are extremely useful.
You can use them to keep work organized between all the departments in your company, as well as let stakeholders know what’s coming.
Product roadmapping is the link between collecting user feedback and execution. Your roadmap will start conversations about your product’s future, and give context for the work you’re doing.
Keep your product roadmap properly maintained, updated, and accessible. It’ll streamline your whole product planning process, and save you a lot of wasted time.
