Everyone wants to see the product roadmap. Sales wants to use it to drive bigger deals, engineering wants to know what is coming next to make technology decisions and other teams want to feel like they are part of a long-term strategy that will take the organization to the next level. But, the market is fickle, with an ever-changing set of priorities and needs. So, how do you reconcile the needs of projecting a long-term product plan with the reality of a constantly changing market, especially when you use an agile approach like scrum?
Agile Loves Roadmaps and Plans
First, let’s dispel a myth. Agile and scrum don’t discourage the creation of a product roadmap. In fact, scrum teams plan frequently. To quote the agile guru Mary Poppendieck: “Agile hates plans, but loves planning.”
In short, with agile teams there is both the need for frequent planning and the challenge of keeping a plan up to date. But many scrum teams want to start a sprint before they have a clear vision for the product. Or worse, if there is a clear vision they ignore it and focus on what they think is best. Having a vision and a backlog are the cornerstones for any scrum team and sprint. In Agile Project Management with Scrum, Ken Schwaber, a scrum co-creator, writes, “The minimum plan necessary to start a scrum project consists of a vision and a product backlog. The vision describes why the project is being undertaken and what the desired end state is.”
Support the Empirical Process
There is no single silver bullet for building the perfect roadmap. Each situation is defined not only by the product, but also by market, audience and organizational culture. What makes sense for a bank selling bonds won’t work for a web company delivering a new media product. Remember the golden rule when you use scrum: Support the empirical process.
Scrum, unlike waterfall, is an empirical approach. Drawing on the ideas of scientific method, it provides a lightweight framework that encourages inspection and adaption through transparency. It assumes you don’t know everything up front and encourages you to deliver working software frequently to learn. Managing the unknown requires agility. Therefore, it is crucial that a product roadmap not provide a detailed list of features and timeline, but instead provides direction for the team to build the right software. In a nutshell: Do not bring a waterfall roadmap to a scrum product delivery.
5 Tips for Managing the Agile Product Roadmap
The following five tips will help you manage and deliver an effective agile product roadmap.
- Focus on customer and user outcomes, not features and functions. Many roadmaps emphasize features and their delivery. But concentrating on customer outcomes makes it possible to describe the plan’s business focus. It also provides flexibility so that scrum teams prioritize the right things rather than requirements that may not deliver the right business outcomes. Avoiding product feature descriptions allows you to focus on intent and define clear measurable success, rather than test criteria. Finally, if the roadmap is well-written, you won’t need to continually explain the objective of a particular item to the rest of the organization.
- Eat the elephant one bite at a time. Roadmaps, unlike college assignments, don’t benefit from size. The best roadmaps don’t provide a detailed list of features. Instead, they instill their audience with a sense of the product’s direction. Rather than providing detailed descriptions, find a phrase—like mobile-first release—that explains the intent. This helps others latch on to the meaning of the release and provides flexibility for the scrum teams to build what is required. Delivering frequent, incremental roadmap updates, or providing an intranet site that shows roadmap status, helps manage change and provide a clear sense of direction. Of course, those updates must clearly connect to the work of the scrum teams delivering against those broad objectives to demonstrate regular progress against these goals.
- Be honest without scaring everyone. How many times have you been to the roadmap presentation only to hear that the killer feature has once again slipped to the next release? Roadmaps that support scrum teams should still forecast, but do it in an honest and open way highlighting that the farther out an item is, the less likely it is to be delivered. Roadmaps are like weather reports: the longer the forecast, the less likely it is to be true.
- Add a clear measure of success to your roadmap and report data on its success. Instead of simply describing the need, provide a way to measure its success. For example, if a required capability is for the user to obtain their credit score, you could define that 12 percent of all customers execute the feature and 50 percent of new customers as a measure of success. By adding a measurable success benchmark to a roadmap item, you provide clarity and encourage the development team to instrument the application. Instrumentation provides a platform for lean analytics and connects nicely to empirical processes that are driven by learning and results. By connecting this data to roadmap items up front, there no ambiguity for the business or the delivery team.
- Put everything in the context of true north. Everyone wants to work on something that matters. In Drive: The Surprising truth About What Motivates Us, Daniel H. Pink describes purpose as one of the three key elements to personnel motivation, along with autonomy and mastery. The purpose of a product is something more than its features, functions or even its user outcomes. Purpose describes why the product exists and is closely linked to an organization’s mission. Describing everything in the roadmap in the context of its purpose allows scrum teams to better understand why at the macro level. The purpose is reflected in the sprint goal, which helps define the sprint backlog and which is then reviewed in the sprint review. Purpose helps connect all these scrum events.
Communicate, Communicate and Communicate Some More
Ultimately, the product roadmap is a tool for communicating direction and providing a broad vision for timelines. It should be used to measure outcome success, communicating future intent and previous learnings. A short, business-focused, customer-oriented and measurable roadmap allows your organization to not only build the right product, but to motivate the entire organization. A successful product roadmap will become the narrative for your entire organization.
Dave West is the product owner at scrum.org. He is a frequent keynote speaker and a widely published author of articles, along with his acclaimed book: Head First Object-Oriented Analysis and Design. He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI. He also managed the software delivery practice at Forrester research where he was vice president and research director. Prior to joining Scrum.org, he was chief product officer at Tasktop where he was responsible for product management, engineering and architecture. Email Dave at [email protected].
By Dave West
To learn more about roadmapping, read the Product Roadmaps issue of Pragmatic Marketer.
