I was in a roadmap review once when the VP of Sales dropped a spreadsheet onto the table. Figuratively, of course. It was a screen share. But the energy was very much “evidence being presented at trial.”

The spreadsheet was a feature comparison matrix. Rows of capabilities, columns of competitors, and our product sitting there with a depressing number of red cells where green ones should be.

“We’re losing deals because of these gaps,” he said. “Customers are literally telling us they went with [Competitor] because we don’t have [Feature X].”

The room nodded. The PM took notes. By the end of the quarter, three of those red cells had turned green.

And our win rate? Unchanged.

The Comfortable Lie of Parity

Here’s what nobody said in that meeting: the customers who chose our competitor didn’t choose them because of Feature X. They chose them because they believed that product better solved their problem. Feature X was the post-hoc rationalisation. The story they told themselves (and us) to explain a decision that was actually about positioning, trust, and perceived fit.

But “match their features” is an actionable request. “Change how the market perceives us” is not. So we built Feature X.

This is the strategy execution gap in action. Not the dramatic version where leadership announces a bold new direction and teams ignore it. The quieter version. Where everyone agrees the strategy is “differentiation” and then proceeds to spend 60% of engineering capacity on parity features because that’s what feels safe.

The gap between strategy and execution isn’t always about resistance. Sometimes it’s about the thousand small decisions that feel reasonable in isolation and catastrophic in aggregate.

Why Parity Feels So Urgent

I’ve watched smart PMs fall into this trap repeatedly, and it’s worth understanding why.

Sales pressure is real. When a rep loses a deal and can point to a specific missing feature, that’s concrete. It’s a story with a villain (the gap) and a hero (the feature you could build). Compare that to “we need to invest in our unique value proposition,” which sounds like something you’d read in a McKinsey deck and then promptly forget.

The comparison matrix is seductive. It transforms ambiguity into checkboxes. Red cells feel like problems to solve. Green cells feel like progress. The fact that this framing might be completely wrong doesn’t make it less comforting.

And there’s the fear. The fear that if you don’t have feature parity, you won’t even get into the consideration set. You’ll be filtered out before you can make your differentiation argument.

That fear isn’t irrational. For some products, in some markets, parity on certain dimensions really is table stakes. If you’re selling a word processor and it can’t save documents, no amount of differentiation will save you.

But here’s where it gets tricky: most feature gaps aren’t that fundamental. They’re not “can’t save documents” gaps. They’re “their dashboard has a pie chart view and ours only has bar charts” gaps. And treating those as urgent survival threats is how you end up with a bloated, undifferentiated product that nobody loves.

The Differentiation Trap Is Real Too

Before this turns into a “just focus on differentiation” pep talk, let me be honest about the other side.

I’ve also watched teams so committed to “building something unique” that they ignored genuine market requirements. There’s a particular arrogance that can creep in when you’ve drunk your own Kool-Aid about how innovative you are.

“Customers don’t know what they want” is true sometimes. It’s also a convenient excuse for not listening.

The differentiation purists have their own failure mode: building something so unique that it solves a problem nobody actually has, or solving a real problem in a way that requires customers to completely rewire how they work. That’s not differentiation. That’s self-indulgence with a product management title.

Pure differentiation without market awareness is just building in a vacuum. Pure parity without differentiation is just copying with extra steps.

What’s Actually Happening Here

The real issue isn’t “parity vs differentiation.” That’s a false binary that sounds like a debate but actually obscures what’s going wrong.

The real issue is that most companies don’t have clear, committed strategy. They have strategy documents. They have OKRs that mention differentiation. They have slide decks with phrases like “unique value proposition” and “competitive moat.”

But when you look at how resources actually get allocated, when you trace the decisions that determine what gets built this quarter, the strategy dissolves into something much more reactive.

Feature parity requests feel urgent. Differentiation bets feel risky. In the absence of genuine strategic clarity, urgency wins.

This is the execution gap. Not a gap between “what we said” and “what we did,” but between “what we thought we agreed on” and “what our collective decisions actually reveal about our real priorities.”

The Signals You’re Already In Trouble

How do you know if this is happening to you? Some patterns I’ve seen:

Your roadmap is primarily populated by competitor reactions. Look at your last three quarters. What percentage of shipped features were responses to competitor moves versus proactive bets on your theory of the market? If it’s north of 50%, you’re not executing a strategy. You’re playing defence.

Your differentiation story keeps shifting. Ask five people in your company what makes your product unique. If you get five different answers, or five vague answers that could apply to any product in your category, the strategy isn’t clear enough to execute.

Win/loss analysis keeps surfacing “feature gaps” but closing them doesn’t move win rates. This is the spreadsheet problem. You’re treating symptoms as causes. The gaps are real, but they’re not why you’re losing.

The team can’t say no to parity requests without escalation. If every “we should match competitor X” suggestion requires a VP to push back, you don’t have shared strategic conviction. You have a hierarchy that occasionally intervenes.

A Different Frame: Bets and Boundaries

Here’s how I’ve seen teams escape this trap. It’s not elegant. There’s no framework with a clever acronym. But it works.

First, you have to name your actual strategy. Not the aspirational version from the offsite. The real one. The one that would make your allocation decisions make sense.

If your roadmap is 60% parity features, your actual strategy is “compete on feature completeness.” That might be the right strategy. But own it. Stop pretending you’re differentiated while acting like you’re not.

Second, if you want to shift toward differentiation, you need to make specific bets and accept the consequences. This means:

Picking one or two dimensions where you will be measurably better than competitors. Not “better user experience” (too vague). Something like “fastest time to first value for mid-market teams” or “deepest integration with [specific workflow].”

Accepting that you will be worse on other dimensions. This is the hard part. Differentiation means trade-offs. If you’re not willing to be worse at something, you’re not willing to be better at something else.

Setting boundaries on parity work. Not zero. But constrained. “We’ll allocate no more than 30% of capacity to parity features, and only when they’re genuine blockers for our target segment.”

Strategy without boundaries isn’t strategy. It’s wishful thinking with a quarterly review attached.

The Politics Nobody Mentions

I’d be lying if I pretended this is purely a product management problem. It’s not.

Sales incentives often favour breadth over depth. A rep gets commission whether the deal closed because of differentiation or parity. If parity features make their pitch easier, they’ll advocate for parity features. This isn’t malicious. It’s rational behaviour given their incentives.

Leadership often lacks patience for differentiation bets. A parity feature ships and you can immediately show “we now have X.” A differentiation bet might take eighteen months to show results, and the results might be ambiguous. In a quarterly review culture, parity looks like progress.

And product managers themselves often find parity work easier to justify. “We need this to compete” is a simpler story than “we need this because our theory of the market suggests that companies in segment Y will increasingly value Z, and if we build the best Z in the market, we’ll win despite gaps elsewhere.”

The second story is better. It’s also harder to tell, easier to challenge, and more likely to be wrong.

What You Can Try Tomorrow

If you’re a PM stuck in this loop, here’s something practical.

Take your current roadmap and categorise each item: parity, differentiation, or infrastructure. Don’t overthink the categorisation. Go with your gut.

Now look at the ratio. Is it what your strategy says it should be?

If not, bring that data to your next planning conversation. Not as an accusation. As a genuine question: “Our strategy says X, but our roadmap says Y. Are we okay with that gap? Should we change the strategy or change the roadmap?”

That question alone can shift the conversation from “should we build Feature X” to “what are we actually trying to do here.”

The Uncomfortable Truth

I don’t have a clean resolution to offer. The parity vs differentiation tension is real. It doesn’t disappear because you’ve named it or because you’ve made better bets.

Some products genuinely need more parity. Some products are already too parity-focused and dying slowly from lack of distinctiveness. The right answer depends on your market, your stage, your resources, and about twelve other factors that I can’t assess from here.

What I can tell you is that the answer rarely emerges from reacting to competitor feature announcements. It comes from having genuine conviction about what you’re building and why, testing that conviction against market reality, and being willing to adjust when you’re wrong.

The strategy execution gap isn’t closed by better documentation or tighter OKRs. It’s closed by making hard choices and sticking with them long enough to learn whether they were right.

Most teams don’t do that. They oscillate between parity panic and differentiation aspiration, never committing fully to either, and wondering why their product feels muddled.

Your product feels muddled because your strategy is muddled. Fix that first.

Anyway. That spreadsheet from last year? The company eventually built all the parity features. Win rate still didn’t move. Two quarters later, a smaller competitor with half the features took 15% of the market by solving one problem extremely well.

The VP of Sales never made another feature comparison matrix. Small mercies.

I once watched a product launch fail in slow motion over eleven weeks. The executive team thought everything was on track. The weekly status updates said so. Green across the board. “On schedule.” “No blockers.” “Proceeding as planned.”

Meanwhile, the actual team knew by week three that the timeline was fiction. A critical API dependency was delayed. The design system couldn’t support the new component patterns. Two engineers had quietly started interviewing elsewhere.

None of this reached the people making resource decisions until week nine, when the launch date became physically impossible to hit. By then, the options had narrowed to bad and worse.

The postmortem blamed “communication issues.” Which is technically true in the same way that a car crash involves “momentum issues.”

The One-Way Valve

Every organisation I’ve worked in has some version of this problem. Information flows beautifully downward. Strategy decks cascade from the executive floor to directors to managers to individual contributors. Priorities get communicated. OKRs get assigned. Everyone knows what leadership wants.

But the return path? That’s where things get interesting.

Reality struggles to travel upward. Not because people refuse to share it. But because the system itself filters uncomfortable information at every level. By the time ground truth reaches the executive floor, it’s been smoothed, softened, contextualised, and occasionally transformed into its opposite.

This isn’t a conspiracy. It’s just how hierarchies work when nobody explicitly designs for reverse information flow.

The distance between “the team knows this won’t work” and “leadership understands this won’t work” is often measured in months. Sometimes the information never completes the journey at all.

For PMs, this creates a specific kind of pain. We sit at the intersection of strategy and execution. We hear the executive vision. We also hear the engineer explaining why that vision ignores three technical constraints. We watch the gap between intention and reality widen, often without clear authority to close it.

Why Reality Gets Stuck

The breakdown happens at multiple points, and understanding each one matters if you want to fix anything.

The translation tax. Every time information passes through a layer, it gets translated. An engineer says “this architecture won’t scale past 10,000 concurrent users.” Their manager hears “there are some scalability concerns.” The director hears “we’re monitoring performance.” The VP hears “the team is handling technical considerations.” The original signal degrades with each handoff.

The optimism gradient. People at every level have incentives to present things positively. Not because they’re dishonest, but because raising problems feels risky while reporting progress feels safe. Each layer adds a small positive spin. By the time it aggregates upward, significant issues have become minor footnotes.

The fear of being the messenger. Telling executives that their strategy has execution problems is career-adjacent behaviour. It can go well. It can also mark you as “negative” or “not a team player.” Most people, quite rationally, choose to let someone else deliver bad news. When everyone makes that choice, the news simply doesn’t travel.

The meeting format problem. Executive updates are typically short, structured, and focused on status rather than exploration. There’s no space for “let me explain why I’m increasingly worried about this.” The format itself selects for green lights and confident assertions.

I worked at a fintech company where the weekly product review had a standing agenda: wins, metrics, roadmap status, blockers. Sounds reasonable. But “blockers” meant things that had already stopped work. There was no category for “things that will probably become blockers” or “risks we’re tracking” or “assumptions that are looking shaky.” So those concerns stayed in team Slack channels and one-on-ones, invisible to leadership until they became urgent enough to qualify as blockers. By which point, urgency meant limited options.

What Executives Actually See

Here’s the part that might generate some empathy for the people at the top.

Executives are drowning in information. They have fifteen direct reports, each running their own domain. They’re in board meetings, customer calls, investor conversations, strategic planning sessions. They’re making decisions about things they can’t possibly understand in detail.

They need filters. They need summarisation. They need people to handle problems without escalating everything.

So when a director says “we’ve got some challenges but the team is handling it,” that’s actually what the executive wants to hear. It means they don’t have to context-switch into your domain. It means they can trust that someone competent is managing the situation.

The system is designed for efficiency, not accuracy. And most of the time, that trade-off works. Most challenges do get handled. Most risks don’t materialise. The filter catches noise and lets signal through.

Until it doesn’t. Until the filter catches signal and lets noise through. Until the thing that looks like a routine challenge is actually a fundamental problem, and by the time anyone realises the difference, the timeline has collapsed.

Executives don’t ignore reality because they’re arrogant. They ignore it because the information systems they rely on are optimised for reassurance, not truth.

The PM’s Peculiar Position

Product managers occupy an odd spot in this dynamic. We’re usually not senior enough to have direct executive access. But we’re close enough to execution to see ground truth clearly. We hear what’s actually happening in standups, in design reviews, in customer calls, in the Slack channels where engineers vent.

This means we often know things that leadership doesn’t. And we face a choice about what to do with that knowledge.

Option one: Stay quiet. Let the information flow through normal channels. Trust that your manager or their manager will escalate appropriately. This is safe. It’s also how problems stay invisible.

Option two: Escalate directly. Go around layers to get critical information to decision-makers. This can work. It can also damage relationships with your direct leadership, who may feel bypassed or undermined. It can mark you as someone who doesn’t respect the chain of command.

Option three: Find indirect paths. Plant questions in meetings. Share data that implies concerns without stating them directly. Hope someone more senior connects the dots. This is politically safer but unreliable.

