Feature Bloat Is the Temu Problem in Software
estimated read time: 5 minutes
Feature Bloat Is the Temu Problem in Software
I bought a flashlight on Temu. It worked twice.
I'll spare you the moral high ground — I've bought things on those platforms, and I'm willing to bet you have too. There's something almost hypnotic about it. Prices so low they feel like a loophole in capitalism. Your cart fills up before you realise what's happening. For a brief moment, it feels like winning.
Then the parcels arrive. The flashlight sits in a drawer. The gadget solves a problem you never actually had. The thrill of cheap gives way to the quiet guilt of clutter. And slowly, all of it makes its way to the bin — plastic, electronics, packaging.
I've started noticing the pattern everywhere. Every time an ad flickers across my screen, every time I catch myself reaching for the cart, the same thought surfaces: I'm buying junk. Not always. But often enough to see the structure beneath the impulse. Things that are cheap to acquire have a way of being cheap in every sense of the word.
Software has the same structural problem
We're entering an era where producing software has never been cheaper or faster. AI coding agents, no-code platforms, offshore teams, rapid prototyping — features ship at a pace and price that would have seemed delusional three years ago. By 2026, 78% of organisations have integrated agentic AI into their primary development workflows. The governor is gone.
And just like a Temu cart, it's very easy to fill up.
Stakeholders say we want everything. Product teams say why not — it's fast. Before long you've got a bloated product full of features that nobody uses, a codebase that nobody fully understands, and a user experience that feels like navigating a warehouse instead of using a tool.
The numbers confirm the damage. 64% of all developed software features are rarely or never used by customers. Nearly half are never touched at all. That's not a rounding error. That's the majority of what gets shipped, sitting in a digital drawer next to my dead flashlight.
Feature bloat is the condition where continuous addition of new functionality overwhelms a product's core value. Every feature must be built, tested, documented, maintained, and explained to new users. But the cost isn't in the building anymore — AI took care of that. The cost is in the keeping. Maintaining features nobody uses. Onboarding users into complexity they didn't ask for. Debugging interactions between seventeen subsystems when the product only needed three.
You built a lot. Cheaply. Quickly. Most of it is junk.
The Age of Taste
In the e-commerce world, the companies pushing back against the race to the bottom aren't the ones making things cheaper. They're the ones curating better. The same shift is arriving in software.
Taste in product management is the evidence-backed discipline of distinguishing between a feature that sounds exciting in a workshop and one that genuinely changes how a user works. It means resisting the temptation to build something just because you can, and asking instead whether you should.
This is what we called the Age of Taste in the Wingman manifesto. The idea is structural: in a world overflowing with cheap options, the most valuable thing you can offer isn't more. It's better. Fewer features, more clarity. Less capability sprawl, more value per interaction.
The companies that win the next decade of software won't execute fastest. They'll decide best.
That's the uncomfortable truth nobody in the "ship fast" discourse wants to hear. Speed without signal crashes planes. When any team on earth can ship ten features this week, "fast" stops being the edge. "Right" does.
Why we built Wingman
The people closest to a product — its users and its stakeholders — are often the worst judges of what it needs. Not because they're wrong, but because they're human. They want everything, the same way I want to fill my Temu cart. The pull of what if we also had… is almost impossible to resist in the moment.
WingmanPM exists to be the voice of taste in that conversation. It takes raw, unstructured customer feedback — the support tickets, the NPS responses, the scattered signals buried across six tools — and turns them into evidence-backed priorities. Not opinions dressed up as data. Actual signal, traced to source quotes, scored with rationale you can read and challenge.
The problem was never that teams don't build fast enough. The problem is that nobody has a reliable, continuous read on what's worth building. In a world where code is essentially free, that gap compounds faster than ever.
Cheap and fast is only an advantage if what you're building is worth building.
If this resonates, read the full manifesto — it's the clearest statement we have of what we're doing and why.