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.

There’s a feature in a product I use that was deprecated in 2019. The sunset notice is still there. The feature still works. It’s been five years.

I asked someone on that team what happened. They laughed in a way that suggested I’d touched something painful.

“Three enterprise customers threatened to leave,” they said. “One of them knew our CEO personally.”

And that was that. The deprecation notice became a permanent fixture, a small monument to the gap between product strategy and organisational reality.

The Seductive Logic of Sunsetting

The case for aggressive deprecation is compelling on paper. Every feature you maintain is a tax on everything else. Bug fixes. Security patches. Documentation. Support tickets. Cognitive load for new users trying to understand why there are three ways to do the same thing.

Marie Kondo for product management: if it doesn’t spark value, thank it for its service and let it go.

I’ve sat through portfolio reviews where we identified features used by less than 2% of the user base consuming 15% of engineering maintenance time. The maths is obvious. The strategic recommendation writes itself.

“We should sunset this” is one of the easiest sentences to say in product management. Actually doing it is something else entirely.

The product management literature loves this topic. Ruthless prioritisation. Simplification as strategy. The discipline to say no, or in this case, to say “not anymore.” It sounds so clean.

What Happens When You Try

Here’s what the literature doesn’t adequately cover: the phone call.

You know the one. Three days after you announce the deprecation timeline, someone from the customer success team messages you. “Can we chat?” And you know before you even join the call that your carefully reasoned sunset plan is about to collide with commercial reality.

“So, Acme Corp uses this feature as the core of their workflow. They’ve built their entire process around it. And they’re up for renewal in two months.”

I’ve had this exact conversation maybe a dozen times across different companies. The details change. The dynamic doesn’t.

The strategy said: reduce maintenance burden, simplify the product.

The execution reality says: this feature is load-bearing for a customer paying us £400,000 annually.

The Translation Layer Failure

This is a classic strategy-execution gap, but not the kind people usually talk about. The strategy isn’t wrong. The execution team isn’t incompetent. The failure is in the translation layer, the space where high-level product direction meets commercial relationships, political dynamics, and the specific humans whose jobs depend on things staying exactly as they are.

Nobody in the strategy conversation modelled for the sales director who sold the feature as a differentiator. Nobody accounted for the VP of Customer Success whose bonus is tied to retention. Nobody mapped the three product managers before you who each tried to deprecate this same feature and quietly gave up.

The feature persists not because anyone thinks it’s valuable, but because the cost of removing it is distributed across too many stakeholders, each of whom can independently veto the decision.

Legacy features often survive not because they’re loved, but because killing them requires more political capital than anyone is willing to spend.

The Vocal Minority Problem

And then there are the users themselves.

Product managers learn quickly that usage data and user sentiment are different things. A feature used by 2% of your base might be used by the most vocal, most engaged, most likely-to-write-an-angry-tweet segment of that base.

Slack learned this when they tried to deprecate IRC and XMPP gateways. The actual usage numbers were tiny. The response from technical users was volcanic. They reversed course, then eventually did deprecate it, but the process took years longer than the usage data suggested it should.

The uncomfortable pattern: the users most dependent on legacy features are often your earliest adopters, your most technically sophisticated customers, the people who built workflows around your product before you’d figured out what it was supposed to be.

They’re also frequently the people who talk to other potential customers. Who write the blog posts. Who speak at conferences.

Sunsetting a feature they depend on isn’t just removing functionality. It’s signalling that their loyalty and investment in your product doesn’t protect them from your changing priorities.

The Honest Calculation

Here’s what I’ve learned, somewhat painfully: deprecation decisions are almost never actually about maintenance costs.

Or rather, maintenance costs are the stated justification, but the real calculation is political. Can we absorb the backlash? Do we have executive air cover? Is the customer success team going to fight us? Will sales blame us when renewals get harder?

The teams that successfully sunset features aren’t necessarily the ones with the best data or the cleanest product strategy. They’re the ones where product leadership has accumulated enough trust and political capital to weather the inevitable resistance.

I watched a PM at a growth-stage startup try to deprecate a feature that was objectively causing problems. Support tickets. Performance issues. Constant edge-case bugs. Every metric said it should go.

She built the case. She socialised it. She got approval.

Then a board member mentioned in passing that their portfolio company used that feature. Deprecation cancelled. No discussion.

What Actually Works (Sometimes)

The few successful deprecations I’ve seen share some common patterns.

First, they’re positioned as migrations rather than removals. “We’re moving you to something better” lands differently than “we’re taking this away.” Intercom did this well when they consolidated their product lines. Not “we’re killing this” but “we’re bringing you into the unified platform with new capabilities.”

Second, they involve absurd amounts of hand-holding. Not email announcements. Actual phone calls. Migration support. Dedicated resources. The cost of doing deprecation well often approaches the cost of just maintaining the feature, at least in the short term.

Third, and this is the one nobody wants to hear, they require someone senior enough to absorb the political damage. Deprecation needs air cover. Without executive sponsorship that won’t evaporate at the first complaint, you’re just creating a backlog item that will sit there for five years with a sunset notice that everyone ignores.

The Tension That Remains

I don’t have a satisfying resolution here. The strategic case for aggressive sunsetting is real. The maintenance burden is real. The product complexity is real.

But so is the political economy of established features. So is the asymmetry between concentrated pain for the users who lose something and diffuse benefit for everyone else. So is the career risk for the PM who picks the wrong fight.

Maybe the honest framing isn’t “PMs must ruthlessly sunset features” but “PMs must build the organisational conditions that make sunsetting possible.” That’s slower. Less satisfying. Harder to put in a strategy deck.

But at least it acknowledges what’s actually happening.

That deprecated feature from 2019? Still there. Still working. The notice says it’ll be removed “in a future release.”

I’m starting to think that’s the most honest thing about it.

I was reviewing a team’s sprint history last month, looking for patterns in their velocity fluctuations. They had a stated policy: 20% of every sprint goes to non-functional work. Security hardening. Performance improvements. Compliance requirements. The foundational stuff.

Over twelve sprints, the actual allocation averaged 6%. And that 6% happened almost entirely in two sprints where an external audit was imminent.

When I asked the engineering lead about it, she just shrugged. “Features always win.”

The Theory Everyone Agrees With

The strategic argument for dedicated non-functional capacity is solid. This work is like maintaining your car’s engine. Skip it long enough and you’re not just risking a breakdown; you’re guaranteeing one. Compound interest works in reverse too.

Security debt accumulates until you’re explaining a breach to customers. Performance degradation creeps until your app is noticeably slower than competitors. Compliance gaps widen until a regulation change catches you exposed.

The 20% rule, or whatever percentage your organisation uses, exists because leaders recognise that leaving this work to “when we have time” means it never happens. Protected capacity. Predictable allocation. The adults in the room being responsible.

Protected capacity for non-functional work is a strategy for avoiding future crises. The problem is that avoiding crises is invisible work.

Every VP of Engineering I’ve talked to endorses some version of this principle. It shows up in team working agreements. It gets mentioned in sprint planning. It sounds so reasonable.

What Actually Happens

Here’s the pattern I’ve watched play out at maybe fifteen different companies now.

Sprint planning starts. The 20% allocation is acknowledged. Then someone mentions the feature that sales promised a customer. Or the executive dashboard that leadership wants by end of quarter. Or the integration that a partner is waiting on.

Suddenly the conversation shifts. “Can we push the security work to next sprint? We’re so close on this feature.” And because the security work doesn’t have a customer name attached to it, doesn’t have a sales rep in the room advocating for it, doesn’t have a deadline that triggers visible consequences... it yields.

Next sprint, the same thing happens. And the sprint after that.

The 20% becomes 10% becomes “we’ll do a dedicated infrastructure sprint later” becomes a vague line item on a roadmap that never quite arrives.

The non-functional work only resurfaces when it becomes a blocker. An enterprise prospect requires SOC 2 compliance before signing. Page load times cross a threshold where users start complaining. A security scan fails and delays a release.

Now it’s urgent. Now it gets priority. Now everyone’s scrambling.

The Translation Layer Breakdown

This is a strategy-execution gap, but it’s a specific kind. The strategy isn’t poorly conceived. The execution teams aren’t ignoring it maliciously. The breakdown happens in the translation layer, where abstract commitments meet concrete sprint decisions.

“20% for non-functional work” is a policy. But policies don’t make tradeoff decisions in sprint planning. People do. And those people are sitting in a room where the feature work has names, faces, and consequences attached to it, and the infrastructure work is a line item that says “ongoing security improvements.”

The feature has a champion. The non-functional work has a category.

I’ve seen teams try to fix this by assigning ownership. A “platform PM” or “infrastructure lead” who advocates for this work the same way a product PM advocates for features. It helps. But it also just shifts the political dynamic. Now you have two people arguing for capacity instead of one work category being implicitly junior to another.

The work that prevents problems will always struggle against the work that creates visible value. Prevention is invisible until it fails.

The Black Box Problem

Here’s where it gets properly frustrating. When non-functional work does happen, it often becomes illegible to the rest of the organisation.

“What did the platform team do last sprint?” “Infrastructure improvements.” “What does that mean?” Silence, or an explanation so technical that everyone’s eyes glaze over.

This isn’t the engineers’ fault. Explaining why you refactored the authentication service to reduce latency by 40 milliseconds is genuinely hard to translate into business value. It’s real work. It matters. But it doesn’t demo well.

So the work becomes a black box. Capacity goes in, something presumably happens, and unless there’s a visible outcome, the investment feels abstract. This makes it even harder to protect that capacity next sprint. Leadership starts asking why the platform team needs four engineers when nobody can articulate what they delivered.

