You built 20 features.
Users use 4 of them.
Before you build feature 21, figure out why 16 are being ignored.
I see this constantly. Teams keep adding features while existing ones collect dust.
Here's why features don't get used:
1. They're hard to find (UX problem)
→ Buried in nested menus → No clear entry point → Poor information architecture → Users don't know it exists
2. Users don't understand the value (onboarding problem)
→ No explanation of what it does → Unclear use case → Missing examples or tutorials → Benefit isn't obvious
3. They solve problems users don't have (discovery problem)
→ Built based on assumptions → Stakeholder pet projects → "Nice to have" disguised as "need to have" → Solution looking for a problem
4. The workflow is too complex (design problem)
→ Too many steps → Requires too much context switching → Easier to use a workaround → Cognitive load is too high
The diagnosis before the prescription.
Before building more, understand why existing features aren't used:
→ Check analytics — Where do users drop off? → Watch session recordings — What are they actually doing? → Conduct user interviews — What do they think features do? → A/B test discoverability — Does better placement help?
This research costs $5K. New development costs $50K.
Do the math.
What usually happens.
Product team: "Users want X!"
Engineering: builds X
Nobody uses X
Product team: "Users want Y!"
Repeat until budget runs out.
What should happen.
Product team: "Users aren't using X. Let's find out why."
Conducts research
Product team: "X is actually useful, but it's hidden and the value prop isn't clear. Let's fix that before building Y."
The best features are the ones you don't have to build.
Because you made existing features discoverable and valuable first.
What's your process for evaluating feature usage?
#ProductManagement #UserExperience #FeatureDevelopment #ProductStrategy #SoftwareDevelopment
→ scopeforged.com
Philip Rehberger Founder, ScopeForged scopeforged.com
