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’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.

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.

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?”

I was sitting in yet another quarterly review last week when someone pulled up the engagement dashboard. You know the one: daily active users trending up and to the right, retention cohorts looking healthy, feature adoption climbing. The VP nodded. The room relaxed. Nobody mentioned that our support tickets had doubled or that three enterprise customers were quietly evaluating competitors.

This happens everywhere. We’ve gotten really good at building dashboards that tell us we’re doing fine.

The thing is, metrics used to be diagnostic tools. Now they’re more like those fake security cameras in parking garages: visible, official-looking, and completely useless for their stated purpose. They exist to make people feel better about not knowing what’s actually happening.

I’ve watched this pattern play out at four different companies now. It always starts the same way. Leadership asks for better visibility. Product scrambles to instrument everything. Engineering builds the pipeline. Someone designs a beautiful dashboard in Looker or Amplitude or whatever. Then everyone promptly starts optimising for the wrong things because the dashboard only shows what’s easy to measure, not what’s important.

Here’s what actually happens: your “North Star” metric becomes the thing you game instead of the thing that guides you. Teams learn which levers to pull to make the line go up. They stop asking whether the line should be going up. They definitely stop asking what’s happening in the spaces between the metrics.

Take engagement. Please. Everyone tracks it. Nobody agrees on what it means. Is it sessions per user? Time in app? Features touched? Actions completed? The answer is always “yes, all of those” because choosing would require admitting what you’re actually trying to learn.

I talked to a PM last month who told me their activation metric was “completing onboarding.” When I asked what onboarding completion predicted, she paused. “Honestly? Just that someone finished the tutorial.” Turns out their best customers skipped onboarding entirely and went straight to the core workflow. But the metric was up 15% quarter over quarter, so leadership was happy.

This isn’t stupidity. It’s incentive design meeting human nature. When you’re judged on metric movement, you move metrics. When the CEO asks about the dashboard in the all-hands, you make sure the dashboard looks good for the all-hands. When OKR reviews focus on quantitative targets, you pick targets you can hit instead of outcomes you need.

The companies that figured this out, the ones doing actual discovery instead of metric theater, they treat dashboards differently. They use them like triage nurses use vital signs: quick checks that tell you where to look deeper, not definitive diagnoses. Spotify’s squad health checks weren’t about tracking numbers. They were conversation starters. Amazon’s working backwards docs force you to articulate the customer problem before anyone looks at a forecast.

Actually, that’s not quite right. Amazon still has plenty of metric theater. Everyone does. The difference is knowing which metrics are for show and which ones matter.

Most product teams have this backwards. They treat their public metrics (the ones in board decks and all-hands) as truth, and their messy qualitative signals (support tickets, sales call notes, user interviews) as nice-to-have context. It should be the opposite. The qual data tells you what’s happening. The quant data tells you how often.

But qualitative work doesn’t scale the same way dashboards do. You can’t set and forget a customer interview the way you can set and forget a Mixpanel board. There’s no automated pipeline for reading Slack screenshots of user confusion. Nobody gets promoted for manually triangulating signals from five different sources.

So we build dashboards instead. We instrument everything. We set up alerts and anomaly detection and weekly metric reviews. We create elaborate rituals around numbers that everyone knows are lagging indicators of things we should have noticed weeks ago.

The really insidious part? These dashboards create their own reality. Once you’re tracking something, teams orient around it. The metric becomes the goal. The dashboard becomes the product. You end up with organisations optimising for dashboard green-ness instead of customer value.

I’m not saying don’t use metrics. Use them. Just stop pretending they’re telling you the whole story. Stop treating them like objective truth instead of subjective choices about what to count. Stop rewarding people for hitting numbers without asking what had to break to make those numbers move.

Your engagement is up because you added a daily notification that 60% of users immediately dismiss. Your activation is up because you shortened onboarding to three steps, and now nobody understands the product. Your retention is up because you’re measuring 28-day retention instead of 90-day, and you stopped counting churned users in the denominator.

These aren’t hypotheticals. I’ve seen every single one in the last six months.

The fix isn’t better metrics. It’s being honest about what metrics can and cannot tell you. It’s spending as much time in support tickets and sales calls as you do in dashboards. It’s asking “what would have to be true for this metric to be misleading?” before you celebrate hitting your target.

It’s accepting that the most important things happening in your product probably aren’t showing up in your weekly metrics review. They’re happening in the gaps. In the workarounds your power users built. In the features they stopped using. In the complaints they stopped making because they stopped expecting you to fix them.

Your dashboard isn’t lying to you on purpose. It’s just showing you what you told it to show. The question is whether you’re still watching what matters, or just watching the screen.

I kept seeing the same Strategy autopsy. Company buys the tool, adopts OKRs, gets the CMS package of consultants on implementation, does the training, runs the workshops. Six months later they’re hitting 90% of their key results and the business is somehow getting worse. Leadership calls it an “execution problem.” It’s not.

The OKRs were accelerating a strategy that was broken from the start.

Here’s what actually happened: someone in a strategy offsite looked at a whiteboard and said “we should improve customer experience.” Everyone nodded. Sounds good. Strategic. Forward-thinking. Then they translated it into an objective, added some key results about NPS and support tickets, and sent teams off to execute. Three months later, engineering optimised for speed, product optimised for features, and customer satisfaction stayed exactly where it was.

The problem wasn’t the OKRs. It was that “improve customer experience” wasn’t a strategy. It was a wish list item with no diagnosis of what was actually broken.