None of these options are great. The right choice depends on your organisation’s culture, your relationships with specific people, and the severity of the information you’re holding.

I’ve made all three choices at different times. Sometimes the quiet approach was right because the issue resolved itself. Sometimes direct escalation saved a launch. Sometimes the indirect path worked. And sometimes I got it wrong, chose the safe option, and watched something fail that I might have prevented.

There’s no formula. But there are some principles that help.

Building Better Upward Flow

If you’re a PM trying to improve feedback loops, you have limited leverage. You can’t redesign the organisation. But you can change how information moves through your immediate sphere.

Separate status from risk. Most updates conflate these. “Here’s what happened this week” blends with “here’s what might go wrong.” Create explicit space for risk in your communications. A section called “assumptions we’re testing” or “things I’m watching” or “early warning signals.” This normalises surfacing concerns before they become blockers.

Quantify uncertainty. Instead of “the timeline might slip,” try “I’d put our odds of hitting the date at 60%, down from 80% last week, mainly due to the API dependency.” Numbers feel more legitimate than vibes. They also make it easier for someone to ask “what would get us back to 80%?”

Build a reputation for accurate prediction. This takes time, but it matters. If you consistently flag risks that materialise and don’t cry wolf about things that don’t, people start listening. Your warnings carry more weight. One PM I worked with kept a simple log of risks she’d raised and their outcomes. After a year, her pattern recognition was so trusted that executives would specifically ask for her risk assessment on new initiatives.

Find the executive who wants ground truth. They exist. Not all leaders prefer filtered information. Some actively seek unvarnished reality and protect the people who provide it. Find that person. Build a relationship. Give them direct access to your perspective, with appropriate discretion about how they use it.

Create skip-level moments. Not formal skip-level meetings, which can feel threatening to your manager. But natural opportunities for executives to hear from people closer to execution. Invite a VP to a customer research session. Include an executive in a technical review. Let them experience ground truth directly rather than through layers of translation.

The Politics You Can’t Ignore

I want to be realistic about something. Surfacing uncomfortable information has risks. Organisations often punish messengers, even while claiming they want transparency.

If you work in an environment where raising problems consistently damages careers, you need to factor that in. I’m not suggesting you sacrifice yourself on the altar of information flow. Being right about a problem but unemployed doesn’t help anyone.

Read your specific context:

• How does your direct manager respond when you raise concerns?

• What happened to the last person who flagged a major risk to leadership?

• Does your company celebrate people who prevented disasters or just people who delivered successes?

• Is there executive sponsorship for honest communication, or just lip service?

If the environment is genuinely hostile to upward feedback, your options are limited. You can work within the constraints, protecting yourself while doing what good you can. You can try to change the culture, which is possible but slow and uncertain. Or you can decide this isn’t the right organisation for you.

I’ve done all three at different points. None of them are wrong. They’re just different calculations about where to spend your energy.

What Executives Can Do (If Any Are Reading)

Most of this article assumes you’re a PM trying to navigate a broken system. But if you’re a leader who suspects your feedback loops are compromised, here are some things that actually help.

Ask questions that invite bad news. Not “are we on track?” but “what would have to go wrong for us to miss the date?” Not “any blockers?” but “what’s the thing you’re most worried about that isn’t on my radar?”

Reward early warnings. Publicly. Explicitly. When someone flags a risk that lets you course-correct, make sure everyone knows that behaviour is valued. The opposite of shooting messengers.

Create safe channels. Anonymous feedback mechanisms. Office hours with skip-level access. Explicit permission to escalate concerns without going through the chain. Not everyone will use them, but their existence signals that upward communication matters.

Go to the ground. Periodically, skip the filtered updates and see reality directly. Attend a sprint review. Join a customer call. Read the support tickets. Not to micromanage, but to calibrate whether the summaries you’re receiving match what’s actually happening.

Audit your own reactions. When someone brings you a problem, what’s your immediate response? If it’s frustration, defensiveness, or “why didn’t you handle this,” people will stop bringing you problems. If it’s curiosity and gratitude, they’ll bring you more.

Try This Tomorrow

If you’re a PM holding information that leadership doesn’t have, here’s a small step.

Write down the thing you know that your executives probably don’t. The risk. The constraint. The customer signal. The team dynamic. Whatever it is.

Now ask yourself: who is one person closer to leadership who should know this? Not necessarily the CEO. Just one step up from your current information boundary.

Figure out how to tell them. Not as an escalation, but as context. “I thought you’d want to know...” or “I’ve been noticing something that might be relevant...” or “Can I share a concern I’ve been sitting with?”

See what happens. Often, the barrier to upward information flow is simply that nobody took the first step. The system defaults to silence, and silence perpetuates itself.

Breaking the pattern starts with one piece of information making one successful journey upward.

The Unfinished Part

I don’t have a clean solution here. Feedback loops break for reasons that are structural, political, and deeply human. The optimism bias, the messenger fear, the efficiency pressure. These aren’t bugs you can patch with a better meeting format.

What I’ve come to believe is that perfect information flow is probably impossible. Some signal will always be lost. Some risks will always stay invisible until they materialise. The goal isn’t a frictionless pipeline from ground truth to executive decision. The goal is good enough information arriving fast enough to enable course correction.

Good enough. Fast enough. Those are fuzzy standards. They require judgment about what matters and what can be safely filtered. They require trust between layers. They require people willing to take small risks to surface inconvenient truths.

Most organisations get this wrong more often than they get it right. The successful ones fail faster. They find out sooner that reality diverged from the plan. They have shorter delays between “the team knows” and “leadership knows.”

That gap will never close completely. But every week you shorten it, you buy yourself options. And options are what let you course-correct before it’s too late.

I once watched a VP of Product spend four months redesigning the entire team structure, moving from centralised to decentralised squads. Workshops. RACI matrices. New reporting lines. Slack channels renamed. The works.

Eighteen months later, her successor spent another four months moving everything back.

Same company. Same product. Different conviction about which structure was “right.”

Here’s what nobody told either of them: the structure wasn’t the problem. The structure is never really the problem. The structure is the thing we fiddle with when we can’t articulate what’s actually broken.

The Seductive Promise of Decentralisation

Autonomous teams sound brilliant on paper. Each squad owns their slice. They make decisions fast. They build deep expertise. They don’t wait for permission.

If you’ve ever sat in a prioritisation meeting with fourteen people arguing about whether Feature A or Feature B deserves the next sprint, you understand the appeal. Just give each team their own backlog. Let them run. Problem solved.

And sometimes it works. I’ve seen decentralised teams at a mid-sized fintech move with startling speed. One squad shipped a complete P2P payment flow in six weeks. No cross-team dependencies. No architecture review boards. No waiting for the “platform team” to build something first.

But here’s what I’ve also seen: three different squads building nearly identical onboarding components because nobody was tracking what already existed. Two teams accidentally degrading each other’s performance because their features competed for the same database resources. And a customer experience that felt like it was designed by five different companies who’d never met.

Decentralisation gives you speed at the cost of coherence. The question is whether you can afford the coherence debt.

The autonomy that makes teams fast also makes them blind to what’s happening two desks over.

The Gravitational Pull Toward Centralisation

Centralised product functions exist because someone, at some point, got burned by fragmentation.

Usually it happens like this: a customer complains that Feature X in one part of the product contradicts Feature Y in another. Or sales loses a deal because the product “feels disjointed.” Or engineering discovers they’ve built the same authentication module four times in four different ways.

So leadership centralises. One product vision. One roadmap. One person (or small group) making the calls about what gets built and when.

And for a while, it’s better. Consistency improves. Redundancy drops. The product starts to feel like a product again, not a collection of loosely affiliated features.

Then the complaints shift. “Everything takes forever.” “We can’t make decisions without escalating.” “I have to schedule a meeting to schedule a meeting.” “The central team doesn’t understand our domain.”

I watched this exact pattern at an enterprise SaaS company. Their centralised model worked beautifully when they had 40 people and one product. At 300 people and five product lines, it became a bottleneck that made decisions at roughly the speed of continental drift.

The Hidden Variables Nobody Talks About

Here’s what most org structure debates miss: centralised vs. decentralised isn’t a binary choice. It’s a spectrum, and where you should sit on that spectrum depends on things that have nothing to do with theory.

Company stage matters. A 50-person startup needs different coordination mechanisms than a 2,000-person enterprise. Obvious, right? Yet I’ve seen early-stage companies implement heavy governance structures borrowed from Fortune 500 playbooks. And I’ve seen enterprises try to “move fast and break things” across 47 product teams, creating breakage nobody could trace back to a source.

Technical architecture matters. If your systems are tightly coupled, decentralised teams will spend half their time negotiating dependencies. If your architecture is genuinely modular, autonomous teams can actually be autonomous. Most companies are somewhere in between, which means their org structure needs to acknowledge that reality.

Customer journey matters. If your product is a single flow that users experience end-to-end, fragmenting ownership creates handoff problems. If your product is genuinely a suite of distinct tools, unified ownership might be overkill.

Your people matter. Some teams thrive with autonomy. Others flounder without clear direction. Pretending everyone operates the same way is wishful thinking.

The structure that works depends on context you can only see if you’re actually inside the organisation. Which is why copying Spotify’s model or Netflix’s model or whatever company just published a blog post about their brilliant approach rarely translates.

What’s Actually Happening Beneath the Surface

When I dig into teams struggling with this question, the structure debate is usually a proxy for something else entirely.

Sometimes it’s a trust problem. Leadership doesn’t trust teams to make good decisions independently, so they centralise. Or teams don’t trust leadership to understand their domain, so they push for autonomy.

Sometimes it’s a communication problem. Information isn’t flowing, so nobody knows what anyone else is building. Centralisation feels like a fix because it forces coordination through hierarchy. But hierarchy is a terrible information conduit.

Sometimes it’s a strategy problem. The company doesn’t actually know what it’s trying to build, so teams either duplicate effort or wait for direction that never comes. Neither structure solves that.

Before you reorganise, ask: what specific dysfunction are we trying to fix, and are we sure the structure is causing it?

I’ve seen teams reorganise to solve problems that had nothing to do with the org chart. A centralised team that “moved too slowly” was actually waiting on legal approvals, not product decisions. A decentralised team that “lacked coherence” actually just needed a shared design system and some cross-team communication rituals.

The Trade-Off Frame That Actually Helps

Instead of asking “centralised or decentralised,” try asking: “Where do we need consistency, and where do we need speed?”

This reframes the question from structure to outcome.

Some things genuinely benefit from consistency:

• Core user experience patterns

• Platform capabilities that multiple teams depend on

• Brand and design language

• Data architecture and definitions

• Security and compliance standards

Some things genuinely benefit from speed:

• Feature discovery and experimentation

• Domain-specific problem solving

• Customer-facing improvements in discrete areas

• Tactical response to feedback

The answer usually isn’t one structure for everything. It’s different coordination mechanisms for different types of decisions.

Consistency needs: centralise the standards, not necessarily the people. A shared design system with clear governance. Architecture principles that everyone follows. A small central team that owns cross-cutting concerns but doesn’t own every decision.

Speed needs: decentralise execution within guardrails. Autonomous teams that can ship without permission, as long as they’re working within agreed constraints.

Practical Signals That Your Structure Is Breaking

How do you know when your current setup isn’t working? Watch for these:

Signs your decentralised model needs more coordination:

• Customers experience jarring inconsistencies between product areas

• Teams are building similar things without knowing it

• Technical debt is accumulating because nobody owns cross-cutting concerns

• Strategic priorities aren’t reflected in what teams actually ship

• Knowledge silos are forming, and people genuinely don’t know what other teams do

Signs your centralised model needs more autonomy:

• Simple decisions require multiple levels of approval

• Teams are waiting, constantly, for someone else to unblock them

• Deep domain expertise is being overruled by generalist central teams

• Innovation is slowing because everything must fit the master plan

• Your best people are frustrated and starting to leave

Neither list is exhaustive. But if you’re nodding at three or more items on either list, you’ve found your problem.

What You Can Actually Try

If you’re a director or VP wrestling with this, here’s what I’ve seen work:

Start with the handoffs. Map where work currently gets stuck waiting for another team or approval. Those friction points tell you more about your real structure problems than any theory.

Experiment with coordination, not reorganisation. Before moving boxes on an org chart, try adding lightweight coordination mechanisms. Cross-team syncs. Shared OKRs for areas that touch multiple teams. Design reviews that create consistency without centralising decisions.

Be honest about what you’re optimising for. Speed and consistency trade off. You cannot maximise both. Pick which matters more for which parts of your product, and design accordingly.

Accept that you’ll need to adjust. The right structure at 100 people is wrong at 500 people. Build in the expectation that you’ll revisit this, rather than treating each reorg as the final answer.

The Uncomfortable Truth

I’ll be honest: there’s a part of me that wishes one answer was simply correct. It would make everything easier.

But after watching this play out across enterprise companies and scrappy scale-ups, across regulated fintech and experimental platforms, I’ve stopped believing in optimal structures. I believe in structures that fit the current context well enough, combined with the organisational awareness to notice when they stop working.

The best structure is the one that creates the fewest problems you can’t see.

Some companies thrive with radical decentralisation. Others need strong central coordination. Most need something in between, and that “something” will shift as the company grows and the product evolves.

The leaders who handle this well aren’t the ones who found the perfect model. They’re the ones who stay curious about what’s actually happening, who listen to the friction their teams experience, and who treat structure as a tool rather than an identity.

One Thing to Try This Week

