TL; DR
Innovators often mistake everyday "frictions"–things that are annoying or limit us somehow–for "problems" that users are motivated to solve.
The key difference: a problem is a friction that people are already trying to fix. If users aren’t taking action, you’re likely chasing a friction, not a real problem. In that case, people may just see it as an everyday part of life; annoying maybe, but not a priority.
To build products that matter, look for evidence that users are already hacking together solutions or making sacrifices to overcome an issue.
Why do users ignore "obvious" problems?
You've done the ethnography. You've heard users' pain. You can feel it! You create a great solution. People confirm how awesome it is. And then ... nothing. No market traction.
I've run into versions of this issue way more often than I'd like to admit. And it's so frustrating!
But eventually, I came to find a litmus test to look for in the field:
Those are "frictions" but not "problems!"
It's tempting for innovators to conflate friction with problem. Here’s the difference:
- Friction: Anything that’s less than ideal–a gap between what users wish for and what reality delivers.
- Problem: A friction that’s painful enough that people are actively trying to solve it, even if their attempts are clunky or incomplete.
For example:
We can’t teleport across the city. That’s a friction. But most people don’t see it as a problem most of the time. They accept traffic, commutes, and travel time as facts of life. They complain. But they aren’t building DIY teleporters in their garages. Yes, sometimes they may surface the issue to elected officials or use them as the basis for votes or other behavior. But even then, someone else is supposed to act on frictions as part of "generally making life better." It's not their personal priority to act.
Call it the "silent suffering" effect. It shows up in many spots, even simple ones like complaining about your company's expense reimbursement software.
Other times, it's about the "fish can't see water effect" rather than silent suffering. For example, until spam filters came along, many people didn't even realize that something could be done about such ads. Back in the physical mail context, junk mail just ... was. There was nothing to do about it. Why would email be any different?
How to spot "real" problems: Look for action
The acid test for a true problem is user behavior. Do people:
- create workarounds or hacks?
- spend money or significant time to address the issue?
- complain and trying to fix it (not just venting)?
- adopt risky, manual, or inefficient solutions?
If yes, you’ve found a problem worth solving. If not, you’re likely dealing with friction–an annoyance, not a motivator.
For example, I once met a user who had thrown out all their kid's plush animals to try (and fail) to solve their kid's medical condition. That's real, radical action, as any parent will tell you!
How to use this
1. The obvious one: Don’t just listen ... Observe
If you've had any kind of formal ethnography or design thinking training, you know this. But it's a good reminder: Watch what users do, not just what they say. Interviews are useful, but behavioral evidence is gold. Look for homegrown solutions, like employer-unauthorized tech use or repeated manual processes.
2. Hunt for “failed fixes”
When people try to solve a problem and fail, it’s a strong signal of unmet demand. Document these attempts; they reveal both the pain and the limits of existing solutions. Even better if they've spent money or social capital on their attempts.
3. Prioritize problems with evidence of action
Rank opportunities not by how “annoying” they seem, but by how much effort users invest in solving them. The more action, the stronger the problem. This can feel harder to do in practice. Degree of perceived pain is just such an emotionally-rich topic that it's easy to default to prioritizing by that, not by failed action, which may indicate that it won't be so easy for us to solve the user's pain.
4. Avoid fighting inertia
Before building, ask: “What are users already doing to fix this?” If the answer is “nothing,” reconsider whether you’re addressing a real need. This is a fairly common issue. It's not that this will never be worth fixing, but at minimum not yet. If you try to solve those issues, you will have to pull people out of their inertia. That takes serious awareness generation, effort, and time. If you can't produce those, it'll be a looong road. That said, those topics can still be part of your work. They may just work better as visions or roadmap milestones than as immediate solutions.
5. Prototype with the “problem-action” lens
Test solutions with users who are already taking action. Their feedback will be more grounded and urgent than that of passive users.
Practical application
Here are ways you might do this:
Map user complaints against remediation efforts using:
- Toolchain fragmentation analysis (e.g., users combining 4+ apps for one task)
- Ritual tracking (e.g., pre-meeting spreadsheet workflows)
Prototype With "Solution-Fatigued" Users
Test with extreme users who:
- have attempted ≥3 DIY fixes.
- can articulate why previous solutions failed.
Set a threshold
E.g., prioritize issues where ≥30% of users have created workarounds.
Design for Progressive Commitment
Leverage active inference theory to reduce adoption friction:
- Start with free micro-solutions, even simpler ones than typical MVPs, e.g., tip sheets instead of do-it-for-you fixes. (Yes, I understand that my "micro-solution" might just be an even-better MVP. 😄)
- Transition to more high-effort solutions as users recognize value.
Close
In the end, complaints don't define problems. The energy that users invest to solve them does. Focus on actions, and avoid the problems I have experienced when I solved frictions!
