October 8, 2025
We live in an unprecedented era for builders. Large Language Models (LLMs) write code. AI tools generate designs. The cost of implementation is plummeting. What once required a team of specialists can now be prototyped by a single person over a weekend.
Yet, despite this technological abundance, our lives haven't transformed as dramatically as we might expect. The fundamental constraint has shifted. The question is no longer, "Can we build it?" but a much harder one: "Should we build it?" The bottleneck isn't execution anymore; it's the quality of the ideas themselves.
But what makes an idea genuinely good? In a world where anyone can build anything, how do we choose which ideas are worth the effort? Rather than starting with an abstract definition, it's more productive to examine what good ideas are not. My framework evaluates an idea's viability by checking for four critical failures.
People won't use solutions that don't address their needs. This seems obvious, yet it's the most common failure mode. Most side projects stall here, focusing on the impressiveness of the solution rather than the effectiveness of the fix. It's simply easier to build something beautiful than to deeply understand what people truly require.
Defining the problem is equivalent to defining your audience. The same situation can represent radically different pain points for different groups. The way you frame the problem dictates who your audience is, and vice versa. Get the problem definition wrong, and you're building for nobody.
Some ideas look promising but fail because they don't grasp the problem deeply enough. Early adopters try the solution, then quietly drift away because it isn't actually useful in their specific daily reality.
Good solutions succeed in specific, critical contexts. They commit to doing one thing exceptionally well, while weak ideas try to be all-in-one solutions for everyone. This happens when creators don't drill down to the essential frustration. Users rarely articulate their problems clearly—they just complain that "it's slow" or "it takes too much time." Your job is to uncover the specific, essential problem beneath those vague surface complaints.
Consider "smart factory solutions." Many software companies launched complete platforms promising to connect all equipment, analyze all data, and optimize everything with AI. Most failed spectacularly because they fundamentally misunderstood manufacturing reality. Even within a single company, protocols differ across factories and workflows. Tech companies focused on building generalized models and training AI systems, creating expensive solutions that didn't fit anyone's actual, messy reality.
Now, contrast this with Calendly. Instead of trying to solve all scheduling problems, it zeroed in on one pain point: the tedious back-and-forth of emails just to find a meeting time. The fix is almost embarrassingly simple: you register your availability, and the other person picks. This laser focus on a single, specific problem generates over $200 million in annual revenue. The idea isn't revolutionary; its genius is its clarity about the problem it solves.
The solution works, but the cost outweighs the benefit. This failure has two typical forms:
The problem isn't valuable enough: The gain from solving it is too small to justify the effort. Side note: This can be a positive signal. It means your problem definition is sound; the market size is just small. Ideas in this category can often be expanded horizontally once you've proved the core solution works, even if you start small.
The solution is over-engineered: The cost (of money, time, or complexity) to implement or use the solution is too high. This is the classic trap of falling in love with the elegance of your solution instead of caring about the user's struggle. You optimize for technical sophistication rather than practical, accessible value.
Even if your idea solves a real problem efficiently, it may be irrelevant if dozens of competitors already exist. Your offering must be notably better or serve a notably different audience.
This is counterintuitive: if solving the problem feels easy, narrow your scope. The more specific your solution, the more intensely your users will love it. You need a small group of people who think your solution is perfect for them, not a large group who think it's "fine, I guess."
Think of project management tools. Asana and Monday.com serve general audiences. But Linear won over software teams by understanding their specific workflow: tight GitHub integration, keyboard shortcuts, and a ruthless focus on speed. By narrowing their scope, they created something a specific, highly demanding group loves deeply.
As the saying goes: it’s better to be loved by a few than merely liked by many.
Here’s a practical process for deciding what’s worth building. First, run your idea through the checklist above to find its weak spots. If your problem definition isn't solid, stop—don't build yet. Refine it until you can name at least one person who would fall in love with your solution.
Next, research competitors. Evaluate their moats: What makes them defensible? Is it network effects, brand recognition, proprietary technology, or deep customer relationships? Compare their strengths and weaknesses with your approach, and critically, define your own moat. What will make your solution defensible once it's launched? Read user feedback on social media and review sites. Does your idea solve the problem more concretely? Does it meet a more specific need? If yes, build. Don't worry about total market size yet; that's irrelevant until you've proven the core value.
In Summary:
The framework and research will give you subtle signals about your idea's viability. But these are still just predictions. The only core feedback that matters comes from the market itself. No amount of analysis can replace actual users interacting with your solution.
This is why speed is paramount. Once you’ve validated your idea and researched the landscape, you need to get something into people's hands quickly. Not a perfect product. Just the smallest thing that lets real users experience your solution.
Not all feedback is equally valuable. Focus on two types of people, each requiring a different approach:
Early Adopters are usually experienced people in fields similar to your idea. They are invaluable for technical feedback and spotting potential issues you might miss. But here’s the caveat: don't follow all their feedback blindly. As experts, they're often outliers whose needs are more sophisticated or niche than what the majority of your potential customers want. Listen to them for technical refinement, but stay true to your original, simple problem definition.
Potential Customers hold the real signal. Their opinions will help you immensely, but they rarely provide direct feedback via surveys. Instead, they respond with their behavior: they either use your solution or they don't; they either come back or they disappear. This indirect feedback is far more honest than what people tell you. Watch what they do, not just what they say.
The goal isn't to build in secret until everything is perfect. The goal is to learn whether your problem definition resonates, whether your solution actually works in practice, and whether people care enough to keep using it. You can't learn any of this without putting something out there.
So, build fast, launch small, and listen closely. The market will tell you what your research couldn't.