OKRs are strategy agnostic. They’ll accelerate a terrible strategy just as efficiently as a brilliant one.

The Formulation Failure That Is Rarely Talked About

Most companies don’t fail at execution. They fail at the bit that happens before anyone opens Jira or writes an objective. The strategy formulation stage, where you’re supposed to figure out what problem you’re solving and why your approach might work.

Richard Rumelt calls this the “Blue Sky” mistake. Confusing aspiration with strategy. “Be the market leader” sounds strategic until you realise it’s just a desire with no explanation of how you’ll get there or what’s stopping you now. Then you turn that into OKRs and wonder why “increase market share by 15%” doesn’t manifest through sheer willpower.

I watched a B2B SaaS company do this last year. Their strategy was “become the enterprise choice.” Clear enough, right? So they set OKRs: ship enterprise features, close five Fortune 500 deals, get SOC 2 certified. Hit all three. Revenue stayed flat. Turns out enterprises weren’t avoiding them because of missing features. They were avoiding them because their brand screamed “startup that might not exist in two years.” The strategy diagnosed the wrong obstacle, so the OKRs solved the wrong problem.

The data backs this up. McKinsey’s research shows 70% of strategic initiatives fail, and it’s rarely because the goals were impossible. It’s because tiny formulation errors at the strategy stage snowball into execution failures. Your OKRs show green on the dashboard, whilst the actual strategic needle hasn’t moved an inch.

Four Ways Strategy Kills OKRs Before They Start

The Moonshot with No Rocket. You set a delusional objective like “grow 300%” without any committed plan for how. Google can do moonshots because they’ve got the committed OKRs underneath, the actual tactical plan. Most companies just have the moonshot. Then they’re surprised when teams burn out chasing an impossible number.

Task Lists Pretending to Be Outcomes. Roger Martin nails this one. You treat strategy like a project plan rather than a set of choices. So your key results measure activity instead of value. “Launch Project X” becomes a KR, you launch it, claim success, and nobody stops to ask whether Project X created any value at all.

The Everything Strategy. Michael Porter’s nightmare. Trying to compete on price and quality and speed and innovation simultaneously. You end up with fifteen top-level OKRs because you refused to choose. Teams burn out moving fifteen metrics by 1% instead of three metrics by 20%. I’ve seen companies do this. The quarterly review deck has seventeen objectives. Nobody can remember what half of them mean.

When your strategy refuses to choose, your OKRs become a to-do list where everything’s important and nothing actually matters.

Boardroom Fantasy Syndrome. Strategy gets formulated in a vacuum by people who haven’t talked to a customer in eighteen months. Marketing sets an OKR for leads, product sets one for enterprise features. Both succeed. The business fails because the leads marketing generated weren’t enterprise qualified and the features product shipped weren’t what those enterprises needed.

I talked to a product leader who called this “the paradox of success.” Their teams were hitting 100% of their OKRs whilst revenue dropped 12%. When they dug in, they found the strategy had been built on assumptions nobody had validated. The OKRs were just executing those assumptions really efficiently.

Why This Keeps Happening

We’ve got this backwards belief that OKRs will fix strategy problems through sheer operational discipline. Set clear goals, measure progress, iterate. Except you can’t iterate your way out of a flawed starting premise.

It’s like debugging code when the architecture’s wrong. You can optimise that function all day. Still doesn’t fix the fundamental design mistake.

The other thing that happens, and this is where it gets properly frustrating, is that leadership treats strategy formulation as a creative exercise. Blue sky thinking. What could we become? Who could we serve? Then someone has to turn that poetry into OKRs and suddenly you’re trying to measure “delight” or “transform the industry.” Good luck with that.

The Anchor Nobody Uses

Here’s what actually works, and I’ve watched maybe three companies do this properly: anchor your strategy in real-world numbers before you write a single OKR.

Not your internal metrics. Not what you hope will happen. The numbers that already exist outside your building. Market growth rates. Category trends. Competitor movement. Customer behaviour patterns. Economic indicators. The stuff that’s happening whether you participate or not.

A fintech I know did this. Before they wrote any objectives, they spent two weeks just mapping external KPIs. SMB failure rates in their target market. Payment processing volumes across the category. Regulatory change timelines. Competitor funding rounds. They found the market was growing at 12% annually, but their segment was only growing at 4%. That single number reframed everything.

Their strategy stopped being “grow faster” and became “figure out why we’re growing slower than the market, then fix that specific thing.”

Suddenly, the OKRs wrote themselves. Not because they had better facilitation or a clearer process. Because the strategy was anchored in external reality rather than internal aspiration.

The key results became testable hypotheses: “If we’re losing to competitors on speed, reducing onboarding time by 40% should close the growth gap.” You can measure that. More importantly, you can tell whether your diagnosis was right.

Another company I know tracks ten external KPIs religiously. Market penetration rates, category search volumes, net revenue retention benchmarks, competitive win rates from Gartner. Every quarter, before they touch their OKRs, they look at those numbers. Has the market shifted? Are the trends still valid? Is our relative position changing?

What This Actually Requires

You can’t do this in a strategy offsite. Well, you can, but you’ll be guessing. It requires someone to actually go find the numbers. Industry reports. Customer interviews. Market research. Competitive intelligence. The boring work of understanding what’s happening outside whilst everyone else is having opinions inside.

It also requires admitting you might be wrong. If you anchor strategy in external KPIs and those KPIs say your brilliant insight is contradicted by market reality, you’ve got to change the strategy. Most leadership teams would rather keep the fantasy and blame execution.

