Photo by Clark Tibbs on Unsplash

Most roadmaps fail in one of two ways: They become an annual PowerPoint promise that nobody on the team is willing to touch again for fear of being held to it, or they live inside a product tool that the executive team never opens. Either way, shortly after it's compiled the roadmap stops doing its job - which is to tell people what you're doing and why.

The fix starts with a reframe. A roadmap is your best guesstimate view of the world based on what you know today. It isn't a contract. Even a traditional Gantt chart, going back to PMBOK, is meant to be updated as reality changed. The moment a team starts treating a roadmap as immutable, they stop wanting to show it to anyone, because now every change looks like a broken promise instead of normal planning.

Over the past six years or so, I've iterated on a one-page framework built around three layers. This version builds on an early iteration Daniel Gotilla used back when we worked together. The top layer is a single sentence: the vision. I test it with what I call the elevator pitch. If you stepped into a lift with your CEO and had three floors (my current Sydney offices three floors) to explain what your team is trying to accomplish with the resources it has, what would you actually say? If you can't answer that in three floors, the vision isn't sharp enough yet. A good one is a half-half mix of aspirational and achievable: enough to point toward something worth building, grounded enough that people can commit to it.

Below that sit three or four strategic initiatives, no more. These are the major problems (think how-might-we statements) or outcomes that have to be addressed to make the vision real. I keep the list short intentionally, because a long list of initiatives isn't a strategy, it's a wish list. One of those HMW lanes should explicitly be tech debt, so engineering has permission to spend real capacity improving what's underneath the product instead of only shipping features on top of it.

Each initiative becomes a horizontal lane across three columns: now, next, and later.

Now is well defined, active work you could potentially link directly to a delivery ticket.
Next is understood at a higher level, quantified enough that you believe it's worth doing, but not committed to the detail of a sprint. Think of it as an epic.
Later is exploratory. it's usually a problem statement. It might change completely or never happen at all, and that's fine, because it hasn't been promised to anyone yet.

I personally prefer sticking to now / next / later and not putting time-boxes like "Q1" in the headings, as that makes it easier to keep re-using the same slides throughout the year.

The design principle underneath all of it is clarity now, optionality later. Commit hard to what's close, and keep what's far away loose enough to adapt. And if you work in an environment where there are multiple products, I like to use this format and have one slide for each product. Compiling the multiple products together, then, is a good way to present your product strategy for the portfolio.

I build this as a single PowerPoint slide. Executives may never open Jira or Confluence, but they open PowerPoint every day. Meeting people in the format they already use is most of what makes a roadmap actually get read.

I've evolved a very simple methodology to derive the info used to help build roadmaps out. It is intended as a process to guide teams through talking to stakeholders and defining a roadmap through broad collaboration - more on that later.

Template is here

screenshot of blank roadmap template

#ProductStrategy #Roadmapping #ProductLeadership