Smart app features that users actually want and use

There is a question that product teams rarely ask out loud: who is this feature actually for? The honest answer, more often than it should be, is that it is for the people who built it. It maps to something the founder wanted, or to a capability the engineering team found interesting, or to a competitor feature that felt threatening to ignore. Users end up with the result regardless.

The gap between what users say they want and what they actually use is where most product budgets quietly disappear.

What users want from an app tends to be quieter than what product teams build. They want things to feel predictable. They want to feel in control. They want the app to understand the moment they are in, not just the task they came to complete. These are not exotic requests, but they are routinely overlooked in favour of feature counts and parity tables.

We have seen this pattern across fitness apps, property tech, vehicle insurance tools, and social products. The projects that hold up are the ones where every feature was questioned, and many were cut. What follows is a collected account of what that process looks like in practice, what it costs when you skip it, and what changes when you do it properly.

Why Most Features Are Built for Builders, Not Users

Product development has a structural bias toward the people doing it. Founders are solving problems they personally experienced. Engineers are drawn to problems that are technically interesting. Designers want portfolios that showcase range. None of these motivations are wrong on their own, but they all point in the same direction: features that serve the team, dressed up as features that serve users.

The evidence supports this. According to The Standish Group's CHAOS Report, 2015, 45% of features in software projects are never used. That is nearly half of everything built, touching nothing real in a user's life.

The reason this keeps happening is that building feels like progress. Every feature added is a decision made, a checkbox ticked, a deliverable shipped. Removing a feature, or deciding not to build one at all, feels like regression, even when it is the better call. Teams rarely have the incentive structures to reward restraint, so restraint rarely happens.

The fix is a questioning habit: does this feature address something a user wants to do, or something we want users to do? Those are different things, and conflating them is where most of the waste originates.

The Vanity Product Problem

We have a name for what happens when a founder's conviction overrides user evidence: a vanity product. We identified this pattern across two separate projects, one a fitness and wellness app, the other a grassroots football product. In both cases, founders arrived with strong, personal conviction about what their product needed to be. Both ignored data emerging from research, focus groups, and surveys when that data contradicted the vision.

The signs were visible early. An excessive drive to perfect the product before launch. Rolling back sign-offs to request further changes. Decision-making that extended far beyond what the scope or timeline could support. We flagged this trajectory on both projects. In both cases, the budgets were exhausted in design and build, and neither product reached a fully live version.

This is not a rare failure mode. According to McKinsey research, 70% of product features fail to deliver expected business outcomes. The vanity product is one route to that number, but it is a particularly costly one because the people involved are often the most committed. Commitment to a vision and commitment to users are not the same thing, and when they diverge, the product is the one that suffers.

The question worth asking at every feature review is simple: whose problem does this solve? If the honest answer is "the founder's" or "the product manager's", the feature needs a much stronger justification before it moves forward.

What Research Actually Reveals About What Users Want

Users are not good at predicting their own behaviour, and that gap matters enormously for app user research and product decisions. When users are asked whether they would use a particular feature, the stated interest is often high. According to AppTweak, 60-80% of users typically respond positively when asked about a feature, but actual usage sits at only 10-20%. That spread is the difference between building something and building something that gets used.

What research more reliably reveals is the context around a task, not just the task itself. When we ran focus groups and user workshops for a property developer building a concierge app for high-rise properties, the client arrived with a pre-formed idea of the product they wanted and a budget they had already mentally committed. We convinced them to run a proper discovery phase before building anything.

What the research showed us was that the product they had imagined was far more complex than it needed to be. Many planned features were dropped entirely. The focus shifted away from digitising existing building systems and toward something more human: creating a genuine connection between residents, their concierge, and one another. The result was a better product and a lower final cost than the client's original estimate.

What users want is rarely what they say they want, and almost never what teams assume they want.

Good research does not confirm a brief. It challenges it. Teams that treat discovery as a validation exercise, rather than a genuine investigation, tend to find what they were looking for and miss what actually matters.

When a Clever Feature Becomes a Safety Problem