But here’s the thing: once you anchor in external numbers, the OKRs stop being aspirational and start being diagnostic. You’re not setting goals. You’re testing whether your understanding of the market is correct. If your OKRs say you’ll close the gap with competitors and you don’t, either your execution failed or your strategy was based on wrong assumptions.

That’s uncomfortable. It means admitting when the strategy’s broken, not just when the execution stumbled.

The Bit That Won’t Change

Most companies will keep doing it backwards. Strategy first, reality later. Set ambitious OKRs, hope something happens, call it “agile” when they pivot three times in one quarter.

The organisations that figure this out, that anchor strategy in external truth before they write objectives, they’re the ones where OKRs actually work. Not because they’re better at goal-setting. Because their goals are tethered to something real.

Your OKRs can’t save a strategy that was doomed at formulation. But if you start with the numbers that already exist in the world, the strategy writes itself. And the OKRs stop being wishful thinking and start being actual experiments with actual learning.

Most people don’t want that level of honesty. They want the comfort of clear objectives even if those objectives are built on fantasy.

Which explains why 70% of strategic initiatives fail whilst everyone’s hitting their key results.

There’s this moment that happens in every product launch I’ve seen. Product marketing gets handed a PRD, maybe some Figma mocks, possibly a Loom of the roadmap review if they’re lucky. Then they’re supposed to build a launch narrative that explains why this matters to customers.

Nobody told them why it actually matters to the business.

So they make something up.

Actually, that’s not fair. They reconstruct a strategy from artifacts and educated guesses, like trying to figure out what a meal tasted like by reading the recipe backwards from the dirty dishes.

The thing is, there usually was a strategic intent. Someone, somewhere, made a bet. Maybe it was about moving upmarket. Maybe it was about defending against a competitor. Maybe it was about finally addressing technical debt that was costing millions. But by the time that intent reaches product marketing, it’s been through so many translations and telephone games that the launch story has nothing to do with the original reasoning.

I watched this play out last quarter. Engineering had spent six months rebuilding the permissions system. The actual reason? Enterprise deals were stalling because we couldn’t support their compliance requirements. Sales was haemorrhaging revenue. The CEO had explicitly said this was make-or-break for moving upmarket.

Product marketing’s launch angle? “Empowering teams with flexible access controls.”

I’ve watched this movie three times now. The ending never changes.

Nobody was wrong, exactly. The feature did enable flexible access. But the strategic bet was about enterprise revenue, and the positioning made it sound like a nice-to-have. The demo showed someone adding a colleague to a project. The case study featured a 50-person startup. The email campaign went to the entire user base.

Three months later, leadership was asking why enterprise pipeline hadn’t moved. Product marketing was asking why adoption was lower than expected. Engineering was asking why they bothered.

This isn’t a one-off. The strategic intent exists in one place. The product rationale exists somewhere else. The go-to-market story exists in a third location. They’re all internally consistent. They’re just not consistent with each other.

Leadership makes a strategic bet in a closed-door session. Product translates that into features based on their interpretation plus whatever engineering thinks is feasible. Design translates product’s requirements into flows that actually work. Product marketing translates all of that into customer benefits, except they’re working from specs and screenshots, not strategy memos.

Each translation is rational. But the cumulative effect is like that game where you whisper a sentence around a circle. By the end, “we’re betting on enterprise to hit our revenue targets” becomes “teams love collaboration features.”

The really weird part? This might be working as intended. Not consciously, but systemically.

If product marketing actually knew the strategic bet, they’d have to own outcomes tied to that bet. If the launch narrative explicitly said “this is for enterprise revenue,” and enterprise revenue didn’t move, that’s a failure. But if the narrative is vague enough, “empowering teams,” well, teams were empowered. Launch succeeded. Nobody’s to blame when the business results don’t follow.

“It’s plausible deniability by organisational design.”

I started noticing this after the third time I heard a PMM say “I don’t have a seat in strategy conversations.” Which is true. But why? The standard answer is hierarchy and access. PMMs aren’t senior enough, or strategy happens at the executive level.

Actually, that’s not quite it. I think it’s more pragmatic. If you tell product marketing the real strategic bet, you’re creating accountability for whether that bet pays off. If you keep them at arm’s length, they can execute tactics without being tied to strategic outcomes. When things go wrong, it’s a marketing execution problem, not a strategy problem.

This serves everyone, in a way. Leadership gets to preserve the illusion that strategy is driving everything. Product gets to focus on building without worrying about market positioning. Product marketing gets to optimise for launch metrics instead of business outcomes.

Everyone has cover.

The cost shows up later. In enterprise deals that don’t close because the positioning doesn’t match the product. In existing customers who get confused by announcements that don’t connect to their problems. In engineering teams that build things nobody buys because the market narrative was wrong from the start.

I talked to a PMM last month who’d been at her company for two years. She’d launched maybe fifteen features. When I asked her what the product strategy was, she laughed.

“I know what we’ve shipped. I can tell you our messaging pillars. But why we’re building what we’re building? No idea.”

She’s good at her job, by the way. Her launch campaigns hit their metrics. Her content performs well. She’s just executing tactics in a strategic vacuum, and everyone’s fine with that until they’re suddenly not.

The companies that have sorted this out, and there aren’t many, make product marketing responsible for translating strategy into markets, not features into benefits. That means PMMs need to understand the bet before they craft the narrative.