The teams that handle this well have learned to make infrastructure work visible. Dashboards showing performance trends. Security scorecards. Compliance checklists with progress indicators. Not because the work wasn’t valuable before, but because value that can’t be seen can’t be defended.

The Uncomfortable Middle Position

I’ve gone back and forth on where I land here.

Part of me thinks the “only when it unblocks revenue” approach is actually honest. It acknowledges that organisations have limited capacity and competing priorities. It forces infrastructure work to justify itself against concrete outcomes rather than abstract principles. It prevents the platform team from becoming a comfortable backwater where engineers do interesting technical work that doesn’t connect to business reality.

Spotify went through a version of this. Their platform teams were given significant autonomy, which led to impressive technical infrastructure but also some work that was, charitably, gold-plating. They’ve since moved toward models where infrastructure investment ties more directly to product needs.

But I’ve also watched the “only when urgent” approach create genuinely dangerous situations. A company I advised deferred security work for eighteen months because it never quite rose to the top of the priority list. Then they had an incident. The remediation cost was roughly 50x what the prevention would have been, and that’s before counting the customer trust they lost.

The 20% rule might be a useful fiction. But fictions that prevent disasters have value, even if they’re not perfectly efficient.

The Question Nobody Wants to Answer

Maybe the real issue is that we’re trying to solve a political problem with a capacity planning framework.

The 20% rule assumes that the obstacle is scheduling. That if we just allocate the time, the work will happen. But the obstacle is usually incentives. Feature delivery gets celebrated. Infrastructure work gets a polite nod at best. Performance reviews reward visible impact. Invisible prevention doesn’t make careers.

Until that changes, protected capacity will keep eroding sprint by sprint, and teams will keep lurching from normalcy to crisis mode when the deferred work finally catches up with them.

I don’t know how to fix the incentive structure. I’m not sure anyone does.

But I’m increasingly convinced that the 20% conversation is happening at the wrong level of abstraction. We’re arguing about sprint allocation when we should be asking why the work needs protection in the first place.

The answer to that question is uncomfortable enough that most organisations would rather just keep debating percentages.

I sat through a post-mortem last year where a team spent ninety minutes documenting why a feature launch had gone sideways. Root causes identified. Action items assigned. Lessons learned captured in a Notion doc that would never be opened again.

Three months later, same team, different feature, nearly identical failure mode.

When I asked whether the previous post-mortem had surfaced this risk, someone pulled up the document. There it was, on page two: “Risk of insufficient QA coverage in edge cases.” Action item: “Improve test coverage.” Status: “In progress.”

The team had done the post-mortem. They’d identified the problem. They just hadn’t actually changed anything.

The Pre-Mortem Promise

Gary Klein introduced the pre-mortem concept in the late 1990s, and it’s elegantly simple. Before you launch, before you commit, gather the team and ask: “Imagine we’re six months in the future and this project has failed. What went wrong?”

The psychology is clever. Prospective hindsight, as researchers call it, increases people’s ability to identify reasons for outcomes by about 30%. Asking “what could go wrong” triggers defensive optimism. Asking “what did go wrong” unlocks different cognitive pathways.

The strategic argument for pre-mortems is compelling. You surface risks while there’s still time to mitigate them. You give permission for skepticism in a culture that often rewards false confidence. You create a structured moment for the person who’s been quietly worried to actually voice that worry.

The pre-mortem’s value isn’t prediction accuracy. It’s permission to speak before speaking becomes criticism.

I’ve run pre-mortems that genuinely changed project trajectories. A team about to launch a pricing change realised they hadn’t modelled how existing customers on annual contracts would react. An infrastructure migration surfaced a dependency nobody had mapped. These weren’t exotic risks. They were obvious in retrospect, but nobody had created space to articulate them.

The Post-Mortem Reality

But here’s what pre-mortem advocates sometimes gloss over: you cannot actually know why something failed until it fails.

Pre-mortems surface the risks people can imagine. Post-mortems reveal the risks that actually materialised, which are frequently not the same thing.

I’ve watched teams run thorough pre-mortems that identified fifteen potential failure modes, then fail for a sixteenth reason nobody anticipated. The pre-mortem created false confidence. “We thought about this carefully. We identified the risks.” But the thing that killed them wasn’t on the list.

Knight Capital’s famous 2012 trading disaster is instructive. They lost $440 million in 45 minutes due to a deployment error that reactivated old code. No pre-mortem would have surfaced “someone will deploy to seven servers instead of eight, leaving legacy code active on one machine.” The failure mode was too specific, too contingent on a particular sequence of human decisions.

The post-mortem, by contrast, could trace exactly what happened. And that tracing revealed systemic issues, deployment processes that allowed partial rollouts, insufficient monitoring, inadequate rollback procedures, that a pre-mortem might have gestured toward but couldn’t have specified.

Pre-mortems imagine failure. Post-mortems dissect it. These are not the same skill, and they don’t produce the same insights.

The Translation Problem

Here’s where I think both camps get stuck.

The pre-mortem is a strategy tool. It operates in the realm of possibility, of adjustable plans, of risks that can still be mitigated. It’s forward-looking and generative.

The post-mortem is an execution archaeology tool. It operates in the realm of what actually happened, of specific decisions and their consequences, of reality rather than projection.

The strategy-execution gap shows up when organisations treat these as interchangeable or, worse, as competing approaches. “We do pre-mortems now, so we don’t need post-mortems” misunderstands what each one offers.

The translation layer failure is subtler. Pre-mortems identify risks, but translating “identified risk” into “changed behaviour” requires something more than documentation. It requires someone to actually do something different. And post-mortems identify causes, but translating “identified cause” into “systemic change” faces the same gap.

Both rituals can become theatre. The pre-mortem where everyone lists risks that get captured and ignored. The post-mortem where everyone agrees on root causes that never get addressed. The document exists. The learning doesn’t transfer.

What Actually Distinguishes Useful Practice

I’ve been trying to figure out what separates teams that genuinely learn from failure from teams that just perform the rituals.

The pattern I keep noticing: it’s not about which method they use. It’s about whether anyone has authority to act on what emerges.

A pre-mortem that surfaces a risk nobody can address is just anxiety documentation. “We might not have enough QA coverage” means nothing if there’s no capacity to add QA coverage. The exercise becomes a way to say “we told you so” later rather than a way to change outcomes.

Similarly, a post-mortem that identifies root causes nobody will fix is just collective grief processing. Useful for morale, maybe, but not for learning.

The teams I’ve seen get value from these practices are the ones where the facilitator can ask: “Okay, we’ve identified this risk. What are we actually going to do about it? Who decides? What’s the timeline?” And then someone in the room has the authority to answer.

Amazon’s post-mortem process reportedly works partly because it escalates to people who can actually authorise systemic changes. It’s not a team exercise in reflection. It’s an input to decision-making at a level where decisions get implemented.

The Uncomfortable Synthesis

I’ve gone back and forth on which matters more.

Pre-mortems feel proactive. They position learning as forward-looking, optimistic even. We’re smart enough to anticipate problems. We’re mature enough to voice concerns. We’re capable of adjusting before it’s too late.

Post-mortems feel reactive. Something broke. We’re doing the responsible thing by understanding why. But there’s always a slight flavour of closing the barn door.

Actually, that framing is probably wrong. It’s not about which is more valuable in the abstract. It’s about which constraint your organisation actually faces.

Some teams fail because they don’t create space for pre-launch skepticism. The roadmap is the roadmap. Concerns are career-limiting. The pre-mortem addresses a real gap for these teams.

Other teams fail because they don’t do rigorous causal analysis after things go wrong. They have opinions about what happened, but nobody traces the actual sequence of decisions. The post-mortem addresses a different real gap.

And some teams, honestly, do both rituals and learn from neither because the findings don’t connect to anyone with authority to act.

The Question Worth Sitting With

Maybe the distinction between pre-mortems and post-mortems matters less than a different question: does your organisation actually change based on what it learns?

I keep meeting teams that have elaborate learning rituals and no learning. The documents exist. The processes run. Nothing changes.

And occasionally I meet teams with barely any formal process that genuinely adapt based on experience. They don’t write post-mortems. They just... fix things when they break, and adjust plans when risks surface.

The ritual isn’t the learning. The ritual is just a container that might enable learning if the organisational conditions are right.

Whether you imagine failure beforehand or dissect it afterward, the question is the same: will anyone do anything differently as a result?

I’m not sure the answer depends on which ritual you choose.

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’ve been trying to find case studies. Real ones. Companies that built something meaningful on a low-code platform, scaled it, maintained it, and are still running it profitably three years later.

The silence is deafening.

What I find instead are launch stories. “I built this in a weekend” threads. Revenue screenshots from month two. Then nothing. The accounts go quiet. The products disappear. The indie hacker moves on to the next thing.

This pattern tells you something important about what’s actually being sold here.

The shovel economics

There’s a reason the people who got rich during the California gold rush were mostly selling pickaxes and denim. The miners, by and large, went broke. The infrastructure providers made fortunes.

Low-code platforms are having their shovel moment. Bubble, Webflow, Glide, Softr, the entire ecosystem is growing at rates that would make a SaaS investor weep with joy. But the success stories from the people using these tools? They’re suspiciously thin on the ground.

I talked to someone at a low-code platform company last year. Off the record, obviously. They admitted that their best customers weren’t building products. They were building internal tools, prototypes, landing pages. Things that didn’t need to scale. Things that didn’t need to work perfectly every time.

“The platform grows when the dream grows. The dream doesn’t require the product to actually work at scale.”

That’s not a criticism of the platforms themselves. It’s an observation about what’s really driving the growth. And it’s not sustainable product companies being born.

Building was never the bottleneck

Here’s what keeps getting glossed over in the low-code narrative. Building a website has been effectively free since about 2004. WordPress, Squarespace, Wix. The tools existed. The templates existed. The hosting was practically free.

