Living in the Problem
What separates products that technically solve a problem from products that people genuinely love
There’s a level of understanding you can’t get from user interviews, market research, or competitive analysis. It doesn’t show up in survey data. You won’t find it in a customer discovery playbook. It’s the knowledge that comes from being personally, viscerally frustrated by a problem you haven’t solved yet.
These days I keep catching myself in moments where the friction I’m experiencing isn’t a distraction from the work, realising instead, it is the work.
A few days ago, I spent two and a half hours in a waiting room while my car’s smashed windscreen was replaced. I didn’t have my laptop, I was working from my phone, trying to be productive in conditions that fought me at every turn. And somewhere in the middle of that, it hit me: this is exactly the constraint users of a product I’ve been working on actually face. Not the windscreen, obviously, but the feeling of trying to do meaningful work when your bandwidth is crushed, your tools aren’t quite right, and the gap between what you want to accomplish and what your environment allows feels enormous.
That’s not an inconvenience - that’s a gift: product research you couldn’t outsource, and you couldn’t buy.
The knowledge gap no amount of research closes
Canonical founder advice says: talk to your users, understand their pain points, map their workflows. And that’s sound advice as far as it goes, but it only produces a secondhand understanding - you’re collecting descriptions of friction, not experiencing it.
The difference matters more than most people think. When you’ve personally felt the sharp edge of a problem, you don’t need someone to explain why it’s urgent. You don’t need to be convinced the pain is real. You carry that conviction in your bones, and it shows up in every product and marketing decision you make.
When you’re living inside the problem, you notice things that never surface in interviews. The micro-frustrations. The workarounds people have normalised so completely they don’t even mention them. The moment where energy plummets not because the task is hard, but because the tools make it harder than it needs to be.
A founder who’s studied the problem knows the what. A founder who’s lived it knows the why, and more importantly, the feeling. That feeling is what separates products that technically solve a problem from products that people genuinely love.
Secondhand empathy has a ceiling.
I’ve watched this pattern play out enough times to trust it: the teams that build from lived frustration make different decisions than the teams that build from observed frustration.
When you’ve only observed the problem, you optimise for the metrics you can see. You build features that look right on paper. You solve the problem as described. And sometimes that’s enough.
But when you’ve lived the problem, you catch the things that never make it into a brief. You know that the issue isn’t the five-minute task itself but the twenty minutes of context-switching around it. You know that what users say frustrates them and what actually frustrates them are often different things entirely.
This is why experiencing low bandwidth, experiencing real constraint, is so valuable. Not as a philosophical exercise, but as a direct input into what you’re creating. Every time I find myself frustrated by the gap between what I want to do and what my tools or circumstances allow, I’m learning something I couldn’t learn any other way.
The friction isn’t blocking the insight, the friction is the insight.
The weight of small tasks
One thing I keep coming back to is how badly we misjudge the weight of small tasks when we haven’t done them ourselves. It’s easy to design a workflow and assume it’s simple. It’s another thing entirely to execute it when you’re tired, distracted, low on bandwidth, and juggling six other priorities.
The tasks that look trivial on a whiteboard become genuine obstacles under real constraint. I’ve sat in that waiting room, phone in hand, trying to get something meaningful done in the cracks between interruptions. The gap between what a task should take and what it actually takes under pressure is where most product assumptions fall apart.
You can’t credibly simplify what you haven’t personally found complicated. If you’re designing workflows for people under pressure, you need to have done those workflows yourself under the worst conditions they’ll face. Otherwise you’re not simplifying. You’re guessing.
Why dismissing your own frustration is a mistake
There’s a temptation, especially when things get busy, to treat personal friction as noise. To push through it. To think “I don’t have time to be frustrated right now, I just need to get this done.”
I’ve seen this pattern in teams. Someone flags their lack of bandwidth, their difficulty keeping up with a particular workflow, and the instinct is to solve around it. Find an efficiency. Remove the blocker. Move on.
But sometimes the better move is to sit with the frustration. To ask: what exactly is making this hard? Where does the energy drop? What’s the real chokepoint, and is it the task itself or everything surrounding it?
When the people closest to the problem are struggling with the workflow, that tells you something about the design, not about the people. The only way to see it clearly is to be close enough to feel it yourself.
The danger of distance
The further you get from the problem, the more abstract your solutions become. This is how products end up technically correct but emotionally wrong. The features work. The flows make sense on a whiteboard. But the experience feels off because nobody who built it has recently felt what it’s like to use it under real pressure.
Distance from the problem doesn’t just reduce empathy. It reduces pattern recognition. When you’re living in the friction daily, you start to notice recurring failure points. You spot the moments where people give up, not because the task is impossible, but because the accumulated weight of small irritations becomes too much.
That pattern recognition is a competitive advantage you can’t hire for and can’t shortcut. Someone closer to the problem, someone who feels it more acutely, will always have a sharper intuition for what needs to change and how to communicate the value proposition of what they have built. And if that person isn’t you, or at least someone on your team, they’ll eventually outperform you.
Frustration as a compass
None of this is comfortable. Living inside the problem means being perpetually aware of what doesn’t work yet. It means experiencing your own product’s shortcomings as personal annoyances. It means your car windscreen gets smashed, and instead of just being frustrated, part of your brain is cataloguing the experience as input.
But that discomfort is precisely what makes it valuable. Comfort and insight rarely coexist. The moments where everything runs smoothly are the moments where you learn the least about what needs to change.
So the question isn’t whether you understand your users’ problems. It’s whether you feel them. Whether the friction that defines their experience is something you encounter in your own day, unprompted, without having to simulate it.
If the answer is no, that’s worth paying attention to. Not because you need to manufacture struggle, but because the gap between your experience and your users’ experience is where blind spots live. And blind spots, in the long run, are what get you outbuilt.
Final thought - this is perhaps the single greatest reason (of many) to treat consultants, and agencies, with a healthy double-dose of skepticism.
If this piece added something to your week, please consider subscribing :)
This hit hard. We often rush to remove friction, but rarely pause to ask what that friction is actually trying to tell us. Great perspective on building from lived experience, not just research.