Intercom did this reasonably well for a while. Their PMMs could articulate why they were building for specific segments, not just what the features did. When they launched their Resolution Bot, the narrative wasn’t “AI helps your team.” It was “you’re spending too much on support, here’s how to fix it.” Strategic intent, product capability, and market positioning in alignment.

But that’s rare. Painfully rare.

Most of the time, product marketing is playing a game where they don’t know the rules. They’re building launch narratives based on guesswork and previous patterns, hoping they’ve read the subtext correctly.

Nobody tells them if they got it wrong until quarters later.

And here’s what nobody wants to admit: sometimes the strategic intent doesn’t exist. Sometimes product just built something because a founder liked the idea, or a big customer asked, or engineering had spare capacity. In those cases, product marketing’s job becomes inventing a strategy retroactively. Making it sound like there was always a plan.

Which, honestly, might explain why everyone’s so comfortable with the ambiguity. If there’s no real strategy to translate, then the translation can’t be wrong.

I’m not sure this is fixable without changing how companies think about the function. Product marketing sits in this weird gap between product and revenue, touching both but owned by neither.

The question isn’t whether product marketing should know the strategy. Obviously they should. The question is whether organisations actually want them to know, or whether the current arrangement serves everyone’s interests too well to change.

Your launch narrative probably doesn’t match your strategic intent. But maybe that’s the point.

During my stint at Quantive (now WorkBoard), I’ve watched a number of companies roll out OKRs following the guidance deck, the same quarterly cadence and the same “align the organisation” rhetoric. Two-thirds of them end up quietly ignoring their objectives whilst still running the ceremony. The remaining third is having existential debates about whether “increase user engagement” counts as an outcome.

Nobody talks about this bit. The part where you’ve got your shiny OKRs pinned to every Confluence page and Slack channel, leadership feels good about clarity, and your team is still building features nobody asked for because someone’s bonus depends on shipping by Q4.

The execution gap isn’t about setting better goals. It’s about the thirty decisions between “we agreed on this” and “we shipped that thing.”

OKRs are brilliant at exposing the gap. Terrible at closing it.

The Thing Everyone Says

“OKRs create alignment.” Sure. I’ve seen perfect alignment on objectives whilst engineering built the wrong thing, design solved the wrong problem, and product measured the wrong metric. Everyone nodded in the same all-hands. Everyone pointed their work at the same quarterly target. The gap still happened.

Here’s what actually occurred: the objective said “improve customer retention by 15%”, the key results were measurable and time-bound, and the team interpreted “retention” as “daily active users” whilst customer success was tracking “accounts still paying after six months.” Both teams hit their targets. Retention barely moved.

That’s not an alignment problem. That’s thirty micro-decisions about what words mean, which signals matter, and whose definition wins when nobody’s looking.

The Bit Nobody Mentions

OKRs are a diagnostic tool masquerading as a management system.

When they work, it’s not because they drove execution. It’s because they revealed where the connective tissue was missing. The good companies see the gap, get uncomfortable, and start asking different questions. The rest just write better objectives next quarter.

I watched a team spend three weeks debating whether their key result should be “80% feature adoption” or “NPS above 40.” Painful meeting after painful meeting. Someone finally said, “Wait, do we even know if those two things correlate?” Silence. They didn’t. They’d never checked. That question, that moment of realising they were optimising for something they’d never validated, that’s what closed their execution gap. Not the OKR itself.

The framework forced them to get specific enough that the holes became visible.

What OKRs Actually Do Well

They make you pick. Not in a prioritisation workshop way, in a “you can’t fudge this in the quarterly review” way. When you write “increase trial-to-paid conversion by 12%” you can’t quietly ship a feature that sort of maybe relates to onboarding and call it progress. The number’s either there or it isn’t.

That clarity is uncomfortable. Which is the point.

They also create a shared vocabulary for about six weeks. Everyone knows what O3 means. You can shorthand in Slack. “Does this move KR2?” becomes a legitimate filter. Then someone new joins, or Q2 starts, and you’re back to translating.

But here’s what surprised me: the best use of OKRs I’ve seen wasn’t during the quarter. It was after. A PM I know runs these brutal post-mortems where they map every shipped feature against their key results. Not to shame anyone. To see the delta between “what we said mattered” and “what we actually built.” The gap between intention and action, right there in a spreadsheet.

Half the features had no line to any key result. They’d been prioritised anyway. Sales asked, a founder had a hunch, engineering wanted to refactor. All valid reasons, maybe. But it meant their OKRs were decorative.

Where It All Goes Sideways

The execution gap opens when you treat OKRs like a contract instead of a hypothesis.

You set them in January. By March, you’ve learned something that makes KR3 irrelevant. But you can’t change it because leadership wants “consistency” and the board deck has those numbers. So you keep reporting progress on a metric you no longer believe matters, whilst quietly working on something else entirely.

Or worse: you set an objective so vague that anything could count as progress. “Improve product quality” means seventeen different things to seventeen different people. Engineering thinks it’s reducing bugs. Product thinks it’s better UX. Customer success thinks it’s fewer support tickets. You have alignment on the words, none on the meaning.

I talked to someone at a fintech startup who had an OKR about “modernising the tech stack.” Their key result was “migrate 80% of services to new infrastructure.” Sounds clear. Except nobody asked whether modern infrastructure would actually solve the problem, which was that their feature velocity was terrible. They hit the key result. Velocity didn’t improve. Turns out the bottleneck was product decisions, not deployment pipelines.

The gap wasn’t in execution. It was in the starting assumption.

The Actually Interesting Question

What if OKRs are meant to fail?

Not in a “we didn’t hit our numbers” way. In a “we learned where our model of reality was wrong” way.

The companies I’ve seen use them well treat missing a key result as data. They don’t immediately blame execution. They ask: was the objective wrong? Was the key result measuring the thing we thought it measured? Did we discover something that changed our theory of impact?

That mindset, where OKRs are questions not answers, that seems to narrow the gap. Because the gap isn’t about doing the work. It’s about doing work that connects to the outcome you claimed to care about.

Most teams don’t want that level of honesty. They want goals that make them feel organised and protect them when things go wrong. “We hit our OKRs” becomes a shield. Even when the business result is nowhere.

What They’re Not

OKRs won’t tell you what to build. They won’t prioritise your backlog. They won’t resolve the argument about whether you’re a feature factory or a product org. They won’t make your roadmap less of a ransom note to stakeholders.

They definitely won’t close the execution gap if your actual problem is that nobody trusts product to make decisions, or engineering is underwater with tech debt, or your discovery process is “founder’s opinion plus vibes.”

I keep seeing teams adopt OKRs like they’re installing new software. As if the framework itself does something. It doesn’t. It reveals things. Whether you act on what it reveals, that’s a different question.

So What Are They Actually For?

OKRs are good for making the gap visible. For forcing specificity. For creating a moment where you have to articulate what you believe will matter and stake a claim.

They’re not good for closing that gap. That requires changing how decisions get made in the thirty moments between goal-setting and shipping. Who gets to say no. What data you trust. How much you’re willing to kill work that doesn’t connect.

You can have perfect OKRs and still build the wrong things. You can have rubbish OKRs and ship something great because someone on the team understood the real problem and had permission to act.

The execution gap isn’t a planning problem. It’s a decision-making problem. OKRs just make it harder to pretend otherwise.

Which might be their real value. Not that they drive better execution. But that they make it obvious when you’re not executing at all.

At Quantive, we had this gorgeous admin dashboard. It tracked everything you’d expect: seat utilisation, login frequency, feature adoption, and configuration completeness. All of it. And for months, we’d celebrate when those numbers ticked up. More logins. More configured OKRs. More teams onboarded. We felt smart about it.

Then we’d lose a customer who looked perfect on paper.

The Thing Everyone’s Measuring

There’s a comfort in admin metrics. They’re clean. They’re immediate. They’re measurable. When a VP asks “How’s the product doing?” you can point to a chart that goes up and to the right. Everyone nods. Meeting adjourned.

This isn’t new. Every CMS, every enterprise platform, every B2B SaaS product has some version of this dashboard. And they all make the same mistake: they measure the admin experience as if it’s the actual value.

It isn’t.

The admin panel is theatre. It’s the green room, not the stage. Success doesn’t happen there. Success happens when your customer’s business does something different, something better, because they’re using your product.

But here’s what nobody’s saying: most product teams don’t actually know what that “something different” looks like. They’ve never asked. They’ve certainly never measured it.

What Successful Companies Actually Do

I started noticing a pattern with our highest-retention customers. They weren’t necessarily the ones with the highest login counts. Some of them barely touched the admin panel. But they had something else going on.

They’d built rituals around OKRs. Monday morning reviews. Quarterly planning sessions where OKRs were the starting point, not an afterthought. They’d connected their strategic objectives to specific revenue metrics and could show you the line between an OKR shift and a business outcome. One customer showed us how a single objective around customer retention had directly influenced their support team’s workflow redesign, which dropped churn by 8% over two quarters.

That’s not an admin metric. That’s a business outcome that happened to involve our product.

The real indicators of success were: Are they implementing OKRs effectively? Are those OKRs driving measurable improvements in their business? Can we see a connection between strategic objectives and revenue impact?

The companies that renewed and expanded weren’t just using Quantive. They were using it to win in their market. And the way they did it was surprisingly consistent. They integrated OKRs into existing workflows rather than creating a separate “OKR process”. They trained teams on the discipline, not just the tool. They made OKRs visible (literally, in some cases, with dashboards in common areas). They argued about them. They changed them when they weren’t working.

Actually, that last bit is important. The best customers changed their OKRs mid-quarter when reality shifted. The worst ones set them once and never looked back. One was adaptive; the other was performative. Same product, wildly different approaches.

And here’s something else: these successful companies almost always had dedicated Customer Success support. We’d assign a CSM who’d spend weeks, sometimes months, helping them build the discipline. The product alone didn’t create that OKR culture. It took someone who understood both the tool and the methodology to help teams navigate the awkward early phases, challenge their assumptions, and model what good looked like. Success wasn’t product-driven. It was product-enabled and people-guided.

The Metrics We Weren’t Tracking

Net Revenue Retention told us which customers would stay. But it took us too long to realise what predicted NRR. It wasn’t feature adoption. It wasn’t login frequency. It was whether the customer had operationalised the OKR discipline internally.

Could we see evidence that OKRs were influencing decisions? Were they referenced in Slack conversations? Did teams adjust roadmaps based on objective progress? Was there a feedback loop between strategic intent and tactical execution?

These weren’t metrics we had dashboards for. We had to dig. We had to talk to customers. We had to ask different questions.

This reminds me of a conversation I had with a customer success lead at a large consultancy. They’d bought Quantive for about 200 users. On paper, adoption was terrible. Maybe 30% of seats were active monthly. But when you looked closer, those 30% were the strategic planning team and executive layer. They were using it religiously to set direction for 10,000 people. The other 170 seats were team leads who logged in quarterly to review objectives and update progress.

Was that bad adoption? Or was that exactly what success looked like for their structure?

We’d been measuring the wrong thing.

Wrap up

Here’s the thing about CMS products, or OKR platforms, or any enterprise tool really: they don’t succeed in isolation. They succeed when they help a customer navigate three interconnected realities.

First, the product itself. How do successful customers configure it? What features do they actually use versus ignore? What integrations matter?

Second, their market. How are they using the product to compete? What advantage does it give them? If they’re in retail, are they using it to coordinate seasonal campaigns? If they’re in enterprise sales, are they using it to align account teams with strategic bets?

Third, their internal dynamics. Who owns the process? How do teams collaborate around it? What governance exists? What rituals have formed?

Most product teams only look at the first dimension. The best ones (or the ones who accidentally stumble into this) look at all three. Because that’s where the patterns are.

A SaaS company and a manufacturing company might both be “successful customers”, but their success patterns will look completely different. The SaaS company might update OKRs monthly and tie them to product velocity metrics. The manufacturing company might update them quarterly and tie them to supply chain efficiency. Both are winning. Both are high NRR. Both use the product differently.

If you only measure admin activity, you’d miss this entirely.

What This Reveals About How We Build Products

The shift here isn’t just about metrics. It’s about what you think your job is as a product manager.

If your job is to increase feature adoption, you’ll build features that encourage logins. You’ll gamify. You’ll send notifications. You’ll add dashboards to the dashboards.

If your job is to help customers win in their market, you’ll build features that connect your product to their reality. You’ll study how successful customers operate. You’ll identify what they do that others don’t. You’ll codify those behaviours into guidance, templates, workflows, or (if you’re ambitious) predictive nudges that help other customers follow similar paths.

This is uncomfortable because it requires you to care about things outside your product. You have to understand your customer’s business model. You have to know their competitive landscape. You have to recognise that your product is a means, not an end.

Part of me still struggles with this. It feels like overreach. Like I’m supposed to be building product features, not studying market dynamics or organisational behaviour. But the customers who succeed don’t separate these things. Why should I?

The Unresolved Tension

Here’s what I’m still figuring out: how do you measure this at scale and in different industries?

It’s one thing to have deep relationships with 20 customers and understand their success patterns intimately. It’s another thing to operationalise that insight across 2,000 customers. You can’t manually study every company’s market positioning and internal rituals. And you certainly can’t assign a dedicated CSM to every account, no matter how much that accelerates success.

But maybe you don’t have to. Maybe you can instrument the patterns. Track the behaviours that correlate with business outcomes. Build feedback loops that surface early indicators of success or failure. Not “Did they log in?” but “Are they exhibiting the patterns we’ve seen in companies that thrive?”

I haven’t cracked this. Neither has anyone else I’ve spoken to. But the companies that figure it out first are going to have a ridiculous advantage. Because they’ll stop optimising for admin engagement and start optimising for customer success in the real world.

Which, honestly, is what we should’ve been doing all along.

There’s a Slack thread I keep thinking about. Engineering lead asks product: “Why are we building this?” PM responds: “We validated it in discovery.” Engineering: “Right, but why this problem?” PM, slightly defensive now: “We literally just spent three weeks talking to users.”

Nobody asks the obvious follow-up: validated it against what?

This is discovery theatre. It’s everywhere. And it’s quietly rotting the connection between strategy and execution.

The Pattern Nobody Names

Here’s what actually happens: leadership sets a direction (let’s say “improve retention”). Product translates that into a roadmap theme. Then comes discovery. A few weeks later, you’re in a review meeting, and someone’s presenting research that coincidentally supports exactly what was already on the roadmap.

Funny how that works.

I’ve watched this play out at four companies now. Different industries, different maturity levels, same dynamic. Discovery becomes the thing you do to prove you did the thing, not the thing that helps you figure out what thing to do.

The tell is in the artefacts. When discovery documentation reads like a closing argument instead of an investigation report, you’re watching theatre.

What’s Really Happening Beneath the Surface

The problem isn’t that teams are lying. Most aren’t. They genuinely believe they’re following best practice: talk to users, identify problems, build solutions. The process looks right.

But look at the incentives. Leadership wants certainty. Stakeholders want commitments. Engineering wants stable plans. Everyone’s optimising for something other than learning.

So discovery mutates. It stops being “what should we do?” and becomes “here’s why what we’re already doing makes sense.” The research questions narrow. The participant selection skews. The synthesis focuses on signal, ignores noise. Not maliciously, just gravitationally. The roadmap has mass. Discovery orbits it.

I’m not sure this is even conscious most of the time.

The real damage isn’t the wasted research effort. It’s the feedback loop you’ve just severed. When discovery can’t falsify your assumptions, it can’t guide your strategy. You’re flying blind while insisting you can see.

The Alibi Pattern

There’s a specific shape to this. Leadership announces a strategic priority. Product interprets it (usually too literally). They identify initiatives that feel appropriately strategic. Then they run discovery.

But here’s the thing: if discovery was genuinely informing strategy translation, you’d see these teams change course sometimes. Deprioritise the big initiative. Challenge the strategic framing. Come back with “actually, the real problem is adjacent to what we thought.”

When’s the last time you saw that happen?

Instead, discovery becomes proof of rigour. “We validated this with 12 users.” What you validated was whether users experience the problem you already decided to solve. That’s not strategy translation. That’s confirmation bias with a user interview guide.

