When Good Teams Get Forced Into Bad Narratives

I run dozens of roadmap clinics every year, and there’s a version of the same conversation that keeps repeating. A platform lead, an infrastructure team, a design systems group, someone responsible for enabling work sits down and walks me through their roadmap. The work is solid. The reasoning is sound. And then they get to the part where they have to explain how any of it maps to the organization’s OKRs.

That’s where things fall apart.

The objectives are always oriented around subscriber growth, revenue, conversion rates, activation. Standard product metrics. And the platform lead is stuck trying to explain that improving core web vitals is, if you squint hard enough and do some napkin math, “one mathematical operation away” from something the exec team actually cares about. They know the work matters. Their exec team wants a number. And the framework they’ve been handed was never designed to produce one for this kind of work.

The OKR Framework Isn’t the Problem

OKRs are a genuinely useful tool for aligning teams around outcomes. The logic behind customer-centric OKRs is clean: set an objective that describes a future benefit, measure it through changes in customer behavior, and give teams the autonomy to figure out how to get there. Jeff Gothelf and Josh Seiden have been advocating for this approach for years, and they’re right. For product teams building features that end users interact with directly, that model works beautifully. You can observe the behavior change. The outcome is measurable. There’s a straight line between what you shipped and what moved.

The problem shows up when organizations take a framework optimized for one type of team and apply it uniformly across every team, regardless of what that team actually does. Platform teams, infrastructure teams, internal tools teams, developer experience teams, design systems teams. These groups exist to make other teams faster, more reliable, more capable. Their “customers” are internal. Their impact is indirect. And the OKR framework, as most companies implement it, has no native vocabulary for that.

Want to see how OKRs connect to roadmap initiatives in practice? Explore the ProdPad sandbox and see OKRs, roadmaps, and ideas linked together in a live environment.

What the Translation Tax Actually Looks Like

Every quarter, enabling teams go through a ritual that product teams rarely have to endure. They take work that has clear value (reducing deployment time, improving API reliability, consolidating authentication flows, paying down technical debt) and spend hours, sometimes days, translating it into the language of external customer outcomes.

The mathematical gymnastics

A platform lead improving CI/CD pipeline speed doesn’t get to say “we cut deploy time by 40%.” They have to construct a chain: faster deploys mean more frequent releases, which means faster iteration on features, which means features ship sooner, which means customers get value sooner, which theoretically improves retention. By the time you’ve built that chain, you’ve wandered so far from the actual work that the OKR reads like a creative writing exercise.

The borrowed metric problem

Because enabling teams can’t easily claim a customer-facing metric, they end up “borrowing” one from a product team. The platform team says their work will contribute to improving activation rates. But activation depends on dozens of variables, most of which the platform team has no control over. When the number doesn’t move (or moves for reasons unrelated to infrastructure), the platform team’s work looks like it failed, even though it delivered exactly what it was supposed to.

The output trap disguised as outcomes

Under pressure to show measurable results, enabling teams often retreat to output-based key results. “Ship the new service mesh.” “Complete the migration to the new auth provider.” These aren’t outcomes. They’re tasks. But they’re the only things the team can guarantee, because the actual outcomes of their work are felt downstream, in other teams’ numbers, on other teams’ timelines.

Product teams and enabling teams incur a “context-switching tax” every time they have to adapt to each other’s operating models. John Cutler has written extensively about this dynamic, and the same pattern applies to goal-setting. When enabling teams are forced to express their work in product team terms, the translation itself consumes energy and introduces distortion.

Struggling to articulate the value of enabling work on your roadmap? Book a free roadmap clinic and bring your real challenges. No demo, no sales pitch.

The Structural Incentives That Make This Worse

The translation tax would be annoying on its own. What makes it genuinely harmful is how organizations respond when enabling teams can’t produce clean OKRs.

Budget conversations become existential

In most companies, budget allocation is tied to demonstrated impact. If a team can’t show a measurable connection between their work and a business metric, they look like a cost center. Platform teams that can’t articulate their strategic value fall into an “expensive request taker” pattern: they fulfill whatever other teams ask for, lose the ability to prioritize strategically, and face constant pressure to shrink. The team that can’t write a compelling OKR gets a smaller budget next quarter. The smaller budget means less capacity, which means slower enabling work, which means product teams slow down too. But the budget cut happened to the platform team, not the product team, so the root cause stays invisible.

Performance reviews punish the wrong behavior

Individual contributors on enabling teams often find their own performance tied to OKR achievement. If the team’s OKRs are poorly suited to the work (and they almost always are), the people doing genuinely critical work get mediocre performance scores. Over time, this drives talent away from enabling roles. The best engineers and designers gravitate toward product teams where the impact is legible and the career trajectory is clearer.

Strategic misalignment compounds silently

When platform work gets chronically undervalued, companies accumulate a kind of organizational debt. Systems degrade. Developer velocity slows. Security vulnerabilities linger. None of this shows up in quarterly OKR reviews because nobody’s OKR is “maintain the foundations.” By the time the damage surfaces (an outage, a breach, a product team that suddenly can’t ship anything because the platform can’t support their needs) the cost is orders of magnitude higher than continuous investment would have been.

