9 Principles of excellent product roadmaps
October 26, 2018
- Roadmaps should be myopic. Planning too far ahead is a sure way to be proven wrong. 6 months is a sensible maximum horizon.
- Roadmaps should be up to date. Out-of-date roadmaps serve to reduce the readers confidence in your ability to deliver. An out-of-date roadmap is worse than no roadmap at all.
- Roadmaps should be simple. Complex Gantt charts and recorded inter-dependencies have no place on a product management roadmap. It is a communication tool. It must be easy to read.
- Roadmaps should be non-exhaustive. A roadmap is not a backlog. Your backlog should stay in JIRA or Trello or whatever other tools you already use. Your roadmap should show tangible chunks of user value.
- Timelines should be imprecise. A roadmap is guide, not a promise. Highlighting exact delivery dates sets the wrong expectation for the reader. Your roadmap should ensure your audience has the correct expectations.
- Roadmaps should be low. Tall roadmaps with many lanes and many work items in parallel are a sign of silos in your team and prevent value being delivered to the user.
- Roadmaps should display the date they were last updated. This helps the reader make a decision about how much to believe.
- Roadmaps should display completed work. The fact that a feature has been recently complete is worth communicating to the reader. Consider it a form of discovery.
- Readers should consume your roadmap where they are. They shouldn’t have to leave their existing tools or sign up for something to see your roadmap. Roadmaps are ultimately communications tools and any friction between the roadmap and the reader only reduces their ability to consume it.
Written by David Tuite who is a product manager at Workday and used to be a software engineer. You should follow him on Twitter