The worst version is when teams run discovery after engineering has already started building. I’ve seen this. Multiple times. At companies you’ve heard of. The discovery work happens in parallel, surfaces inconvenient truths, gets ignored because “we’re too far down the path to change now.”

At that point you’re not even pretending. You’re just checking a box.

Strategy Translation vs. Strategic Justification

Real strategy translation starts with discomfort. You take a strategic direction (”own the enterprise market” or “become the workflow hub”) and you sit with how impossibly vague that is. Then you generate hypotheses. Actual testable hypotheses with falsifiable predictions.

If we believe owning enterprise means solving compliance anxiety, then we’d expect to hear procurement teams raising security questions before pricing. We’d see deals stalling at certain review stages. We’d find champions who can’t get budget approval.

Discovery tests those hypotheses. And crucially (crucially) it’s designed to break them.

When discovery is strategy’s alibi instead, the hypotheses are backwards-engineered. You start with the solution, infer the problem it solves, then go find users experiencing that problem. Research design becomes an exercise in confirming your roadmap makes sense.

The smoking gun is what doesn’t make it into the findings. All the contradictory signals. The users who said the problem wasn’t actually painful. The people who pointed at different issues entirely. That stuff gets coded as “edge cases” or “not our target segment.”

Except sometimes those edge cases are trying to tell you something.

The Company Size Trap

This gets worse as companies scale. Smaller teams can get away with informal discovery: someone talks to three customers, learns something, adjusts. The feedback loop is tight. Discovery and strategy blur together naturally.

But at 200 people? At 800? You need process. So you build it. Discovery becomes a phase. It gets templates, cadences, review meetings. You hire researchers. You create documentation standards.

And somewhere in that formalisation, you lose the ability to say “wait, this doesn’t make sense.”

I watched a team at a scale-up run an eight-week discovery initiative. Proper qualitative research, quantitative validation, the works. They came back with findings that directly contradicted the roadmap assumption. Leadership response? “Interesting. Let’s keep that in the backlog and revisit next quarter.”

The roadmap didn’t change. Because the roadmap wasn’t actually a hypothesis. It was a commitment they’d already made to the board.

That’s when discovery stops informing strategy and starts performing it.

The Testable Hypothesis Problem

Most teams aren’t actually working with testable hypotheses. They think they are. They’ll say things like “we believe users need better collaboration features.” That’s not a hypothesis. It’s a statement of intent wearing a hypothesis costume.

A testable hypothesis looks like: “If we reduce comment latency below 200ms, we’ll see threaded discussions increase by 30% and session depth grow by 15%, because the current delay breaks conversational flow and people give up.”

That can be falsified. You can discover you’re wrong about the latency threshold. Wrong about which conversations it affects. Wrong about whether flow matters.

When discovery is genuinely connected to strategy, it’s trying to falsify these things. You’re actively looking for disconfirming evidence. The goal is to get less wrong before you build.

But strategy theatre doesn’t want falsifiable hypotheses. It wants confirmable narratives. So you get vague problem statements that any research can support: “Users are frustrated with the current workflow.” Well, yes. Users are always somewhat frustrated. What specifically? Which workflow? Frustrated how?

Doesn’t matter. It’s on the roadmap.

What This Reveals About How We Work

The real issue isn’t that product teams are bad at discovery. Most teams I’ve worked with are genuinely trying to learn from users. The issue is organisational pressure creates a reality distortion field.

When you’re expected to deliver on quarterly commitments, when your performance review depends on hitting roadmap milestones, when leadership has already told the board what’s coming, discovery stops being genuine inquiry. It can’t be. The system won’t let it.

I keep coming back to this: discovery theatre exists because uncertainty is professionally dangerous. If you run discovery that genuinely questions the roadmap, you’re creating problems. You’re slowing things down. You’re introducing doubt. In most organisations, that’s not rewarded. It’s punished.

So teams adapt. They run discovery that looks rigorous but can’t threaten the plan. They ask questions with predetermined answers. They synthesise findings that align with stakeholder expectations.

And then they wonder why their products miss the mark.

The Uncomfortable Truth

Part of me thinks this is worse than not doing discovery at all. At least when you’re just building from gut instinct, everyone knows you’re guessing. There’s honesty in that.

But discovery theatre creates false confidence. You’ve talked to users. You’ve got data. The findings deck looks professional. Leadership feels informed. You’ve de-risked the roadmap.

Except you haven’t. You’ve just created better documentation for why you’re still guessing.

The question that keeps nagging at me: is this fixable within most organisational structures? Or does real discovery (the kind that genuinely informs strategy) require a level of organisational courage that most companies simply don’t have?

I don’t have a clean answer to that. Which might be the most honest thing I can say about it.

I’ve watched three companies ship the same product in the past year. Different markets, different problems, different value propositions. Same rounded corners, same button states, same card patterns. You know exactly what I’m talking about. That clean, professional, very-2024 aesthetic that screams “we have our shit together” while quietly ensuring every strategic pivot costs six months and requires an act of God.

The design system sold itself on velocity. Ship faster, maintain consistency, scale the team. And it delivered spectacularly. Your checkout flow looks great. Your dashboard is coherent. Engineers love the documentation.

What nobody mentions in the Figma files is that you’ve accidentally turned strategy into a renovation project.

The Thing Everyone’s Saying

Design systems are infrastructure. They’re meant to free teams from reinventing buttons so they can focus on hard problems. The component library is your shared language, your operational backbone. Without it, you get chaos. Every squad designing their own date picker, every feature looking like it came from a different company.

This is all true. I’m not here to argue against design systems. I’ve built them. I’ve sat through the workshops where we debate whether the tertiary button should have 6px or 8px padding.

The Thing Nobody’s Saying

Your design system optimises for similarity at exactly the moment you need difference.

Last month, a PM I know wanted to test a completely different approach to their pricing page. Not a tweak but a genuine rethink. Different information hierarchy, different interaction model, different persuasion architecture. The kind of thing you’d do if you were genuinely uncertain about your monetisation strategy and wanted to learn something real.

The conversation with design and engineering went like this: “Sure, but we’ll need to build five new components, extend the theming system, and update the documentation. Probably three sprints, assuming it doesn’t conflict with the navigation refresh.”

So they didn’t do it. They shipped another variation of the existing pattern, called it a test, learned nothing meaningful, and moved on. The design system had made the safe choice free and the interesting choice expensive.

At Airbnb, they spent years building a design system so robust it became famous. Then they needed to differentiate Experiences from Homes, and suddenly realized their system was built for consistency when the strategy required contrast. They ended up with this awkward hybrid where Experiences sort of broke the rules but not quite, because actually breaking them would mean forking the component library. The strategic differentiation they needed lived in this narrow band of “different enough to notice, similar enough to not require engineering work.”

The Translation Failure

This connects to something larger that nobody wants to admit: most implementation infrastructure is built for iteration, not transformation.

Your design system, your API architecture, your data models, your service boundaries. They all encode assumptions about what your product is and what problems it solves. That’s fine when you’re scaling an established pattern. It becomes suffocating when you need to test whether that pattern is actually working.

A fintech startup I know wanted to pivot from B2B to B2C. Their entire component library was built around table-heavy, data-dense interfaces. Complex filtering, bulk actions, admin controls everywhere. To make something that felt consumer-grade, they’d need to essentially maintain two design systems. So they didn’t pivot. They found a way to convince themselves the B2B path was fine, actually.

The pattern is consistent: the infrastructure built to move quickly in one direction actively resists movement in another direction. Design systems are just the most visible example because they live in Figma where everyone can see them.

The Machinery of Sameness

Component libraries work through constraint. Every button needs a type prop: primary, secondary, tertiary. Every card needs a variant: default, elevated, outlined. Every input needs a state: default, error, success. You’re not designing interfaces anymore, you’re assembling Lego bricks.

This is genius for operational efficiency. Engineering teams can ship features without involving designers. QA knows what to test. Accessibility is baked in. Handoff friction disappears.

But watch what happens to strategic differentiation. Your new AI feature gets primary buttons because that’s what you have. Your experimental pricing model gets the standard card treatment because building a new pattern requires a review board. Your attempt to create urgency without feeling manipulative gets sandboxed into existing component states that were designed before you knew you needed urgency.

The design system doesn’t say “no.” It just makes “yes” so expensive that teams self-censor. Strategic bets start to look like each other not because the strategy is similar, but because the implementation options are limited.

I’m not convinced this is fixable through better taxonomy. I’ve seen teams try. They create “experimental” variants, build “breakout” exceptions, establish “strategic initiative” component categories. It helps at the margins. But the fundamental tension remains: a system built for consistency can’t simultaneously optimise for differentiation.

What Gets Optimised

Think about how features get prioritised in your component backlog. You build the patterns you need most often. The login flow, the settings page, the data table, the form validation. Totally reasonable.

But “most often” correlates with “already doing.” You’re encoding your current strategy into your future implementation options. The thing you might need to do gets no components built for it because you don’t know you need them yet.

Meanwhile, competitors without your mature design system can ship weird things faster. Not because they’re smarter, but because they haven’t yet optimised away their degrees of freedom. Their inconsistency is a feature when they need to test something genuinely different.

There’s something darkly funny about this. Your design system maturity becomes an anchor the moment market conditions change. That thing you built to move faster makes you slower precisely when speed matters most.

The Strategic Debt

At some point, every company with a mature design system hits this moment: they need to do something genuinely different, and the system blocks them. So they either don’t do the thing, do it badly within system constraints, break the system and deal with the consequences, or build a second system for “strategic initiatives.”

None of these options are great. The problem isn’t the design system itself, it’s the implicit assumption that operational excellence and strategic flexibility can be optimised simultaneously. They can’t. They’re in tension. Sometimes direct opposition.

The design system gives you leverage on execution. That’s real value. But leverage amplifies force in the direction you’re already moving while making it harder to change direction.

Where This Shows Up

Your company probably has a narrative about being nimble, testing quickly, following signals. Then look at your last five “strategic experiments.” How many of them used the existing component library almost exclusively? How many times did “what would it take to build this?” turn into a conversation about component abstraction and system scalability?

The strategic pivot that requires new infrastructure patterns gets quietly translated into the strategic tweak that fits existing patterns. Nobody thinks they’re compromising. Everyone thinks they’re being pragmatic. But pragmatism compounds. After enough pragmatic choices, your strategy starts to look suspiciously like your component library.

I don’t have a clean answer here. Part of me thinks you need to budget for strategic waste, deliberately build things that break your system just to keep the muscle memory alive. What I do know is that if your design system never gets challenged, if every strategic bet fits neatly into existing patterns, if your roadmap never requires new component primitives, you’re probably not actually testing strategy. You’re iterating on execution.

And at some point, the market changes in a way your component library wasn’t built for.