And yet most businesses still failed.

Because the bottleneck was never “can I build a website.” It was “do I have a business case that works.” It was customer acquisition. It was unit economics. It was figuring out whether anyone actually wanted the thing you were building.

Low-code doesn’t solve any of that. It just makes the building part faster. Which means you get to the part where you discover nobody wants your product slightly sooner. That’s not nothing, but it’s not what’s being advertised.

The marketing around these platforms sells capability as if it were outcome. “Build your SaaS in a weekend.” Sure. But the building was never the hard part.

The maintenance problem

I keep thinking about SLAs. About contracts with penalty clauses. About users on annual subscriptions who expect the thing to work.

Who fixes the vibe-coded creation when it breaks at 2am?

There’s a particular brittleness to low-code applications that becomes obvious the moment you need to debug something non-trivial. The abstraction that made building fast becomes the abstraction that makes fixing slow. You’re not looking at code you wrote. You’re looking at code the platform generated, filtered through a visual interface that may or may not expose what’s actually happening underneath.

I watched a founder spend three days trying to figure out why their app was timing out for users in certain regions. The answer was buried in how the platform handled database queries, something they had no direct control over and limited visibility into.

This is fine for prototypes. It’s fine for internal tools. It’s even fine for side projects with forgiving users.

It’s not fine when you’ve sold enterprise contracts with uptime guarantees.

“The speed you gain building is the speed you lose debugging.”

The fantasy of the one-person unicorn

There’s something almost predatory about how low-code success is marketed to solo founders. The message is relentless: you should be hitting a million in ARR within months. If you’re not, you’re doing it wrong. Your vibe-coded AI wrapper just needs better marketing. More Twitter threads. A different template.

The reality is that sustainable software businesses require sustained effort across multiple disciplines. Product development, yes, but also customer support, sales, operations, legal, accounting. The tools don’t solve for any of that. They just remove one (relatively small) obstacle from a path that has dozens.

I’m not saying solo founders can’t build real businesses. Some do. But the narrative that low-code enables this at scale is looking increasingly like survivorship bias dressed up as strategy. We see the rare wins. We don’t see the thousands of abandoned projects, the failed launches, the founders who burned out trying to support an application that was never designed to be supported.

The enterprise question

Here’s what I can’t stop wondering about. If these platforms are genuinely capable of building scalable, maintainable software, why aren’t enterprises buying them?

Not for internal tools. Enterprises do use low-code for that. I mean for actual product development. For the software they sell to customers. For the systems that run their business.

The answer, I think, is that the people with deep pockets and real requirements looked at low-code and saw exactly what it is: a tool for speed, not for scale. A way to validate ideas, not to build lasting infrastructure.

Corporations have IT departments and procurement processes and security reviews for a reason. They’ve learned, often painfully, that the thing that’s easy to build is often expensive to maintain. That technical debt compounds. That abstractions leak at the worst possible moments.

Where this probably ends

I don’t think low-code goes away. The platforms will survive. Some will thrive. The use cases that actually fit, internal tools, prototypes, simple workflows, those are real and valuable.

But the growth rates? The breathless projections? The “future of software development” rhetoric?

That cools off. It has to. Because eventually the market figures out that building was never the bottleneck, and the companies that succeed are the ones that solved the harder problems. The business model problems. The customer problems. The “why would anyone pay for this” problems.

The shovels keep selling for a while longer. The gold, as always, remains elusive.

I’m still looking for those case studies, though. Three-year-old low-code products with real revenue, real users, real operational maturity. If you’ve got one, I genuinely want to see it.

The silence continues to tell me something.

I sat in a quarterly review last month where a PM was grilled for twenty minutes about why revenue was flat. Not product metrics. Not user behaviour. Not adoption curves. Revenue.

She didn’t set the pricing. She didn’t control the sales team’s targets. She didn’t approve the marketing spend. She couldn’t hire engineers to ship faster. But she was accountable for the number on a spreadsheet that resulted from all those things she couldn’t touch.

This is happening everywhere now. And I think we need to talk about how broken it is.

The accountability without authority problem

Here’s the pattern I keep watching unfold. Company decides PMs should be “more business-oriented.” Leadership reads a blog post about product-led growth or sees a job description from Stripe. Suddenly PMs are expected to own P&L, build financial forecasts, set pricing strategy, and project revenue with the confidence of someone who actually controls any of those variables.

Except they don’t control them. Sales has their own targets and incentives. Marketing allocates budget based on their own priorities. Finance sets pricing constraints. Engineering capacity is negotiated, not granted. The PM sits in the middle of this, responsible for an outcome that emerges from a system they can influence but never direct.

“Ownership without authority isn’t empowerment. It’s a setup.”

I’ve seen this movie three times at different companies. It ends the same way. The PM either burns out trying to control the uncontrollable, or learns to play a sophisticated blame-deflection game that helps no one. Neither outcome makes the product better.

Revenue is a trailing indicator of doing the right things

This is the part that keeps getting lost. Revenue doesn’t come from focusing on revenue. Revenue comes from solving real problems for users in ways they’ll pay for. It comes from reducing friction in activation. It comes from building features that increase retention. It comes from finding the pricing model that aligns value delivered with value captured.

These are product problems. They involve understanding user behaviour, running experiments, making bets, learning from failures. They require patience and iteration and occasionally accepting that the thing you built isn’t working.

None of that maps cleanly to a quarterly revenue forecast.

When you make PMs accountable for revenue directly, you create an incentive to optimise for revenue directly. Which sounds sensible until you watch what happens. Dark patterns in onboarding. Aggressive upsells that damage trust. Features built for the pricing page rather than for users. Short-term wins that erode the foundation you’re standing on.

I worked with a team once that hit their revenue targets for six straight quarters while their NPS cratered. They were technically succeeding while systematically destroying the product’s future. The metrics said growth. The users said goodbye.

The cancer cell problem

There’s a quote I keep coming back to. “Growth for the sake of growth is the ideology of the cancer cell.” I think about this every time someone asks a PM to justify a product decision purely in revenue terms.

Not everything valuable shows up in this quarter’s numbers. Some things matter because they build trust. Because they reduce support load. Because they make the product more resilient. Because they create optionality for future directions you can’t predict yet.

Technical debt reduction doesn’t have a revenue line item. Neither does accessibility work. Neither does the refactor that makes the codebase maintainable for the next five years. These are investments in sustainability, and they’re invisible to a P&L mindset.

“The best product decisions often look like bad business decisions in the quarter you make them.”

When PMs are forced to justify everything through revenue, this kind of work becomes impossible to prioritise. You get a product that’s optimised for extraction rather than value creation. That works until it doesn’t.

What PMs should actually own

Here’s where I land on this, and I’ll admit I’m still working it out.

PMs should own outcomes. Specific, measurable, user-centric outcomes. Activation rates. Retention curves. Task completion. Time to value. The metrics that indicate whether the product is actually solving the problem it claims to solve.

Revenue is downstream of these things. If you’re moving the right outcome metrics, revenue follows. If you’re not, no amount of financial forecasting will save you.

This means PMs need to be skilled at identifying which metrics actually correlate with revenue. That’s a real capability, and it’s undervalued. The PM who can say “if we improve day-7 retention by 5%, here’s what that means for LTV” is doing more valuable financial work than the PM who’s building spreadsheets full of projections they can’t actually influence.

But it also means PMs need permission to focus on those leading indicators rather than being held directly accountable for the trailing ones. That requires leadership to understand the difference. Which, increasingly, they don’t seem to.

The resourcing gap nobody mentions

There’s another dimension to this that gets conveniently ignored. If you want PMs to own revenue, they need resources to influence it. Headcount. Budget. Authority to make pricing changes. Access to sales and marketing data. The ability to run experiments without six layers of approval.

Most PMs have none of this. They’re expected to own revenue while requesting permission to change a button colour.

I talked to a PM last week who’s accountable for a £2M revenue target. She has three engineers, shared with another product. She can’t adjust pricing without a six-week legal review. She can’t see the sales pipeline. She can’t influence marketing spend.

What exactly is she supposed to do? Will really hard?

The question I keep asking

If PMs are going to own revenue, then give them the actual authority to influence it. Let them set prices. Let them control budget. Let them hire. Let them fire. Make them mini-GMs with real power.

But if that’s not on the table, and it usually isn’t, then stop pretending that putting revenue on their OKRs is anything other than accountability theatre. It’s a way for leadership to distribute responsibility without distributing power. It protects executives when numbers are missed. It does nothing else.

I don’t know how to fix this systemically. The trend seems entrenched. The job descriptions keep demanding P&L experience. The interview questions keep focusing on revenue impact.

Maybe the answer is for PMs to get better at pushing back. At articulating why outcome ownership is more valuable than revenue ownership. At making the case for leading indicators over trailing ones.

Or maybe the answer is that the role is being redefined into something it was never meant to be, and those of us who care about products need to find a different title.

I’m not sure yet. But I know the current setup isn’t working. The PMs I talk to are exhausted, playing a game where the rules keep changing and the scorecard measures things they can’t control.

That’s not product management. That’s organisational theatre with extra spreadsheets.

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.

There’s a moment in every product audit where you find the feature. The one that took a quarter to build, that nobody uses, that solves a problem the team assumed existed but never actually verified.

Every company has at least one. Most have dozens.

I was reviewing a product’s analytics last month and found a reporting module that had taken four engineers three months to ship. Usage data showed eleven people had opened it in the past year. Eleven. Two of them were the PM and the designer who built it.

When I asked about the discovery work behind it, I got a familiar answer. “We had customer requests.” Which, when I pushed, turned out to be two enterprise clients who mentioned it in passing during renewal calls. Nobody had validated whether reporting was actually the problem. Nobody had checked if those two clients represented a broader need. Nobody had tested whether the solution they were building would even address what those clients meant.

