The software you paid for that delivers nothing: when 80 % of features serve no one

You fund the development of a piece of software, your team or your supplier delivers feature after feature, and yet the result disappoints. It is not just an impression: studies show that up to 80 % of the features of a software product are almost never used. That is one development in two, sometimes more, paid for nothing. The cause is not technical, and the missing link has a precise name: the Product Owner.

An SME invests in developing a bespoke tool, or in extending an existing platform. The weeks go by, the budget drains away, the technical team conscientiously delivers what it was asked for. Then comes real use, and the cold shower: users work with a handful of screens, ignore half the features, and ask for simple things that were never prioritised. The software works perfectly. It is simply not much use. This waste has a single origin: nobody decided what really mattered.

The figure the industry knows and keeps quiet

The data is familiar to professionals and rarely mentioned to clients. By analysing the actual use of features in enterprise applications, the Standish Group established that 64 % of them are rarely or never used, and 45 % never at all. More recently, the software vendor Pendo, working from usage data on hundreds of software products and tens of thousands of applications, found worse still: around 80 % of features are rarely or never used, and only about 12 % generate 80 % of daily use. Translated into money, that means the majority of the development effort on most products funds things that users do not value enough to touch.

The real problem: nobody says no

Why do we build so many useless things? Because in most projects, every stakeholder adds their own requests and nobody arbitrates. Sales wants one option, accounting another, an important client has asked for a feature, the leader had an idea in a meeting. With no one to rank and refuse, the scope swells, the technical team builds everything, and the budget dissolves into features nobody will use. Software development almost never fails for lack of technical skill: it fails from an excess of things built and an absence of prioritisation. Activity is mistaken for value.

The Product Owner, the decisive link

In agile methods, one role exists precisely in order to solve this problem: the Product Owner. Their job is not to code, it is to decide. They own and rank the backlog of requests, they translate the business need into clear priorities for the technical team, and above all they decide: what gets done now, what gets pushed back, what will never be done at all. They bridge the leader, who knows the business value, and the developers, who know the technical cost. They are the guarantee that every euro of development goes towards what pays, and not towards what clutters. Without that role held firmly, a software project almost always drifts into a catalogue of useless features.

Why SMEs do not have this role, and how to get it

Most SMEs have no Product Owner. The leader lacks the time and does not always have the method, the technical team ends up deciding business priorities it does not command, and the external supplier builds what it is ordered to build without challenging the relevance. The result is predictable. Yet this role does not require a full-time hire: it requires method, presence at the key moments, and the mandate to decide. That is exactly what a fractional Product Owner brings, by setting the development cadence, holding the prioritisation, and protecting the budget against request inflation. The return on investment shows quickly: fewer features built, more features that are useful.

Build less, deliver more value