A lot of teams have a roadmap and call it a strategy. You can usually tell, because when you ask why a particular item is on it, the answer is "because a customer asked" or "because leadership wanted it." The roadmap is a list. Nothing explains why that list and not a different one.
When I was directing digital product strategy across the Travelxp group, covering both the OTT streaming platform and the OTA booking side, the hardest part wasn't building the roadmap. It was being clear enough about strategy that the roadmap made sense to people who weren't in the room when it was decided.
What each one answers
| Strategy | Roadmap | |
|---|---|---|
| Main question | Where are we going, and why will we win there? | What are we doing next to get there? |
| Time horizon | Usually a year or more | Usually weeks to a few quarters |
| Changes | Rarely, after real learning | Often, as evidence comes in |
| Content | Target users, problems, choices, what you won't do | Bets, outcomes, sequencing |
| Audience | Leadership, the whole company | Product teams, stakeholders |
The roadmap should be an expression of the strategy. If the strategy changes, the roadmap should change. If the roadmap changes and the strategy doesn't, there should be a clear reason, like new evidence about which bet works best.
A one-page strategy
I like strategies that fit on one page. Something like:
- Who we serve. The specific users or customers we're focusing on.
- The problem. What they're struggling with that matters to them.
- Our advantage. Why we're well placed to solve it. Content, data, distribution, expertise.
- The choices. Where we're focusing and, just as importantly, where we're not.
- How we'll know. The few measures that tell us the strategy is working.
The "where we're not" part is the most often skipped and the most useful. A strategy that doesn't rule anything out isn't really making a choice.
Marty Cagan at SVPG writes a lot about product strategy being about focus and making hard choices, not just listing goals. 1
Signs the roadmap has no strategy
- Items on the roadmap can't be traced to a clear goal.
- Every team's roadmap points in a different direction.
- The roadmap changes completely every quarter.
- Nobody can explain why one big item was chosen over another.
- Saying no to a request is impossible, because there's no principle to point to.
If you see these, I'd go back and agree on the strategy before touching the roadmap again.
Connecting the two
I tie each roadmap item to a part of the strategy. Often that's through an outcome, like in the outcome-based roadmap example. The outcome sits between the strategy and the work, and makes it clear why each item is there.
OKRs can play a similar role for a quarter. They pick which parts of the strategy to push on now. I wrote about OKRs for product teams separately.
Revisit strategy on purpose
Strategy shouldn't change every month, but it shouldn't be frozen either. I'd review it on a regular schedule, maybe twice a year, and whenever something big changes: a new competitor, a major customer shift, a technology change like the arrival of capable LLMs.
When it changes, say so clearly, and update the roadmap to match. A strategy that quietly drifts while the roadmap stays the same leaves teams working on things that no longer fit.
Keep them separate documents
It's tempting to put strategy and roadmap in one big document. I prefer keeping them separate. The strategy is short and stable. The roadmap is longer and changes often. Mixing them makes the strategy feel as temporary as the roadmap, which isn't what you want.