The Difference Between a “Problem Worth Solving” and a “Nice Idea”
- Tushar
- Dec 9
- 5 min read
Founders and first-time product managers rarely struggle with generating ideas. They struggle with recognising which of those ideas actually deserve to exist. In reality, most ideas sound promising when said out loud, look neat on a whiteboard, and even make sense logically. But so do movie plots and TED talks.
The real trouble starts when you ask the only question that matters:
Do users genuinely feel this problem deeply enough to change their behaviour?
Through my years of building a D2C business, selling across marketplaces, talking to hundreds of small business owners, and evaluating early-stage products for founders, I learnt this the hard way: a nice idea is cheap. A problem worth solving is rare.
I am writing this article to help you identify the difference early, before you burn your runway, your time, or your confidence.
Table of Contents
Why Nice Ideas Appear Convincing Even When They Should Not
A nice idea satisfies your logic, not your users’ reality.
Ideas often look promising because they originate from an internal trigger. Something inside you says, this makes sense, this should exist, this will definitely work.
But internal triggers are deceptive because they come from your vantage point, not the user’s lived experience. When I built my D2C business, I assumed that good product pages and great prices would automatically lead to sales. It took me months of no orders to realise that buyers did not care about my logic. They cared about their fears, their habits, their shopping patterns, and their trust constraints.
A nice idea usually checks the following boxes:
It sounds good when explained.
You can defend it logically.
People around you nod because they want to be polite.
You can visualise the solution clearly.
You can build it quickly if needed.
But these signals tell you nothing about whether a user truly feels the pain.
A Problem Worth Solving Reveals Itself in Behaviour, Not in Opinions
A real problem can never be validated by asking, would you use this? It only shows up when you observe what people repeatedly do today to survive without your product.
During my qualitative research at Razorpay, I saw this distinction play out every day. Many micro-business owners told me they wanted smooth shipping processes. But when I examined their behaviour, the real story emerged. Most of them continued standing in long queues at India Post offices because they did not own printers and therefore could not use private shipping aggregators. That behaviour revealed a real constraint, which later helped shape the India Post shipping feature inside Ezegro.
Behaviours expose truth. Opinions hide it.
If you want to find real problems, watch what people already do despite the inconvenience. That is where product insight truly begins.
Logical Pain Points Are Not the Same as Lived Pain Points
A lived problem interrupts a user’s day. A logical problem interrupts your imagination.
One of the earliest founders I worked with wanted to build a home-management app. His assumption was simple: homeowners struggle to coordinate tasks with their domestic staff, so an app would streamline everything.
It made sense logically. It even sounded like an urban India use-case. But in the real world, it collapsed in minutes.
When I spoke to users across Delhi, Mumbai, Hyderabad and Gurugram, here is what I found:
Most families managed their homes through simple verbal instructions.
Only a very small percentage of domestic staff used smartphones.
No one felt enough friction in the daily workflow to replace it with a digital system.
The founder’s idea had logic, visuals, and appeal. But it collapsed because the underlying problem was not lived strongly enough.
Every product graveyard is filled with nicely crafted ideas that users were never bothered enough to adopt.
A Problem Worth Solving Has Natural, Imperfect Workarounds
A nice idea does not produce any urgent workaround. A real problem forces people to hack their way through it.
At Sangeeta Enterprises, before I launched my marketplace business, I spoke to 50 different sellers. Every one of them had strong makeshift processes for dealing with returns, logistics failures, and fake cancellations. They did not enjoy the process, but they repeatedly improvised because they had no alternative.
This is what problem evidence looks like:
People are already solving it for themselves, badly, inefficiently, or expensively.
A product simply replaces an inefficient workaround with a cleaner, cheaper or faster alternative. If users do not have a workaround, it often means the pain is not strong enough to trigger action.
A Nice Idea Has High Excitement but Low Consequence
The easiest way to test whether you are dealing with a nice idea is to ask: what happens if the user never solves this? In most nice ideas, the honest answer is: nothing major happens.
In contrast, real problems always have consequences. In my marketplace business, choosing the wrong packaging material caused immediate monetary loss. Using the wrong category listing reduced ranking overnight. Misunderstanding returns policy could wipe out profit margins. These were not theoretical pains. They had consequences every single day.
A good problem always carries risk, cost, stress or repeated friction.
A Problem Worth Solving Has a User Who Is Already Trying to Solve it
Whenever I evaluate founder ideas today, I look for one thing first: is the user already trying to succeed at something, and is something blocking them?
If users are not actively trying, you cannot build momentum. If users are trying and failing or struggling, you are in the right territory.
This is why the strongest zero-to-one products often emerge from industries where people are already hustling with imperfect tools. The demand already exists. The product just gives it shape.
How to Recognise a Real Problem From Day One
Over the years, I started using a simple internal test. Whenever I felt excited about an idea, I would force myself to check for three layers of reality.
First, is the user truly struggling today?
Second, what is their existing workaround?
Third, how badly does the current solution fail for them?
If you cannot answer these three questions with depth and evidence, you are dealing with a nice idea.
A real problem always survives interrogation.
Why This Distinction Matters for Your Time, Energy and Money
Many promising careers, early startups, and founder journeys collapse because they invest in a nice idea too early. The execution becomes heavy, the vision becomes emotionally embedded, and pivoting becomes painful.
Knowing the difference between these two categories is not a theoretical skill. It is a survival skill. Your ability to progress as a product manager or founder depends on how early you can drop nice ideas and double down on difficult, consequential, behaviour-anchored problems.
Every good product manager develops a sense for “problem heat”. Some problems are lukewarm. Some are mildly painful. A few are burning. And once in a while, you find a problem so strong that users are already halfway solving it themselves, waiting for someone to make it easier.
Those are the only problems worth building for. Everything else is noise. If you are unsure whether the idea you carry today is a nice idea or a real problem waiting to be solved, do not guess. Analyse it in conversation with users, not in isolation with your thoughts.
Comments