Traditionally, roadmaps have taken the form of a powerpoint or Gantt chart with a list of features and delivery dates. As teams have moved towards Agile development, roadmaps have evolved to embrace change.
Perhaps Mandy Priamo, Staff Product Manager at Pivotal Toronto, explains it best. "Roadmaps are not release plans. They do not define deliverables by iteration, but rather outline why we intend to deliver."
Roadmaps for Agile teams include:
-
Focused on outcome over output.
-
Evolving over static.
-
Embrace learning over establishing certainty.
While those guiding principles are a great place to start, Product teams still find it challenging to build good roadmaps. Tim Lombardo, Director of Product Management at Pivotal New York, and I went on a journey to build a diagnostic for teams at Pivotal. What we mapped out are six tests we recommend all teams consider using to assess the quality of their outcome-oriented roadmaps.
Test 1: Are The Outcomes Clearly Articulated?
A well-articulated outcome describes the value that a team intends to create, for who and for which persona. A well-articulated outcome says more about the impact on the user and less about the details of the solution. It is also valuable to mention how you plan on achieving the outcome to give a sense of general direction the team plans to take.
For Saikiran Yerram, Senior Product Manager at Pivotal San Francisco, he “has consistently seen solution based roadmaps such as "Doing X will solve Y" instead of "Solving Y will achieve <some desired outcome>.” The best outcomes based roadmaps clearly show what will the user do more (or less) once the problem Y is solved.”
When looking at your outcome be sure to ask yourself these questions:
-
Does it elucidate who the outcome is meant to help? Outcomes could be for customers, business or even your team.
-
What is the impact you hope to achieve?
-
Why is working on this outcome the most valuable thing you could be doing with your time? What are you deprioritizing to work on this? Listing the other outcomes that your team *could* work on but have decided not to is great way of showing what you factored into your prioritization decision. It also helps to break out your roadmap into short-term, mid-term, long-term so you can lay out how you are prioritizing your work. As you are articulating outcomes for mid and long term think about what you are hoping to learn/validate instead of the thing you plan on building.
-
Does it align with the priorities of your business?
Test 2: How Good Are Your Metrics?
Identifying metrics that tell you that you are making progress can be difficult. Often, it’s tempting to measure output and call it a day once it's shipped. However, a good metric tells you whether and by how much you were able to impact or add value for your persona. When looking at your metrics of success ask yourself these questions:
-
Do your metric(s) measure whether or not the outcome (not output) has been achieved? Beware of vanity/proxy metrics that appear correlative, but are not. Example: high acquisition numbers do not indicate that you are actually solving the problem for the user. Dan Jahner, Senior Product Manager at Pivotal San Francisco, “tests for whether a set of metrics are sufficient by trying to envision ways in which the metrics could be achieved without actually affecting the outcomes they intend to measure.”
-
Is the metric measureable? Take a moment to think about whether you can actually measure it and if it is easy to measure.
-
Do you have a baseline (or can you afford the time to get one) to be able to see progress? Prototyping, user interviews, current product instrumentation, and customer support tickets are all quick ways to achieve a baseline.
-
Are your metrics a mix of quantitative and qualitative? Quantitative metrics will only give you a signal of where to look. Qualitative metrics help you understand the signals and build the story.
Test 3: Have You Articulated Risks and Mitigations?
Every outcome you want to drive comes with associated risks or uncertainties. An important part of successfully executing on your roadmap is to make sure you have a good sense of your biggest risks and unknowns and have a plan to mitigate the risks. Ask yourself these questions for each outcome:
-
Do you have a clear sense of the risky assumptions around your outcome? What are the leap of faith assumptions you are making which, if invalidated, will adversely affect the outcome you are hoping to achieve?
-
Have you identified and prioritized the riskiest assumptions that you need to tackle immediately?
-
Do you have a plan on how to test those assumptions?
Test 4: Does Your Roadmap Represent an Aligned Viewpoint?
A roadmap at its core is a way of communicating priorities that are shared by the team and leadership or the team and customers/users. It is the cornerstone that can be used to make sure that everyone is on the same page on priorities and outcomes.
Building a roadmap that represents your point of view is easy. Building a roadmap that represents a viewpoint that is aligned with the team and leadership is much harder. So ask yourself:
-
Was your team involved in building the roadmap? Would they be able to represent and speak to the roadmap as well as you?
-
Can you clearly connect the priorities outlined to one or more business objectives?
-
Were your leaders/stakeholders involved as you were iterating on the roadmap?
Test 5: Is Your Roadmap Easy to Discover and Consume?
As mentioned earlier, a roadmap is a communication tool. It helps to communicate the shared priorities of the team externally to stakeholders like leadership, customers, users, marketing, sales, etc. The last thing you want to do is get on a call every time someone wants to understand what the team is working on. Ask yourself:
-
Is your roadmap easy to find? One easy trick is to link to it in your communications.
-
What is the context people need to have to understand your roadmap? Provide references to material that helps with building context.
-
Who is your audience? You might need different framing and information for internal stakeholders vs external stakeholders.
Test 6: Do You Have a Systematic Approach to Reviewing and Iterating Your Roadmap?
Starting a roadmap document is the easy bit. Tracking to it and updating it as you have more data is where a disciplined practice is needed. It is important to come back to roadmaps regularly as a team to see how you are tracking against your goals. It’s a great way to refocus and track progress. It also creates space to reflect on things that are blocking you or slowing you down. So ask yourself:
-
Do you have time set aside at a regular cadence to revisit the roadmap with your team and main stakeholders to reflect on the progress you are making, sharing learnings and updating your roadmap based on new information?
-
Is the cadence the right cadence? The cadence should relate to the frequency of your feedback loops and also how frequently your stakeholders might want updates. If you are working on something with short feedback loops it is likely you want to revisit the roadmap at least every month. If you have high certainty and the feedback loops are longer you might be fine re-visiting the roadmap every other month or every quarter. Anything more than once a quarter is definitely too long.
Building and maintaining roadmaps are intimidating. It is a way of telling a rich story of how your team is striving to add value to the business and the customers. Putting in the effort to do it forces teams to take the space to be thoughtful and critical of what they plan on building and why. It also helps teams keep themselves accountable to the things they sign up for. Like everything else it takes discipline and continuous iteration and improvement, so don’t feel disheartened if you don’t get it right immediately. The journey is more important than the destination.
Thank you for all the folks at Pivotal who were involved in the research and making of this blog. Special thanks to Tim Lombardo who was my pair and partner in crime.
