The cost of building faster than you can explain
We talk a lot about technical debt. But we talk a lot less about what happens when product innovation outpaces an organization’s ability to explain it.
I’ve been thinking about this lately because I’ve seen versions of the same problem show up across startups, scale-ups, and enterprise organizations. A team ships something new. A PM demos it. Sales gets excited. A customer hears about it. Someone references it in a deck. Someone else mentions it in a renewal conversation.
A few weeks later, everyone is talking about the thing. The problem is that nobody has actually agreed on what the thing is.
What started as a feature becomes five different interpretations of a feature. Product teams have one understanding. Sales has another. Marketing has a third. Customers have built their own version entirely.
And that’s where I think narrative debt begins.
Narrative debt: what gets built accelerates, what gets understood lags, and the gap between them compounds.
The concept borrows heavily from technical debt. Ward Cunningham described technical debt as the future cost of decisions made in the interest of speed. The issue was never taking the shortcut. The issue was forgetting you took it and allowing the interest to compound.
Narrative debt works similarly. Every time product velocity outpaces organizational understanding, we borrow against future clarity.
What’s interesting is that this isn’t usually the result of failure. Product teams should be moving quickly. Sales teams should be talking about things customers care about. Marketing teams should be trying to keep up with a moving target. Customer Success teams should be focused on adoption and value realization.
Everyone is doing exactly what they’re supposed to do. But the debt accumulates anyway.
Once you start looking for it, it’s surprisingly easy to spot. Sometimes it’s a feature that gets demoed long before anyone has decided how to position it. Sometimes it’s a capability that engineering understands perfectly, but customers struggle to connect to business value. Sometimes it’s a website, sales deck, and product page that all describe the same thing differently. Sometimes it’s positioning from eighteen months ago still influencing customer conversations even though the product has evolved far beyond it.
None of those issues seem particularly dangerous on their own. Together, they create organizational drag.
What makes narrative debt harder to manage than technical debt is that there isn’t a repository to inspect. Technical debt lives in systems. Narrative debt lives in people. It lives in customer assumptions, sales conversations, executive presentations, onboarding materials, analyst briefings, conference demos, and product reviews. By the time you discover it, you’re usually looking at a symptom rather than the cause.
A customer expected something different, or a launch didn’t land, or a sales cycle stalled, or a competitor successfully framed your category before you did. Or a combination of the above.
The challenge isn’t that narrative debt exists. The challenge is that most organizations don’t account for it. We track launches. We track adoption. We track pipeline. We track feature velocity.
But very few teams have the means or the time to track understanding.
That becomes especially apparent when conversations shift to launch tiering. Not every release deserves a major campaign. Not every feature needs a webinar, an analyst briefing, a sales enablement program, or an announcement strategy. That’s a smart adjustment and, frankly, a necessary one.
On the flip side, launch tiering and narrative debt are solving different problems.
Tiering helps teams manage attention. Paying down narrative debt is about managing understanding. It’s about ensuring translation happens on purpose, not by accident, because the understanding gets built either way; the only question is whether you built it or the market did.
A release doesn’t stop creating expectations simply because it wasn’t important enough to launch broadly. Customers still see it. Reps still talk about it. Successful teams still support it. The feature still enters the market whether or not marketing formally announces it.
Which means every decision around releases and launching creates the next question: What understanding still needs to exist? That’s the question I don’t see enough teams asking.
Because that’s ultimately what narrative debt measures. Not whether a feature shipped. Not whether a campaign ran. Not whether a launch happened. It measures the gap between what an organization knows and what its customers, prospects, partners, and internal teams understand.
The companies that seem to manage this best don’t necessarily launch more. They translate more.
Consider Apple and Notion.
Apple rarely lets a capability reach customers without a shared narrative around it. Engineering complexity goes in one side; a simple, human explanation comes out the other. The customer doesn’t need to understand the underlying architecture. They need to understand why it matters.
Notion faces a different challenge. The product is incredibly flexible, which makes it difficult to explain consistently. Rather than relying on a single positioning statement, they built templates, use-case libraries, and a community that continuously translates the product into practical outcomes.
Different approaches. Same discipline. Neither company assumes understanding happens automatically.
That’s the trap I believe many organizations fall into. From the outside, clarity looks effortless. In reality, clarity is usually the result of deliberate alignment. It’s the product of difficult conversations about positioning, naming, prioritization, and customer value. Simplicity is rarely the starting point. It’s the outcome.
That’s why I increasingly think organizations need the equivalent of a narrative debt register.
Engineering teams track technical debt. Product teams track roadmap commitments. Yet few organizations systematically track where understanding has drifted from reality.
Features that have been demoed but never fully positioned. Capabilities customers consistently misunderstand. Messaging that differs across channels. Legacy narratives that continue shaping expectations long after the product has evolved.
Not because every gap requires an immediate action, but because visible debt can be managed. Invisible debt compounds.
A simple diagnostic might be enough to start:
- Can Product explain it?
- Can Sales explain it?
- Can Customer Success explain it?
- Can a customer explain it back?
If those answers don’t sound roughly the same, narrative debt is probably accumulating somewhere.
Which is why I increasingly think one of the most important responsibilities of product marketing isn’t launches, campaigns, or collateral. It’s managing the gap between what gets built and what gets understood. Especially with the pace of change occurring across organizations today.
The debt will accumulate regardless. Product shouldn’t slow down. The roadmap shouldn’t slow down. The market certainly isn’t slowing down.
But if understanding is a prerequisite for adoption, organizations need to manage it with the same intentionality they bring to managing technical debt.
We have mature disciplines for tracking code quality, product delivery, and revenue performance. I’m not convinced we have one for tracking understanding yet.
If that discipline is going to exist, the register it produces has to stay alive — and a living document needs a trigger: something that says now, not next quarter. Chris Butler, a product manager at GitHub, frames this as a shift from Chronos to Kairos — from calendar time to the right time. I’ve been chewing on his Pendomonium talk since March; there’s more I want to say about it for another time.
Most teams revisit their messaging because it’s the quarterly cycle, not because anything has actually moved. But narrative debt doesn’t accumulate on a schedule. It accumulates when a competitor reframes the category, when a feature ships ahead of its positioning, when Sales and Customer Success quietly begin describing the same capability in two different languages. The register should be opened when those signals fire — not when the calendar says it’s time.
There’s a deeper obstacle, too. For most of its history, narrative debt has been impossible to inspect precisely because it lives in people, not systems. There was never a repository. But if agents can now absorb the toil of documentation and connection — linking decisions, messaging, and customer feedback into something maintained rather than assumed — then narrative debt may finally get a repository of its own. Agents handle the toil; humans handle what it means. It’s worth sitting with how strange that is. Technical debt always had a codebase to point at. Narrative debt never did. That may be changing.
And it returns us, oddly, to where the metaphor began. In Ward Cunningham’s original formulation of technical debt, the debt was never really about messy code — as Michael Feathers has argued, it was about the growing distance between what a team had come to understand and what its system actually reflected. Narrative debt simply relocates that distance from the codebase to the market.
Which means it was always the same work: closing the gap between understanding and reality before the interest comes due. There’s an irony worth naming — the term technical debt itself fell victim to what Martin Fowler calls semantic diffusion, its original meaning worn down as it spread, until “understanding gap” quietly became “bad code.” The metaphor I’m borrowing is, fittingly, its own best example. The difference now is that we may finally have the tools to see the gap before it diffuses.
My hypothesis: The organizations that build that repository first, and make it a consistent discipline, the one narrative that was never had in the first place, may just launch better. But even more importantly, they’ll get closer to understanding what they mean along with everyone else.
TL;DR
Narrative debt slows understanding.
When understanding breaks down, trust follows shortly behind.
And trust is what keeps customers around long enough to realize the value you built in the first place.