Such a roadmap focuses on product goals<\/a>, benefits, or outcomes like acquiring customers<\/em>, increasing engagement<\/em>, and removing technical debt<\/em>. Features might still exist, but they should derived from the goals and used carefully. I like to recommend using no more than three to five features per goal, as a rule of thumb.<\/p>\n To help you develop your agile product roadmap, I have created a goal-oriented roadmap template called the GO Product Roadmap<\/em>. It consists of five elements: date, name, goal, features, and metrics, as the picture below shows. You can download the template for free from romanpichler.com\/tools<\/a>, and you can find more information on how to use it in my article The GO Product Roadmap<\/a>.<\/p>\n Before you create your roadmap, capture and validate the\u00a0product strategy<\/a>. I like to regard the strategy as the path chosen to realise your vision and the roadmap as an actionable product plan that communicates how the strategy is implemented. In other words, I like to derive the roadmap from the strategy.<\/p>\n An effective strategy should describe the product’s value proposition, the target market. standout features, and business goals. Make sure that you can confidently state these, that you have done the necessary product strategy work<\/a>. Otherwise, you risk creating a product roadmap that is not realistic and actionable.<\/p>\n Your product roadmap should tell a coherent story about the likely growth of your product. Each goal should build on the previous one<\/a>, particularly as long as your product has not reached maturity<\/a>.<\/p>\n To come up with the right roadmap narrative, follow these two tips: First, break the user, customer, and business goals stated in the product strategy into specific and measurable subgoals. Then order the subgoals so that they form a coherent story. If I wanted to offer a healthy eating product, for example, that helps middle-aged men reduce the risk of developing type-2 diabetes, the the goal of the first, initial release (MVP<\/a>) might be to build a user community. The goal of the second release might be to increase engagement, and the goal of the third one might be to generate revenue.<\/p>\n Second, resist the temptation to add goals and features to the product roadmap to please powerful stakeholders or broker a deal. While I am a big fan of collaborative product roadmapping, this should not result in weak product decisions and compromises, see my tips Secure Strong Buy-in<\/a> and Have the Courage to Say No<\/a> below.\u00a0<\/p>\n Be careful not to add too many details to your product roadmap. Keep your roadmap simple and easy to understand. Capture what really matters and leave out the rest by focusing on the goals. Keep the features on your roadmap coarse-grained and derive them from the goals. Do not show epics or user stories<\/a> on your product roadmap but keep them in the product backlog<\/a>. Use the product roadmap as a strategic product plan and the product backlog as a detailed one that facilitates execution, as the picture below shows.<\/p>\n <\/a><\/p>\n The best product roadmap is worthless if the people required to develop, market, and sell the product don\u2019t buy into it. A great way to get to agreement is to collaborate with the key stakeholders<\/a> and involve them in creating and updating the product roadmap. This allows you to leverage their ideas and knowledge, it creates shared understanding, and it makes it more likely that people will support the plan.<\/p>\n Running a collaborative roadmapping workshop is a great way to engage everyone and create a shared product roadmap, as the following picture illustrates.<\/p>\n Make sure, though, that you ask a skilled facilitator, for instance, your Scrum Master<\/a>, to facilitate the workshop. This includes choosing the right decision rule<\/a>, for example, consent, and ensuring that everyone is heard and nobody dominates. (See my article Making Effective Product Decisions<\/a> for more help on how to successfully decide with stakeholders and dev team members.)<\/p>\n <\/a><\/p>\n While you want the key stakeholders to support the product roadmap, you should not make the mistake to say yes to every idea and request. This would turn your product into a feature soup, a random collection of features. \u201cInnovation is not about saying yes to everything. It\u2019s about saying no to all but the most crucial features,\u201d said Steve Jobs. Use your vision and product strategy to make the right decisions.<\/p>\n But before you explain why an idea or request cannot be added to the product roadmap, carefully listen<\/a> to the stakeholder’s idea. Take a genuine interest in what the individual\u00a0 has to say and seek to understand her or his underlying need or motivation. This makes the person feel valued and understood, which will make it more likely that the individual is able to hear a negative answer and is still willing to support the roadmap. (See also my article 5 Tips Saying No Stakeholders<\/a>.)<\/p>\n Dates on product roadmaps has been a hotly debated topic amongst some product people for a while. I recommend using dates or time frames on an internal roadmap that coordinates the work carried out by the internal stakeholders, such as, marketing, sales, and support, and the development team. This helps you make important trade-off decisions between shipping on time and fully meeting a goal. What’s more, it provides clarity for the stakeholders and development teams helping them do their work.<\/p>\n But when you use an external roadmap that is shown to customers and users and often used as a sales tool, then I suggest not showing any dates or time frames but sequencing your releases and possible employing a now-next-later grid to order them. Please see my article “Should Product Roadmaps Have Dates?<\/a>” for more information.<\/p>\n When using a goal-oriented roadmap, ensure that every goal is specific and measurable so you can tell if you have met the goal or not. If your goal is to acquire customers, for example, then ask yourself how many new customers should be acquired; and if your goal is to reduce technical debt, determine how much of the bad code should be removed or rewritten.<\/p>\n![\"The](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2016\/07\/GOProductRoadmapTemplate.png\")
<\/a><\/p>\n
\n2 Do the Necessary Prep Work<\/h3>\n
![\"Product](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2014\/05\/StrategyAndProductRoadmap.png\")
I like to use my\u00a0Product Vision Board<\/a> to describe the product strategy. The board captures the vision, the target group, the problem to be solved or the benefit to be provided, the key features of the product, and the business goals. You can download the Product Vision Board template from romanpichler.com\/tools\/<\/a>\u00a0for free.<\/p>\n
\n3 Tell a Coherent Story<\/h3>\n
\n4 Keep it Simple<\/h3>\n
![\"Product](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2016\/07\/ProductRoadmapAndProductBacklog.png\")
<\/p>\n
\n5 Secure Strong Buy-in<\/h3>\n
![\"Product](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2016\/07\/roadmapping-workshop-with-stakeholders.png\")
<\/p>\n
\n6 Have the Courage to Say No<\/h3>\n
\n7 Know When to Show Dates<\/h3>\n
\n8 Make your Roadmap Measurable<\/h3>\n
![\"Determine](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2016\/07\/DetermineCostTopDown.png\")
<\/p>\n![\"Product](\"https:\/\/www.romanpichler.com\/wp-content\/uploads\/2016\/07\/RoadmapReview.png\")
<\/p>\n\n\n