Pick one recurring frustration your team experiences. Maybe it’s waiting for approvals. Maybe it’s duplicated work across teams. Maybe it’s inconsistent customer experience.

Ask yourself: is this a structure problem, or is it something else wearing a structure costume?

If it’s genuinely structural, what’s the smallest change that might help? Not a reorg. A process tweak. A new ritual. A shared artefact.

Try that first. See what happens.

Because the dirty secret of org design is that most of the real work happens in the spaces between the boxes on the chart. The structures that succeed aren’t the ones that look elegant in a presentation. They’re the ones that make it easier for smart people to do good work together.

And that, unfortunately, requires more attention than any single reorganisation can provide.

A few months ago, I watched a junior PM run a discovery sprint that would have taken me two weeks five years ago. She used AI tools to synthesise customer interview transcripts, identify patterns across support tickets, and generate hypothesis clusters from usage data. The whole thing took three days.

My first reaction was mild professional jealousy. My second was a question I’ve been chewing on since: if discovery is getting faster and cheaper, what exactly am I supposed to be good at now?

I don’t think I’m alone in asking this. The ground is shifting under product management, and the PMs who built their identity around being “the voice of the customer” or “the discovery expert” are feeling it. Those skills still matter. But they’re becoming table stakes rather than differentiators.

What’s emerging as the new premium skill? The ability to understand and influence systems. To see how strategy connects to execution through causal chains. To model the feedback loops that make organisations work or fail.

This isn’t abstract theory. It’s the practical answer to a problem that’s been plaguing product teams for years: the gap between what leadership decides and what actually gets built.

The Discovery Compression

Let me be direct about what’s happening. The discovery activities that used to require significant PM time and skill are getting automated or augmented at speed.

Customer interview synthesis? AI can do a reasonable first pass. Competitive analysis? Tools are scraping and summarising faster than any human. Survey analysis, support ticket pattern recognition, usage data exploration? All increasingly assisted.

This doesn’t mean discovery becomes irrelevant. Someone still needs to decide what questions to ask. Someone needs to catch the nuances that automated tools miss. Someone needs to build the relationships that surface insights no tool can reach.

But the labour-intensive parts of discovery, the parts that used to fill PM calendars, are compressing. What took weeks takes days. What took days takes hours.

This creates a strange moment. PMs suddenly have capacity they didn’t have before. And the question becomes: capacity for what?

I’d argue the answer is systems thinking. Not because it’s trendy, but because it addresses the specific failure mode that kills most product efforts: the disconnect between strategic intent and execution reality.

The Gap Nobody Talks About Honestly

Here’s something I’ve observed across every company I’ve worked in, from 50-person startups to enterprise organisations with thousands of employees.

Strategy gets set at the top. Smart people think hard about market position, customer needs, competitive dynamics. They produce a strategy that makes sense on paper.

Then it travels downward through the organisation. And somewhere between the executive floor and the team actually building things, it transforms. Not maliciously. Not through incompetence. Just through the accumulated friction of translation, interpretation, incentive misalignment, and local constraints.

By the time strategic intent becomes shipped product, the connection is often tenuous. Teams build things that technically satisfy the strategy but miss its spirit. Or they build things that made sense given their local context but don’t serve the larger goal. Or they build exactly what was specified, only to discover the specification itself was flawed.

The strategy-execution gap isn’t a communication problem. It’s a systems problem. And you can’t fix a systems problem with better slide decks.

This is where traditional PM skills fall short. Being great at discovery helps you understand customers. Being great at stakeholder management helps you navigate politics. Being great at prioritisation helps you make trade-offs. But none of these directly address the systemic dynamics that cause strategy to mutate as it moves through the organisation.

For that, you need different tools.

What Systems Thinking Actually Means for PMs

When I say “systems thinking,” I don’t mean drawing complicated diagrams that nobody reads. I mean developing the ability to see and influence the causal structures that shape outcomes.

This includes several related capabilities:

Causal loop recognition. Understanding that most organisational dynamics are circular, not linear. Team velocity affects deadline pressure, which affects technical debt decisions, which affects future velocity. Customer churn affects revenue, which affects hiring, which affects product quality, which affects churn. These loops exist everywhere. PMs who can identify them can intervene at leverage points rather than fighting symptoms.

Delay awareness. Systems don’t respond instantly. You make a decision today, and the effects show up weeks or months later. PMs who understand delays can set appropriate expectations, design better feedback mechanisms, and avoid the trap of over-correcting based on lagging signals.

Stock and flow intuition. Some things accumulate (customer trust, technical debt, team knowledge). Some things flow (revenue, bugs, feature requests). The relationship between stocks and flows determines system behaviour. PMs who grasp this can predict non-obvious outcomes and design interventions that account for accumulation effects.

Incentive mapping. Every person in your organisation responds to incentives. Engineering is measured on velocity. Sales is measured on closed deals. Marketing is measured on leads. These incentive structures create system behaviour that may or may not align with strategic goals. PMs who can map these incentives can anticipate where strategy will get distorted and design countermeasures.

This might sound academic. It isn’t. Every PM already does informal systems thinking when they predict “if we ship this, sales will promise features we can’t build, which will create support load, which will pull engineering into firefighting.” That’s a causal chain. The shift is making this intuitive practice more explicit and rigorous.

Connecting Systems Thinking to Strategy Execution

Here’s where this gets practical for closing the strategy-execution gap.

Systems thinking reveals where strategy gets lost. When you can model the causal chains between executive decisions and team behaviours, you can see exactly where translation breaks down. Maybe the strategy requires cross-team coordination but the incentive structure rewards team-level wins. Maybe the strategy assumes a capability that doesn’t exist and nobody wanted to admit it. The system model makes these failure points visible.

It enables earlier course correction. If you understand the feedback loops in your organisation, you can design leading indicators that detect strategy drift before it becomes irreversible. Not just “are we on track” but “are the systemic conditions in place for this strategy to succeed.”

It helps you design interventions that stick. Most attempts to close the strategy-execution gap focus on communication. More alignment meetings. Better documentation. Clearer OKRs. These help, but they don’t change the underlying system dynamics. A PM with systems thinking can identify structural changes, different incentives, new feedback mechanisms, altered information flows, that create sustainable alignment rather than temporary compliance.

It makes you a better strategic partner. Executives often set strategy based on market analysis without fully accounting for organisational dynamics. A PM who can model how strategy will interact with the existing system can flag implementation risks during strategy formulation, not just during execution. “This strategy assumes engineering can ship faster than our current architecture allows. Here’s what would need to change.”

The Analytics Evolution

There’s a related shift happening around analytics that connects to this.

Traditional PM analytics focused on product metrics. Usage, conversion, retention, feature adoption. Important stuff. Still important.

But systems-oriented analytics looks different. It focuses on the relationships between metrics rather than metrics in isolation. It asks questions like:

• What’s the lag between a change in activation rate and a change in retention?

• How does engineering velocity affect customer satisfaction, and through what intermediate steps?

• When we increase sales headcount, what happens to support load six months later?

This requires different analytical muscles. Correlation analysis across time series. Causal inference methods. Simulation and scenario modelling. The ability to build simple quantitative models of system behaviour and test them against reality.

I’m not suggesting every PM needs to become a data scientist. But the PMs who can partner effectively with analytics teams, who can frame systems-level questions and interpret systems-level answers, will have a significant advantage.

As discovery gets automated, the PM value shifts from gathering information to understanding the structural relationships that determine whether information leads to good outcomes.

What This Means Practically

If you’re a PM wondering how to develop these capabilities, here are some starting points.

Learn to draw causal loop diagrams. Not because the diagrams themselves are magic, but because the practice of creating them forces you to articulate your mental model of how things connect. Start with a problem you’re facing. Map out what causes what. Look for the loops. You’ll be surprised what you discover.

Study your organisation’s incentive structures. Sit down and list what each function is actually measured on. Not officially measured. Actually measured. The things that affect promotions and bonuses and reputation. Then trace how those incentives would logically affect behaviour around your current strategic priorities. Where are the alignments? Where are the conflicts?

Build a simple model of your product’s value chain. From initial customer awareness through to expansion revenue or referral or whatever your end-state is. Map the stocks and flows. Where do things accumulate? What are the conversion rates between stages? What are the delays? This becomes a tool for predicting where changes will have impact.

Run pre-mortems with a systems lens. Before launching an initiative, ask: “Assume this failed. What systemic dynamics would have caused that failure?” Push beyond individual mistakes to the structural conditions that make mistakes likely.

Practice explaining second-order effects. When discussing a decision, force yourself to articulate at least one consequence of a consequence. “If we do X, then Y will happen, which means Z will probably follow.” This exercises the causal thinking muscle.

The Trade-offs and Risks

I should be honest about the downsides of this shift.

Systems thinking can become analysis paralysis. If you model everything, you never ship anything. The map is not the territory, and sometimes you need to act with incomplete models.

It can feel abstract to stakeholders. Telling an executive “the feedback loop structure here creates a reinforcing dynamic that will amplify any initial deviation from plan” is not how you win friends. Translation into concrete, specific terms remains essential.

Not every organisation values this. Some companies want PMs who just execute. Who take requirements and deliver features without questioning the system that produced those requirements. Developing systems thinking in that environment might make you frustrated rather than effective.

Discovery still matters. I don’t want to overcorrect. Understanding customers, validating assumptions, testing hypotheses. These aren’t obsolete. They’re just becoming less sufficient on their own. The PM who can do discovery and systems thinking will outperform the PM who does only one.

Try This Tomorrow

Here’s a small experiment. Pick a strategic priority your team is currently working on. Something that came from leadership and is meant to drive important outcomes.

Now trace the path from that strategic priority to actual shipped product. Write down every handoff, every translation, every decision point.

For each step, ask:

• What could cause the original intent to get diluted here?

• What incentive does this person or team have that might conflict with the strategic goal?

• What information would need to flow backward to detect if something went wrong?

You’ll likely find two or three spots where the system is poorly designed for faithful strategy execution. Those are your leverage points. Those are the places where a structural intervention, not just a conversation, might actually close the gap.

The Uncomfortable Reality

I’ll be honest about something. This shift in PM skills isn’t entirely comfortable for me. I built my career on being good at customer discovery, at synthesising research, at translating user needs into product requirements. Those skills got me here.

Now the craft is evolving. The thing I was good at is becoming commoditised, and the thing that matters next is something I’m still developing. That’s humbling. Sometimes it’s frustrating.

But I also think it’s right. The strategy-execution gap has been the unsolved problem of product management for as long as I’ve been in this field. We’ve tried solving it with better discovery. With better prioritisation. With better communication. And yet the gap persists.

Maybe the reason it persists is that we’ve been treating a systems problem with non-systems tools. Maybe closing the gap requires PMs who can see the whole board, not just their corner of it. Who can model how decisions flow through organisations and get transformed along the way. Who can design feedback loops that actually work.

That’s the bet, anyway. The discovery work that filled my calendar is getting faster. The time I’m getting back needs to go somewhere. I’m putting it into understanding the systems that determine whether any of that discovery actually matters.

We’ll see if it pays off.

The Frog That Boiled

You’re three months into a retention initiative. Product shipped a redesigned dashboard. Engineering fixed some bugs. Design polished the onboarding flow. All good work. All on time. Retention moved 0.3%.

Nobody panicked on day one when product interpreted “retention” as engagement features while engineering heard “stability improvements”. Nobody raised flags in week four when design started optimising for new users instead of keeping existing ones. Nobody questioned the Slack thread in month two, where someone quietly redefined the success metric because the original target looked unreachable.

Small holes. Tiny misalignments. Each one defensible on its own.

The execution gap isn’t one big break. It’s a hundred little holes in the translation layer between “what leadership wants” and “what teams build”.

The ship drifted. Not dramatically. Not obviously. Just steadily, meeting by meeting, decision by decision, until you’re so far from the intended destination that nobody can remember what it was supposed to be.

Each hole lets a bit of intent leak out. A vague word here. An assumed context there. A priority that shifts without announcement. A metric that gets quietly swapped.

By the time the water’s boiling, the frog’s cooked.

The Holes Nobody Sees

At a B2B SaaS company, the board wanted to “expand in enterprise”. Sales heard “bigger deals” and chased Fortune 500 logos. Product heard “enterprise features” and built SSO, advanced permissions, audit logs. Engineering heard “scale” and rebuilt infrastructure. Marketing repositioned towards CIOs.

Eighteen months later: three enterprise clients, sophisticated features that small customers didn’t need, tripled infrastructure costs, and stalled mid-market revenue because nobody was watching it.

Nobody made a wrong decision. Everyone translated correctly according to their function. But the translations never aligned, and the tiny gaps between them compounded into a strategic detour that cost them a year and a half.

The holes in the translation layer come in patterns. Different organisations get different combinations, but the cascading effect is always the same.

Alignment Collapse

Product teams ship features without understanding how they connect to strategic goals. Leadership says “customer lifetime value” but doesn’t explain whether that means retention, expansion, or reducing support costs. Teams guess. They guess differently.

There’s no clear line from “here’s what I’m building this sprint” to “here’s why the board cares”. So teams fill in their own interpretation, and three teams fill it in three different ways.

I watched a company spend six months building a recommendation engine because “personalisation” was a strategic pillar. Nobody told product that the actual strategic goal was reducing churn in enterprise accounts, where personalisation doesn’t matter because they’re buying for teams, not individuals. Zero impact on the metric leadership actually cared about.

