From Mission to Task: How to Connect Strategy to Your Roadmap
A stack that keeps your roadmap honest — and a warning about the gap in the middle.
The most common criticism of a bad roadmap isn't "you shipped the wrong thing." It's "I don't understand why you're shipping this at all."
That's a strategy problem wearing a roadmap costume. And it's a trap a new PM can fall into quickly at a big company, because large orgs give you plenty of ambient guidance — OKRs cascading down from the CEO, quarterly priorities, "corporate pillars" — but very little explicit linkage between the vague stuff at the top and the concrete tickets at the bottom.
Lenny Rachitsky's canonical framing for the full stack is this:
- Mission — What are we trying to achieve?
- Vision — What does the world look like when we've achieved it?
- Strategy — What's our plan to win?
- Goals — How will we measure progress?
- Roadmap — What do we need to build to get there?
- Task — What's one unit of work we can tackle next?
Six layers, each one a level more concrete than the one above it. The reason to internalize this stack early is not that you'll ever write a document that looks exactly like it — you won't. It's that when something on your roadmap feels off, you can walk up the stack and find where the linkage broke.
Start at the top, even if it feels silly
If you're a new PM, your instinct may be that defining mission and vision is not your job. Your company already has one. Your boss's boss wrote it. Your work is to ship features, not mint slogans.
Fair. But the mission and vision aren't for you to write — they're for you to use. They're the test your roadmap has to pass.
Lenny's examples of mission statements are blunt and functional: Tesla — "Accelerate the world's transition to sustainable energy." Stripe — "Increase the GDP of the internet." Google — "Organize the world's information and make it universally accessible and useful."
Now apply that test to your own work. If you're a PM at a major auto insurer, your company's mission is probably some version of "protect our customers when bad things happen." Look at your current sprint. Is every item on it traceable back to that mission? Probably not. Some of it is compliance. Some of it is tech debt. Some of it is a request from a senior leader that slipped in the side door. That's fine — the question is whether you know why each item is there.
The missing middle: strategy
The piece that breaks most often is strategy. Chandra Janakiraman of VRChat, writing on Lenny's about his "Strategy Blocks" framework, describes exactly this gap:
At Headspace back in 2016, we had established our product roadmap and success metrics and our mission and vision, but teams were still confused about why we were working on the projects we chose. Without that clarity, teams weren't able to get several projects off the ground and had unproductive debates on what to build.
That's the failure mode to watch for. A company can have a mission, a vision, metrics, and a roadmap — and still have teams that can't explain why. Because strategy is the connective tissue, and it's usually the thing no one wrote down.
Janakiraman defines a good strategy articulation as having three components:
- 3 to 5 focus areas (he calls them "strategic pillars")
- Areas that should explicitly not be the focus
- Explanations for why these choices were made
That second one is the tell. A strategy without anti-priorities isn't a strategy — it's a wish list. And a roadmap hanging off a wish list is a roadmap that grows forever.
The impact → goals linkage
Here's where the stack does real work for you as a PM. Lenny's framing: "when prioritizing the many ideas your team has, you look at the ROI — the effort vs. the impact. The impact you're prioritizing against is based on how much you expect the project will impact your goals."
That sentence is worth taping to your monitor.
Impact is not a vibe. Impact is "how much does this move our goals." Goals are "how we measure progress toward our strategy." Strategy is "our plan to achieve our vision." If you can't connect an idea to a goal, you can't estimate its impact — which means you can't prioritize it — which means it shouldn't be on your roadmap yet.
This is especially useful at a big company where everyone has an opinion about your roadmap. Sales wants the feature that closes the big account. Compliance wants the audit report redesign. Your VP wants the shiny AI thing she read about on LinkedIn. The honest response isn't "no" — it's "which of our goals does this move, and by how much?" That question puts the burden back where it belongs.
A worked example: Tesla all the way down
Lenny walks through Tesla as an example of the full cascade:
- Mission: Accelerate sustainable energy.
- Vision: The most compelling car company of the 21st century.
- Strategy: Build an expensive sports car → use the revenue to build a more affordable car → use that revenue to build an even more affordable car → while doing so, also provide zero-emission electric power.
- Goals: Unit sales, market share, profitability at each rung.
- Roadmap: Build Roadster → Model S → Model 3 → energy products.
- Task: Today's engineering ticket.
The key property: any given task on a Tesla engineer's desk is traceable four or five layers up. That's not bureaucratic overhead — it's the thing that lets a 100,000-person company make coherent decisions without checking in with Elon about every ticket.
What to actually do on Monday
A few practical moves for a PM inheriting a roadmap in a big org:
- Write your strategy as a one-pager, even if your company hasn't asked you to. Three pillars, three anti-priorities, one paragraph each on the "why." This is for you, not the org. It's a lens you'll use to defend the roadmap.
- Tag every roadmap item with the goal it affects. If an item has no goal, flag it. It's either missing a justification or it shouldn't be there.
- Keep a "not on roadmap" list. When you say no to a request, record why — which pillar it didn't fit, or which goal it didn't move. This list is the receipts you'll need next quarter when the same request resurfaces.
- Use the Lenny cascade in 1:1s. When your manager asks why you're pushing back on a request, walk up the stack: "This doesn't ladder to our retention goal, which is the main metric under our 'reduce claims friction' pillar." That's a much stronger answer than "I don't think it's a priority."
- Don't expect the cascade to be clean. Companies are messy. Your job isn't to force everyone to agree on a pristine strategy doc — it's to have enough of a shared answer that your roadmap isn't just a list of whatever landed in your inbox this week.