Execution · · 5 min read

From Roadmap to Reality: A 3-Layer Execution Model

Most roadmaps die in the gap between strategy and sprint tickets. This three-layer model closes that gap by creating a clear translation path from "what we want" to "what gets built."

The roadmap is not the problem. The translation is.

Most product teams are reasonably good at writing strategy — broad strokes about where the product is headed, what outcomes matter, which customer segments to prioritize. And most engineering teams are reasonably good at executing on well-scoped tickets. The failure happens in the middle: the translation from strategic intent to implementable work.

I have seen this break in two directions. The roadmap stays too abstract (“improve onboarding conversion”) and engineers spend three sprints building the wrong thing because nobody specified what that meant technically. Or the roadmap gets decomposed straight into tasks too early, disconnected from strategy, and teams ship features that are technically correct but strategically useless.

The fix is not better communication. It is a structured model with three distinct layers, each with its own purpose and owner.

The Three Layers

Layer 1 — Strategy: What outcome are we trying to achieve and why?

Layer 2 — Initiative: What product capability, system, or change enables that outcome?

Layer 3 — Technical Decomposition: What specific work needs to happen to build that capability?

These are not just planning phases. They are three different types of thinking that require different skills, different information, and different decision-making authority.

Layer 1: Strategy

Strategy answers a specific question: What change in user behavior or business metric are we trying to drive?

A useful strategic statement has three elements:

  1. The current state (“Our enterprise customers spend an average of 40 minutes onboarding a new employee”)
  2. The target state (“We want to reduce that to under 10 minutes”)
  3. The business rationale (“This is the top churn driver for customers in the 50–500 seat segment”)

What is notably absent: any mention of features, screens, or technical solutions. Strategy should be completely implementation-agnostic. If your “strategy” includes product decisions, you have skipped a layer.

The PM owns this layer. It requires market knowledge, customer insight, and business context that PMs accumulate through research, customer conversations, and data analysis.

Layer 2: Initiative

Initiative answers a different question: What product or system capability would create the outcome defined in Layer 1?

This is where product design thinking lives. Given the outcome we want, what change to the product would produce it? An initiative might be:

“Build a step-by-step onboarding wizard that pre-populates employee data from HRIS integrations and reduces manual data entry by 70%.”

This is more concrete than strategy but still not implementation. It describes what the product will do without prescribing how the system will do it.

The PM and senior engineering collaborate here. The PM brings the user and business perspective. Engineering brings the technical perspective — what is feasible, what integration points exist, what the architectural implications are.

Critically, initiatives also carry explicit constraints and non-goals. In the onboarding example:

  • Constraint: Must work within our existing permissioning model
  • Non-goal: Not handling contractors or part-time employees in V1

These constraints are Layer 2 artifacts. They shape the Layer 3 work.

Layer 3: Technical Decomposition

Technical decomposition answers: What specific work — systems, APIs, data models, UI components — needs to be built?

This is purely engineering territory. Once the initiative is defined and the constraints are clear, how you implement it is an engineering decision. The PM should not be decomposing tickets. Engineering should not be modifying the initiative definition without a product conversation.

A proper Layer 3 decomposition for the onboarding wizard might produce:

  • Data model changes to support draft employee records
  • HRIS integration layer (starting with the three most common providers)
  • Wizard UI component with validation state machine
  • Admin configuration screen for field mapping
  • Migration scripts for existing customers

Each of these is a distinct engineering workstream with its own estimates, dependencies, and risk profile.

Why the Model Works

It keeps ownership clean. PMs own the “why” and “what,” engineers own the “how.” When you hear “the PM is micromanaging implementation decisions,” it usually means Layer 2 and Layer 3 have collapsed together. When you hear “the engineers built the wrong thing,” it usually means the Layer 2 initiative was under-specified.

It creates natural checkpoints. Before moving from Layer 1 to Layer 2, you should validate that you understand the problem well enough. Before moving from Layer 2 to Layer 3, you should validate that the initiative is clear enough for engineers to decompose without constant interruption.

It makes estimation more accurate. One of the biggest sources of estimate error is decomposing work before the initiative is clear. Engineers pad estimates to account for ambiguity they can feel but cannot name. When the Layer 2 initiative is sharp — good constraints, clear non-goals, explicit tradeoffs — estimates become dramatically more reliable.

It gives you a place to absorb change. When priorities shift (and they will), you can often absorb the change at Layer 1 or Layer 2 without rewriting all of Layer 3. If the outcome changes, rebuild the initiative. If the initiative changes, re-decompose the technical work. This is more efficient than the common approach of throwing out everything and starting over.

Putting It in Practice

The three-layer model is not a formal process. It is a mental frame that helps you know what kind of conversation you should be having.

Before your next planning session, take your top three roadmap items and ask yourself honestly: what layer are they defined at?

If they are at Layer 1 (“improve activation”), the initiative has not been defined. Engineering cannot start building.

If they are at Layer 3 (“add email step to onboarding flow”), the strategic rationale may be absent. You are building something but you do not know if it is the right something.

If they are all at Layer 2 — product initiatives with clear outcomes, constraints, and non-goals — you are ready to actually ship.

That transition, from Layer 1 to Layer 2 to Layer 3, is where most teams have the most to gain. It is unglamorous work. But it is the work that separates teams that consistently execute from teams that consistently struggle to translate their intentions into reality.