This one’s insidious because everyone’s working hard. The roadmap looks strategic. The all-hands slides mention the vision. But the connection’s missing.

Capacity Black Holes

Leadership sets ambitious goals. Product commits. Engineering’s already at 110% capacity. Something’s got to give. Usually it’s quality. Sometimes it’s the strategic work that gets bumped for urgent bugs and tech debt.

The hole here isn’t just bandwidth. It’s capability. Teams don’t have the skills for what strategy demands. You need ML expertise for the personalisation engine, but your engineers know React. You need enterprise sales experience, but your team has sold to SMBs their whole careers. Nobody admits it upfront because it sounds like failure. So you learn on the job, slowly, expensively, while the strategy timeline slips.

Ownership Ghosts

The VP announces the strategy. Nobody translates it into work. Or rather, everybody translates it differently, in their own heads, and nobody’s responsible for checking if the translations match.

“Improve developer experience” lands on three teams. Platform thinks it means better APIs. Product thinks it means better documentation. DevRel thinks it means more tutorials. Six months later, developer NPS hasn’t moved because the actual problem was confusing pricing, which none of them owned.

The ghost appears when you ask “who’s accountable for turning this strategic goal into specific work?” and get vague answers.

Measurement Drift

You start measuring monthly active users. Someone in leadership casually mentions “engaged users” in a meeting. Product ops updates the dashboard without telling anyone. Design’s still optimising for MAU. Engineering’s tracking DAU. Three different metrics, all called “active users”, none aligned.

Or worse: you’re measuring the wrong thing entirely. Leadership wants revenue impact. Product’s measuring feature adoption. Engineering’s measuring system performance. Design’s measuring user satisfaction. All good metrics. None of them prove you’re hitting the strategic goal.

Incentive Mismatches

The strategy says “long-term customer value”. Bonuses are based on quarterly revenue. Sales optimises for Q4 numbers. Product gets pressure to ship quick wins. Engineering’s rewarded for velocity, not sustainability. Everyone’s playing a different game.

This one’s brutal because individuals are making rational choices. They’re optimising for what they’re measured on. It’s just not what the strategy needs.

At a SaaS company, leadership wanted “product-led growth”. Sales was incentivised on deal size. So they kept selling to enterprise, which needed heavy customisation, which killed the product-led motion. Two years of strategic focus, zero movement on the metric, because the incentive structure was screaming “do the opposite”.

Frozen Strategy

Leadership sets the strategy in January. The market shifts in March. Competitors launch in May. Customer needs change in July. The strategy document stays the same. Teams keep executing against goals that stopped being relevant four months ago.

The annual planning cycle is designed for stability. But most markets aren’t stable anymore. You’re locked into OKRs that made sense in Q1 but are nonsense in Q3. Nobody wants to admit the strategy’s wrong. So you keep executing, dutifully, against a target that’s moved.

Or there’s no feedback loop at all. Teams ship. Users react. Data comes in. Nobody adjusts the strategy based on what’s actually happening. You discover in December that the thing you built in March didn’t work, but you only check once a quarter, so you built three more versions of it before anyone noticed.

Cultural Antibodies

The strategy says “move faster, experiment more”. The culture says “don’t ship broken things”. Engineering wants perfect code. Design wants pixel-perfect interfaces. Legal wants three rounds of review. You’ve announced a strategy that your culture is designed to reject.

Or it’s silos. Strategy requires product, engineering, and data to collaborate. But product doesn’t trust engineering’s estimates. Engineering doesn’t respect product’s priorities. Data doesn’t have access to the systems they need. Everyone’s protecting their territory. The strategic initiative dies in cross-functional warfare that nobody admits is happening.

The Cascading Landslide

These holes don’t stay isolated. They compound. They cascade. They create chain reactions that turn small problems into strategic failures.

Alignment collapse means teams build the wrong things. Building the wrong things wastes capacity. Wasted capacity means the right things don’t get built. Missing the right things means metrics don’t move. Metrics not moving triggers leadership panic. Panic creates new priorities. New priorities without clear ownership create more alignment collapse.

Round and round.

At a healthtech company, leadership wanted to “improve patient outcomes”. Nobody defined what that meant (alignment hole). Product built engagement features while clinical wanted diagnostic tools. Engineering was underwater (capacity issues). Nobody was accountable for the translation (ownership ghost). They measured feature adoption instead of health outcomes (measurement drift). Sales was incentivised on new logos, not patient results (incentive mismatch). The market shifted but the annual plan stayed the same (frozen strategy). Clinical staff resisted because they weren’t trained (cultural antibodies).

Eighteen months. Millions spent. Zero impact on patient outcomes.

Not because anyone was incompetent. Because seven small holes cascaded into strategic failure.

Why You Don’t Catch It

The hard part? You often sense something’s off.

Product’s talking about user engagement while leadership’s asking about revenue. Engineering’s excited about the refactor while sales is wondering where the promised features are. You’re in a meeting where everyone’s nodding but you can tell they’re all thinking different things.

You feel the drift. But you can’t always name it. And even when you can, you might not have the authority to fix it. Alignment collapse? That’s a leadership problem. Capacity issues? That’s a headcount problem. Incentive mismatches? That’s above your pay grade. Cultural antibodies? Good luck changing that.

The frog doesn’t jump out because the temperature rises slowly enough that each moment feels survivable. By the time it’s obviously wrong, you’re too invested to stop.

So you let it slide. Just this once. Just this meeting. Just this sprint.

I’ve been the PM who sensed the strategy wasn’t translating but didn’t have the evidence to prove it. Who saw the alignment issues but couldn’t get leadership to sit down and clarify. Who knew the metrics were wrong but couldn’t change them mid-quarter. Who watched the cultural resistance kill the initiative but couldn’t force change management.

Sometimes you don’t catch it because you can’t. You lack authority. You lack evidence. You lack the political capital to fight that battle when you’re already fighting three others.

Making the Holes Visible

You can’t plug every hole. But you can catch them faster and shrink the cascade.

On alignment: When someone uses an outcome word, stop. Translate it immediately. “Improve activation” becomes “what’s the activation event, what’s our current rate, what’s the target, who are we measuring, and how does this connect to the revenue goal leadership cares about”. Write it down. Check if everyone wrote the same thing. They won’t have. Fix that now, not in month three.

On capacity: Before committing to strategy, do a brutal capacity audit. What’s already committed? What’s the actual available hours? What skills do we have versus need? If the gap’s too wide, say it. Loudly. Don’t quietly agree to do six months of work in three with skills you don’t have.

On ownership: Draw the accountability map. Who translates this strategic goal into specific work? Who decides when interpretations conflict? Who checks if we’re still aligned? Get names. Get explicit agreement. Make it someone’s job.

On measurement: Define success before you write code. What are we tracking? What’s the target? When are we checking? How does this metric prove we hit the strategic goal? If you can’t draw a straight line from your metric to the board’s goal, pick a different metric.

On incentives: Look at what people are actually rewarded for. If it doesn’t match what strategy demands, flag it. You might not fix it, but at least you’ve named the mismatch. Sometimes that’s enough to get it changed. Sometimes you just work around it.

On adaptability: Build review cadences that can actually change things. Monthly strategy check-ins where you can kill work that’s not landing. Quarterly recalibrations where you can shift priorities based on what’s happening. Don’t lock the plan in January and ignore reality for eleven months.

On culture: Spot the antibodies early. Is this strategy asking people to work in ways that conflict with how they’re trained, rewarded, or structured? If yes, either change the strategy or invest in change management. Don’t just announce transformation and hope culture magically shifts.

The best teams I’ve seen do this relentlessly. They’re annoying about it. They catch vague language and force specificity. Not in formal ceremonies. Just in how they work.

Not because they’re pedantic. Because they’ve been the frog before. They know what boiling feels like.

Where This Goes Next

I’m building a series on the translation layer components that break most often. How alignment collapses and how to catch it. How capacity constraints silently kill strategy. How ownership ghosts create chaos. How measurement drifts off target. How incentives sabotage execution. How frozen strategies become irrelevant. How cultural antibodies reject change.

Each piece will show you where the holes typically form, how to spot them early, and what you can do tomorrow to plug them. No frameworks. Just patterns from teams that stopped boiling frogs.

Because the truth is: you’re not failing at execution. You’re failing at translation. The gap between “what the board wants” and “what teams build” is filled with small, compounding holes that nobody’s managing.

Fix the translation layer. Make the holes visible. Stop the drift early.

Or keep boiling. Your choice.

Your exec team spent three months crafting a strategy. They emerged from an offsite with slides, frameworks, and conviction. Six weeks later, your engineering lead asks what you’re actually building next quarter, and you realize you can’t quite explain how yesterday’s sprint planning connects to that confident deck from March.

Something broke in translation. Again.

What Actually Happens When Strategy Goes Missing

I’ve watched this play out enough times to spot the early signs. The leadership team announces bold direction. People nod earnestly. Then everyone returns to their desks and... continues exactly what they were doing before. Not because they’re stubborn or checked out. Because nobody quite knows what to stop doing, or what the new thing looks like at ground level.

Here’s what that gap looks like from the PM seat. You’re in a product review, walking through your roadmap. Someone from the exec team squints at your Q2 plans and says, “How does this ladder up to our platform play?” You freeze. Your roadmap predates the platform play. Or maybe it doesn’t, but nobody told you what “platform play” actually means for your domain. You mumble something about “alignment” and “exploring options” and make a note to have a conversation you should’ve had two months ago.

The real problem isn’t that strategy gets lost. It’s that strategy often arrives pre-lost. Packaged in language so polished it slides right past the messy reality of building products.

The Translation Problem Nobody Admits

Strategy documents have this weird property. They get more confident as they get more abstract. “Accelerate platform adoption across enterprise segments” sounds clear until you’re the PM who needs to decide whether that means building SSO first or fixing the onboarding flow that’s haemorrhaging users.

The McKinsey people call this the “mobilization gap.” Nice phrase. What they mean is: most companies are terrible at turning strategic choices into organizational readiness. The bit where you figure out who does what, with which resources, starting when. The unglamorous logistics that determine whether your strategy lives or dies.

I’ve seen research claiming 74% of executives admit their strategies don’t translate into concrete actions. Which means either:

• 26% of executives are lying, or

• We’ve collectively decided this is just how strategy works

Neither answer is great.

“The biggest gap between Strategy Champions and stragglers is in mobilization, the phase of translating strategic choices into organizational readiness.”

That’s from McKinsey research, and it tracks with what I’ve seen. The companies that actually execute strategy spend absurd amounts of time on the boring stuff. Who owns what. What resources exist. What we’re explicitly choosing not to do. The stragglers write beautiful strategy docs and wonder why nothing changes.

When Everyone’s Aligned on Paper

There’s this meeting I keep attending. Different companies, same meeting. Leadership gathers to “align on priorities.” Two hours later, everyone leaves feeling aligned. But ask three different VPs what the top priority is, and you’ll get three different answers. All technically correct. All mutually exclusive in practice.

This is what misalignment actually looks like. Not open disagreement (that you could fix). But confident consensus that means different things to different people. Your CTO heard “invest in platform infrastructure.” Your CPO heard “ship revenue features.” Your CEO heard both and assumed you’d figure out the balance. Nobody did.

“Misalignment isn’t open disagreement. It’s confident consensus that means different things to different people.”

The product org inherits this mess. You’re supposed to build the roadmap that delivers the strategy, except the strategy contains built-in contradictions nobody surfaced. So you make choices. Reasonable choices, probably. But they’re your choices, not strategic choices. And when the quarterly review comes around and your roadmap doesn’t match someone’s mental model of the strategy, you’re the one who “wasn’t listening.”

Actually, you were listening. You were listening to three different versions of the same story.

The Real Dysfunction Hiding In Plain Sight

Let me tell you what I learned building products in fintech, then moving to SaaS, then dipping into Web3, then back to enterprise. The dysfunction isn’t unique to any industry. It’s not a startup problem or an enterprise problem. It’s a human systems problem dressed up in business language.

When strategy fails to translate, it’s usually because:

Someone is optimizing for consensus over clarity. Writing strategy documents that everyone can agree with requires making them vague enough that everyone sees what they want to see. This is political genius and operational suicide.

The strategy assumes resources that don’t exist. You’ve committed to four strategic bets, but you have capacity for 1.5. Leadership knows this. Product knows this. Nobody says it out loud because that would mean choosing, and choosing means disappointing someone important.

The incentive systems haven’t caught up. Your strategy says “platform thinking” but your bonus structure still rewards shipping features. Guess which one wins? Here’s a hint: people do what you pay them to do, not what you tell them to do.

Nobody wants to admit what we’re not doing. Every strategy is also a list of things you’re explicitly choosing not to pursue. Except nobody writes that list. Too risky. Too many feelings. So you end up with strategy by omission, where people discover the boundaries by running into them.

“Every strategy is a list of things you’re choosing not to pursue. Except nobody writes that list.”

I shipped a product once where the strategic direction was “become the system of record for X.” Sounds clear, right? Wrong. What nobody wanted to say was that becoming the system of record meant killing our old flagship product that still generated 40% of revenue. The strategy was real. The roadmap was fantasy.

How to Spot This Before It Kills Your Quarter

You can see strategy gaps forming before they blow up your roadmap. Here’s what to watch for.

The euphemism test. When leadership talks about the strategy, listen for words that sound specific but aren’t. “Drive adoption.” “Improve experience.” “Accelerate growth.” These are fine as outcomes, useless as direction. If you can’t describe three concrete examples of what success looks like, you don’t have strategy, you have aspiration.