This is discovery debt. And it’s everywhere.

The compound interest problem

Technical debt gets talked about constantly. Everyone understands the concept. You take shortcuts in code, they accumulate, eventually you pay them back or the system collapses under its own weight.

Discovery debt works the same way, but it’s harder to see. Every feature you ship without validating the problem creates a liability. Every assumption you encode into your product without testing it adds weight. Every bet you make based on intuition rather than evidence compounds.

The difference is that technical debt shows up in your codebase. Discovery debt shows up in your retention curves, your support queues, your feature adoption metrics. It’s diffuse. It’s delayed. By the time you notice it, you’re three years into a product full of things nobody wanted.

“Technical debt slows down your engineering. Discovery debt means you’re efficiently building the wrong things.”

I’ve started asking teams a simple question: for each major feature you shipped last year, can you show me the research that informed it? The win rate is troubling. Maybe one in five can produce anything beyond “we had a hypothesis” or “customers were asking for it.”

The backlog graveyard

Here’s where it gets uncomfortable. Go look at your backlog. Not the active stuff. The bottom. The tickets that have been sitting there for eighteen months, slowly sinking under the weight of newer priorities.

That’s your discovery debt made visible.

Every one of those items represents something someone thought was important enough to capture but nobody thought was important enough to validate. They accumulate. They create a false sense of completeness. They make your roadmap planning slower because you’re constantly scrolling past ghosts of ideas past.

But the real debt isn’t in the backlog. It’s in what you already shipped.

I worked with a team that had a feature set they called “the museum.” Twelve interconnected capabilities that had been built over two years, used by almost nobody, but so entangled with the core product that removing them would take longer than building them did. They were paying maintenance costs, cognitive load costs, onboarding complexity costs, all for features that existed because someone once had a hunch.

The debt wasn’t the backlog items they hadn’t built. It was the shipped features they couldn’t remove.

The quantification trap

There’s a growing movement to measure discovery debt the way we measure technical debt. Story points of unvalidated assumptions. Risk scores on shipped features. Confidence intervals on roadmap items.

I understand the impulse. If you can’t measure it, you can’t manage it. Finance wants numbers. Leadership wants dashboards. “We have discovery debt” doesn’t get budget approved. “We have 847 story points of unvalidated assumptions representing £2.3M in potential rework” might.

But I’m sceptical of this approach. Discovery debt isn’t really quantifiable in meaningful terms. How do you assign a number to “we don’t actually know if users need this”? How do you score the risk of a feature that might be fine or might be fundamentally misconceived?

“Not everything that counts can be counted. Discovery debt is one of those things.”

The attempt to quantify often becomes a distraction from the actual work. Teams spend weeks building frameworks for measuring debt instead of doing the discovery that would reduce it. The spreadsheet becomes the deliverable.

What I’ve seen work better is simpler. Flag the shipped features with lowest adoption. Identify the upcoming roadmap items with weakest evidence. Make a list. Start at the top. Do the research you should have done before building.

Less satisfying than a dashboard. More likely to help.

The ownership vacuum

Here’s the question that’s causing the most friction: who fixes this?

Product managers created much of the debt by shipping without validating. But they were often responding to pressure from leadership who wanted velocity over rigour. And they were working within systems that rewarded output over outcomes.

UX researchers, where they exist, might seem like natural owners. But most discovery debt predates their involvement. And asking research to audit and remediate years of PM decisions creates organisational tension that helps nobody.

Engineering increasingly wants a seat at the discovery table. Fair enough. But they’re also the ones being asked to maintain the features that shouldn’t have been built, which creates a different kind of frustration.

I’ve watched this debate consume entire quarters. The energy spent arguing about ownership is energy not spent actually reducing debt.

My view, for what it’s worth, is that discovery debt is a team sport to fix even if it wasn’t a team sport to create. The PM who shipped the unvalidated feature two years ago might not even work there anymore. The researcher who could have caught it might not have been hired yet. Assigning blame is satisfying but useless.

What matters is whether you’re going to keep accumulating or start paying down. That’s a decision for the whole product team, owned by whoever has the authority to protect time for it.

The uncomfortable truth

Here’s what nobody wants to say. Most products have so much discovery debt that addressing it properly would mean admitting that large portions of what exists shouldn’t.

That’s organisationally terrifying. Careers were built on those features. Promotions were earned shipping them. OKRs were hit. The sunk cost fallacy has tenure.

So teams do a softer version. They commit to “doing more discovery going forward” while leaving the existing debt untouched. They validate new features while ignoring the validated-by-nobody features already in production.

This is better than nothing. But it’s not fixing the problem. It’s deciding to stop digging while standing in a hole.

I don’t have a clean answer here. The debt is real, the causes are systemic, and the remediation is painful. Some of it might never get paid down. The features will just sit there, slowly becoming more expensive to maintain, until someone finally kills them or the product gets sunset entirely.

Maybe that’s fine. Maybe some debt you just live with.

But I’d feel better about that conclusion if more teams were at least looking at the invoice. Most haven’t even opened the envelope.

I’ve been watching my feed fill up with people who were “Product Manager” last month and are now “AI Product Manager” this month. Same job. Same company. Same responsibilities. New prefix. And look, I get it. I really do. Some guy posted a compensation chart showing AI PMs making double or triple what regular PMs earn. It had coloured bars and everything. Must be true.

Here’s the thing.

I’ve watched this exact pattern play out at least four times in my career. The prefix changes, the salary hype circulates, and suddenly everyone’s repositioning. Remember when we were all supposed to become Crypto PMs? I knew people who pivoted their entire personal brand around blockchain product management in 2021. They had NFT profile pictures. They joined Discord servers at midnight. They wrote thought pieces about decentralised product strategy.

Where are they now? Back to regular PM work, mostly. The NFT profile pictures quietly disappeared around Q2 2022.

I know because I have been the NFT PM, I’ve built an NFT Marketplace for Fragmented NFT’s.

Before that it was IoT. Everyone was an IoT PM for about eighteen months. Connected toasters. Smart fridges that would order your milk. And before IoT there was the great SaaS migration. If you weren’t a SaaS PM, you weren’t a real PM.

The technology changes. The hype cycle doesn’t. We just keep rotating through prefixes like they’re seasonal fashion.

But here’s what I’ve been wrestling with lately. The real question isn’t whether to add AI to your title. The real question is one we’ve been dodging for years: should you be a generalist or a specialist?

And chasing hype cycles doesn’t actually answer it. It just delays the reckoning.

Think about it. If you’re rebranding yourself as an AI PM because you saw a LinkedIn salary chart, you’re not becoming a specialist. You’re becoming a trend follower. There’s a difference. The actual AI specialists, the ones commanding those salaries, they were building ML products three years ago when the rest of us were still arguing about story points. They didn’t pivot when the hype arrived. They created the hype by shipping things that worked.

By the time a specialism becomes a LinkedIn hashtag, the window for genuine expertise has already narrowed. You’re not early. You’re a consumer of someone else’s innovation.

This is the part nobody wants to hear. Following established hype means you’re already behind. The people who made real money in crypto were building in 2017, not 2021. The IoT specialists who actually matter were thinking about connected devices in 2014. By the time the compensation charts circulate and the recruiters start calling, the first-mover advantage has evaporated.

What’s left is a crowded field of people who all updated their headlines at the same time.

I talked to a recruiter last month who told me AI PM roles are the hottest thing she’s seen in years. When I asked what AI PM actually means, she said it depends on the company. Some want ML background. Some want prompt engineering skills. Some just want regular PMs who aren’t scared of the technology. Most of them, she admitted, don’t really know what they’re hiring for yet.

Which tells you something important about fake specialisation.

The people actually doing interesting AI product work don’t call themselves AI PMs. They call themselves “PM at Anthropic” or “ML Platform PM at Stripe” or whatever. The specificity is the point. They’re not optimising their headlines for LinkedIn algorithms. They’re solving actual problems in actual domains. Their specialism isn’t a prefix. It’s accumulated knowledge that took years to build.

Meanwhile, the generalists keep doing what generalists do. Moving between domains. Applying pattern recognition across contexts. Translating between engineering and business and design. This is also valuable work. Possibly more valuable, depending on where you sit.

The honest answer is that most of us aren’t specialists or generalists. We’re opportunists wearing whichever hat seems most marketable this quarter.

Actually, that sounds harsher than I mean it.

What I’m trying to say is this. Real specialisation takes years. It means going deep on something before anyone’s paying a premium for it. It means being interested in the technology itself, not the salary charts. The AI PMs earning double your salary didn’t become specialists six months ago. They were obsessing over transformer architectures while you were running sprint retros.

And real generalism is also a choice. It means deliberately staying broad. Building transferable skills. Accepting that you’ll never command the specialist premium, but you’ll also never be obsolete when the hype shifts.

The thing that doesn’t work is pretending to be a specialist by following trends. You get neither the depth of true expertise nor the breadth of genuine generalism. You just get a slightly outdated LinkedIn headline and the vague sense that you’re always one cycle behind.

Part of me wants to add AI to my title anyway. Get in on the salary premium before the market corrects. Follow the hype like I probably should have followed crypto or IoT or whatever comes next.

But I’ve been around long enough to know that by the time I’m following, I’ve already lost. The real question isn’t which prefix to chase. It’s whether I want to go genuinely deep on something, or stay genuinely broad across everything.

Everything else is just marketing.

I will keep working on those Nano Banana memes, though. That thing’s going in my portfolio regardless of what I decide.

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.

Something odd is happening in performance review conversations across the tech industry. After years of hand-wringing about whether you can even measure PM performance, organisations are now experimenting with metrics that sound suspiciously like they were invented by someone who has never actually shipped a product.