What Enabling Teams Actually Need From a Goal Framework

The solution isn’t to exempt enabling teams from goal-setting. Teams without clear objectives drift. They become service desks, reactive and unfocused, which is its own failure mode. The solution is to design goal-setting that fits the actual shape of the work.

Recognize internal customers as real customers

The framework for writing OKRs when your customers are internal starts with a deceptively simple insight: platform teams do have customers. They’re just internal. Jeff Gothelf and Josh Seiden have laid this out clearly. And those customers have behaviors that can be observed and measured. If your platform team supports product teams, you can measure how often those product teams deploy, how long they spend on boilerplate work, how frequently they encounter integration issues. These are legitimate outcomes. They’re just not the outcomes that show up in the company’s external metrics dashboard.

Separate the “what” from the “so that”

A useful pattern is to let enabling teams own objectives at their own level of abstraction, and then explicitly map the connection to downstream outcomes without collapsing the two into a single OKR. The platform team’s objective might be: “Reduce average deployment cycle time for product teams by 30%.” The documented rationale (not a key result, but an explanatory layer) connects that to the company’s broader goals. This preserves the integrity of the team’s actual work while maintaining strategic alignment.

Build roadmaps around the work, not the borrowed metric

This is where tooling matters. When your roadmap shows initiatives connected to objectives, and those objectives are explicit about what level of the organization they serve, the enabling team’s work becomes visible in its own right. The roadmap tells the story of what’s being done, why it matters, and how it connects to broader strategy, without forcing every initiative through a single, ill-fitting OKR lens.

In ProdPad, we’ve seen teams use portfolio-level and product-level objectives precisely for this kind of separation. Company-level OKRs capture the big external outcomes. Product-level OKRs capture what individual teams (including enabling teams) are driving toward. The connection between them is explicit but not forced. Each team’s roadmap is coherent on its own terms.

The Organizational Pattern Behind the Problem

There’s a deeper pattern worth naming. Organizations tend to design their operating models around their most visible teams. Product teams are visible because their output faces the customer. Sales teams are visible because they generate revenue. Enabling teams are invisible by design. Their whole job is to make other people’s work better. When the operating model rewards visibility, it structurally disadvantages the teams whose success looks like other teams’ success.

This isn’t a problem you can fix with better OKR coaching alone. It requires a decision at the leadership level to recognize that not all valuable work produces the same kind of signal, and that the absence of a clean metric is not the same as the absence of value.

The concept of organizations getting trapped in the “build trap” by measuring output over outcomes is well documented. Melissa Perri has made this case for product teams. The parallel for enabling teams is the “narrative trap”: being measured by someone else’s outcomes, and losing credibility when those outcomes don’t neatly correspond to the work being done.

What Senior Product Leaders Can Do

If you lead a product organization that includes platform, infrastructure, or enabling teams, this is your problem to solve. The people doing the enabling work already know it matters. What they need is an operating model that reflects that.

Audit your OKR structure for team-type blindness

Look at your current OKRs. Are they all framed in terms of external customer behavior? If so, you’ve implicitly told your enabling teams that their work doesn’t count unless it can be shoehorned into someone else’s metric. Add a layer of internal-facing objectives that enabling teams can own with integrity.

Make enabling work visible on the roadmap

If your company uses a single roadmap format that only shows customer-facing initiatives, enabling work becomes invisible. Create roadmap views that surface platform and infrastructure initiatives alongside product work, connected to their own objectives. When enabling work is visible to leadership, it stops being treated as overhead and starts being treated as investment.

Fund enabling work as a portfolio allocation, not a project justification

The worst version of this problem is when enabling teams have to write a business case for every quarter of their existence. Platform investment should be a standing portfolio allocation, reviewed for effectiveness, not a project that has to be rejustified against product team metrics every cycle.

Stop asking enabling teams to “tell the story” of their impact

This advice gets given constantly, and it’s well-intentioned, but it papers over the structural problem. Enabling teams shouldn’t have to become storytellers to survive. The operating model should make their contribution legible without requiring a narrative performance every quarter.

The Framework Isn’t Wrong. The Application Is.

OKRs work. They’re a powerful alignment tool. But alignment breaks down when the framework is applied as if every team operates the same way, faces the same measurement landscape, and produces the same kind of output. The moment you force a platform team to express their work as a derivative of someone else’s customer metric, you’ve introduced a distortion that makes the whole system less honest.

The best organizations I see in roadmap clinics have figured this out. They run OKRs at multiple levels. Enabling teams get objectives that match the actual shape of their work. The roadmap becomes the connective tissue that shows how platform investment supports product outcomes without collapsing the two into a single narrative. And enabling work is treated as an investment in capability, visible and valued on its own terms.

Bad OKRs don’t just produce bad goals. They force good teams into bad narratives. And when that happens often enough, the good people on those teams stop fighting the framework and start looking for somewhere that values what they do.

The system is the thing to fix. The teams are already doing the work.