The resource allocation test. Look at where your engineers are actually spending time. Does it match the strategy document? If your strategy says “enterprise focus” but 70% of eng is fixing consumer bugs, you’ve found the gap. Resources don’t lie. Words do.

The decision latency test. When someone asks “Should we build feature X?”, how long does it take to answer? If the answer is “Let me check with five people and get back to you,” your strategy isn’t doing its job. Strategy should make decisions faster by providing a framework. If it’s making decisions slower by adding more cooks, something’s broken.

The team confusion test. Ask three individual contributors on different teams to explain the strategy. If you get three wildly different answers, you’re not aligned, you’re all just using the same words differently. This happens more than you think.

What You Can Actually Do About It

Right. You’ve spotted the gap. Strategy exists in slide form but not in practice. What now?

Make the trade-offs explicit

Someone needs to say the quiet part out loud. You can’t do everything. So what are we not doing? I’ve started keeping a “Not Doing” list that’s as detailed as my roadmap. Features we could build but won’t. Markets we could chase but aren’t. Improvements we’re deliberately postponing. Writing this down feels dangerous. It is dangerous. It’s also clarifying.

Try this in your next planning session: For every strategic priority, list three things you’re explicitly choosing not to do. Watch how fast the fake consensus evaporates.

Create decision heuristics, not frameworks

Your team doesn’t need another prioritization matrix. They need a way to make calls when you’re not in the room. Give them principles that actually work. Not “focus on customer value” (useless). More like “B2B over B2C unless the B2C feature enables B2B workflows” (specific enough to be wrong, which means it’s specific enough to be useful).

At Quantive, we had a simple rule: any feature requiring more than two quarters of data science work needed VP approval, period. Arbitrary? Yes. Clarifying? Absolutely. It killed three months of circular debate about ML features.

Build the forcing functions

Strategy without measurement is just wishful thinking. But here’s the thing: measuring outcomes is hard and slow. You need faster feedback loops. Leading indicators that tell you if you’re on track before the quarter ends.

If your strategy is “platform first,” start tracking how many new features are built on the platform versus outside it. If you’re “enterprise focused,” measure what percentage of design reviews include enterprise-specific concerns. These aren’t perfect metrics. They’re smoke detectors, not fire extinguishers. But you want to know about the smoke.

Accept that some sacrifices are real

Here’s the uncomfortable bit. Sometimes the strategy is sound, but executing it means killing things people love. Products. Features. Markets. Teams, sometimes. You can’t translate strategy without accepting this. The companies that do strategy well aren’t avoiding hard choices. They’re making them visibly, early, and then moving on.

I’ve had to sunset products that were profitable but off-strategy. It’s miserable. The team’s upset. The customers are confused. The board wants to know why you’re killing something that makes money. You do it anyway because the alternative is spreading resources so thin that nothing works.

The Uncomfortable Truth About Strategy Execution

Most strategy execution advice treats this like a process problem. Get better at cascading goals. Use OKRs properly. Improve your communication. Fine. Do those things.

But the real issue is usually political, not procedural. Someone high up doesn’t actually want the strategy to succeed because it threatens their domain. Or multiple executives are playing chicken, waiting to see if the strategy sticks before committing resources. Or the strategy is intentionally vague because getting specific would expose disagreements nobody wants to have.

You can’t process-engineer your way out of political misalignment. At some point, someone needs to have the awkward conversation. Preferably someone with enough capital to survive it.

If you’re a senior PM or director, that someone might be you. Sorry. It’s not in your job description, but it’s in your job. You’re close enough to execution to see where the strategy breaks down, senior enough that people might listen, and dispensable enough that you can take the reputational hit if it goes wrong.

This is what “strategic thinking” actually means in practice. Not writing decks. Not facilitating workshops. But being willing to name the gap between what we say we’re doing and what we’re actually doing, and then pushing until someone either fixes it or admits we’re not going to.

What to Try Tomorrow

Enough philosophy. Here’s what you can do this week.

Run a strategy translation workshop with your immediate team. Take the company strategy and work backwards. If this strategy is true, what would we stop doing? What would we start? What would we do differently? Write it down. Compare notes. The gaps will be obvious.

Ask the “how would we know” question in your next planning meeting. Every strategic statement, follow up with: “How would we know if we’re making progress on this next quarter?” If nobody can answer, the strategy isn’t ready for execution.

Create a decision log. For two weeks, write down every time you or your team had to make a strategic choice without clear direction. What were you deciding? What information did you need? Who did you have to ask? At the end of two weeks, you’ll have a map of where your strategy has holes.

The Thing Nobody Wants to Acknowledge

Here’s what I’ve learned after doing this across multiple companies, industries, and company stages: sometimes the strategy is deliberately vague because the leadership team can’t agree. Sometimes it’s vague because they don’t actually know what to do. And sometimes it’s vague because being specific would require admitting resource constraints that everyone knows but nobody wants to say out loud.

None of these are process problems. They’re courage problems.

The gap between strategy and execution isn’t going away. It’s inherent in how organizations work. The question is whether you’re going to pretend it doesn’t exist or learn to navigate it. Because your roadmap depends on it, your team’s sanity depends on it, and your ability to ship anything meaningful depends on getting good at this translation work.

Nobody taught you this in PM school. There is no PM school. But this is the job. Not the fun stuff in the blog posts about vision and innovation. The boring, political, uncomfortable work of turning vague strategic intent into specific product choices while keeping everyone roughly pointed in the same direction.

It’s not elegant. It’s not “best practice.” It’s just what works when you’ve run out of other options and someone needs to actually build something.

Anyway. Good luck with Q3 planning.

There’s a particular kind of silence in a product review meeting when someone pulls up a screen that nobody remembers building. You squint at it. Three different button styles. A workflow that requires six clicks when two would do. A settings panel that looks like it was designed by a committee across three time zones who never actually spoke to each other.

“When did this happen?” someone asks.

The answer, of course, is slowly. Then all at once.

The Quiet Accumulation

I once worked on a product where we spent eighteen months “moving fast.” We hit every quarterly target. Leadership loved us. The OKRs were green. We were growth incarnate.

Then one quarter, activation rates dropped. Not dramatically. Just enough to notice. Support tickets crept up. Users started asking for features that already existed. Which should have been the first clue.

What we discovered was that our product had become, over those eighteen months, a kind of geological formation. Layer upon layer of rushed decisions, each one reasonable in isolation, had stratified into something genuinely confusing. We’d accumulated so much UX debt that users were essentially paying the interest on every single interaction.

The thing about UX debt is that it doesn’t throw errors. There’s no build failure. No red alert in your monitoring dashboard. It just sits there, compounding, making everything slightly harder than it needs to be.

What Actually Is This Stuff?

Technical debt gets all the attention because engineers are good at naming things and even better at complaining about them. But UX debt is its quieter, more insidious cousin. And your dev to designer ratio is 100-1.

The longer design debt is ignored, the harder it becomes to fix.

It’s the accumulated cost of every decision where you said “we’ll clean this up later” and then didn’t. Every inconsistent interaction pattern. Every screen that was built quickly for one use case and then got pressed into service for three others. Every moment where you chose speed over coherence because the quarterly review was in two weeks.

Some teams distinguish between design debt (visual inconsistencies, component library chaos) and UX debt (confusing workflows, poor information architecture). Honestly, in practice they tend to travel together like old friends who’ve been causing trouble since university.

The dangerous part isn’t any individual shortcut. It’s the interaction effects. Three minor inconsistencies become one major confusion. Five “temporary” workarounds become a workflow that nobody can explain to a new user.

How Growth Pressure Manufactures This Debt

Here’s the loop that creates this problem, and once you see it, you’ll spot it everywhere:

1. Team gets growth targets

2. Team ships features faster to hit targets

3. Features get built without full design exploration

4. Small inconsistencies accumulate

5. User experience degrades incrementally

6. Activation and retention soften

7. Leadership responds with more aggressive growth targets

8. Return to step one, but worse

The particularly cruel thing is that this loop often produces success metrics in the short term. You shipped more. You hit the targets. The dashboards look healthy. And meanwhile, your product is slowly becoming a maze that users tolerate rather than enjoy.

I watched this happen at a fintech company where we were adding enterprise features at a rate that made our design system look like a suggestion rather than a standard. Every new feature team built their own patterns because waiting for design alignment would slow them down. Twelve months later, we had what one designer accurately described as “four products wearing a trenchcoat pretending to be one.”

The Warning Signs

Most articles about UX debt tell you to look for obvious symptoms. Support tickets. Drop-off rates. Users complaining.

But here’s the thing. By the time users are complaining, you’re already deep in it. The early signals are much more subtle:

Users ask for features that already exist. This one kills me. It means your product has become opaque enough that people literally cannot find what you’ve already built. Every time I hear “users keep asking for X” and X already exists, somewhere hidden three levels deep in a submenu, I know we’ve got a problem.

Onboarding time keeps creeping up. You won’t notice this if you’re not measuring it carefully. But if it’s taking new users longer to reach value than it did a year ago, and you haven’t added complexity deliberately, something’s gone wrong.

Internal teams avoid certain parts of the product. When your own sales team routes around features during demos, that’s data. When customer success has a list of “don’t touch this” areas they warn users about, that’s a red flag wrapped in a flare.

Design reviews become archaeology expeditions. If every design review includes twenty minutes of someone explaining why something is the way it is, and the explanation involves three different teams and a departed founder, you’re looking at debt.

The “quick fix” ratio is climbing. Track how many of your shipped changes are band-aids versus proper solutions. When that ratio tips toward band-aids, your velocity is actually making things worse.

The Hidden Costs That Don’t Show Up In Reports

Here’s what doesn’t appear in any quarterly business review:

The feature you built that 40% of users never discover because the navigation got too complicated.

The enterprise deal that almost closed until the prospect did a proper evaluation and got confused by the inconsistent terminology across screens.

The support cost of explaining the same workflow seventeen different ways because the product itself isn’t clear.

The engineering time spent building workarounds for UX problems that should have been solved in design.

The slow bleed of users who don’t churn dramatically but simply stop expanding their usage.

When users can’t intuitively find or use features, they turn to customer support, increasing costs.

I’ve seen products where the support burden alone would have justified a quarter of focused UX debt reduction. But nobody had ever done the maths because the costs were distributed across too many line items.

Why Teams Keep Creating This Debt Anyway

Part of me wants to be righteously angry about this. Just build it properly the first time! Have some standards!

But honestly, I’ve been the person making these trade-offs. And usually the reasons are understandable, even if the long-term consequences aren’t.

The pressure to ship is real. When leadership is asking why the roadmap is slipping, “we’re investing in coherent interaction patterns” is not an answer that lands well. The incentive structure in most organisations rewards visible output over invisible quality.

Design debt is hard to measure. You can point to a technical debt item and say “this will cause an outage if we don’t fix it.” UX debt is harder to quantify. Users won’t crash. They’ll just gradually find your product less pleasant to use.

Everyone’s working on their piece. In a feature-team world, nobody owns the overall experience. Everyone’s optimising their bit. The result is a product that works great in each individual section and confuses the hell out of anyone trying to use it as a whole.

“Later” never comes. We all know this. The cleanup work gets deprioritised forever because there’s always something more urgent. And urgency is defined by what’s measurable, which UX debt usually isn’t.

So What Actually Works?

I’m not going to pretend there’s a clean solution here. If there was, nobody would have this problem. But there are approaches I’ve seen work.

Make it visible. Create a UX debt backlog alongside your tech debt backlog. Give items a severity rating based on user impact. Review it monthly with the same seriousness you give to security vulnerabilities. The act of tracking it forces acknowledgement that it exists.

Tie it to business metrics. This is where the work is. Find the connection between UX friction and activation rates. Between inconsistent patterns and support costs. Between confusing navigation and feature adoption. Once you can say “this UX debt item is costing us X in support costs monthly,” suddenly it becomes a prioritisation conversation like any other.

Build in maintenance time. Some teams do this as a percentage of each sprint. Others do periodic “fix-it weeks.” The specific approach matters less than the commitment to doing it regularly rather than in one heroic cleanup that never actually happens.

Design reviews that actually review. Not just “does this look okay” but “does this match our patterns” and “how does this fit with the screens before and after it.” Include someone in design reviews whose job is to ask these questions.

Run UX audits. Not constantly, but periodically. Walk through key user journeys and document every friction point, every inconsistency, every moment of confusion. The audit itself is often enough to generate urgency.

You don’t have to eliminate all design debt. You just need to treat it as real debt and manage it with intention.

Accept some debt consciously. This is the hardest one. Sometimes shipping fast with known UX compromises is the right call. But make it explicit. Document what you’re not doing and why. Put it in the debt backlog. The problem isn’t taking shortcuts. It’s taking shortcuts and pretending you didn’t.

A Litmus Test For Your Current State

Here’s something you can try this week. Pick your most important user journey. The one that drives the metric leadership cares most about.

Now watch three users go through it. Not power users. New or occasional users.

Note every moment they hesitate. Every click they take that isn’t on the happy path. Every question they ask. Every time their face shows confusion even briefly.

If that list is longer than five items, you’ve got UX debt affecting your core business.

If that list includes items your team has known about for more than six months, you’ve got a prioritisation problem, not just a debt problem.

The Uncomfortable Truth

None of this will make you popular in the short term. Fighting for UX debt reduction means arguing against visible features in favour of invisible improvements. It means slowing down when everyone wants to speed up. It means spending time on things you’ve already shipped instead of new things that look good in roadmap presentations.

But here’s what I’ve learned from watching this pattern play out across different companies: the teams that ignore UX debt don’t actually move faster in the long run. They just defer the cost. And the interest on that cost is paid in confused users, bloated support teams, and eventually, the kind of “big redesign” project that takes eighteen months and still doesn’t fix everything.

The teams that treat UX quality as a first-class concern, that budget for it explicitly, that track it alongside tech debt, those teams look slower in the quarterly view but faster in the annual view.

Your product is either getting easier to use or harder to use. There’s no steady state. Every decision is either paying down debt or accumulating more.

The question isn’t whether you have UX debt. You do. Everyone does.

The question is whether you’re managing it, or whether it’s managing you.

That settings panel I mentioned at the beginning? It took us three months to untangle. Three months we could have spent on features if we’d built it properly the first time. The debt always comes due. The only variable is whether you choose when to pay it.

I watched a Product Ops team get dismantled last year. Not for lack of effort. They’d built dashboards, standardised sprint ceremonies, created feedback loops with customer success. By every textbook measure, they’d done their job.

The execution gap hadn’t budged.

If anything, teams were more frustrated than before. More meetings. More templates to fill. More “alignment sessions” that aligned precisely nothing. The Head of Product Ops left quietly, probably wondering what went wrong.

Here’s what went wrong: they’d installed a turbocharger on a car with no wheels.

The Amplification Problem

Product Ops has become the organisational equivalent of a superfood. Everyone wants it. Most people aren’t entirely sure what it does. And the marketing around it promises transformation without acknowledging that some bodies reject even the healthiest interventions.

The pitch goes something like this: Product Ops creates the connective tissue between teams. It handles the operational burden so PMs can focus on strategy. It standardises processes and ensures data flows to the right places.

“Product Operations is what a trainer and nutritionist are to an elite athlete.”

Lovely metaphor. But what happens when your athlete has a torn ACL and refuses to acknowledge it?

Here’s what nobody tells you in the thought leadership pieces: Product Ops is an amplifier, not a transformer. It makes your existing organisational dynamics louder and more visible. If your company has healthy cross-functional relationships, clear decision rights, and genuine strategic alignment, Prod Ops will accelerate that. You’ll ship faster, learn quicker, waste less.

But if your organisation is dysfunctional? If leadership says one thing and measures another? If teams are fighting over territory and nobody trusts the data anyway?

Prod Ops becomes a megaphone for chaos.

The Dysfunction Multiplier

I’ve seen this pattern play out across at least four companies now. It looks different each time, but the underlying mechanics are identical.

A company decides they have an execution problem. (They’re right, they do.) Someone reads that 96% of billion-dollar companies have Product Ops. Leadership concludes that Product Ops must be the missing ingredient. They hire a Head of Product Ops, give them a vague mandate to “improve how we work,” and wait for the transformation.

What happens next is predictable.

The new Prod Ops lead starts asking questions. They want to understand the current state: How do decisions get made? Where does customer feedback go? Who owns the roadmap? What does the data say?

And they discover something uncomfortable. The reason execution is broken isn’t a lack of process. It’s that the processes they do have are actively working against each other. Marketing has one definition of success, Product has another, and Engineering measures something else entirely. Leadership wants innovation and predictability simultaneously. Nobody trusts the metrics because the metrics have been gamed for years.

Into this mess walks a well-intentioned Prod Ops team armed with Notion templates and a mandate to create consistency.

They document the current processes. (Which makes visible how contradictory they are.) They build dashboards. (Which surface data nobody wants to see.) They try to standardise sprint ceremonies. (Which reveals that different teams have fundamentally different understandings of what a sprint even means.)

Every intervention, however sensible, exposes another fault line.

“Product Operations serves as the custodian of the product data ecosystem. Their responsibility is to ensure the integrity of product data and transform raw usage statistics into structured, actionable information.”

Sure. But what if nobody wants actionable information? What if actionable information would require people to change their behaviour, admit past mistakes, or give up pet projects?

The Prod Ops team becomes the bearer of unwelcome truths. And organisations have a well-documented response to messengers bearing unwelcome truths.

What Actually Has to Be True

So is Product Ops just doomed? Should companies skip it entirely?

No. But they need to be honest about what has to be true before Prod Ops can actually help.

First: You need genuine executive commitment to transparency. Not the “we value transparency” that appears on the values poster. Actual willingness to surface uncomfortable data and act on it. If your leadership team doesn’t want to know the real cycle time, the real adoption rates, the real reasons features fail, then Prod Ops will either become a producer of sanitised reports or a political liability.

I worked with a fintech where the CEO genuinely wanted to understand why their time-to-market had doubled. She didn’t love what the Prod Ops analysis revealed (too many approval layers she’d personally instituted), but she acted on it. That’s rare.

Second: Decision rights have to be clear before you can standardise anything. Prod Ops can document and streamline a process. It cannot adjudicate a turf war. If Product and Engineering fundamentally disagree about who owns technical roadmap decisions, no amount of process documentation resolves that. It just creates a paper trail of the conflict.

In matrix organisations, this gets particularly messy. Someone asked me recently why their Prod Ops team felt like a “dumping ground” for orphan tasks. Because in a matrix, tasks without clear owners don’t disappear. They accumulate. And they accumulate wherever there’s capacity and a mandate vague enough to absorb them.

Third: The underlying incentives have to point roughly the same direction. If Sales is compensated on signed contracts regardless of deliverability, Marketing on MQLs regardless of conversion, and Product on features shipped regardless of adoption, you have a system designed to produce misalignment. Prod Ops can make this misalignment more visible. It cannot override incentive structures.

A colleague of mine ran Prod Ops at a series B company where the Sales VP openly admitted to promising features that weren’t on any roadmap. His commission depended on it. The Prod Ops team built beautiful intake processes and prioritisation frameworks. Sales ignored them because ignoring them was economically rational.

The Artefacts, Processes, and People Problem

Assuming you’ve got the prerequisites in place, here’s where it gets practical.

Most Prod Ops implementations fail because they focus on creating artefacts (templates, dashboards, documentation) without addressing processes (how work actually flows) or people (whether anyone will use the damn thing).

Artefacts are the easiest part. Anyone can build a Notion database or configure a Jira workflow. The templates look professional. They feel like progress. Leadership sees tangible output and assumes value has been created.

But an artefact nobody uses is just digital clutter.

Processes are harder. They require actually changing behaviour. Getting the sales team to log customer feedback in a consistent format. Convincing engineering leads to participate in standardised retrospectives. Ensuring that the data entering your dashboards is captured at the right moment in the right way.

This is change management, not operations. And it’s slow, frustrating work that doesn’t photograph well for quarterly updates.

People are the hardest. Prod Ops needs to hire or develop individuals who can operate across functional boundaries without formal authority. Who can push back on leadership without becoming defensive. Who understand both the data and the human dynamics underlying the data.

I’ve seen technically excellent Prod Ops leads fail because they couldn’t navigate politics. I’ve seen politically savvy ones fail because they didn’t understand product development well enough to earn credibility. The combination is rare.

How to Spot Whether Yours Is Helping or Hurting

If you already have a Product Ops function, here’s a diagnostic.

Signs it’s helping:

• PMs say they have more time for customer work (and you believe them)

• Cross-functional teams reference the same data when making decisions

• Processes feel like scaffolding, not bureaucracy

• The Prod Ops team can articulate their OKRs in terms of outcomes, not activities

• Leadership uses Prod Ops insights to make actual decisions, including uncomfortable ones

Signs it’s hurting:

• More meetings than before Prod Ops existed

• Templates that nobody fills out correctly (or at all)

• Dashboards that get built and then ignored

• The Prod Ops team spends most of their time chasing people for compliance

• Everyone agrees the processes are good “in theory”

• When asked what Prod Ops does, people outside the team struggle to answer

The worst case is when Prod Ops becomes a performance of operational maturity rather than actual operational maturity. All the artefacts exist. The quarterly reviews look impressive. And nothing has actually changed about how work gets done.

What to Try if You’re Stuck

If you’re a Prod Ops lead watching your function struggle, or a product leader wondering why the investment isn’t paying off, here’s what I’d do.

Stop standardising for a month. Seriously. No new templates. No new processes. Just watch. Where are the real friction points? Not the ones people complain about in feedback surveys, but the ones that cause actual delays, rework, and frustration. These are rarely where you think they are.

Pick one workflow and make it undeniably better. Not “more documented.” Better. Faster. Less annoying. Something concrete that people will notice and appreciate. Build credibility through demonstrated impact, not comprehensive coverage.

Have the uncomfortable conversation about authority. If Prod Ops is supposed to standardise processes but has no authority to enforce them, you don’t have an operations function. You have a suggestions department. Either get explicit executive sponsorship with teeth, or be honest about the limitations.

Measure what matters to PMs, not what matters to slides. The metric that actually indicates Prod Ops value is whether product managers feel more effective. Survey them directly. Track their time allocation. If they’re spending the same amount of time in status meetings and filling out templates as before, your operational improvements are probably just different overhead.

The Uncomfortable Conclusion

Here’s what I keep coming back to.

Product Ops is a good idea. In environments with reasonable executive alignment, clear decision rights, and coherent incentives, it absolutely closes execution gaps. I’ve seen it work.

But most companies don’t have those things. They have the appearance of alignment (we all agree on the strategy!), unclear decision rights obscured by collegial relationships, and incentives that subtly work against each other.

In those environments, installing Product Ops is like adding another violin section to an orchestra where the musicians are reading from different sheet music. The sound gets louder. It doesn’t get more harmonious.

“The gap between strategy and execution remains one of the most critical and persistent challenges for modern enterprises.”

True. But Prod Ops doesn’t close that gap by existing. It closes it by surfacing information that enables better decisions. And if your organisation systematically avoids information that would require uncomfortable changes, then Prod Ops either becomes complicit in that avoidance or becomes the enemy.

Neither outcome is what the function was designed for.

So before you hire that Head of Product Ops, ask yourself honestly: Do we actually want to know what’s broken? Are we prepared to act on what we learn?

If the answer is yes, Prod Ops can be transformational.

If the answer is “probably not, but we should still look like we’re doing something about execution,” save the headcount. You’ll need it when the next reorg happens.

There’s a moment I remember from about three years ago. We were in a quarterly planning session, and someone pulled up the company strategy document. It had been written maybe eight months prior. Beautifully crafted thing. Clear market positioning, defined customer segments, a coherent thesis about where we’d win.

The room went quiet.

Not because the strategy was bad. Because nobody recognised it. The roadmap we’d been executing bore almost no resemblance to what was on that slide. We’d drifted. Feature by feature, deal by deal, we’d wandered so far from the original intent that looking at the strategy felt like reading someone else’s diary.

This is the gap. Not a dramatic explosion. Not a visible failure. Just a slow, grinding disconnect between what leadership thinks they communicated and what teams actually build.

And when that gap gets wide enough, you end up running a feature factory without ever deciding to.

What a Feature Factory Actually Looks Like

The term gets thrown around a lot, usually as an insult. But it’s worth being specific.

A feature factory is an organisation that measures success by the volume and velocity of what it ships, not by whether any of it matters. The primary question isn’t “Did this change customer behaviour?” or “Did this move the metric we care about?” It’s “Did we ship it?”

“If you’re just using your engineers to code, you’re only getting about half their value.” — Marty Cagan

The symptoms are recognisable once you know what to look for:

Teams celebrate releases with no discussion of impact. The backlog is a graveyard of half-validated ideas, each one added because someone important asked for it. Engineers feel like ticket machines. Product managers feel like project managers. Designers feel like decorators brought in after the decisions are made.

And here’s the thing that doesn’t get said enough: most of the people working in feature factories are talented, well-intentioned professionals. They’re not lazy. They’re not stupid. They’re trapped in a system that rewards motion over progress.

The tragedy is that everyone’s working hard. They’re just working on the wrong things.

The Anatomy of the Gap

So how does this happen? How do organisations with perfectly reasonable strategies end up building products that have nothing to do with them?

I’ve seen a few patterns repeat across different companies, industries, and team sizes. None of them are complicated. That’s what makes them so insidious.

The strategy exists but doesn’t travel.

Someone, usually at the executive level, crafted a strategy. Maybe it was good. Maybe it was even shared at an all-hands. But then... nothing. No translation layer. No mechanism to turn “we’re going to win in mid-market B2B” into “here’s what that means for your sprint.” The strategy lives in a document. The work lives in JIRA. And the two never meet.

I worked with one team where the CEO had a clear point of view about their differentiation. Genuinely sharp thinking. But the product org had never seen it written down. They were making prioritisation decisions based on what sales asked for, because in the absence of clear strategic direction, the loudest voice wins.

Incentives point the wrong way.

When product managers are evaluated on features shipped, they ship features. When engineering leads are measured on velocity, they optimise for velocity. When sales compensation is tied to closing deals this quarter, they promise whatever it takes to close deals this quarter.

None of this is malicious. It’s just physics. People respond to the scorecard they’re actually judged against, not the one in the vision statement.

The feedback loop is broken or missing entirely.

Teams build something. It goes live. And then... silence. Nobody measures what happened. Nobody checks if users adopted it, if behaviour changed, if the problem was actually solved.

Without that feedback, there’s no way to learn. No way to correct course. You’re flying blind, so you default to the only thing you can see: output. At least you can count that.

Discovery gets squeezed out.

