Sharing the Roadmap
Know Your Audience!
Roadmaps need to be shared. A roadmap created that is ignored is not a roadmap. It’s an artifact of a broken system. Roadmaps need to be seen, discussed, and updated for them to have value and purpose.
Thus, it’s important to pick a way to visualize the roadmap in a way that is meaningful for people involved and there needs to be a reasonable and logical cadence to updates and communications around it.
Know your audience!
By this point in the chapter, it should be clear that a roadmap is tailored to the specific organization, technology, goals, and teams that care about the roadmap. A format that is clear and useful to one group might be confusing or misleading for another.
This is especially true within a single organization as the focus of each team (developers, marketers, finance, etc.) can be different and so a highly technical roadmap might be almost useless to a group of marketing folks who understand digital marketing but are not technology experts.
Thus, the roadmap should use both a visual format and summarize things at a level of detail that’s relevant and clear to the groups involved. (In some cases, you might even want to create a few versions of the roadmap - one for developers, one for finance, one for executives, etc.)
What to highlight?
Given that different groups have different roles and focus within the organization, highlight information in the roadmap that’s most relevant to each group. Make sure that key milestones and deadlines are highlighted, and that there’s a “sense of timing” with the presentation so viewers can see what’s happening now, in the near future, and in the far future.
For Business Leaders:
Executives and senior managers are charged with setting organizational strategy, communicating this to the people employed within the organization, and then ensuring resources are used effectively in the pursuit of the strategy.
Thus, roadmaps for a business leadership audience should focus on concepts related to:
- Alignment between the work being done and larger strategy
- Milestones showing when tangible results will be delivered or will be live
- Financial events that will be require significant investment or approvals
- Go/No-Go Deadlines where executives can approve or deny further investment
When reviewing the roadmap, be prepare to answer questions from business leaders around these same key points:
- What risks might delay delivery, increase costs, or otherwise cause other issues for the forecast?
- How do we know that all costs and investments are captured by this?
- Did all of the teams involved on the roadmap agree to this timeline and forecast?
- Did finance, accounting, and legal teams review this to be sure there are no hidden risks?
The bottom line: be ready for high-level questions about certainty, costs, risks, and cross-team collaboration when presenting a roadmap to an executive.
For Marketing Teams:
Marketing teams are often closely involved with roadmaps as they do market research, track user experience, and gather information to share with product development teams. Given this, marketing teams will want to understand how products will evolve, when new products will be released, and how they need to prepare to market these to customers. The roadmap should focus upon:
- Key dates of deliverables that define new features or product launches
- Events where partnerships, collaborations, or other similar matters are visible to customers
- Definition of releases and changes that will improve customer experience, retention, or organizational profitability
Conversely, when presenting roadmaps to the marketing team, be prepared to answer key questions like:
- What are the release dates for the next major milestones? How certain are these dates?
- When will key features or changes be finalized and low-risk to change so that these can be incorporated into marketing messages, social media, and other assets?
- Will there be any beta testing periods available for power users, media partners, social media influencers, or similar groups who can help publicize the changes in the future?
And, of course, if there’s anything on the roadmap that contradicts or is not supported by market research, be prepared for some very direct questions on those roadmap items. (Note: infrastructure or “hidden work” is not what this means; if a product is being built that is not shown as interesting or useful to customers, this is where marketing and product development teams will ask very pointed questions…)
For Finance Teams:
Finance teams manage the flow of cash in and out of the organization in a way that respects the time-value nature of money. The total amount spent on a project is different from the value of money spent and this difference becomes larger as the time gaps grow between each cash outlay. If this doesn’t make any sense, that’s OK. This isn’t a book about finance, it's a book about getting work done in tech.
The bottom line is that finance folks, especially in huge organizations or for work over many quarters, are going to ask stuff like this:
- At what points will there be cash outflow, as in “dollars out the door” for subscriptions, licenses, or other expenses? (This is different from ongoing expenses for salaries, overhead, etc.)
- Have all milestones and all work been reviewed to be sure that external costs have been clearly estimated? How were those costs estimated?
- If a milestone is delayed, is the accompanying expense also delayed? Where will expenses be required at a specific time despite the pace of work?
- What work has been done with supply chain, legal, and finance to be sure that vendors have been appropriately vetted and contracts are negotiated?
- How has marketing and product development worked to ensure that incoming revenue (new customers, etc.) timing is accurate? What model was used to forecast increased revenue?
- Is there an overall ROI, CBA, or NPV model that all teams (product, marketing, technical, finance) have reviewed and agree is high-quality?
Enjoy.
For Technology Teams and Developers:
Technology teams need to think about the “gotchas” with a new project. For example, rolling out a new system might not require much development time, but integrating something into existing infrastructure, DevOps and release management, and support processes can be work. Serious work. Questions from technology teams may include:
- Investigation of milestones and the features delivered, to be sure infrastructure needs can handle the new loads, customer volumes, or release processes.
- Questions about training, especially where new technology roll-outs or introductions are concerned. Note that training is often a concern for 100% internally-developed systems as it is a concern for introducing new commercial/open-source platforms or new languages.
- Where do roadmap items intersect with other important work that isn’t directly visible on the front-end, such as major patches, system updates, or similar work that’s required to keep systems secure and high-performing?
There can be many others, often spiraling down into very low details (very quickly!). Ensure that questions at the “roadmap level” are answered clearly but when technology questions start to become too specific or focused on one issue to ask for that to be addressed outside of a typical “roadmap discussion”.
Do not dismiss the focused technology questions, as they often can reveal very important challenges or risks. One small thing can often derail a major effort, but a roadmap discussion is about strategy. Once the specific question can be addressed in a different meeting, the roadmap stakeholders may need to change strategy, edit or add milestones, or so on.
The goal of a technology roadmap discussion is to show the big picture. Specific items should be addressed, but not at the expense of talking about how the day-to-day work being done helps the organization reach larger goals.