I first noticed this last quarter when a friend showed me her company’s new PM scorecard. It included something called “decision latency.” The basic premise is straightforward: measure the gap between when a decision is requested and when it gets made. Faster equals better. Lower numbers mean you’re agile. Higher numbers suggest bottlenecks, indecision, or what one exec apparently called “governance bloat.”

On paper, this makes sense. And there’s data to back it up. Research suggests that if decision latency of a team is reduced from 5 hours to 1 hour, their time to market increases by 30%. Medium That’s the kind of number that gets put on slides. It travels well in leadership meetings.

But here’s what nobody seems to be asking: what counts as a decision?

Because in my experience, the best PMs are often the ones who delay decisions deliberately. They hold off until they’ve gathered one more data point. They wait to see how the competitor’s launch lands. They let the engineer finish the technical spike before committing to an approach. Measuring decision speed without measuring decision quality is like celebrating a restaurant for how quickly they burn your steak.

The Hypothesis Cycle Obsession

Then there’s “hypothesis cycle time.” The premise here is that you should track how quickly your team moves from “we believe X” to “we now know whether X is true.” Speed of learning. Velocity of validated bets.

I’ve watched this play out twice now at companies that got very excited about experimentation culture. What actually happens is that teams start running smaller, safer experiments because those complete faster. The big bets, the ones that might actually reveal something meaningful about customer behaviour, get quietly deprioritised because they take longer and drag down the cycle time number.

A PM at a payments company told me recently:

“We optimised ourselves into running forty button colour tests and zero pricing experiments. Our cycle time looked incredible. We learned almost nothing that mattered.”

This is the classic trap of optimising for what’s measurable instead of what’s meaningful. Hypothesis-driven development is genuinely valuable. But measuring the time between hypothesis and conclusion, without weighting for the significance of what you’re testing, creates perverse incentives that anyone who has worked in quarterly targets could see coming.

Roadmap Accuracy and the Certainty Theatre

Perhaps the most concerning metric I’ve encountered is “roadmap accuracy.” The idea is simple: look at what you said you’d ship six months ago, then look at what you actually shipped. High correlation means you’re reliable. Low correlation means you’re bad at planning or easily swayed.

This one genuinely baffles me.

If your roadmap accuracy is consistently above 90%, you’re not doing product management. You’re doing project management with better marketing. The entire point of continuous discovery is that you’re supposed to learn things that change your direction. You’re supposed to talk to customers who reveal that the feature you planned is solving a problem they don’t have. You’re supposed to encounter technical constraints that make your original approach unworkable.

Spotify famously abandoned their squad model because teams were spending more time following the prescribed structure than building products. But for years, every company copied it anyway because it looked organised on a diagram. Roadmap accuracy feels similar. It’s certainty theatre. It rewards teams for ignoring signals that should change their plans.

A former Atlassian PM described their approach to early-stage bets:

“Prove that your product gives value to a small number of users. Then, and only then, prove that your product gives value to a large number of users.”

That’s the opposite of roadmap accuracy. That’s roadmap flexibility as a feature, not a bug.

Customer Bet Success Rate: The One That Almost Works

The metric I’m most curious about is “customer bet success rate.” The concept tracks the percentage of product bets, major initiatives framed as customer-focused hypotheses, that achieve their stated outcomes within a defined timeframe.

This is closer to measuring what matters. It focuses on outcomes rather than activities. It acknowledges that PMs make bets and some of those bets fail, which is actually how good product development works.

But even this one has problems.

First, who defines success? A feature that hits its adoption target but cannibalises revenue from another product line might look successful in isolation. Second, what’s the time horizon? Some bets take eighteen months to reveal their true impact. Third, and most importantly, if your bet success rate is too high, you’re probably not taking enough risks. A 100% success rate suggests you’re only pursuing the obvious.

I’ve yet to meet a company that has figured out how to calibrate this properly. The ones who’ve tried usually end up either defining success so narrowly that everything passes, or so broadly that the metric becomes meaningless.

What We’re Actually Measuring

Here’s the uncomfortable truth beneath all of this. These new metrics exist because organisations still don’t trust their PMs, and they’re trying to find numbers that will do the trusting for them.

But product management resists quantification precisely because it’s about judgement, context, relationships, and the ability to hold contradictory information in your head while still making forward progress. You can measure the outputs of those things. You can sometimes measure the outcomes. But measuring the quality of the thinking itself?

Rich Mironov puts it well: he’s “hesitant to assign numeric goals to individual product managers” ProductPlan because “as soon as there is a numerical, measurable target to be reached, it’s human nature that employees will alter their behavior to hit this designated goal instead of taking a big-picture approach to the job.” ProductPlan

I don’t think decision latency, hypothesis cycle time, roadmap accuracy, or customer bet success rate are useless. Some of them might even be helpful if used carefully, with context, and as one signal among many.

But I worry that we’re building measurement systems for the PMs we wish we had, in the organisations we wish we worked in, rather than acknowledging the actual complexity of product work. The best PMs I know are simultaneously fast and slow, certain and uncertain, planful and reactive.

Try putting that on a dashboard.

I sat in a product review last month where a VP proudly declared that the team would no longer be measured on features shipped. “We’re an outcomes-focused organisation now,” she said. “We care about customer value, not velocity.” The room nodded. Everyone felt virtuous.

Six weeks later, that same VP sent a Slack message asking why the roadmap looked “light” for Q2. The team had been running customer interviews and analysing retention cohorts. They hadn’t shipped anything visible. The outcomes focus lasted exactly until someone needed something to show the board.

This is the practicality gap that nobody wants to talk about. The outcomes versus outputs debate was settled philosophically years ago. Of course you should measure customer and business value. Of course shipping features that don’t move metrics is pointless busywork. Of course the goal is retention, revenue, engagement, satisfaction, not story points completed.

And yet.

The Attribution Problem Nobody Solved

Here’s the thing about outcomes: they’re lagging indicators that often take months to materialise, and when they do, good luck figuring out which work actually caused them.

Your retention improved by 4% this quarter. Was it the onboarding redesign that shipped in January? The pricing change from November finally taking effect? The competitor who imploded and sent you refugees? The macroeconomic shift that made customers less likely to churn anywhere? Some combination of all four that you’ll never untangle?

I’ve watched product teams spend entire offsite sessions trying to attribute outcome changes to specific initiatives. The honest answer is usually “we’re not sure, but we have theories.” That’s intellectually honest. It’s also completely useless when your finance partner needs to justify headcount.

Loom figured this out with what they call “Video First View” as their activation metric. A new customer isn’t considered fully activated until they create their first video and it gets at least one view within a week of signing up. That’s a good leading indicator. It’s measurable, attributable, and tied to a behaviour they can actually influence.

But most teams don’t have metrics that clean. Most teams are working with outcomes that involve dozens of variables, long feedback loops, and stakeholders who need answers faster than the data can provide them.

The Morale Thing Nobody Mentions

There’s another dimension to this that gets conveniently ignored in the outcomes discourse: people need to feel like they’re making progress.

I talked to an engineering lead at a fintech company that went fully outcomes-focused eighteen months ago. Teams stopped tracking velocity. They stopped celebrating releases. Everything was oriented around moving customer metrics.

“By month four, people were miserable. We’d work for weeks on something, ship it, and then... nothing. The metric wouldn’t move, or it would move and we couldn’t tell if it was us. There was no sense of accomplishment. No rhythm. Just waiting.”

They eventually reintroduced some output tracking. Not as the primary measure of success, but as what he called “progress heartbeats.” Ways for the team to feel forward motion while waiting for the outcomes to reveal themselves.

This is the part that gets left out of the thought leadership. Humans are not infinitely patient creatures who can delay gratification for quarterly business reviews. They need smaller wins. They need to see the thing they built go live. They need someone to say “good work” more often than once per OKR cycle.

The Stakeholder Translation Problem

Actually, that’s not quite right. The morale issue is real, but there’s something deeper happening here.

Most product teams don’t operate in isolation. They exist within organisations that have sales teams making promises, executives making forecasts, and board members asking questions. Those stakeholders often don’t care about your carefully constructed outcome metrics. They want to know what’s shipping and when.

A PM at a B2B SaaS company told me about her quarterly business review:

“I walked in with this beautiful presentation about how our NPS had improved and our support ticket volume had dropped. The CEO’s first question was ‘what features shipped this quarter that I can tell customers about?’ He didn’t want outcomes. He wanted a list.”

You can argue that the CEO was wrong. You can say he should care more about customer satisfaction than feature announcements. But arguing with reality doesn’t change it. The PM still had to produce a feature list. The outcomes story was a nice addition, not a replacement.

This is the translation problem. Outcomes are how product teams should think about their work. Outputs are often how the rest of the organisation needs to hear about it. Pretending that gap doesn’t exist, or that you can simply educate stakeholders into caring about retention curves, ignores how most companies actually function.

The Uncomfortable Middle Ground

So where does this leave us?

I think the honest answer is that most teams need both, and the ratio depends on context in ways that resist prescription.

Early-stage products need more output focus because you’re still learning what outcomes even matter. You’re shipping to discover, not shipping to move a known metric. Mature products can lean more heavily into outcomes because the feedback loops are established and the attribution is cleaner. Teams with supportive leadership can be more outcomes-focused than teams reporting to executives who want feature counts.

The real skill, and I’m still working on this myself, is knowing when to shift between the two framings. When to tell the outcome story and when to tell the output story. When to push back on “what shipped this quarter” and when to just answer the question.

Product Focus suggests using what they call leading indicators: metrics like the proportion of customers taking the standard proposition rather than a customised solution, or the number of customers actively engaged in testing and pilots. Product Focus These sit somewhere between pure outcomes and pure outputs. They’re things teams can influence directly, they move faster than lagging business metrics, and they correlate (hopefully) with the outcomes you actually care about.

That’s probably the right direction. Find the intermediate measures that bridge the gap. But I’ve yet to see a company that’s fully cracked this. Everyone’s still fumbling toward something that works for their specific situation.

The Part I Haven’t Resolved

Here’s what I keep coming back to. The outcomes movement was a necessary correction to years of feature factory thinking. Teams shipping roadmap items that nobody used, celebrating velocity while customers churned, conflating busyness with value.

But the correction overcorrected. It created a new orthodoxy where admitting you track outputs feels like confessing to a product management sin. Where the “right” answer in any discussion is always outcomes, even when outcomes aren’t practically measurable or attributable in your context.

The best PMs I know hold both ideas simultaneously. They genuinely care about customer and business value. They also track what shipped this sprint and feel good when the release goes out. They think in outcomes and communicate in outputs, or vice versa, depending on the audience.

That’s not intellectual inconsistency. That’s just the job.

I remember the exact moment I realised the Mini-CEO thing was nonsense. I was three months into my first PM role, full of Ben Horowitz quotes and misplaced confidence, and I walked into a sprint planning meeting ready to “drive the product forward.”

The tech lead looked at me like I’d suggested we rewrite the backend in COBOL. “That’s not how we’re building it,” she said. And that was that. No debate. No negotiation. Just a polite but unmistakable reminder that I had precisely zero authority over how anything got done.

Nobody had warned me. The job descriptions said “own the product vision.” The Medium posts said “CEOs of the product.” What they failed to mention was that owning the vision and making anyone do anything about it are entirely different things.

The Seductive Logic

Look, I understand why the metaphor caught on. There’s a certain elegance to it.

A CEO sets direction for a company. A PM sets direction for a product. A CEO balances competing stakeholder interests. A PM balances customers, business, and technology. A CEO is accountable for outcomes. A PM is accountable for... well, this is where it starts to fall apart, actually.

The comparison flatters everyone involved. It makes PMs feel important. It gives hiring managers a shorthand for explaining the role to candidates. It provides a mental model that sounds coherent in interviews.

Ben Horowitz wrote the original “Good Product Manager/Bad Product Manager” memo at Netscape in the late 1990s, and variations of the CEO framing have been circulating ever since. The intent was probably to emphasise ownership and accountability. What it actually created was a generation of PMs who thought they had authority they don’t have, working with engineers and designers who resented the implication that they reported to someone who couldn’t write code or push pixels.

What CEOs Actually Have

Let’s be specific about what the CEO comparison implies and why it’s wrong.

CEOs have hiring and firing authority. They can remove people who aren’t performing and bring in people who will. PMs work with whatever team they’re assigned, often for years, regardless of fit or capability.

CEOs control budgets. They decide how resources get allocated across the organisation. PMs typically have no direct budget authority. They can request. They can influence. They can make compelling cases. But the actual decision sits elsewhere.

CEOs have positional power. When a CEO says “this is the direction,” people follow it because the CEO said so. When a PM says “this is the direction,” the response is often “let me check with my manager” or “I’ll need to see the data” or simply “no.”

Most importantly, CEOs are accountable for the overall profitability of the entire company. They answer to boards about revenue, margins, market position, shareholder value. PMs are accountable for product outcomes that may or may not translate into company success, through attribution chains that are often fuzzy at best.

A quote that has been shared by Casey Winters said:

“I’m ‘accountable’ for retention in my product area. But I don’t control pricing, I don’t control the sales motion, I don’t control what competitors do, and I don’t control the support experience after someone buys. I’m accountable for an outcome I can influence maybe 30% of.”

That’s not CEO accountability. That’s something else entirely.

The Strategy-Execution Chasm

Here’s where the Mini-CEO myth does its most insidious damage: it creates a fundamental disconnect between strategy and execution that most organisations never properly diagnose.

When you tell PMs they’re responsible for product strategy, they take that seriously. They build roadmaps. They identify market opportunities. They craft positioning. They think in quarters and years, not sprints. All of that is good. That’s the job.

But a strategy without execution authority is just a wish list with better formatting.

I watched this play out at a niche travel tech company last year. The PM had a genuinely sharp strategy for repositioning their mobile app toward business travellers. Clear target segment. Differentiated value proposition. Compelling customer research to back it up. The kind of strategy deck that gets head nods in leadership reviews.

Six months later, almost none of it had shipped. The engineering team had been pulled onto technical debt work by their own leadership. The design team was understaffed and prioritising a different product line. Marketing had committed to a campaign calendar that didn’t align with the new positioning.

The PM had “owned” the strategy. She just couldn’t make any of it happen.

“I felt like I was holding a map to somewhere nobody else was going. I knew where we should be heading. I just couldn’t get anyone to walk in that direction.”

This is the strategy-execution gap in its purest form. And the Mini-CEO metaphor makes it worse by implying that PMs can close that gap through sheer force of ownership. Real CEOs can say “this is the strategy, now everyone align.” PMs can only ask nicely and hope the stars align.

The Damage It Does

The Mini-CEO label wouldn’t matter if it were just inaccurate. Lots of job titles are inaccurate. But this one actively harms how PMs work with their teams.

I’ve seen fellow PMs walk into rooms assuming they’re the decision-maker, only to discover that engineers have strong opinions about technical approach, designers have strong opinions about user experience, and nobody agreed to be “managed” by someone with no formal authority over them.

The result is usually one of two failure modes. Either the PM tries to assert authority they don’t have, creating conflict and resentment. Or they retreat entirely, becoming glorified note-takers who facilitate meetings but never actually drive outcomes.

Neither is good. And both stem from a fundamental misunderstanding of what the PM role actually is.

The best framing I’ve heard comes from a principal PM at a logistics company:

“I’m not the CEO of anything. I’m the person who makes it easier for talented people to build the right thing. I’m in service to the team, not in charge of it.”

That’s a completely different orientation. It’s influence through facilitation. It’s leadership through alignment. It’s making yourself useful rather than making yourself important.

Why The Gap Persists

The strategy-execution gap isn’t just a PM problem. It’s an organisational design problem that the Mini-CEO myth helps obscure.

When a strategy fails to execute, companies have a convenient scapegoat: the PM who “owned” it. But in most cases, the failure sits in the system, not the individual. Engineering capacity was allocated by engineering leadership. Design priorities were set by design leadership. Marketing timelines were locked in before the PM’s strategy even existed.

The PM is positioned as the integrator of all these functions but given no actual integration authority. They’re expected to align cross-functional teams through persuasion alone, in organisations that have built incentive structures, reporting lines, and resource allocation processes that actively work against alignment.

I’ve started noticing a pattern: the companies where PMs struggle most with execution are usually the ones where functional silos are strongest. The companies where PMs thrive tend to have genuinely cross-functional teams with shared goals and joint accountability.

The difference isn’t PM skill. It’s organisational architecture. But hiring a PM and calling them a Mini-CEO is easier than restructuring how the company actually works.

The Authority You Actually Have

Here’s what’s interesting, though. PMs do have authority. Just not the kind the Mini-CEO metaphor implies.

You have authority over the problem definition. You can say “this is the customer problem we’re solving” and, if you’ve done your research, people will generally believe you.

You have authority over prioritisation logic. You can say “here’s why we’re doing X before Y” and, if your reasoning is sound, the team will typically accept it.

You have authority over the narrative. You can shape how the product is understood internally and externally, how success is defined, how tradeoffs are framed.

These are real forms of power. They’re just not executive power. They’re persuasive power. Earned power. Power that comes from being right more often than you’re wrong, from having context others don’t have, from building relationships that give your perspective weight.

Rich Mironov, who’s been writing about product management longer than most of us have been doing it, consistently emphasises that a product manager isn’t writing code, testing products, creating marketing pitches, buying advertising, or actively selling their product. ProductPlan All of that happens downstream. The PM role is upstream: figuring out what to build and why. But “figuring out” is different from “commanding.”

Closing The Gap Without The Title

The PMs who actually get strategy executed tend to operate very differently from the Mini-CEO archetype.

They build relationships before they need them. They understand what engineering leadership cares about and frame their strategies in those terms. They find the places where their product goals and other teams’ goals overlap, then exploit those overlaps relentlessly.

They make the work easier to execute, not just easier to understand. Instead of handing over a strategy deck and expecting alignment, they break the strategy into pieces that fit how the organisation actually delivers. They sequence work to match resource availability, not just logical priority.

They create accountability structures that don’t depend on their authority. Shared OKRs. Joint roadmap reviews. Regular cross-functional syncs where execution gaps become visible to everyone, not just the PM quietly fuming in the corner.

None of this requires being a CEO. It requires being useful, being credible, and being relentless about removing friction from the path between strategy and shipped product.

The Part I’m Still Working Through

I don’t think the Mini-CEO metaphor is entirely without value. There’s something useful in encouraging PMs to think holistically, to take ownership rather than waiting for direction, to feel accountable for outcomes even when the path to those outcomes runs through other people’s work.

The problem is that metaphors shape behaviour. And this particular metaphor shapes behaviour in ways that make PMs worse at their jobs, not better. It encourages command when influence is required. It suggests authority where there is only accountability. It sets up expectations that reality will inevitably disappoint.

Worse, it lets organisations off the hook for structural problems. When strategy doesn’t execute, blame the PM who “owned” it. Never mind that the PM had no actual mechanism to make execution happen. Never mind that the company designed an impossible role and then acted surprised when people couldn’t do it.

Maybe the answer is just to retire the metaphor entirely. Call PMs what they actually are: the people responsible for making sure the right product gets built, working through teams they don’t control, toward outcomes they can’t fully attribute, closing the strategy-execution gap through influence rather than authority.

