Product roadmap best practices: informative and transparent

· 6 min read
Product roadmap best practices: informative and transparent

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:

  • Organize development work within the organization
  • Help other departments sync up and offer their perspective on product plans
  • Keep stakeholders and customers informed and excited

However, product roadmaps are only truly useful if a few key practices are followed.

Today, we’re going to talk about 5 best practices for effective and informative roadmapping.

These tips apply to both internal and public roadmaps. You’ll get the most out of your hard work building them.

Keep it 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. This doesn’t just apply to the product team, but other departments, too.

Externally, an out of date roadmap is useless to stakeholders (investors, customers, etc).

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 just this:

Source: Department of Product

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 even if they’re not currently actively working on 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 to the roadmap

Make sure all action items discussed in meetings, documents etc are always added immediately after. It should become second nature to add any hard conclusions to the 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 prevent these things.

Don’t overpromise

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.

Think very carefully about the scope of each thing you present in your roadmap, and whether it’s even doable. If it’s not, don’t put it in the roadmap.[/caption]

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.

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 can change based on new information, requests, and priorities. 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.

It’s important to keep 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
  • An easy way to contact whoever is in charge of informing the roadmap
  • An easy way to contact the whole company about their roadmap if needed

For example, the Canny roadmap allows for discussion and comments over any roadmap entry:

Add public or private comments via Canny

Remember—additional feedback and input is always a good thing. It’ll make your roadmap more diverse and adaptable to changes outside your product.

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 with any of them, 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 in the roadmap will make the people directly responsible more aware, involved, and proud about it.

Just kidding

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.

Keep the format consistent

It doesn’t matter whether you keep your product roadmap in Canny, Trello, or somewhere else.

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 entires 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.

Put constant work and thought into your product roadmap

Product roadmaps, whether used internally or publicly, are a great thing to have.

You can use them to keep work organized between all the departments in your company, as well as let stakeholders know what’s coming.

They start conversations about your product’s future, and provide input into everyone else’s work.

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.

Need an easy way to build and organize your product roadmap?


Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts


Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

Canny is a user feedback tool. We help software companies track feedback to build better products.

Leave a comment

© Canny 2020
Privacy · Terms · Security

Come backstage, where we share an honest look into building Canny. You’ll be the first to know when we post new content.


Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts