Last week we covered two options for building your roadmap. Now that it’s compiled, it’s time to share it out. A roadmap is a marketing tool for your plans for the coming quarter and year, so investing time in ensuring your intents are crystal clear is worth it. You also need to remember that different audiences will require different views of your roadmap.

Some good things to think about no matter who you are preparing your roadmap are:

Color Coding Is Your Friend

Differentiate groups of items on your roadmap with consistent colors. It will help those who are looking at it understand the balance of what your plans are. Some common options for color coding include:

Different products within your portfolio
Target Customer Size
Target Customer Geography
Strategic Intent (New Revenue, Retention, or Cost Savings)
Different software teams

(ooooh…. aaaaaah… colors)

Quarterly Themes Help Tell Your Story

Separating the roadmap into quarterly themes has two purposes. The first is external. Themes allow sales and marketing teams to understand how all of the items are related and apply to a particular customer segment. The second is internal. By having cohesive focus, developers can feel accomplished with whatever they’ve completed in that three month period.

Get Buy-in Before Sharing

Nothing is worse that presenting your roadmap to the whole company only to have one of the bigwigs publicly criticize it. If you’ve followed the steps in the previous weeks, you have justification for everything that’s included (and NOT included). You’ve talked to countless stakeholders internally to inform what you’ve prioritized, and it’s worth going one more round with them to discuss your final selections and ensure that they are onboard. Any stakeholder objections can be responded to in private. You can even mention your rebuttals when presenting your plans to preemptively cutoff others with similar concerns.

Sharing Is Caring

Put your roadmap in a place where people can find it, and make that place consistent so that they always know where to locate it. Depending on your organization, that maybe an online location like a corporate wiki, Confluence, Sharepoint, Trello board, or something similar. Recently, there has been an onslaught of specialized SaaS tools to share roadmaps as well, like Aha, Monday, Product Board, Product Plan and others. We don’t have a big preference for any of these options, only that everyone in the company uses the same one. We’d also like to encourage you to think about creating a physical printout of the roadmap to hang in the office somewhere (especially if everyone is colocated) so that there are visual reminders to what the company is working towards as people go from meeting to meeting.

(This one is a little messy, and probably too detailed, but look at the color coding and the themes! Note that this is different than a KanBan board)

Cater To Your Audience

Depending on who will be reading your roadmap, you should change the level of detail available. As mentioned last week, for the sales/marketing team and customers it’s important to only show when features will be available for public consumption. The internal sales groups will figure out when they’ll be able to start demoing / selling the feature later, but the important date to drill in is when prospects will be able to utilize them. In contrast, the engineering teams need to know when initiatives will be worked on and what time will be dedicated to discovery/design vs. development. Finally, if you are a product leader that is presenting to the exec team or board, it’s important to keep things high-level and ALSO to include any R+D costs (expressed in $$, not by # of sprints) or percentage investments you can predict so that they understand where the money is going.

(This is what a board presentation slide might look like. Note the color coding by product, the quarterly themes, the high level strategic goals, and the R+D headcount allocation… a real home run on a single slide!)

*Note that it’s Flexible

Often people believe that roadmaps are etched in stone and cannot change. When in fact, that isn’t true and would be a bad idea if it was. Hopefully, as the year progresses you’ll learn things about your customers and the market that warrant shifts in your plans. Manage expectations with those who are reviewing the roadmap that similar to side view mirrors, items may be different than they appear. This is especially true for initiatives that are slated for quarters much later in the year. Find a way to communicate this verbally and in writing so that when things change (as they should) that your colleagues don’t fall into the Build Trap again.

Our six week annual planning strategy series is coming to a close, and we’d like to leave you with this final thought…

Revisit your roadmap quarterly to ensure that the right things are still included. You should be monitoring your metrics to see if the outcomes you we targeting are coming to fruition. Ask yourself these questions: