I just googled the terms "roadmap definition" and this is what I got:
What strikes me is that the notion of time is entirely absent from both definitions. So why is it that we so often think of roadmaps as a delicate game of deadlines?
Your projects are bets that you make to improve your business and the experience of your customers. You _hope_ that your new onboarding will facilitate adoption. You _hope_ that the latest feature will delight users. But you can't be sure. And it would help if you had a simple way to discuss the tactics and risks with the team.
That's where roadmaps come in. They help the team debate all the bets in flight and come up with the optimal order for them. Are we shipping the right bit of value? Are we taking too many risks at once? Do we need to change the order of things? These are the questions that the team needs to focus on, but they vanish as soon as you start using timelines.
A timeline treats your projects like a game of Tetris. You're trying to fill blank spaces with rectangles of different sizes and colors. Too often, the discussion shift towards capacity rather than value.
– There's a bit of space left in here!
– Oh, maybe we can add this small thing then.
But there's no such thing as a small project. And now you have 2 people working full time on something that was never a priority. Unknown unknowns pop up, scope expands, and you end up delaying significantly other valuable improvements.
As soon as you put the time axis in front of people, you'll see the questions changing from "should we do this first?" to "can we ship it faster?". People will debate the shapes of your rectangles rather than why they exist in the first place.
There's another simple approach that you can adopt for your roadmaps. Create a doc with 3 columns:
This format will help you emphasize the order of things rather than their due dates. And this is where it relates to OKRs. You set OKRs at the beginning of the quarter to give your team a sense of direction. Objectives represent your North Star. Your Key Results will help the team measure progress. And your projects are how you move the needle. Then, you should measure progress on your KRs every week to see if the work you do is having the right impact:
A Now, Next, Later roadmap makes it easy to move things around. Your Now column shouldn't change as it's committed work, but you can quickly look at the Next and Later columns to see if there's a better way to arrange things. Timelines don't provide the same flexibility as they're capacity-based rather than value-based.
Being an outcome-driven team does not mean that you reject the idea of outputs. It means that you start by defining success first, and then you pick the best way to get there. And you can (and should) go one step further by treating that relationship as a feedback loop.
Outcomes help you pick the right outputs to work on. Results from your outputs help you refine your outcomes.
Startups need to be focused and flexible. OKRs can help a lot with the former, but they'll quickly stiffen your team if you start cascading your goals.
You can't just throw OKRs in a spreadsheet and expect your team to be outcome-driven. You need first to get the right culture to create an environment where teams can iterate to reach their goals.
There's a lot that we can learn from software teams to improve the OKRs process.