Estimated reading time: 2 minutes
A few years ago, when I started having enough teams to lead that I couldn't fit everything on a post-it note anymore, I discovered the work of Janna Bastow (@simplybastow).
What seems an obvious concept today was quite abstract back then: get rid of Gantt charts and start thinking about buckets: Now, Next, Later.
For more details on Janna's vision, I suggest checking this thread.
One of the core objectives of your roadmap is that it should never lie.
It will change. Changing is the only way a roadmap never lies because there is simply no way you got it right from the start.
Now contains those items that are happening. People are working on these right now. Accidents may still occur but are less frequent.
Next is a prioritized list of projects you are confident will move to Now as soon as you have the capacity. Of course, priorities may shift, and Next can change. It often will.
Later is a vision of the future with today's information. It constantly evolves based on new learnings. It's a visualization of your strategy, not a promise.
My pragmatic approach
The Now/Next/Later roadmap works well as a tool to figure out what your future product should look like and how to get there from here.
I'll be candid, though, "it will be ready when it's ready" isn't practical when working across teams and disciplines, and, in my book, a pretty big red flag (we'll discuss why tomorrow).
So my concession to timelines is that once projects move to Now and teams dive into them, I ask them to estimate their duration. I also require them to update that information systematically every time an event delays their progress when it happens. With this approach, our roadmaps never lie, but we have a tool that rallies all stakeholders and enables cross-team collaboration.