It’s less flattering. It’s also more honest.

And honestly, the job is hard enough without pretending you’re something you’re not.

Here’s what nobody says out loud: product-led growth is a distribution model that works brilliantly for specific contexts and fails spectacularly outside them. But we’ve somehow decided it’s a universal truth, like gravity or compound interest. Because it sounds cool & trendy and promotes more power accumulation at the PM level.

I’ve seen it at enterprise software companies, start-ups and B2B tools. Someone at an exec offsite mentions Slack or Figma, and suddenly there’s a roadmap item about “bottoms-up adoption” wedged between actual customer needs. It’s cargo cult thinking dressed up as strategy.

Product-led works when you’ve got low friction, quick time-to-value, and individuals who can make buying decisions. Think Notion, Calendly, Loom. But when you’re selling data centre optimisation software to procurement committees, the self-serve signup form isn’t bold innovation. It’s just confusing.

The thing everyone believes

The narrative is seductive. Cut out the expensive sales team. Let the product do the talking. Users become champions become buyers. Growth compounds. It’s elegant, it’s efficient, it’s... completely wrong for most companies.

And look, I get it. Sales-led feels heavy. Expensive. Old world. There’s something deeply appealing about the idea that if you just build it well enough, they’ll come. It’s the field of dreams for SaaS companies.

But that appeal is doing serious damage. I’ve watched companies:

• Build self-serve flows nobody asked for

• Create free tiers that cannibalise their sales pipeline

• Invest in viral loops for products people use once a quarter

• Hire growth PMs when they needed account managers

• Obsess over activation metrics whilst ignoring implementation success

“The best product strategy is the one that actually works for your business model, not the one that works for the company you wish you were.”

What’s actually happening (and what nobody admits)

Let’s be honest about what these debates really are. When executives argue about being product-led versus sales-led versus operations-driven, they’re not having a business conversation. They’re having a power struggle dressed up in business terminology.

Who gets the final say on roadmap priorities? Who controls the budget? Whose metrics define success? Call it product-led and suddenly the CPO has leverage. Call it sales-led and the CRO runs the show. Operations-driven? Well, the COO just won.

I’ve sat in enough exec meetings to recognise the pattern. Someone tables an “important initiative” about go-to-market motion, and what follows is twenty minutes of people defending their organisational territory whilst pretending to care about customer outcomes. It’s a theatre.

The company that spent eighteen months on their failed PLG transformation? The real story was their new CPO trying to claw back authority from a sales leader who’d run the place for a decade. The product-led initiative was just the weapon they chose.

And look, even from a product manager’s perspective, creating a product management dictatorship is completely irrational. You end up focusing on product metrics that have bugger all to do with whether the business actually works.

I’ve seen PMs celebrate hitting their activation targets whilst the company’s burning cash. They’ve built the perfect onboarding flow for users who never convert. They’ve nailed their engagement metrics whilst sales can’t close deals because the product doesn’t solve the actual buying committee’s problem.

You’re chasing DAUs when the business model requires annual contracts. You’re obsessing over viral coefficients when expansion revenue comes from dedicated account teams. You’re measuring feature adoption when customers actually care about implementation speed.

It’s not just bad for the business. It’s career suicide. Because when the board asks why revenue’s tanking, “but our retention cohorts look great” isn’t going to save you.

There’s a second-order effect playing out that’s more interesting than the strategy choice itself. Companies that force product-led motions into sales-led businesses create organisational confusion that takes years to untangle.

Your engineering team starts focusing on signup conversion. Your customer success team wonders why they’re suddenly doing pre-sales. Your sales team feels undermined. Your CFO sees ballooning CAC with declining ACV. And your product team is building features for a customer journey that doesn’t exist.

I watched this at a compliance software company. They added a free trial. Signups went up. Great. Except 90% of signups were individual contributors who had zero buying authority. The actual decision makers, the ones at VP level who’d previously get straight to a demo with sales, now had to wade through a self-serve flow designed for a completely different buyer.

The conversion rate tanked. But hey, MQLs were up.

My point

Here’s what I think: being sales-led is not a temporary state on the way to product-led enlightenment. For many companies, it’s the right end state.

If your product requires implementation, configuration, or integration, you need humans in the sales process. If your buyer isn’t your user, you need humans. If deals involve procurement, legal, security reviews, you definitely need humans. If your product solves a problem people don’t know they have yet, humans.

The companies doing this well aren’t apologising for their go-to-market. Salesforce isn’t embarrassed about their enterprise sales team. SAP isn’t rushing to add self-serve. Workday knows exactly what they are.

And here’s something else nobody wants to say: some products are just interfaces for a service. That’s it. That’s the whole thing. And that’s completely fine.

Your scheduling software isn’t the product. The reliable infrastructure and support that makes meetings actually happen is the product. The app is just how customers interact with it. Same with most B2B software, honestly. The product is the implementation team, the ongoing improvements, the quarterly business reviews, the account management. The software is the front door.

But we’ve convinced ourselves that admitting this is somehow shameful. Like being a service business is less sophisticated than being a product business. So companies build elaborate self-serve features for products that fundamentally require human intervention to deliver value. It’s absurd.

Actually, that’s not quite what I mean. They’re not just accepting it. They’re leaning into it. They’re building product experience around what works for their actual motion, not what works for the PLG playbook.

The pattern I keep seeing

Companies with real product discipline make this call early. They look at unit economics, at their ICP, at buying committees and implementation timelines. Then they build a product experience that supports their actual go-to-market, not someone else’s.

When I was working with a fintech company selling to CFOs, we had this moment of clarity. We’d been trying to build viral sharing features. Why? Because that’s what product-led companies do. Except CFOs don’t share budget management tools. They don’t invite their mates. They buy through an RFP process that takes six months.

Once we stopped pretending, everything got easier. We built better reporting for demos. We created proof-of-concept environments sales could spin up. We invested in integration quality instead of signup conversion. Revenue grew faster.

Here’s another pattern worth noting: some organisations would be significantly more profitable if they just added a proper layer of CSMs between sales and the product. Not as an expensive add-on, but as the actual delivery model.

I know a company that sells workforce management software. They tried self-serve onboarding. Activation rates were terrible. Then they hired three CSMs to do personalised onboarding calls. Suddenly customers were live in two weeks instead of never. Expansion revenue tripled. The CSMs paid for themselves in the first quarter.

But that model doesn’t fit the product-led narrative. It’s human-intensive. It doesn’t scale logarithmically. It requires hiring people instead of tweaking funnels. So companies avoid it even when the unit economics scream that it’s the right move.

“Sometimes the most scalable solution is admitting you need humans in the loop and building your business model around that reality.”

The irony is that focusing on sales-led doesn’t mean ignoring product quality. If anything, it demands more from your product because the stakes per deal are higher. Lose a self-serve user, you’ve lost £20 MRR. Lose an enterprise deal, you’ve lost £200k ARR and poisoned a potential reference.

Part of me wonders if we’ll look back at this period as a temporary hype cycle, like agile or design thinking. Not that those concepts are wrong, just that the universal application was daft.

Or maybe the pendulum swings further. Maybe in five years, every company really can be product-led because buying behaviour shifts entirely. I doubt it though. Some categories just require human relationship and trust.

What this reveals

The obsession with product-led is really about control. As product people, we want to believe our craft is enough. Build it right and the market responds. It’s comforting. It’s also naive.

The companies that win are the ones comfortable with the reality that go-to-market matters as much as product. Sometimes more. They hire product people who understand that a killer demo flow matters more than a slick onboarding sequence. That customer expansion features beat new user activation features.

They build products for how they sell, not how they wish they could sell.

And honestly? There’s something refreshing about that clarity. Stop performing product-led. Build what actually moves your business forward. Your investors will thank you. Your team will thank you. Your customers probably won’t notice because they were never looking for self-serve anyway.

The question isn’t whether you should be product-led. It’s whether you’re honest enough to admit what actually works.

You’ve seen the pattern. Leadership announces ambitious goals. Product teams nod along in the all-hands. OKRs get written. Roadmaps get built. Then nothing happens at the pace anyone expected.

The post-mortems always blame the same things: unclear priorities, poor communication, misaligned stakeholders. So you add more planning ceremonies. More check-ins. More roadmap reviews. And execution gets worse, not better.

I’ve watched this play out at three different companies now, and the explanation everyone reaches for is always wrong. It’s not that teams don’t understand what needs doing. It’s that they’ve been trained, systematically and accidentally, to wait.

The thing everyone’s saying

Walk into any retrospective where execution lagged and you’ll hear the same diagnosis: teams need clearer direction. More context about the why. Better understanding of the strategy. Someone will inevitably suggest another offsite to align on vision.

This makes intuitive sense. Of course people execute better when they understand the strategy. Of course autonomy requires context. The problem is that most execution gaps don’t come from lack of understanding. They come from lack of permission.

Actually, that’s not quite right. It’s worse than lack of permission. It’s the learned behaviour that comes from having your initiative redirected often enough that you stop taking it.

What I’m actually seeing

Here’s the pattern I keep noticing: a PM spots something important that needs doing. They check with their lead. The lead says “good idea, but let’s run it past the VP first.” The VP says “interesting, can you put together a one-pager?” By the time approvals circle back, either the moment’s passed or someone else got told to own it instead.

The PM learns: don’t start things, propose things. Wait for the strategy deck that tells you what’s in scope. Execution becomes a game of reading tea leaves about what leadership actually wants versus what they said they wanted.

I saw this break completely at a mid-stage B2B company last year. They’d grown from 50 to 200 people and suddenly nobody could ship anything without three layers of review. A product designer told me she’d stopped proactively fixing UX issues because she’d learned that any unscheduled work got flagged as “lack of focus” in her next 1:1.