On a fitness social app, we were working with a product designed around real-time location sharing. The premise was straightforward: show users where nearby people were, so they could meet up for shared workouts. It was a sensible idea on paper, and the team behind it was genuinely enthusiastic about the social potential.

Research changed the picture. It revealed that a high proportion of users were female, and that precise, real-time location sharing created a significant security concern for that user group. A feature that felt enabling to one part of the audience felt threatening to another. The clever idea became a safety problem.

We redesigned it fundamentally. Rather than showing a user's exact location, the app would display only an approximate area, placing the person within a 200 to 500 metre radius. That was enough proximity data to tell a potential workout partner that someone was nearby. From there, users could view each other's profiles and message through the app's built-in chat before choosing to share their exact location.

Before launching any feature that involves personal data, map your full user profile against every edge case. A feature that works for your assumed user may actively harm a different group in your actual audience.

The redesigned approach preserved the core value of the feature while putting control firmly in the user's hands. The result was adoption the original design would never have achieved, because it was built around how users actually felt, not just what the product team hoped they would do.

Sequencing Trust Before High-Stakes Actions

The fitness social network redesign also revealed something broader about how products earn the right to ask for sensitive information. The original design asked for precise location immediately, before any social connection had formed. That sequence was the problem. A user who knows nothing about the person on the other side of the app has no basis for deciding to share their whereabouts.

The redesigned sequence built trust in stages. First, the app indicated rough proximity, enough to confirm a potential match was nearby. Then it enabled profile review. Then in-app conversation. Only after those stages had run their course could users choose to share their exact location and arrange a meeting. Every step earned the next one.

This sequencing principle applies well beyond location sharing. Any product that asks for something of personal or financial significance before it has demonstrated value to the user will face resistance. The resistance is the appropriate response to a product that has not yet justified the ask.

Map the trust journey before mapping the feature journey. Ask what a user needs to believe about your product before they will comfortably do what you are asking them to do, then sequence accordingly.

The products that do this well tend to be the ones that feel safe to use, even when they handle sensitive data. That feeling does not come from a privacy policy. It comes from the order in which things happen.

Context Is Not an Afterthought

On the concierge app project, one of the more detailed pieces of work involved notification timing. The client's instinct was a fixed schedule: send a welcome message two days after move-in. It is a reasonable starting point, but it ignores almost everything relevant about what moving home actually looks like.

We ran focus groups and scenario research to understand the real behaviour. Someone who arrives at a new property in the morning is likely to start unpacking that day. Someone who arrives in the evening almost certainly will not. A single person moving in alone takes longer to settle than a household of two or three. The fixed two-day rule would have landed the same message on people at entirely different points in their experience of moving.

The result was a dynamic timing system: notifications triggered not by a calendar delay but by arrival time and household size. Someone arriving at 9am with a partner would receive their first outreach at a different point than someone arriving alone at 8pm. The message was the same. The moment it arrived was calibrated to when it would actually land well.

Context shapes how information is received. A feature that delivers the right content at the wrong moment is still a poorly designed feature. Understanding the user's emotional state at the point of contact, not just their task state, is part of building something that feels considered rather than automated.

Simplicity as a Feature Decision, Not a Design Decision

There is a tendency to treat simplicity as a design problem. If something is too complex, the visual designers will clean it up, the UX team will reorganise the flows, and the copy team will make the labels clearer. Those things help, but they cannot rescue a product that has too many features. At some point, complexity is a product decision, and it has to be made at that level.

The concierge app project illustrated this directly. The client arrived wanting to give residents in-app access to everything: building information, maintenance requests, service bookings, and more. The stated goal was reducing demand on the concierge. What the research showed was that this approach would have produced a complicated product while removing the human interaction that actually made residents feel connected to their building.

We pushed back on the original brief. Rather than giving everyone access to everything, we argued for doing fewer things well and keeping the concierge visible as a person worth talking to. Each concierge was given a profile in the app listing personal conversation topics, football, motorsport, whatever applied, explicitly inviting residents to talk to them about those subjects. The goal was to model the kind of human conversation that builds community, rather than reduce the concierge to a transactional information desk.

Simplicity here was not a visual call. It was a decision to build less and to make what remained more human.

