What is a Roadmap?
Its a one to two year timeline of what major features are going to be added to a product or a portfolio of products. It depicts strategic objectives - markets, themes, financial returns, etc.
What is not a Roadmap?
Collecting all planned projects and presenting them on a timeline along with expected financial gains - is not a roadmap. This is a tactical list of items that are planned to be done.
A roadmap can contain tactical items but it also shows the strategic objectives.
Building a Roadmap
Build a roadmap by listing the big ideas, sequence these ideas i.e. idea A needs to be done before idea B, break ideas into user stories and put them on a time line.
The sequence of implementing the ideas should make sense to the business and customers. For example, if the product manager for Blogger website decided that the next big ideas* are -
- Integration with Social Media
- Tablet App
- Email notification on comments
* these ideas should be of value to the customers, this requires some level of interview/survey or other techniques to understand what the customer needs and where the competition fails.
A possible sequence may involve splitting ideas as -
1. Twitter Integration - tweet new posts
2. IPad App - support for writing posts and responding to comments
3. Email notification on comments and responses
4. Facebook, Google+, LinkedIn Integration - share new posts
5. Android Tablet App - full support
6. IPad App - support for browsing blogs, posting comments
These items when listed under the three themes - Social, Mobile & Email along with the effort estimate on a timeline is a roadmap. These 6 user stories need to be expanded further, broken down into features, discussed with the development team, refined and then implemented.
When discussing the roadmap with the engineering teams remind them that the estimate for each idea is a guess and not a commitment. This allows them to respond swiftly, without spending too much time on details.
Stakeholders - as in project management, when building a roadmap you need to manage expectations of your stakeholders. The sales team that will sell the product, the internal customers who will provide you the components or supporting infrastructure, the engineering team, senior management and in some cases the external customers (too) should understand the rationale behind the roadmap, the sequence of items, the estimated timelines, etc. If they aren't involved in building the roadmap early on, they are likely to not support/agree to it.
Sharing the Roadmap
Roadmaps need to be shared with the right audience. Internal communication to all groups requires careful planning at the initial stage of building the roadmap and during the process it requires that appropriate communication is done. Finally once the roadmap is ready, it needs to communicated as the final version so that everyone can align their work/plans to it.
Sharing the roadmap to external audience is tricky. Most companies don't like to share their plans, fearing regulatory requirements or disclosing results of internal studies to competition. A trimmed down version of the roadmap may be shared, without revealing too much about the timelines or features.
Depending on the type of product, there's always the risk of customers delaying purchase in anticipation of an improved product two or three releases down the track.
Some companies may benefit from revealing their roadmaps, for example companies which offer their product via subscription may fend off competition by letting their customers know about upcoming additional features, thus keeping them locked in.
This is a balance between company culture, product and customer strategy.
Its a one to two year timeline of what major features are going to be added to a product or a portfolio of products. It depicts strategic objectives - markets, themes, financial returns, etc.
What is not a Roadmap?
Collecting all planned projects and presenting them on a timeline along with expected financial gains - is not a roadmap. This is a tactical list of items that are planned to be done.
A roadmap can contain tactical items but it also shows the strategic objectives.
Building a Roadmap
Build a roadmap by listing the big ideas, sequence these ideas i.e. idea A needs to be done before idea B, break ideas into user stories and put them on a time line.
The sequence of implementing the ideas should make sense to the business and customers. For example, if the product manager for Blogger website decided that the next big ideas* are -
- Integration with Social Media
- Tablet App
- Email notification on comments
* these ideas should be of value to the customers, this requires some level of interview/survey or other techniques to understand what the customer needs and where the competition fails.
A possible sequence may involve splitting ideas as -
1. Twitter Integration - tweet new posts
2. IPad App - support for writing posts and responding to comments
3. Email notification on comments and responses
4. Facebook, Google+, LinkedIn Integration - share new posts
5. Android Tablet App - full support
6. IPad App - support for browsing blogs, posting comments
These items when listed under the three themes - Social, Mobile & Email along with the effort estimate on a timeline is a roadmap. These 6 user stories need to be expanded further, broken down into features, discussed with the development team, refined and then implemented.
When discussing the roadmap with the engineering teams remind them that the estimate for each idea is a guess and not a commitment. This allows them to respond swiftly, without spending too much time on details.
Stakeholders - as in project management, when building a roadmap you need to manage expectations of your stakeholders. The sales team that will sell the product, the internal customers who will provide you the components or supporting infrastructure, the engineering team, senior management and in some cases the external customers (too) should understand the rationale behind the roadmap, the sequence of items, the estimated timelines, etc. If they aren't involved in building the roadmap early on, they are likely to not support/agree to it.
Sharing the Roadmap
Roadmaps need to be shared with the right audience. Internal communication to all groups requires careful planning at the initial stage of building the roadmap and during the process it requires that appropriate communication is done. Finally once the roadmap is ready, it needs to communicated as the final version so that everyone can align their work/plans to it.
Sharing the roadmap to external audience is tricky. Most companies don't like to share their plans, fearing regulatory requirements or disclosing results of internal studies to competition. A trimmed down version of the roadmap may be shared, without revealing too much about the timelines or features.
Depending on the type of product, there's always the risk of customers delaying purchase in anticipation of an improved product two or three releases down the track.
Some companies may benefit from revealing their roadmaps, for example companies which offer their product via subscription may fend off competition by letting their customers know about upcoming additional features, thus keeping them locked in.
This is a balance between company culture, product and customer strategy.
