Don’t be disheartened by the title—this is about a common issue in product development. Last week, PRIMO’s CPO, Mr. Paul Phawin, spoke at two consecutive events—the IRIS Practical Digital Design CoP and the Product Owner Meetup organized by the Thailand Startup Association. At both events, panels raised the issue: “Features people buy don’t get used, and features people use weren’t what they wanted.”
As someone working on the tech side, this really struck a chord. Often we spend so much effort building what the business requested, but after launch, only about 20% of features actually get real use, and the other 80% remain untouched.
There are two main perspectives I want to highlight:
-
First, I don’t want product builders to feel discouraged if something they worked hard on doesn’t get used.
-
Second, know that this is a universal challenge for product people—and it has academic or theoretical grounds behind it.
Why It Happens: 5 Core Causes
1. Law of the Vital Few (Pareto Principle)
By nature, users focus on the 20% of features that solve their main pain points. The rest may be seen as “extras,” no matter how much effort went into them.
2. Cognitive Load Limitation
People have limited bandwidth for learning new things. Extra features that aren’t necessary only add mental burden, so users often just ignore them.
3. Lack of Problem–Solution Fit
Some features emerge from ideas or market pressure rather than being validated with actual users—so they might not address a real problem.
4. Onboarding & Discoverability Issue
A great feature means nothing if users don’t know it exists or don’t understand how to use it—this leads to feature abandonment.
5. Behavioral Inertia
Users stick with old habits unless a new feature offers vastly better value or solves a major pain point. Small improvements don’t usually trigger change. And sometimes users use something just because they have to, not because they want to
When Loved Features Become Difficult: Recommended Action Plan
To avoid the frustration of building features that go unused:
-
Prioritize based on impact vs. effort, rather than trying to deliver on every request.
-
Continuously validate needs with both business stakeholders and actual users—what is really needed?
-
Design onboarding flows so that users discover and understand new features exactly when they need them.
So for those of us working in the system, we might need to be a little less discouraged. It can be tiring to build something that no one uses, but instead of feeling disheartened, it’s better to look at the data and ask why it wasn’t used—then keep improving from there.
| Because ultimately, “a system that actually gets used” is better than “a system full of modern technology and beautiful design that no one uses.” |
Even if we’ve already built it, if no one uses it, we must accept that and move on. Keep going—you’re not alone. Many friends in the field feel the same.
But if you really want to make a product that users deeply understand and truly use >> Read more