Last week I held a great AMA session in the Israeli Product Managers community. The topic was very relevant to this time of the year: roadmaps. You are probably planning your roadmap for next year as we speak. Or, if you are in a startup, you might be building the first roadmap that should lead you towards product-market fit.
If you read my strategic roadmap guide you should know that unlike what many people think, a roadmap is not a work plan. Instead, it is – as its name suggests – a map, a guide, that should help you explain to the entire company how exactly you are going to meet your goals.
But once you do that, there comes a time when you must translate this general guide into action, and that means first and foremost breaking it down into smaller deliverables and putting ETAs (Estimated Time of Arrival) on them. In many organizations, it would mean creating quarterly OKRs, but on the other hand, with the attempt to create a meaningful outcome-based roadmap, how can you commit to a goal to be delivered exactly within one quarter?
As with every problematic situation, the solution starts when you acknowledge that you (we) have a problem. And the problem here is that there is an inherent tension between results and timelines. It should sound familiar – whenever you are working on time estimates for any feature, you know that it’s a matter of scope, resources, and time. In fact, we are used to thinking that the scope and resources impact the timeline, but in reality if you have a strict deadline (or simply a quarter or a sprint) it is the time and resources that would usually impact scope, or if both your timeline and scope are fixed, you must adjust resources accordingly.
In this triangle of time, resources, and scope, you can only set two of them (any two) and the third one would need to be adjusted accordingly. BTW, if you try to set all of them without any flexibility, it would typically impact another aspect that is not listed here – quality. In some cases, it’s the right thing to do, but even if it is – make sure you compromise on the things that you truly are willing to compromise on and not simply compromise on whatever happens eventually.
All of this happens even when you operate under relative certainty (e.g. smaller features that you know exactly what to do and have a good understanding of what it takes). But when you get to roadmaps, there is an inherent layer of uncertainty added. The longer you look into the future, the more uncertain it is. The closer you are to business results (as opposed to feature delivery), things depend less on you, and uncertainty is added. The harder the problem you are trying to solve, let alone with complex technology or algorithmic research, there is less certainty that you can actually solve it, and the timeline becomes a mystery.
No wonder that when it comes to roadmaps (strategic, long-term ones), creating a solid timeline is challenging. But don’t worry, there are still things you can do. Here is how you should approach it.
Draw a Clear, Complete, and Agreed-Upon, Path
I need you to go back in time with me. Those of you who are old enough remember that we used to drive to places without Waze. There was a physical map, I had one of those books in the car with me, and when I needed to go somewhere, I would ask my parents to show me on the map where exactly I should be driving. They highlighted the roads and the turns I should take to get to where I needed to be. They couldn’t say how long it would take me to get there, but they showed me the complete path to where I wanted to be.
That’s an important part of your roadmap. Of course, the first part is to know where you want to go, and the goals discussion is a super important one, but then you need to pave the way. Too many companies skip this step and instead of showing the full road to be taken, they go right into the deliverables and timelines. You really don’t want to get there too fast. The path is what glues everything together and makes the whole roadmap logical. It should make sense to people.
This path should entail your product strategy and looks something like that: our mission is to make [your domain] accessible to all people. It should be an easy and simple experience [unlike today]. To get there we will start with smaller companies who cannot afford to put a lot of resources into this problem but still need to solve it. Then we will go to the larger ones who would be happy to not have to do it by themselves although they could. Eventually, we will build a platform that would allow 3rd parties to deliver their own services to their customers with our technology. This example is completely made up but I hope it makes sense to you.
In this step, you need to debate the path within the company and ask yourself or let others ask you why this is the right path. Maybe you should start with the larger organizations first? By doing that you will get a much better understanding of your domain and the real constraints that you are dealing with.
Define the Outcomes That Mark the Move Between the Phases
Once you have an agreement on the path you should be taking, you need to know when to take each turn. Unlike a real map of roads, where the junction shows up ahead of you, in our world, you are creating the junctions yourself. So how would you know that it’s time to move to the next phase? In the example above, when would you be ready to move to larger companies?
The best way to deal with it is again without timelines since some things need to happen in the world (AKA results) regardless of the time it takes. Ask yourself what needs to happen or which outcomes you need to have before you can move to the next stage. The more you understand and agree on it with management in advance, the less chaotic it would be when the time comes to make the actual decision.
OKRs fall nicely into this task, but you can use any other method that works for you. Essentially, the objective is whatever you are trying to achieve on a single road before you turn, and the key results are the details of how you would know that it was indeed achieved and it’s time to take that turn.
This would require you to think far into the future and look backward. But trust me, it is much easier to do this way than to find yourself standing in this future, looking at the results you have and wondering if they are good enough or not. Thinking about these in advance helps you consider things much more objectively, without being already in the situation and trying to adjust the numbers to match whatever decision you really want to make.
Communicate a Number of Timeline Alternatives
Now it’s time to put timelines on these. Of course, these timelines are only an assessment. While everyone understands it in theory, not everyone accepts it as it is, even if they say they do. The above framework of discussing the path and the key results that you need to achieve to move between stages sets the ground for a more intelligent and strategic discussion on this.
Generally, you should put two options on the table: one that is led by results and one that is led by timeline. Note that both options would have both results and timeline in them eventually, but as with the triangle example I gave above, only one is fixed and the other needs to be adjusted accordingly.
For example, you can decide to go with quarterly OKRs as the lead method. That would mean that you need to break down the KRs for the first and second phases into something that could fit in a single quarter. Now, since you don’t really know if this is 100% achievable within a single quarter, there are a number of options for how this would impact the Q2 OKRs. You can give these options already when you plan for Q1, to highlight the fact that this is just an estimate, and to demonstrate that you have a plan for whatever outcome Q1 will bring.
Alternatively, you can decide to lead the company with outcome-based progress. It means that you must meet the first milestone before you get into the second one, no matter how long it takes (or at least with large flexibility on the timeline here). This is more relevant to startups and major strategic initiatives than to more tactical efforts. Still, organizations can’t operate without some time estimates so that everyone else (marketing, sales if relevant, customer success and so on) knows what to expect and how to prepare for their part in the game. In this case, present your outcomes, a few alternatives for how long it would take to get there, and what you are going to do in each alternative.
You might have noticed that the bottom line in both methods is that you discuss a few alternatives for progress over time and have a clear path for each. There isn’t a clearer way that I know of to signal to management that timelines are volatile. It is for sure much stronger than just saying it time and again.
I encourage you to give it a try. Your roadmap for next year would be much more robust this way, and your stakeholders much happier with an outcome they were prepared for in advance.