When you’re early, “shipping” feels like the whole game.
You’re building the thing. There aren’t many users. There’s no habit to break. Every feature is a step toward something that doesn’t exist yet: a product someone would choose.
In that phase, adoption is almost a meaningless metric. Not because it doesn’t matter, but because the only people who can adopt are the few people you’ve managed to convince to try an unfinished product. If they don’t use a feature, it might be because they’re not the right customer, or because they haven’t had time, or because the feature is rough. You still ship it. You’re not optimizing the present. You’re constructing the future.
Then you get customers. Real ones. Not “design partners” who like talking to founders, but customers who are busy and paying and trying to do their job.
And without anyone choosing it, your product becomes something else: a system.
That’s when shipping changes.
The first thing you notice is that your new features don’t land the way you imagined. You ship something that would have been a huge deal six months ago, and adoption is… fine. A handful of customers find it. A smaller handful use it. Most don’t.
At first you assume this is a marketing problem. You need better announcements. Better emails. Better videos. You need to educate.
But what’s really happening is more basic: your customers have a limited budget of attention. And you’re spending it faster than they can earn it back.
Every product has a rate at which it can change without making people feel lost. You only find that rate after you exceed it.
The weird part is that this can happen even when you’re doing well.
It can happen because you’re doing well—because the cost of building features goes down, or your team gets more capable, or the product gets more modular, or AI makes implementation cheaper, or you simply get into a rhythm. Suddenly you can ship ten new things a month. And it feels like progress.
But if you ship ten new things a month, your customers are not adopting ten new things a month. They’re adopting maybe one, or two, or none. Not because they’re stubborn, but because they already have a workflow that works “well enough,” and switching costs are real even when the new thing is better.
This creates a new kind of gap: not between what you could build and what you have built, but between what you’ve built and what your users know exists.
At that point, it’s tempting to treat adoption as the master metric. If customers aren’t using a feature, the feature is a failure. You shipped the wrong thing. Or you shipped it badly. Or you didn’t educate.
Sometimes that’s true. But not always.
The mistake is assuming there’s one definition of “success” for a feature.
There are at least two.
One definition is: a feature succeeds if your current customers adopt it.
That’s a sensible definition when the feature exists to make current customers happier: reduce churn, reduce support, make work faster, increase expansion. In that world, shipping a feature that only 20% of customers use might be a miss, because the point was to improve life for most of the base.
But there’s another definition: a feature succeeds if it increases the product’s ability to win.
In that world, adoption among your existing customers can be low and the feature can still be a big win.
Because your existing customers aren’t the market. They’re the past market. They chose you based on the product you had then, plus a little optimism about what you might become. They built workflows around the old shape of the product. They have habits. They have workarounds that are “good enough.” They don’t re-evaluate your product every week.
New prospects do.
A new customer is the only kind of customer who fully sees your product. They look at the whole thing at once. They’re paying attention. They’re comparing. They’re deciding. For them, a feature can matter enormously even if none of your old customers ever use it.
This creates a funny situation: you ship a feature, and only 20 out of your 100 current customers adopt it. It looks mediocre.
Then you sign 100 new customers, and 90 of them use that feature, because it’s part of the reason they signed. Or because your onboarding naturally leads them to it. Or because they don’t have the old habit that competes with it.
Was the feature a success?
If you only look at the installed base, you’d say no.
If you look at the product’s trajectory, you’d say yes.
This isn’t a corner case. It’s a pattern.
Most features that change onboarding, defaults, or “how you’re supposed to do things” will be adopted much more by new customers than by old ones. Old customers are not blank slates. They already learned your product once, and learning it again has a cost. Often the cost is not time; it’s disruption. You’re asking them to trade certainty for possibility.
So the real question isn’t “should we ship for existing customers or future customers?” You almost always do both. The question is: what do we expect this feature to do?
And if you don’t answer that, you end up with a roadmap that’s hard to judge, because you’re judging different kinds of work with the same yardstick.
You can see this in how teams argue.
When a product team ships a feature that helps win deals, someone says, “But our customers aren’t using it.”
When a product team ships a feature that improves retention, someone says, “But it won’t move new ARR.”
Both are right. They’re just using the wrong scoreboard.
The deeper thing you’re noticing—especially once you have a meaningful customer base—is that you need an explicit vector. Not forever. But for a period.
At any point, you can choose to optimize more for:
- extracting more value for the installed base, or
- building the product that wins the future market.
Even if those overlap, the emphasis changes how you allocate effort.
If you’re optimizing for the installed base, you should be paranoid about adoption. A feature that isn’t adopted is wasted complexity. It increases cognitive load, support burden, and the feeling that the product is “always changing.”
If you’re optimizing for future market capture, you accept that not everything will be adopted by the current base. Your goal is not to convert the past. It’s to shape the next cohort.
But there’s a constraint that applies in both modes: you can’t let shipping outrun comprehension forever. If you do, you start accumulating “value debt”—features that exist but don’t change outcomes because people never absorb them. And the product starts to feel heavy, not powerful.
This is why the bottleneck shifts. Early on, the bottleneck is building. Later, the bottleneck is making new capability become normal.
That doesn’t mean you need more newsletters. It means you need to decide what kind of feature you shipped, and make sure it meets the standard for that kind.
If it’s for the installed base, it needs a path to adoption. Not a blog post. A path.
If it’s for winning, it needs to show up in deals, onboarding, and evaluation. Not as “we also have this,” but as a reason to choose you.
Once you start thinking this way, you stop treating low adoption as a generic failure. Sometimes it’s failure. Sometimes it’s lag. Sometimes it’s simply that you built something for the future, and your current customers are living in the past you created for them.
And that’s not a bad problem to have.
It just means you’re no longer only building a product.
You’re managing time.