Skip to content
Founders’ price Launch pricing for your first twelve months. 40 Playbooks, 40% discount for Founders. View the playbooks →

Roadmap Planning

TTool · Roadmap Planning

By , Editor · · What’s Next

“The process of creating and maintaining product roadmaps that communicate planned development direction.”

Stakeholders want a plan. The team wants flexibility. The last roadmap became a contract the moment it was shared, and now half the items on it are wrong but nobody will say so.

Roadmap Planning is the practice of creating and maintaining product roadmaps that communicate direction without pretending to predict the future. You structure time horizons with decreasing detail — committed near-term, likely mid-term, exploratory long-term — and emphasise outcomes and themes rather than specific features.

Three horizon columns - 01 now, 02 next, and 03 later - under the caption 'themes commit to direction. Features rent credibility against dates.'
Method visual — Roadmap Planning

Its strength lies in the planning process itself: engaging stakeholders, surfacing conflicts, making trade-offs explicit. The document is secondary. Reach for it when the team needs shared direction and stakeholders need enough predictability to plan around, while preserving room for discovery as learning occurs.

It fails the moment a roadmap is treated as a contract rather than a communication tool — when items can't be removed without a political battle, the roadmap has stopped serving its purpose. Without strategic clarity upstream, a roadmap just sequences confusion.

Your next move: Which item on your current roadmap will you genuinely defend in six months when the assumptions behind it have changed — and which are you secretly hoping no one mentions?

What it looked like for them

SkyRocket, early 2010s. The founder was exceptionally good at selling — good enough to close tens of thousands of dollars in enterprise software deals on the strength of a PowerPoint, before there was any product, any architecture, or any team to build one.

There was no roadmap. There was no plan for how the sold features would be built, in what order, by whom, or by when. What existed was a set of promises made to paying customers and a gap between those promises and reality that widened with every sale.

The founder took a short leave of absence. In his absence, the development team quit en masse, took the client contracts with them, and the company collapsed overnight. A roadmap wouldn't have made the product appear faster. But it would have forced the question: is what we're selling buildable by the people we have, in the time we've promised? The answer, had anyone written it down, would have been no. Nobody wrote it down.

- returns a SafeString and get.js throws on it }}
A move inside a Playbook

“I'm behind and I have to decide what to drop.”

Open the Playbook →

Share the Playbooks