“We kept talking about autonomy in our values deck while training everyone to ask permission for everything that mattered.”

The execution gap wasn’t about skill or clarity. Everyone knew what good looked like. They just knew that doing it without explicit air cover was more dangerous than waiting.

The ownership paradox nobody mentions

Here’s what makes this hard: you can’t grant ownership. That’s not how it works. You can assign responsibility, but ownership is something people take. And they only take it when the environment proves it’s safe to do so.

Most companies try to close the execution gap by pushing ownership down. “You own this now,” leadership announces, as if saying it makes it real. But ownership without authority is just accountability with extra steps. You get all the blame when things go sideways, none of the room to make calls that might prevent it.

I’m reminded of a conversation with an engineering lead at a company that had just reorganised into squads. They’d copied Spotify’s model (everyone copies Spotify’s model) and declared teams fully autonomous. Except teams still couldn’t choose their own tooling. Or adjust their roadmap mid-quarter. Or decline features that made no sense for users. They had ownership of delivery, not decisions. Which meant they had neither.

The execution gap widened because now teams felt accountable for outcomes they couldn’t actually control.

What actually builds ownership (and why it’s uncomfortable)

The teams I’ve seen close execution gaps didn’t do it through better planning. They did it by making the space genuinely unsafe for inaction and genuinely safe for initiative.

That sounds contradictory because it is. You need both. Letting poor performance slide kills execution just as surely as punishing smart risks. But here’s what companies miss: most teams know the difference. They know when they’re being lazy versus when they’re being cautious. The problem is their management doesn’t trust them to know.

I watched a director at a fintech startup fix this in a way that felt almost reckless at the time. They told their product team: if you spot something broken that’ll take less than a week to fix, just do it. Don’t ask. Document the decision and the reasoning, but don’t wait for approval. They’ll argue about it in the next product review if it was wrong.

The first month was chaos. Teams shipped things that overlapped. A few initiatives went nowhere. But something shifted. People started taking responsibility for gaps they noticed instead of filing them under “someone should probably look at that eventually.”

The director got questioned in the exec meeting about why their team’s roadmap looked so messy. Their answer was perfect: “Because we’re solving problems as we find them instead of waiting for quarterly planning to tell us it’s okay to care.”

The artifact nobody looks at

Want to diagnose whether you’ve got an ownership problem? Look at your Slack threads. Not the public channels where people perform productivity. The DMs and private channels where actual work coordination happens.

If you see lots of “checking if it’s okay to...” or “who owns the decision on...” or “just want to make sure we’re aligned before...”, you’ve trained people that initiative requires permission. If you see people explaining decisions they’ve already made and asking for feedback on execution, you’ve built space for ownership.

The execution gap shows up in the questions people ask before they start, not in the work they do after.

What this reveals about how product teams actually work

Most execution frameworks assume rational actors operating in rational systems. You set clear goals, provide sufficient context, remove blockers, and teams execute. Except teams aren’t optimising for execution. They’re optimising for survival in whatever organisational environment they’re in.

If the environment punishes wrong bets more than it rewards right ones, teams won’t bet. If it rewards visible activity over meaningful progress, teams will perform busyness. If it requires consensus before action, teams will wait for consensus.

You can’t fix execution without fixing what the system is actually selecting for. And in most companies, the system is selecting for risk avoidance dressed up as alignment.

Part of me thinks this is why small teams move faster, and it’s not about communication overhead. It’s that there aren’t enough layers for initiative to get lost in. When you see a problem and the only person to check with is sitting next to you, ownership is the default state. Add three approval layers and waiting becomes the default.

The bit I’m still figuring out

Here’s where I get stuck: how do you scale genuine autonomy without descending into chaos? Because the companies I’ve seen pull off high ownership at scale all did it differently. Amazon’s written narratives create space for deep thinking before decisions. Stripe’s operational rigour means you can move fast because the rails are solid. Neither tried to copy the other.

Maybe that’s the point. You can’t template your way to ownership. You have to build the specific conditions where your teams stop waiting and start deciding. Which means the playbook everyone’s looking for doesn’t exist.

The execution gap closes when teams believe taking initiative is less risky than waiting for direction. Everything else is just coordination theatre.

I’ve watched this play out four times now across different companies. New CPO arrives. Town hall gets scheduled. Deck gets polished. Everyone smiles nervously and waits to see if they’re about to be reorganised into oblivion.

And then... nothing happens. For weeks.

That silence isn’t inaction. It’s the most dangerous part of the whole transition. Because while you’re waiting for the strategy memo, your new boss is forming opinions about you based on almost nothing. That offhand comment in the lift. Whether you responded to their Slack message in three minutes or three hours. The body language in that first 1:1 where you tried too hard to seem valuable.

Here’s what I’ve noticed nobody talks about: the 90-day playbook everyone references is written for the incoming leader, not for you. It assumes you’re the clay waiting to be moulded. But you’re not clay. You’re a person with context, relationships, and probably a few skeletons in the roadmap that you’re hoping don’t get exhumed.

The Three Archetypes Are Real. Sort Of.

There’s a framework floating around that says new product leaders fall into three types: the Disruptor (aggressive growth, burn it down), the Optimiser (fix the machine, improve margins), and the Stabiliser (stop the bleeding, rebuild trust). I’ve found this broadly true, except for one problem.

Most new leaders don’t know which archetype they are yet.

They arrive with a mandate from the board or CEO that sounds clear but isn’t. “Fix the product organisation” could mean anything from “ship faster” to “fire everyone over 40.” The incoming CPO is doing their own translation work, often in real time, figuring out what they’re actually supposed to accomplish while pretending they already know.

“When any new leader joins a team or company there is always the deluge of pent-up concerns, challenges, and ideas. I’ve seen others get completely overwhelmed or get thrown off course by the ‘what about’ tsunami. My lesson learned was to start by just listening.”

That’s Steve MacLaughlin, reflecting on his first 90 days as CPO. Notice what he’s describing: not confident strategic clarity, but information overwhelm. Your new boss is drinking from a firehose while trying to look like they’ve got a map.

This creates an odd dynamic. You know more than they do about the product, the customers, the tech debt, the political minefields. But they hold the power. The question isn’t whether to share what you know. It’s how to share it without looking like you’re either defending the old regime or angling for their job.

The Middle Manager Trap

If you’re a Director of Product or Group PM, you’re in a particularly awkward spot. You’re senior enough to be evaluated as potential leadership material but junior enough to be considered expendable if the new boss wants to bring in their own people.

I’ve watched good product leaders make the same mistake repeatedly here. They treat the transition as a performance review. They pull together decks showing everything they’ve shipped, every metric they’ve moved, every fire they’ve put out. Look at me! I’m valuable!

The problem? New leaders are drowning in data already. Another deck full of historical wins isn’t what they need. What they need is someone who can help them understand the current situation without spin. Someone who’ll say “that initiative everyone’s excited about? It’s three quarters behind and the team knows it but nobody wants to tell the CEO.”

That kind of candour is terrifying. It could backfire spectacularly. But I’ve seen it work more often than the alternative, which is carefully managed optimism that gets exposed eventually anyway.

“The worst thing a holdover can do is to show herself to be an unshakeable part of the old guard. Usually that means defending plans and assumptions that need to be reconsidered under the new management.”

Paul Schwada nails it there. The instinct to protect what you’ve built is human. But it reads as resistance, which reads as threat, which reads as “put this person on the list.”

What Actually Changes (And What Doesn’t)

Here’s something counterintuitive: the day-to-day work often doesn’t change much in leadership transitions. Sprint ceremonies still happen. Customer calls still need to be scheduled. The backlog still exists. Engineers still want clarity on requirements.

What changes is the interpretation layer. The same roadmap that was “appropriately ambitious” under the old regime becomes “unfocused and scattered” under the new one. The same discovery process that was “thorough” becomes “too slow.” Features don’t change; the narrative around features changes.

This is why reading the archetype early matters so much. A Disruptor will view a comprehensive discovery process as bureaucracy blocking speed. An Optimiser will view the same process as a potential efficiency lever. A Stabiliser might see it as exactly what’s needed to prevent another quality crisis.

Same reality. Completely different story.

And here’s where it gets properly uncomfortable. Sometimes you need to change the story you tell about your own work. Not lie. But reframe. That six-month research initiative becomes either “deep customer insight foundation” or “quick validation before scaling” depending on what resonates. You’re not being dishonest. You’re being fluent in the language your new leader speaks.

The Part Nobody Wants to Say Out Loud

Some transitions fail. Not because anyone did anything wrong, but because the fit isn’t there.

I’ve watched talented Directors of Product leave within six months of a new CPO arriving. Not because they were pushed out, exactly, but because the working relationship never clicked. Different communication styles. Different risk tolerances. Different assumptions about what product management even is.

The standard advice is “give it time” and “be adaptable.” That’s true up to a point. But if you’re three months in and every interaction feels like speaking different languages, the uncomfortable question becomes: is this worth fighting for?

There’s no shame in deciding it isn’t. The worst outcome isn’t leaving. The worst outcome is staying in a role where your judgement is constantly second-guessed, your autonomy steadily eroded, and your confidence slowly ground down until you forget you were ever good at this.

I don’t have a tidy conclusion here. Leadership transitions are genuinely uncertain, and anyone who tells you they have a formula is selling something.

What I do know is this: the leaders who navigate transitions best aren’t the ones who perform the hardest or defend the loudest. They’re the ones who stay curious about what the new boss is actually trying to accomplish, honest about the situation they’re walking into, and clear-eyed about whether the emerging direction is something they can genuinely get behind.

That last part is the question worth sitting with. Not “how do I survive this?” but “do I want to?”

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.