When there’s pressure to “keep teams busy” (a phrase that should make any PM’s eye twitch), discovery feels like a luxury. Why spend time talking to customers when there’s a backlog full of features waiting to be built?

This is how you end up with teams that are brilliant at execution and terrible at direction. They can build anything. They just don’t know if they should.

The Hidden Costs Nobody Wants to Calculate

Here’s what bothers me about the feature factory conversation: we talk about it like it’s just inefficient. Like the problem is we’re wasting some engineering cycles.

The costs are much worse than that.

You’re compounding technical debt. Every rushed feature adds weight to the codebase. Every shortcut becomes a tax on future development. I’ve seen teams where a feature that should take two weeks takes six, because the codebase has accumulated so much cruft that every change is a surgery.

You’re burning out your best people. There’s something soul-destroying about shipping things you know don’t matter. Senior engineers leave. Thoughtful PMs leave. What you’re left with is people who’ve made peace with the assembly line, or people who haven’t been there long enough to notice.

You’re training the organisation to ignore outcomes. This might be the worst one. When you celebrate shipping regardless of impact, you’re teaching everyone that impact doesn’t matter. That cultural debt is harder to pay down than any technical debt.

You’re missing the opportunities that actually matter. While your teams are busy building features nobody asked the right questions about, your competitors might be solving the problems your customers actually have. The opportunity cost is invisible but real.

Bridging the Gap: What Actually Works

Right. So what do you do about this? I wish I had a three-step framework that fixes everything. I don’t. But I’ve seen some patterns that help.

Make the strategy concrete and visible.

The strategy cannot live in a deck that gets presented once and forgotten. It needs to be translated into something teams can actually use for decision-making.

This is where something like a North Star Metric becomes useful. Not because it’s magic, but because it gives you a filter. Every proposed initiative can be tested against a simple question: “How does this affect the thing we said we cared about?”

At Quantive, working with enterprise clients like Adobe and John Deere, I watched teams struggle with exactly this translation problem. The companies that figured it out weren’t the ones with the fanciest OKR software. They were the ones where leaders consistently connected daily work back to strategic intent. Weekly. In every meeting. Relentlessly.

Protect time for discovery. Actually protect it.

Teresa Torres talks about continuous discovery as “at a minimum, weekly touchpoints with customers, by the team building the product.”

Weekly. Not “when we have time.” Not “before big initiatives.” Weekly.

This feels impossible in a feature factory because the machine is hungry. There’s always something that needs to ship. But here’s the counterintuitive bit: the discovery work is what makes the delivery work worthwhile. Without it, you’re just efficiently producing waste.

“Continuous discovery is about ensuring that every solution is tied to a validated customer opportunity.”

I’ve found the Opportunity Solution Tree useful here. Not as a religion, but as a forcing function. If you can’t draw a line from the feature you’re about to build back to a real customer problem, that’s information.

Change what you measure and celebrate.

If your sprint reviews are all about “what we shipped” and never about “what changed because of what we shipped,” you’re reinforcing the feature factory.

Start asking different questions. “What did we learn?” “What behaviour are we seeing?” “Did the thing we built last month actually work?”

This feels awkward at first. Teams aren’t used to it. But over time, it shifts the culture from output obsession to outcome curiosity.

Give teams problems, not solutions.

This requires trust, which requires that leadership actually lets go of control. Easier said than done, especially in organisations where executives got promoted by being the person with the answers.

But here’s what I’ve seen work: define the outcome you need, explain why it matters, set the constraints (budget, timeline, technical boundaries), and then get out of the way. Let the team figure out how to get there.

Marty Cagan calls this “empowered teams.” The mechanics matter less than the principle: you’re trusting smart people to solve problems, not treating them as ticket-processing machines.

Use economics to fight back against low-value requests.

When stakeholders come with feature requests (and they will, constantly), you need something better than “that’s not on the roadmap.”

Cost of Delay is useful here. It forces you to quantify: what’s the economic impact of not doing this? And what’s the economic impact of doing it instead of something else?

Not every conversation needs to become a financial model. But being able to say “if we build Feature X instead of Feature Y, we’re leaving approximately £400k on the table this year” is different from saying “I don’t think Feature X is a priority.”

Start small. Create a bright spot.

You probably can’t transform your entire organisation overnight. You might not even be able to transform your entire team. But you can probably run one experiment.

Pick one initiative. Do the discovery work properly. Measure outcomes, not just delivery. See what happens.

If it works, you’ve got evidence. If it doesn’t, you’ve learned something. Either way, you’ve broken the pattern.

The Uncomfortable Truth

I should be honest about something. Closing the strategy-execution gap is harder than any of the advice above makes it sound.

Organisations resist this change because the feature factory, for all its dysfunction, provides certainty. Executives can look at a roadmap and feel like they know what’s happening. Teams can look at a backlog and feel like they know what success looks like. There’s comfort in motion, even purposeless motion.

Outcome-driven work requires living with more ambiguity. You’re not promising to ship Feature X by Q3. You’re promising to move Metric Y, and you’re honest that you’re not sure how yet.

That’s a harder sell. To leadership, to stakeholders, sometimes to your own team.

But the alternative is continuing to build products that don’t matter, celebrating shipments that don’t connect to value, and wondering why the strategy slides still feel like fiction.

The gap between strategy and execution isn’t a one-time fix. It’s a discipline. A practice of constantly asking: “Is what we’re building connected to what we said matters?”

Sometimes the answer is no. And that’s the moment when you get to decide whether you’re going to keep feeding the factory, or start building something that actually works.

Anyway. That’s the thing about feature factories. Nobody wakes up and decides to run one. You just stop asking the questions that would reveal you already are.

As a rule of thumb, a leadership team will spend three months crafting a strategy to let’s say move upmarket. Enterprise customers, higher ASPs, the whole playbook. They will have slides and a lot of conviction. What they rarely will have is a single conversation about what would happen when their best customer success person quit because enterprise deals take nine months and her bonus was tied to quarterly closed deals.

The strategy is fine. The stress test is missing.

Here’s what I mean. You finish the strategy document, send it round for comments, get a few “looks good” replies from people who skimmed it during their commute. Then you jump straight into translating it for product, for sales, for marketing. You write OKRs. You update roadmaps. You create Jira tickets. You’ve gone from strategic intent to tactical execution without checking if the thing can actually survive contact with your organisation.

That gap is where strategies go to die.

The bit everyone skips

Strategy documents assume a clean world. They assume your engineering team will happily pivot from feature work to platform investment. They assume customers will pay more because you’ve decided you’re premium now. They assume your CFO won’t panic when ARR dips for two quarters while you retool.

Reality is more chaotic. Your engineer lead has six months left on her technical debt roadmap and she’s already told her team they can finally fix the authentication system. Your biggest customer is threatening to churn if you don’t build their specific feature. Your board wants growth this quarter, not next year.

The strategy doesn’t fail because it was bad. It fails because nobody checked if it was loadable into your actual context.

This is where stress testing comes in. Not the financial kind, where you check if you can survive a recession. The kind where you deliberately try to break your strategy before you launch it. You poke holes. You surface conflicts. You make the problems visible when they’re still theoretical instead of discovering them six months in when you’re haemorrhaging cash and the exec team is demanding to know what went wrong.

Most teams skip this because it feels negative. You’ve just spent weeks building consensus around a strategy and now you want to... criticise it? Worse, you want to get a room full of people to imagine it failing?

Yes. Exactly that.

What you’re actually looking for

When you stress test a strategy, you’re hunting for three types of problems.

First, the logic gaps. Does this actually make sense? If we move upmarket, do we have the sales infrastructure to close enterprise deals? Do our contracts support multi-year agreements? Can our product handle enterprise security requirements? These are table-stakes questions but they get skipped when everyone’s nodding along to the big vision.

Second, the resource conflicts. Every strategy implies trade-offs but most documents gloss over them. “We’ll focus on enterprise AND maintain our self-serve motion.” Right. With which engineering team? Your five-person product org is already underwater. Something has to give. What gives? And who decides?

Third, the organisational antibodies. Your company has an immune system. It rejects things that don’t fit. If your strategy requires moving slowly and deliberately but your culture rewards shipping fast and iterating, you’ve got a problem. If your strategy needs cross-functional collaboration but your org structure creates silos with conflicting goals, you’ve got a problem.

These aren’t unknowable. They’re predictable. But you have to look.

The pre-mortem that actually works

Forget the complicated frameworks for a minute. The simplest stress test is the pre-mortem. You gather the people who’ll execute the strategy (not just the ones who wrote it) and you tell them this: “It’s 18 months from now. The strategy failed. Completely. Tell me what went wrong.”

I know it sounds grim. It works because it flips the psychology. Instead of defending the strategy, people start spotting risks. Instead of group optimism, you get group paranoia. Which is exactly what you need.

Here’s how to actually run one. Don’t overthink it.

Give people five minutes to write down, privately, why the strategy failed. Actual reasons. Specific failures. “The product couldn’t scale to enterprise loads.” “Sales couldn’t articulate the value prop.” “Marketing got defunded halfway through the rebrand.” “Our best PM quit because they hated enterprise work.”

Then go round the room. Everyone shares one failure scenario. No debate yet, just capture. You’ll notice patterns. Technical risks cluster. Political risks cluster. Market risks cluster.

Now vote. What are the three most dangerous failure modes? Not the most likely (people are terrible at probability). The most dangerous. The ones that would actually kill the strategy.

For those three, you write prevention plans. Not someday. Today. Before you translate the strategy into OKRs or roadmaps. If the biggest risk is “engineering can’t deliver the enterprise features we need”, what’s the mitigation? Do you hire differently? Descope other work? Build in six-month buffer? Partner with someone who has the tech?

The goal isn’t to eliminate risk. You can’t. The goal is to make the trade-offs explicit and manageable rather than implicit and surprising.

When your strategy assumes things it shouldn’t

I ran a pre-mortem once where the top failure scenario was “customer success can’t handle the volume”. The strategy document had us doubling customer count but hadn’t mentioned staffing. When we dug in, turns out finance had already frozen CS headcount. The strategy was relying on an assumption (we’ll hire more CS) that was factually wrong.

We found that in a 60-minute meeting. Imagine finding it six months in, when you’ve already signed the customers and your CS team is drowning.

This is the pattern. Strategies make assumptions. Optimistic ones. The market will respond this way. Competitors will do that. Our team can handle this. Our customers want that. Some assumptions are fine. Some are load-bearing. You need to know which.

Walk through your strategy and list every assumption. Then categorise them. Which ones, if wrong, would tank the whole thing? Those are your load-bearing assumptions. Now test them. Not with research necessarily (though sure, if you can). Test them with the people who’ll actually encounter reality. Ask your sales team if they think customers will pay 40% more for the new positioning. Ask your engineers if they can build the platform features in the timeline. Ask your customer success team if they can support a completely different customer profile.

Listen to their doubt. That’s signal.

The competitor move you’re ignoring

Most strategies have a section on competitive landscape. It’s usually backward-looking. “Here’s what they do today.” Fine. Now tell me what they’ll do when you execute your strategy.

You’re moving upmarket? Your biggest competitor will probably defend that territory. How? Price cuts? Feature parity? Bundling deals? FUD campaigns about your stability? They won’t sit still.

You’re launching a new product line? Someone will copy it or undercut it or tell customers it’s a distraction from your core competence.

You’re changing your pricing model? Your customers will compare you to alternatives under the new model, not just the old one.

This isn’t paranoia. It’s basic game theory. But I see strategies all the time that assume the market is static. It’s not.

The stress test here is war gaming. Get a small group (three to five people) and split them. Half play your company executing the strategy. Half play your main competitor responding. Give them 30 minutes to sketch the moves and countermoves.

You’ll learn things. Like maybe your competitor has deeper pockets and can sustain a price war longer than you thought. Or maybe they’re distracted by their own strategic mess and won’t react at all. Or maybe the real threat isn’t them, it’s a new entrant you haven’t thought about.

The point isn’t to predict the future perfectly. It’s to stress test whether your strategy is robust to different competitive responses or whether it only works if everyone else cooperates.

The resource conversation most are avoiding

Every strategy requires resources. Money, people, time, attention. Most strategy documents hand-wave this. “We’ll need investment in X.” Sure. From where?

Your finance team has a budget. Your product team has a roadmap. Your engineering team has a backlog. Your marketing team has campaigns planned. Your strategy is now asking all of them to pivot. Something has to give.

This is the conversation that makes people uncomfortable. Because it forces prioritisation. Real prioritisation. Not “let’s do both” or “we’ll work harder”. Actual choices.

If you’re moving upmarket, you’re probably deprioritising features for your current mid-market customers. Are you OK with that? Will they churn? How much churn is acceptable? If you’re investing in platform scalability, you’re delaying new product features. For how long? Will that cost you deals?

The stress test here is making the trade-offs explicit before you commit. List what you’re gaining from the strategy. Now list what you’re giving up. Not in abstract terms. In concrete terms. “We’re giving up feature X, which 30% of customers have requested, to build infrastructure that benefits no one directly for six months.”

If you can’t stomach that trade-off, your strategy isn’t real yet.

The cultural friction you’re pretending isn’t there

Strategies often require cultural change. “We need to become more customer-centric.” “We need to move faster.” “We need to be more data-driven.”

Cool. How?

Culture isn’t a switch you flip. It’s reinforced by structure, by incentives, by who gets promoted, by what gets celebrated, by what gets punished. If your strategy requires behaviour change but you haven’t changed the underlying systems, you’re asking for cultural transformation through sheer willpower.

