I don't disagree that timelines are important. However, here is the problem I consistently see:
Wrong Way: Most roadmaps contain timelines that are "We're going to build this specific thing and we're estimating it's going to take this long" (Even worse is if they're specifically bucketed by quarters with strict cut offs). Isolated estimates of how long something will take will always be wrong because it doesn't account for all the work in the system and the trade offs that brings with it. Basic Lean theory at work.
Right Way: "We're going to try and create this future state of the world, we'll know we're there as measured by x y z metrics, and we're going to budget this much time and this many resources to try and pull this off. Here's some high level ideas of how we can do this".
When you roadmap in the second way, you can still provide the business a timeline, but:
- You leave yourself the ability to pivot your approach along the way and still try and hit those measurables (futures not features, you want to be crystal clear about where you're trying to get without committing to how you're going to get there in any specific way)
- You transition the evaluation of your results away from a boolean (did you build this thing or not), to a discrete measurable, that still allows you to achieve some amount of success even if you didn't completely hit the goal ("Our target was a 60% reduction in support calls, and we were able to reduce by 40%").
I'd also argue that a kanban style roadmap (considering, planning, next, doing, done), is more than enough of a timeline even without dates, so long as each outcome seems reasonable enough to achieve in 2-4 month efforts. The reason why, is I can look at the right side of the roadmap and immediately understand that you've prioritized those Outcomes as being more impactful than the left side of your roadmap.
(Extreme caveat here: You have to have a leadership team that buys into this approach. Some leaders will look at this and just say WTF where's your Gantt chart. You can then either teach them the right way, do what they say and probably fail, or quit, your call).
Your "right way" is the right approach to anchor on but in reality it never works out as nice as it sounds. Common problems:
1. You have some projects that are rigorously time bound (e.g. we absolutely need to ship X by Y date). Maybe scope is negotiable a bit but you definitely need results by a certain date.
2. Implicitly all of your work is time bound. Even if you say "we want to get to a 60% reduction in support calls", the follow up question is "by when?". Tons of internal forces (employee reviews, shifting company priorities) shift the framing from "we think a 60% reduction in support calls is a healthy sustainable level for our business, and that is our goal" to "we are targeting a 20% reduction in support calls over the next six months". Then your multi-quarter big-bet projects need to be broken down into phases which won't have an impact on the support calls by themselves, so you have to take ship goals or create other goals to capture that work (not great)
> 1. You have some projects that are rigorously time bound (e.g. we absolutely need to ship X by Y date). Maybe scope is negotiable a bit but you definitely need results by a certain date.
In this case, you explicitly call out that roadmap item, and label it as "this thing will win out and other initiatives will be delayed if this thing goes sideways"
> 2. Implicitly all of your work is time bound. Even if you say "we want to get to a 60% reduction in support calls", the follow up question is "by when?". Tons of internal forces (employee reviews, shifting company priorities) shift the framing from "we think a 60% reduction in support calls is a healthy sustainable level for our business, and that is our goal" to "we are targeting a 20% reduction in support calls over the next six months". Then your multi-quarter big-bet projects need to be broken down into phases which won't have an impact on the support calls by themselves, so you have to take ship goals or create other goals to capture that work (not great).
Yes, you're right, I didn't write that one clearly. For outcomes like that, you should have defined "come up for air" dates where you measure and determine whether you keep going or call it as good enough/not worth it to continue and then move on to other things.
Wrong Way: Most roadmaps contain timelines that are "We're going to build this specific thing and we're estimating it's going to take this long" (Even worse is if they're specifically bucketed by quarters with strict cut offs). Isolated estimates of how long something will take will always be wrong because it doesn't account for all the work in the system and the trade offs that brings with it. Basic Lean theory at work.
Right Way: "We're going to try and create this future state of the world, we'll know we're there as measured by x y z metrics, and we're going to budget this much time and this many resources to try and pull this off. Here's some high level ideas of how we can do this".
When you roadmap in the second way, you can still provide the business a timeline, but:
- You leave yourself the ability to pivot your approach along the way and still try and hit those measurables (futures not features, you want to be crystal clear about where you're trying to get without committing to how you're going to get there in any specific way)
- You transition the evaluation of your results away from a boolean (did you build this thing or not), to a discrete measurable, that still allows you to achieve some amount of success even if you didn't completely hit the goal ("Our target was a 60% reduction in support calls, and we were able to reduce by 40%").
I'd also argue that a kanban style roadmap (considering, planning, next, doing, done), is more than enough of a timeline even without dates, so long as each outcome seems reasonable enough to achieve in 2-4 month efforts. The reason why, is I can look at the right side of the roadmap and immediately understand that you've prioritized those Outcomes as being more impactful than the left side of your roadmap.
(Extreme caveat here: You have to have a leadership team that buys into this approach. Some leaders will look at this and just say WTF where's your Gantt chart. You can then either teach them the right way, do what they say and probably fail, or quit, your call).