Finding Problems That Matter
You’d think that in a world overflowing with products, the hardest part of building something new would be execution. It isn’t. The real challenge is finding a problem that actually matters—one that people feel deeply enough to change behavior or pay to solve.
If you’re a cloud engineer or technically inclined builder, this challenge can feel especially frustrating. You have the skills to create complex, scalable systems, yet every idea seems to collapse under the same realization: the real pain points aren’t where people say they are. They’re hidden in the messy gap between public conversation and private frustration.
This article explores how successful builders uncover meaningful problems, whether it’s better to work inside a domain or approach it as an outsider, and what methods actually lead to insights that matter. By the end, you’ll have a clearer, more practical path to identifying problems worth solving—and building something people truly need.
Why Surface-Level Research Fails
Understanding why surface-level research fails
One of the most common traps aspiring founders fall into is relying on what people say in structured environments—interviews, surveys, or polished online discussions. While these methods feel productive, they often produce sanitized, incomplete answers.
When people are asked directly about their problems, they tend to generalize, simplify, or even misrepresent their experiences. They might describe what sounds reasonable rather than what actually frustrates them in the moment. This creates a disconnect between stated needs and lived reality.
For example, a developer might say, “Deployment pipelines are slow,” but what actually bothers them could be the anxiety of failed deployments at 2 a.m., unclear rollback processes, or lack of visibility into logs. These deeper frustrations rarely surface in direct questioning.
This is why many experienced builders shift their focus away from asking and toward observing. Instead of collecting answers, they look for patterns in unfiltered environments where people express themselves without an audience in mind.
Where Real Problems Reveal Themselves
Where real problems actually show up
If you want to find genuine pain points, you need to go where people complain honestly. These are rarely formal spaces. Instead, they live in communities where people feel safe being candid.
Online forums like Reddit, niche Slack groups, Discord servers, and private Facebook communities are goldmines for this kind of insight. In these spaces, people aren’t trying to impress anyone—they’re venting, troubleshooting, and sharing frustrations in real time.
For instance, someone building in the parenting or education space might discover recurring complaints about scheduling chaos, communication breakdowns with schools, or inconsistent learning tools—not through surveys, but by quietly reading hundreds of posts over time.
The key is volume and patience. One complaint means little. But when you see the same issue phrased differently across dozens of conversations, you’ve likely found something real.
[Visual suggestion: A diagram showing the difference between “stated problems” vs. “observed frustrations,” with examples from forums or community posts.]
Over time, patterns emerge. You begin to notice:
– Repeated complaints about the same workflow or tool
– Workarounds people invent to cope with limitations
– Emotional language indicating frustration, not just inconvenience
These signals are far more reliable than any single interview.
Insiders, Outsiders, and Proximity to the Problem
Working inside the domain vs. entering as an outsider
There’s an uncomfortable truth that many people try to avoid: the most reliable way to understand a problem deeply is to live it.
Working inside a domain—whether as an employee, contractor, or even a temporary participant—gives you access to nuances that no amount of research can replicate. You experience the constraints, the trade-offs, and the daily friction firsthand.
For example, a cloud engineer building tools for DevOps teams will gain far more insight by actually managing infrastructure, handling incidents, and dealing with real deployment pipelines than by interviewing others about it.
This approach has two major advantages. First, it exposes problems you didn’t know existed. Second, it helps you understand which problems are worth solving. Not every frustration is important enough to justify a product.
That said, not everyone can switch careers or embed themselves in a new domain. In those cases, the next best option is to partner closely with someone who already lives in that world.
This isn’t about hiring someone for occasional feedback. It’s about forming a relationship where you have continuous, unfiltered access to their experience. Ideally, this person becomes a co-founder or a deeply involved design partner.
The difference is significant. Instead of guessing what matters, you get a steady stream of real-world context: what’s broken, what’s annoying, what’s critical, and what’s just noise.
[Visual suggestion: A comparison chart showing “Outsider Research,” “Embedded Experience,” and “Design Partner Collaboration,” highlighting depth of insight and speed of learning.]
From Observation to Action
A practical process for uncovering real problems
If you’re starting from scratch, here’s a simple process you can follow to move beyond surface-level ideas:
First, pick a domain you’re genuinely curious about or adjacent to your existing skills. This keeps motivation high during the slower discovery phase.
Second, immerse yourself in unfiltered communities. Spend weeks—not hours—reading discussions without trying to validate an idea. Focus on understanding language, recurring themes, and emotional signals.
Third, document patterns. Keep track of repeated complaints, especially those tied to workflows or tools. Look for clusters rather than isolated issues.
Fourth, test your understanding informally. Instead of asking, “Do you have this problem?” try reframing it: “I’ve seen people struggle with X in these situations—does that match your experience?” This often leads to more honest conversations.
Fifth, get closer to the problem. This could mean freelancing in the space, shadowing someone’s workflow, or collaborating with a domain expert. The goal is to reduce the distance between you and the actual work.
Finally, build small experiments. Before committing to a full product, create lightweight solutions or prototypes that address a specific pain point. Observe whether people actually use them.
[Visual suggestion: A step-by-step flow diagram illustrating this process from “Domain Selection” to “Prototype Testing.”]
Tips and practical advice for builders
Focus on behavior, not opinions. What people do is more reliable than what they say. If someone has created a workaround, that’s a strong signal of a real problem.
Look for urgency. Problems tied to deadlines, money, or stress are more likely to drive adoption than mild inconveniences.
Avoid idea-hopping. It’s tempting to jump between domains when nothing feels “perfect,” but depth comes from staying long enough to see patterns.
Be wary of “nice-to-have” solutions. If removing your product wouldn’t significantly impact someone’s day, it’s probably not solving a core problem.
Prioritize proximity. The closer you are to the problem—either through experience or partnership—the better your decisions will be.
[Formatting suggestion: This section could be presented as a concise bullet list or checklist for quick reference.]
Conclusion
Finding meaningful problems isn’t about brainstorming clever ideas or conducting a handful of interviews. It’s about getting close—close to the people, the workflows, and the frustrations that don’t show up in polished conversations.
Whether you choose to work inside a domain, partner with someone who does, or immerse yourself in honest communities, the goal is the same: uncover patterns that reflect real, repeated pain.
The builders who succeed aren’t necessarily the most creative—they’re the ones who listen better, observe longer, and stay patient enough to see what others miss.
If you’re serious about building something useful, start by stepping away from the idea of “finding a problem” quickly. Instead, commit to understanding a space deeply. The right problem won’t need to be forced—it will become obvious.
References and further reading
“The Mom Test” by Rob Fitzpatrick – A practical guide to talking to users without getting misleading feedback.
“Obviously Awesome” by April Dunford – Insights on positioning and understanding customer needs.
Indie Hackers (indiehackers.com) – Real founder stories and discussions about problem discovery.
Y Combinator Startup School (startupschool.org) – Free resources on validating ideas and finding product-market fit.
Online communities such as Reddit, Hacker News, and niche Slack groups – Valuable sources for unfiltered user experiences.