Outcome roadmaps

A roadmap is a communication tool: it tells the organization what problems you intend to solve and in what rough order — not a contract to ship seventeen features by March 31. When roadmaps become Gantt charts of feature promises, discovery dies, engineers become a feature factory and every slip looks like failure even when you learned the right thing.

Think of strategy as the argument for where and how you win, the roadmap as the sequenced bets that pursue that argument and OKRs as the scoreboard. If those three disagree — strategy says activation, roadmap is full of enterprise checkboxes, OKRs track NPS — the org will thrash.

The big idea

Feature roadmaps feel concrete to executives and customers. They also freeze solutions too early. If the goal is "reduce time-to-first-value," the team might ship a checklist, a template gallery or a concierge onboarding — whichever works. An outcome roadmap keeps that optionality. You can still name candidate solutions under an outcome — just label them as bets, not promises, until discovery confirms.

Marty Cagan and others argue empowered teams need vision + strategy + outcome objectives, not a prioritized feature backlog handed down as destiny. When leadership insists on feature dates for board slides, translate: show the outcome, the leading bets and confidence — then offer a date range only for the thin slice you are willing to commit to.

A train timetable vs a destination board is the picture. The timetable promises platform 4 at 9:12. The destination board says "north, then the coast, then we will see." The analogy breaks when a regulator or a contract really does need 9:12 — then you commit a thin slice, not the whole year.

Walking through it

Sales wants a date for SSO. Outcome framing: "Next: enterprise readiness — SSO is the leading candidate because three deals are blocked; we'll confirm scope after security review in two weeks." You gave a sequence and a decision point without inventing a ship date you cannot defend.

For engineers: ask "what outcome is this for?" when a feature lands on the roadmap without a KR. Offer sequencing and cheaper tests. Push date-precision only where dependencies or external promises require it.

Common mistakes

• Gantt of features as the only artifact. Discovery then looks like a broken promise.
• Success = shipped the checklist. Activation at 12% with a shipped checklist is not success.
• Dates on every theme because the board asked. Date the thin committed slice; keep the rest as sequence.

Check yourself

1. Goal is "reduce time-to-first-value." Why is "Checklist v2 ships March 31" a weaker roadmap line?

It freezes the solution. An outcome line lets the team pick checklist, templates or concierge based on evidence.

2. Strategy says activation, the roadmap is enterprise checkboxes, OKRs track NPS. What happens?

The org thrashes. Align the three: strategy chooses problems, roadmap sequences bets, OKRs score whether they worked.

Key takeaways

• Roadmaps communicate sequence and intent; they are not Gantt contracts.
• Prefer outcomes above initiatives; label solutions as bets until discovery confirms.
• Align strategy, roadmap and OKRs or the org will optimize three different things.

Further learning

SVPG articles — Marty CaganA partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group Vision vs. Strategy — SVPGA partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group

Next: sequence without fake dates in now / next / later.