Small Changes That Shift the Numbers

One of the most consistent things we find is that the changes with the highest impact are rarely the most technically complex. On a fitness app, early abandonment during the onboarding flow was a problem. Users were dropping out during the orientation questions, a series of inputs designed to personalise the experience. The team's instinct was to redesign the question set.

The change that actually worked was simpler. We added a single line telling users how long the questions would take. That framing gave users the information they needed to commit to the process. They entered the orientation in a more prepared state, with realistic expectations, and they completed it at a higher rate. The questions themselves did not change. The context around them did.

A similar principle applies to how products ask for permissions. Asking permission rather than demanding access shifts something psychologically. "Can we connect your address?" lands differently to a pre-checked field the user has to opt out of. "Is it okay if we send you notifications?" creates a different relationship to "Notifications are on by default." The information exchanged is identical. The feeling of control is not.

These changes are available to any product team without a significant build. They require attention to the user's emotional state at each point in a journey, rather than attention to the task architecture alone.

Feature Parity Does Not Equal Adoption

A common strategic instinct is to audit what competitors have built and make sure your product matches or exceeds it. Feature parity becomes the benchmark. If they have a social feed, you build a social feed. If they have a recommendation engine, you build one too. The logic feels sound: users who want those things will have no reason to go elsewhere.

The logic is wrong, and there is substantial research confirming it. Feature parity does not drive adoption. What drives adoption is whether users feel the product understands their specific situation, their emotional state, and the context they are operating in. A feature that works in one setting cannot be transplanted into a different context and expected to perform.

The table below shows the difference between parity thinking and context thinking:

The vehicle manufacturer's accident reporting app is a clear example of context thinking at work. The original product had a reporting button. Users who had just been in an accident were expected to navigate to it, recall what information they needed to gather, and complete the form under stress. The feature existed. Almost nobody used it well.

We redesigned the product to use the device's accelerometer to detect a sudden stop after movement, then proactively ask "Have you been in an accident?" The app then guided users through voice memos for witness statements and visual diagrams showing exactly which photo angles to take. The same information was being collected. The context around collection changed everything.

How to Test Whether a Feature Actually Justifies Its Existence

Most features are never tested against a simple question: what happens if we remove this? Teams are willing to spend weeks debating whether to build something, but rarely willing to find out what life looks like without it once it exists. That asymmetry is where a lot of unnecessary complexity accumulates.

A structured way to evaluate any feature involves four questions. Work through them in order before committing to build, and again before deciding to keep something that already exists.

1. Does this mechanic serve a specific user need, or does it serve the product's engagement targets?
2. Does the user control how this feature behaves, or does the product decide on their behalf?
3. Can a user reduce or disable this feature without losing genuine value from the product?
4. If you turned this feature off for a subset of users, what would happen? If the honest answer is "we would never do that", the feature's real purpose is revealed.

Run the removal test on your three most used features and your three least used ones. The results are rarely what teams expect, and the conversation they start is usually worth having.

Nearly 60% of app features are rarely or never used, according to research cited by Futuristic Bug. That figure reflects the cost of building without this kind of accountability. A feature that cannot survive the removal question probably should not survive the roadmap either.

Conclusion

The apps users actually use tend to have one thing in common: they were built by people willing to remove things. Not people with the biggest budgets, or the most engineering capacity, or the longest roadmaps. People who kept asking whether what they were adding was genuinely serving someone.

The projects we have described here, the fitness social network, the concierge app, the accident reporting tool, the fitness onboarding flow, each involved a point where the right call was to do less. To drop a feature, to redesign a dangerous one, to simplify a flow, to let a question be answered before the next one was asked. Those decisions are harder to make than adding a feature, and they produce better products.

What we find, again and again, is that users do not want more. They want the right things, delivered at the right moment, in a way that respects where they are. That is a research question as much as a design question, and it has to be asked before a single line of code is written.

If your product is carrying features that nobody uses, or onboarding flows that lose people before they reach value, or permission requests that feel like demands rather than invitations, those are solvable problems. They are product decisions waiting to be made differently.

Let's talk about your product and find out which decisions are worth revisiting.

Frequently Asked Questions