Big rocks first
Your roadmap is a working hypothesis
Product is probabilistic. That means you can't know for sure when Feature X will ship or if Initiative Y will work. You have a thesis about what matters and an informed guess about timing.
Your roadmap's job can't be precision. Your roadmap's job is communication: it needs to explain how you get from here to there, and why. Because your team need direction. Stakeholders need context. Leadership need strategy.
Making it comprehensible in one place - in a world that won't stop moving - is hard. We reach for tools to help us, and this is where it so often goes wrong.
The false choice
On one end of the spectrum, you build it from scratch.
You might use a spreadsheet, or a slide, or if you're lucky a physical or virtual whiteboard. While you can sometimes create exactly what you need, updating it is a nightmare. Every time things change - which is all the time - you're pretty much rebuilding it from scratch.
It's hard to build, hard to share, and hard to maintain.
On the other end, you've got enterprise complexity. These tools promise certainty they just can't offer. It's the illusion of precision through a deluge of features. A boring sludge of design slop, endless (and pointless) integrations, seventeen membership tiers, dependency-mapping, AI-suggested priorities, Gantt charts that pretend to know Q4 of next year.
But you don't use half of them, setup takes weeks, updating it properly is painful (so of course, you put it off). And your team still asks "so what are we actually doing?"
Work around the work
Both ends of the spectrum fail the same way: you spend more time managing the tool than doing the work.
Marty Cagan coined "product management theatre" for work that looks like work but isn't. Roadmap maintenance can easily become theatre if you're not careful. Lots of roadmap tooling exists to manage itself. You feed the tool so the tool can produce outputs that justify the tool. It's a closed loop — and does the actual work get better?
Your team need to know three things: what matters, when you're doing it, and that it might change. It's that simple (albeit not easy).
Rocks and sand
There's an old demonstration where someone fills a jar with big rocks, then pebbles, then sand, then water. Everything fits around the rocks. But if you leave the big rocks till the end, you run out of room. Same jar - but with much less in it.
Many roadmaps are full of sand and pebbles. Every feature idea, every stakeholder wish, every "quick win" someone, somewhere lobbied for in a meeting. The roadmap becomes a catalogue of everything you might do. And if everything's a priority, nothing is.
Good roadmaps start with the big rocks.
You know what they are for your product. You're thinking of them right now: the two or three (or perhaps four things) that actually move things forward. Not the sand and pebbles you spend most of your time and energy dealing with.
This is what big rocks first means.
Identify the rocks that change your trajectory. Make them visible to everyone. And let everything else fill in around it.
Less is clearer
When your roadmap has unlimited space and optionality, you can go in any direction. So you avoid making the hard decisions and tangling with the tradeoffs you need to. Prioritisation takes a back seat and you include everything. And day by day, the roadmap bloats into a sort of vague backlog pretending to be a plan (that nobody believes).
When you introduce constraints - less options, less swimlanes, less integrations - you're forced to choose. What actually matters? What are you willing to cut? What's a big rock and what's sand?
A simpler tool demands clearer thinking. You can't hide away from your own priorities.
Now-Next-Later roadmaps work because they trade false precision on dates for clarity on what's next. Big rocks first builds on that instinct: it's not just about when, it's about the weight of the work and what it means.
Which initiatives deserve the most space? What do you spend most of your time talking about? What's the thing that, if you ship it, makes everything else easier?
So use size to show importance. Position shows sequencing. When reality shifts - and it will - you drag, rearrange, and move on.
The fog lifts
When you put the big rocks in first (and crucially you, your team and your stakeholders are clear on what those rocks are), something fundamental shifts.
A roadmap with three big rocks communicates your priorities instantly. Anyone - engineer, director, new hire - can look at it and understand your strategy. This, then this, then that.
When reality changes and your plan is blown to pieces, you move the rocks and get back to work. Instead of debating formatting, or worrying you've not tagged each initiative with a weighted, AI-optimised prioritisation score... you talk about the real stuff. The hard stuff (which is so often the good stuff). The work is the work, again.