Chapter 4. Building Effective Roadmaps
Effective roadmaps help a cross-functional organization make deliberate choices about a product’s development. Whether you’re writing a roadmap or reading one, you have a stake in making sure the roadmap answers the questions on which you need stakeholders to provide consensus. Here are some questions that good roadmaps answer.
What Impact Will This Have on Users?
Outcomes are more important than outputs. When building a product roadmap, it helps to be explicit about the types of behavior that you intend to encourage. In Agile development, this intent is codified in user stories: As a [type of user], I want to [activity]. In other development methodologies, use cases perform a similar function. Regardless of how it works in your organization, the goal is the same: put the user first and speak to the behavioral impact that you want to create, not just the outputs that must be built.
How Will We Measure Impact?
It also helps to know how you will measure that impact—especially if your team will need to implement the metrics. Work with stakeholders to get consensus at the outset on how you’ll measure and have them ballpark the impact they expect a feature to have. Document your hypotheses. Prior to implementation, those estimates will provide a gut check for the roadmap—is this outcome realistic? Post-release, comparing the hypotheses with actuals will help create a feedback loop that will improve your ability to estimate impact in future releases.
What Are Our Strategic Objectives?
As an engineering leader, understanding the strategic objectives that underlie a series of releases will help you guide your team on the abstractions that will be long lasting, the expectations the business holds on scale requirements, and where new interfaces will need to exist between teams and services. It’s also a good way to talk about timing and the order of operations. Even if these objectives are documented elsewhere, explicitly referencing the Objectives and Key Results (OKRs) you’re building toward will help make sure your plans are consistent with your goals.
What Are We Willing to Give Up?
There’s a wide range of features you could build; the roadmap is intended to capture those that you will build. Out of a broad product opportunity space, the roadmap articulates the specific choices that have been made. Sometimes, that strategy is most evident in the reflection of what you’re willing to give up. To do this, consider the opportunity costs—the features you’re not pursuing—as a way to make explicit the product values you are expressing. For example, if your market places a high value on privacy, there are a number of social features that you won’t be able to pursue. By highlighting those trade-offs, you can expose the strategy underneath them.
What Are We Testing and What Mistakes Are We Comfortable Making?
Another important function of a roadmap is to reveal the places where there’s uncertainty. Uncertainty is part of the process; if the correct answer was obvious, someone else would have built it already. For your team, flagging the areas of the implementation under active testing is important for managing the level of attention you invest in an implementation.
Similarly, not every step will take you forward. If you knew that you were making a mistake, you probably wouldn’t make it. With that in mind, effective roadmaps should also flag irreversible steps and make sure there’s consensus among stakeholders that the risk is worth it.
How Will These Features Roll Out?
Effective roadmaps help coordinate the release by indicating how features will be introduced to users. The marketing team will probably appreciate having visibility into the work for which it will need capacity. Assume the same is true for the other teams you work with; use the roadmap to identify those dependencies upfront.
By covering the plan for releasing features in the roadmap, it will help build alignment and de-risk a release. For instance, if you know that a feature has open questions and is being actively tested, you can recommend giving preview access to a small set of customers and collecting their feedback before turning it on for everyone. Anticipating this in the roadmap will make it significantly easier to implement feature flags during development and will provide the other teams you’re working with the flexibility they can use to answer the open questions.
Good roadmaps create momentum as more teams’ needs are represented. That doesn’t happen by accident. Someone in the organization is working to ensure that your product’s roadmap spurs the coordination that makes the product better with every release. Even if you’re not responsible for crafting the roadmap, you can make it more effective by helping to ensure that it’s answering the right questions.
Thank you to Stephanie Wai for reading and editing drafts of this essay.