That doesn’t work.

I watched a company try to shift from project-based work to outcome-based work. The strategy was clear. The exec team was aligned. But the bonus structure still rewarded shipping features, not achieving outcomes. Performance reviews still asked “what did you deliver?” not “what impact did you have?” The Jira workflow was still organised by project.

Six months in, everyone had reverted to project-based thinking because that’s what the system rewarded.

The stress test here is asking: what behaviours does this strategy require? Now audit your systems. Do they support those behaviours or fight them?

If your strategy needs cross-functional collaboration but your org chart creates silos with separate goals, that’s friction. If your strategy needs long-term thinking but your OKR cycles are quarterly with no rollover, that’s friction. If your strategy needs experimentation but your culture punishes failed bets, that’s friction.

You can either change the systems or change the strategy. You can’t ignore the friction and hope it resolves itself.

What to actually do this week

Right. Enough theory. Here’s what you can do before your strategy becomes roadmaps and OKRs.

1. Block two hours with your core execution team. Not the strategy authors. The people who’ll have to make this real. Product, engineering, sales, customer success, marketing. Whoever touches the work.

2. Run the pre-mortem. It’s 18 months out. The strategy failed. Why? Capture everything. Vote on the top three killers. Build mitigation plans for those three today.

3. Then test your load-bearing assumptions. List them. Pick the three that, if wrong, would tank the strategy. Figure out how to validate them before you commit significant resources. Maybe it’s a pricing experiment. Maybe it’s a customer interview sprint. Maybe it’s a technical proof of concept. Small, fast tests.

4. Finally, audit one system for cultural friction. Pick the most obvious one. If your strategy needs behaviour X but your incentive structure rewards behaviour Y, that’s your starting point. You don’t have to fix everything. Fix the one that’ll cause the most pain.

This isn’t comprehensive. It won’t catch every risk. But it’ll catch enough to avoid the stupid failures. The ones where everyone looks back and says “we should have seen that coming.”

You should have. You didn’t because you skipped the stress test.

The bit that stays uncomfortable

Here’s what nobody tells you about stress testing strategies. It doesn’t make the strategy better in some clean, satisfying way. It makes it messier. More qualified. More realistic.

You start with a crisp vision. Three priorities. Clear goals. After stress testing, you add caveats. “Unless competitor X responds by cutting prices.” “Assuming we can hire five engineers by Q2.” “Provided customer success can scale with us.”

That feels worse. It is better.

Because those caveats are real. They exist whether you name them or not. Naming them means you can watch for them, plan for them, mitigate them. Ignoring them means you get surprised six months in when reality doesn’t match your document.

Most strategies fail not because they were wrong but because they were brittle. They only worked in one very specific set of conditions that never quite materialised. The ones that survive aren’t necessarily smarter. They’re just more honest about what could break them and they have contingencies.

Stress testing won’t guarantee success. Nothing will. But it’ll help you spot the failures that were always coming. And sometimes that’s enough.

Next time you finish a strategy document and everyone’s nodding along, that’s your signal. The nodding means you haven’t found the conflicts yet. Run the pre-mortem. Find them. Then decide if you still want to run the strategy, or if you need to rewrite it before it rewrites itself in production.

You know that moment in a leadership all-hands when the VP of sorts unveils the new vision with genuine excitement, and you watch the engineering leads’ faces go carefully blank?

That’s the moment.

The one where everyone nods, someone asks a polite clarifying question, and then engineering goes back to their desks to figure out what any of it actually means.

I’ve been on both sides. The silence after those presentations isn’t hostility. It’s a translation lag.

The Thing Nobody Says Out Loud

Product leadership talks in outcomes and market position. Engineering builds in systems and constraints.

This isn’t a bug in how either group thinks - it’s literally their job. But somewhere between “we need to own the mid-market segment” and “ Jira ticket PROD-2847: refactor authentication service,” something gets mangled.

The problem isn’t that product leaders are too abstract. It’s that they’re abstract in ways that don’t map to engineering’s mental model of risk, effort, and technical debt. And engineering isn’t being difficult when they push back on timelines - they’re doing math that product leadership can’t see because the variables live in a codebase that leadership stopped reading three promotions ago.

Here’s what this actually looks like: product announces we’re “becoming the platform of choice for merchant payments.” Engineering hears: massive concurrent user load, probably need to rearchitect the data layer, someone’s going to have to own monitoring, and oh great, we’re definitely not staffed for this.

Nobody’s wrong. But nobody’s connecting either.

Where the Mistranslation Happens

There are three places this breaks down consistently, and I’ve watched it happen at companies from 50 people to 5,000:

The vision stays too high for too long. Leadership lands on a strategic direction - maybe it’s moving upmarket, maybe it’s platform extensibility, maybe it’s AI features because it’s 2025 and everyone’s doing AI. That direction is real and necessary. But it stays conceptual for months while product leadership figures out the go-to-market story, and engineering is left building... what? The stuff that was already on the roadmap. By the time product hands over actual requirements, engineering has spent a quarter reinforcing the wrong parts of the system.

Ownership boundaries are implied, not explicit. Product says “we need this to be reliable at scale” without defining what scale means or who owns the infrastructure work. Engineering assumes product will bring clear acceptance criteria. Product assumes engineering will flag technical concerns early. Both groups are waiting for the other to be more specific, and meanwhile, the kickoff meeting ends with a vague agreement to “align more closely going forward.”

The story format doesn’t translate. Product writes user stories. Engineering needs system stories. A user story describes what a customer experiences. A system story describes what the platform must withstand. “As a user, I want to export my transaction data” is fine for a feature discussion. Engineering needs: expected data volume, acceptable latency, failure modes, dependencies on other services, and what happens when the export takes 40 minutes because someone’s trying to pull three years of transaction history.

This isn’t pedantry. It’s survival. Engineering has seen production break in ways product leadership can’t imagine, and they carry that scar tissue into every planning conversation.

What Engineering Actually Needs to Hear

Let me be specific about the translation layer that works. When product leadership communicates a vision, engineering needs four things they rarely get:

The forcing function. Not just “what we’re building” but “what constraint we’re solving for.” Are we bottlenecked by deployment speed? Customer onboarding friction? Revenue concentration in one customer segment? That constraint tells engineering where the system pressure is building. Without it, they’re guessing which technical problems actually matter to the business.

The boundary conditions. What’s in scope for this quarter versus what’s aspirational for next year? What’s a must-have versus a nice-to-have? And critically: what are we explicitly not doing? Engineering can’t optimise for everything. They need to know which corners they can cut and which ones will get them woken up at 2am six months from now.

The consequences of technical choices. Product leadership rarely understands that architectural decisions made today lock in constraints for years. Engineering needs to surface: “If we build this the fast way, we cap out at 10,000 users and refactoring later costs six months. If we build it to scale, it takes an extra quarter now but we’re clear to 100,000 users.” Product leadership has to make that call. But engineering needs permission to present the tradeoff without sounding like they’re blocking progress.

Who owns the gaps. There’s always unglamorous work between “vision” and “shipped feature.” Data migration. Monitoring. Documentation. Customer comms during downtime. Support tooling. That work doesn’t appear in user stories, but it appears in engineering’s backlog, where it crowds out feature development. Someone needs to own it, and product leadership needs to acknowledge it exists.

Here’s the uncomfortable bit: product leadership often doesn’t want to think about boundary conditions and technical consequences. That’s the messy stuff. The vision is cleaner, more inspiring, easier to present to the board. But if engineering is left to infer the constraints, they’ll infer conservatively - because they’re the ones who get woken up when the system falls over.

The Ownership Problem That Nobody Fixes

There’s a specific pathology that shows up in every company I’ve worked with: product leadership says “we need to move faster,” and engineering hears “we need to cut corners,” and both groups retreat into defensiveness.

What’s really happening: product leadership sees opportunity cost. Every quarter we don’t ship a feature is a quarter a competitor might. Engineering sees technical debt compounding. Every corner we cut now is a week of unplanned work later, and probably during the worst possible time.

Both are right. But the conversation becomes a negotiation over timelines instead of a shared understanding of risk.

The fix isn’t better estimation. It’s shared ownership of the tradeoff. Product leadership needs to say:

“Here’s the market window. Here’s what we’re willing to sacrifice to hit it. Here’s what we’re not willing to sacrifice.”

Engineering needs to say:

“Here’s what breaking in production looks like. Here’s what technical debt we can service later. Here’s what will become unrecoverable.”

Then you make the call together. Not product pushing for faster, not engineering lobbying for perfect. A conscious decision about what you’re optimising for this quarter, with everyone’s eyes open about what it costs.

I’ll be honest: most companies don’t do this. They do a version where product leadership sets the timeline, engineering objects, product leadership doesn’t move the timeline, and engineering builds resentfully while planning for the production incident they know is coming.

How to Spot the Translation Breaking Down

You don’t need to wait for a postmortem to see this pattern. Watch for these signals:

Engineering starts asking a lot of clarifying questions in planning meetings - not hostile questions, just specific ones about edge cases and scale. That’s not them being difficult. That’s them trying to reconstruct the mental model product leadership is working from, because it wasn’t clearly communicated.

Product starts saying “just build the simplest version” more often. That phrase is fine occasionally. When it becomes a refrain, it means product leadership has stopped trusting engineering to make pragmatic tradeoff decisions, and engineering has stopped trying to explain the technical implications because they’ve learned product leadership doesn’t want to hear it.

Roadmap items keep getting pushed because of “technical complexity” that product leadership didn’t see coming. This is the tax you pay for underspecified vision. Engineering discovers halfway through that the feature requires rewriting a core system, and now you’re three months behind.

Engineering brings up technical debt as a blocker, and product leadership treats it like a distraction from “real work.” Technical debt is real work. It’s the accumulated cost of previous tradeoff decisions. If product leadership doesn’t acknowledge it, engineering will eventually stop surfacing it - and start building more cautiously to avoid creating more of it.

A Practical Frame for Better Translation

Here’s what I’ve seen work when both sides commit to it:

Start with the customer problem, not the solution. Product leadership should present: “Here’s the segment we’re losing. Here’s what they’re telling us in churn interviews. Here’s what our competitors offer that we don’t.” Engineering can pattern-match that to technical capabilities and flag where the system has gaps. This conversation is vastly more productive than “we need to build a dashboard” without context about why or for whom.

Run lightweight technical discovery in parallel with product discovery. Don’t wait until product has a fully baked spec to involve engineering. Bring engineering into early customer conversations. Let them hear the pain directly. Then give them two weeks to spike the technical approach while product is refining the requirements. By the time you’re ready to commit to a roadmap, both groups are working from the same understanding of scope and risk.

Write stories that describe the system’s job, not the user’s job. User stories are useful for product thinking. But when you hand work to engineering, reframe it: “The system must support 500 concurrent exports without degrading performance for other users.” That’s a requirement engineering can test, estimate, and commit to. “As a user, I want to export data” isn’t specific enough to build against.

Make capacity allocation visible and shared. If your engineering team spends 40% of their time on technical debt and operational work, product leadership needs to see that in the roadmap. Not as a complaint, but as a fact about team capacity. That 40% isn’t negotiable unless you’re willing to accept production instability. Once product leadership understands the actual capacity for feature work, timeline conversations get more realistic.

Review technical decisions together. When engineering proposes an architectural change, product leadership should be in the room. Not to approve the technical details - they don’t need to understand the database internals - but to understand the business implications. “This will take an extra month, but allows us to expand into Europe without a second rewrite.” That’s a business decision, not a technical one. Product leadership should make it.

What You Can Try Tomorrow

If you’re product leadership: go ask your engineering lead what technical debt is blocking them. Not in a planning meeting - in a 30-minute conversation where they can be candid. Listen without proposing solutions. Your goal is to understand what they’re managing that doesn’t show up in your roadmap. Then ask: “If we gave you one quarter to fix the biggest problem, what would it be and what would it unlock?”

If you’re engineering leadership: write a one-page doc for your product leader that maps their vision to technical capability gaps. Be specific. “To own mid-market, we need: SSO, role-based permissions, 99.9% uptime SLA, and support for 10x current data volume. We have: none of those. Estimated effort: 9 months with the current team.” Don’t couch it in apologies or hedging. Just state the gap.

If you’re in the middle of this - senior PM, tech lead, someone straddling both worlds: you’re the translator whether you want to be or not. Start writing decision docs that force both groups to get specific. “What are we building? Why now? What happens if we delay? What breaks if we rush?” Four questions, answered jointly, before a single ticket gets written.

The Thing That Remains Unresolved

The fundamental tension is still here. Product leadership is paid to see around corners and push for speed. Engineering is paid to keep the system running and think in decades. Those incentives don’t naturally align.

But they also don’t have to be at odds. The companies that do this well treat the gap between vision and implementation as a shared problem, not a blame loop. They assume both groups are competent and acting in good faith. They make tradeoffs explicit instead of letting them emerge as surprises three months into a project.

Most companies don’t do this. They do a version where product leadership presents a vision, engineering builds what they think was meant, and six months later everyone’s frustrated because the thing that shipped doesn’t quite solve the problem product had in mind.

The silence after those all-hands presentations? That’s your signal. If engineering isn’t asking hard questions immediately, it’s not because they understand. It’s because they’ve learned that asking won’t change the timeline, so they’ll just build something and hope it’s close enough.

You can fix that. But only if both groups admit the translation layer is broken.