A document that can effectively rally people around a plan needs to be more than just a list of features and dates. It needs to tell the story of what it will be like when you achieve your vision, what it will take to get there, and how you will know if you are making progress.
We think of a product vision as a description of how a specific sort of customer will benefit from your product when it is fully realized and ubiquitous.
These are the goals and outcomes that your product will deliver to the business. They describe the measurements that will change as you release.
Broad (aka. non-specific like quarters or “Now, Next and Later”) timeframes are better than exact dates.
Themes are the customer needs and problems that your features will address.
Protects you and the customer from assuming that the roadmap is a promise.
Developing the Wombat Roadmap
Here they take a fictional hose company and write a product vision and roadmap for it.
These are optional components that will enhance your roadmap in important ways.
Features and solutions
The specific deliverables that will fulfil the needs and solve the problems identified in the themes.
Stage of Development
The roadmap could show labels like
prototyping to indicate the state of each feature. This helps the customers understand what to expect.
Indicating the level of confidence is a great way to offset the sense that it’s a promise. It’s like an advanced disclaimer.
You can call out cohorts of customers if you have more than one.
Roadmaps for large orgs can have product areas which each have separate business objectives.
Secondary components added to the roadmap
Here they take the secondary components and add some of them to the roadmap.
These are things that you probably don’t want directly on the roadmap but should have to hand anyway in case stakeholders ask.
There’s no specific list. Just a bunch of examples.