Large companies often get less from their strategies than they plan for. In a 2005 study, Michael Mankins and Richard Steele found that companies' strategies delivered on average only 63% of their promised financial value (Mankins and Steele, HBR 2005, via Bain). That shortfall is often called the strategy execution gap.
The gap has many causes, from over-optimistic plans to slow decisions. One of them sits squarely inside the design team's reach: the moment a strategic priority stops being words and becomes a product, somewhere between design and engineering.
Key takeaways
- Strategies often underdeliver. One well-known 2005 study found they delivered only 63% of their promised financial value.
- The design handoff is often where strategy first becomes product, and 92% of designers in Figma's research say the handoff process could be improved.
- Letting designers work in the real codebase removes a translation step instead of managing it better. Code review and release checks stay in place.
Where product strategy execution breaks down in large companies
Strategy in a large company travels a long way before it reaches a customer. It starts as an annual plan. It becomes a set of quarterly priorities, then a roadmap, then tickets, then mockups, then code. Every step is a translation, and every translation is done by different people with different context.
Bureaucracy makes each step slower. In Gary Hamel and Michele Zanini's survey of more than 7,000 Harvard Business Review readers, respondents spent an average of 28% of their time on bureaucratic chores. Nearly 80% of respondents in companies with more than 5,000 employees said bureaucracy significantly slows down decision-making (HBR, 2017). The sample is self-selected, so treat the exact figures with care.
Distance adds a second cost. Decisions get made far away from the work. By the time a priority has passed through several layers of planning, the people building the feature are working from a summary of a summary. They usually know what to build. The reasons behind it, and the trade-offs the strategy allows, rarely survive the trip.
Why the design handoff is where strategic intent gets lost
Of all those translation steps, the design handoff deserves attention from design leaders for a simple reason: it is the one they have the most control over.
A designer is often the first person to turn a strategic priority into something concrete. "Reduce onboarding drop-off for enterprise admins" becomes a specific flow, with specific screens, states and copy. That flow carries decisions that never make it into a ticket: what to leave out, what to emphasize, which edge cases matter.
Then the flow is handed off, and an engineer rebuilds it from a different tool with different constraints. Figma, which makes design and developer tools, surveys both groups regularly. Its 2025 research found that "differences in assumptions" is the top challenge developers name when working with designers, cited by 52% (Figma, 2025). Figma's design statistics page reports that 91% of developers and 92% of designers believe the handoff process could be improved (Figma, retrieved September 2026).
A difference in assumptions is one way strategic intent disappears, and it is one design leaders can act on. Nobody decides to ignore the strategy. In that example, the bulk-invite state that was the whole point of the enterprise admin priority gets cut as an edge case. The flow ships, and the feature quietly stops serving the reason it was built. We covered the mechanics in why UX breaks after the design handoff.
A note on evidence: we could not find a primary study that measures what the handoff costs in rework. Figures that circulate widely, such as a rework percentage attributed to Nielsen Norman Group, lead to no original publication we could find. Surveys report the friction. We found no rigorous measurement of the cost.
Roadmaps and approval layers keep intent at arm's length
Roadmaps are meant to connect strategy to execution. In large companies they often fill up with internal requests and get reviewed as lists of features. They become the thing teams are measured against instead of the outcome the strategy was chasing.
Approval layers add the same kind of distance. When every design change needs sign-off before anyone can see it working, teams debate pictures of the product. Stakeholders approve a mockup, engineering builds something slightly different, and nobody finds out until it ships.
What helps is shortening the distance between an idea and something real that people can react to. That is why we argue prototypes should be your first move when product work gets fuzzy.
What changes when designers work in the real product
Where design work happens is changing fast. Figma's 2026 AI report is based on 8,403 survey responses. It found that the share of designers who took part in development work rose from 21% in 2025 to 41% in 2026. Over the same period, the share of developers doing design work rose from 44% to 60% (Figma, 2026). We wrote about what that shift means for designers' careers in the new design ladder.
When a designer works directly in the real codebase, the step of turning a design into code can disappear. The design and the implementation become the same artifact. The change still goes through code review and whatever release checks the company already runs.
An example from a smaller team
Prelude is a Series A company that builds verification and fraud prevention for signups, and a Modeinspect customer. We include it because it shows the handoff mechanism clearly. Its numbers say nothing about how a large company would fare.
Prelude's designers used to explore in Figma while engineers built in the codebase, and the space between them ran on specs, revisions and waiting. Ideas queued behind engineering capacity. The team then started prototyping and shipping UI on its own codebase with our product. For work that used to wait on engineering capacity, the time from idea to merged pull request dropped from about 31 days on average to 13. Handoffs per feature went from five or more to one (Prelude customer story). Engineering review still gates every merge.
"It's something I'd wanted to prototype for a long time - I did it in five minutes, with real data. That prototype ended up as a PR we merged," said Quentin Le Bras, Chief Product and Design Officer at Prelude.
For a large company, the transferable part is the mechanism rather than the numbers. Removing a translation step is a different lever from managing it better, and one worth testing in a single product area.
Five shifts for design leaders in large companies
Design leaders have more standing here than they often assume. McKinsey tracked 300 publicly listed companies over five years. The top quartile on its Design Index achieved 32 percentage points higher revenue growth and 56 percentage points higher total returns to shareholders than their industry peers (McKinsey, 2018). The index measures design leadership practices in general, not whether designers work in code, and the result is a correlation. It does show that design maturity and business results tend to move together.
Each of the shifts below is a change in where your team spends its effort. Some are easy to start. Shift 3 takes the most negotiation.
1. Tie every design review to an outcome
Before a design review, restate the strategic outcome the work serves in one sentence. If nobody in the room can, the problem is upstream of design, and more mockups will not fix it.
2. Prototype on the real product, early
Prototypes built on mock data show the happy path. Prototypes built on the real product show how a flow holds up with real volumes, empty states and errors, which makes them far better at settling disagreements. See how AI prototyping on a real codebase changes what a prototype can be.
3. Let designers change the product within the gates you already have
Most large companies already have a strong quality gate: engineering code review. Designers can open reviewable changes that go through that same gate. More design autonomy does not have to mean a new approval layer, and design and engineering collaboration moves into the review itself.
This is harder in large companies than in small ones. Designers need repository access and a working development environment. Code ownership rules may route every change to a specific team. Regulated products often add change-control and compliance steps, and reviewers have limited capacity. Start with one product area where an engineering lead is willing to review design changes, and agree up front on what kind of change is in scope.
4. Treat the design system in code as the contract
When design and engineering disagree about what a component should look like, the design system in code should settle it, rather than the Figma file or whoever built it last. That makes the design system the source of visual and behavioral consistency.
5. Measure idea-to-production time
Track how long it takes for a validated idea to reach customers, and how many handoffs it passes through on the way. It shows how much translation sits between a decision and your customers. Pair it with the outcome from shift 1, because fast delivery of the wrong thing is still a leak.
Where strategy leaks, and how to plug it
Each row below maps a translation step to the shift above that addresses it.
| Translation step | What gets lost | Shift that helps |
|---|---|---|
| Plan to design review | The outcome the work serves | 1. Tie every design review to an outcome |
| Design to stakeholder sign-off | How the flow behaves with real data | 2. Prototype on the real product, early |
| Design to code | States, edge cases and details | 3. Let designers change the product within the gates you already have |
| Design file to component library | Consistency with the rest of the product | 4. Treat the design system in code as the contract |
| Decision to customer | Visibility into how long delivery takes | 5. Measure idea-to-production time |
Frequently asked questions
What is product strategy execution? Product strategy execution is the work of turning strategic priorities into shipped product decisions. It covers roadmaps, design, engineering and release, and it succeeds when what ships still reflects why it was built.
Why does strategy fail in large companies? There are many causes. Strategy passes through many translation steps before it becomes a product, often handled by people with less context than the original decision-makers. Bureaucracy slows those steps down: in one survey of more than 7,000 HBR readers, people spent 28% of their time on bureaucratic chores. The handoff between design and engineering is one of the last steps, so whatever context has survived until then can still be lost there.
How can design teams improve strategy execution? By shortening the distance between an idea and working product. Tie design reviews to outcomes and prototype early on the real product. Let designers make reviewable changes in the codebase, treat the design system in code as the contract and measure how long ideas take to reach customers.