The most successful software product in the history of finance is ugly, looks like the 1980s, and costs around $32,000 a year per user. Most of the people paying for it use a tiny fraction of its thousands of functions. By any “feature” metric, the Bloomberg Terminal should have been displaced decades ago.
It hasn’t. It brings in over $12 billion a year, almost all of it subscriptions. And the interesting question isn’t why it’s so expensive. It’s why nobody leaves.
Bloomberg doesn’t sell features, it installed a behavior
A trader builds their whole day around that black-and-amber screen: the keyboard, the shortcuts, the workflow. Its internal chat, Instant Bloomberg, connects around 325,000 professionals. If your counterparty is there, you have to be there. Leaving the Terminal isn’t switching tools, it’s switching professional lives. The cost of leaving isn’t financial, it’s psychological.
That’s what making product is: installing a new behavior in someone. Tomorrow they do something different from yesterday, decide differently, work differently, because your product makes it easier, more obvious, or more inevitable. If nobody changes anything, you didn’t make digital product. You made software, which is not the same thing and not even close.
I read recently that PMs are useless. Whoever says that has never made product in their life, and is confusing making product with productizing, the dumb easy brother of making product.
Productizing: surface with nothing underneath
Productizing is the opposite: adding surface without installing anything underneath. An integration because a competitor has it. An alert because a big customer asked. A new view because someone in a meeting said “it’d be nice to have.” Each one has its own individual logic. None has a target behavior behind it. Locally correct, globally incoherent, and this isn’t only an AI thing.
The difference is real, and it’s been measured.
Pendo analyzed real product usage across hundreds of companies and found that 80% of the features in average software are used rarely or never. Just 12% drives 80% of daily use. Their estimate: around $29.5 billion of cloud R&D spent on features almost nobody touches. The classic Standish Group Chaos report gave a similar figure: roughly 64% of features used rarely or never. The methodologies of both studies are debatable, worth knowing, but the direction is the same however you measure it.
That’s what productizing at scale produces: surface that exists without changing anything, more and more team to maintain something that adds nothing to the bottom line. Well, it adds something: a drag on it.
The feature factory
Why do almost all organizations end up there? John Cutler named it the feature factory: companies that measure success by how much they ship (features launched, story points closed) instead of by what changes in the user.
The funny thing is they’re usually productive in the conventional sense: they ship fast, keep velocity high, show a visible record of finished work. They’ve optimized the activity of building, not the result of building. And they fall into it without meaning to, because productizing produces immediate signals of progress (releases, demos, changelogs, meetings where you show something new) while changing behavior is invisible for months. Almost no organization rewards the invisible. It rewards activity. And productizing is activity.
The button with the little star
The textbook example is right in front of us. In 2024 and 2025 half the software industry dropped an AI “copilot” in the corner of the screen, a button with a little star. Why? Because investors and the market expected it.
The result was predictable when you add surface with no map of behavior. Some CRMs saw adoption drop around 20% after rushed AI launches that complicated the experience, and a majority of enterprise AI pilots ended with no measurable impact on the bottom line. The button went in to exist, not to change what the user does. And an AI feature that doesn’t change the workflow is, exactly, one more feature nobody uses.
2026: AI puts Bloomberg to the test
Here’s where it gets interesting. That same AI has started testing Bloomberg. Perplexity launched a product aiming to replicate part of the Terminal’s flow for around $200 a month against nearly $32,000 a year. According to an industry survey, about a third of hedge funds and asset managers plan to reduce or drop terminals over the next 18 months.
And this is what matters for anyone building product: when the cost of switching collapses, you find out whether you installed a genuine behavior (something the user wouldn’t abandon even if leaving were free) or whether you were just living off friction and subscription inertia. AI is about to do two things at once: make any feature cheap to copy, and make any switching cost cheap to cross. The only thing that survives both is having genuinely changed what someone does.
The one test worth running
From there comes the one test worth running before anything goes on a roadmap. Complete this sentence before you write a single line of spec:
Thanks to this, [type of user] will go from doing [X] to doing [Y], and we’ll know it when we see [metric Z].
If you can’t complete it, you don’t have a product idea yet. You have a feature idea. Not the same thing, and the difference compounds over time: installing behavior creates accumulated advantage (the user comes back because they’ve reorganized their life around that habit), accumulating features creates attention debt (more options, no stronger reason to stay).
I’m not saying productizing is bad. Sometimes it’s the right call: reaching competitive parity, not losing a customer threatening to leave, buying time. The problem isn’t doing it. It’s doing it on autopilot, without knowing it, until you’ve gone two years unable to answer a simple question: what new behavior did we install this quarter?
That, in the end, is the one question that separates the two kinds of team. And in the coming decade, when copying a feature costs an afternoon and crossing a switching cost costs a $200-a-month subscription, it’s going to be the only one that matters.
That test, “from X to Y, we’ll know with Z,” is the parent of acceptance criteria. First you decide what behavior you install; then comes the engineering discipline of making sure the code actually delivers it, because a green build is not a correct feature. That second part is what PaellaDoc automates. The first part is yours, and if you struggle to answer the question, you already have the answer.