The Startup Graveyard Is Full of Problem Solvers

For centuries, the town square clock told everyone what time it was. Nobody had that problem. Then a watchmaker started selling something nobody asked for: the time on your wrist. It solved no new problem. The clock in the square was still there, doing its job just fine, thank you very much. What the watchmaker did was something else entirely: he convinced people that not wearing one meant falling behind somehow. And it worked. That was not the work of someone who solved a problem. That was the work of someone who invented a need. And once the need existed, others followed. Not to solve the original problem, but to expand the need itself. Sport watches, dress watches, dive watches, luxury watches. None of them competed with the town clock. All of them competed for a place on your wrist. The need had become the market.

“Find a problem and solve it” is probably the most repeated piece of startup advice in existence. It sounds sensible, actionable, and reassuringly simple. It is also incomplete. During one of my sessions as a mentor at Google Launchpad in Romania, I asked a group of startups a question: is a good product one that solves a problem, or one that satisfies an important need better than anything else? The distinction may sound academic, but it changes how you think about products, markets, competition, and growth. I arrived at this question after building several service-oriented companies. Some failed despite having perfectly reasonable technical solutions. The technology worked. The teams worked. The supposed problem simply did not matter enough to the market.

That is the uncomfortable part founders tend to avoid. A problem can exist without being important. It can be annoying without being urgent. It can be technically interesting while remaining commercially irrelevant. When a product becomes part of something people consider necessary, the situation changes. Usage is more frequent, retention tends to be stronger, and growth can happen through behavior rather than persuasion. You are no longer reminding customers that they have a problem. They already know why they want the product.

The problem with solving problems

Startups usually begin their pitches with some variation of the same sentence:

We are solving a huge problem.

Sometimes they are. More often, they are solving something the founders have decided must be a huge problem. Those are not the same thing.

In many of the pitches I have reviewed, the team had spent months building a solution before having meaningful conversations with real customers. The problem had been validated internally, usually through enthusiasm, assumptions, and a slide containing a suspiciously large market estimate. Then they talked to people. The potential customers did not care enough. Some agreed that the problem existed but had no intention of paying to solve it. Others had already created a workaround. A few did not recognize the problem at all.

When I told founders, “I would never use this,” or simply asked, “Why would I use it?” the reaction was often a combination of skepticism and confusion. They had become so familiar with their own reasoning that they could no longer imagine someone rejecting it. This pattern kept appearing, and it made me question the conventional advice. Solving a problem is not a bad objective, but it is not proof that a product deserves to exist. It certainly does not guarantee a sustainable business.

Not everyone has your problem

The first limitation is obvious: not everyone has the problem you are solving.

Founders often describe a narrow inconvenience as if it were a universal condition. Once they start speaking with customers, they discover that the problem affects a small group, appears infrequently, or depends on a very specific context. There is nothing wrong with serving a niche. A small market can support an excellent business. The mistake is believing that a niche problem automatically creates a massive opportunity. The more specific the problem, the more carefully you need to examine the size, frequency, and willingness to pay behind it. A painful event that happens once every five years may be less valuable than a minor inconvenience that appears every morning.

Frequency matters. Context matters. Priority matters. The fact that a problem exists is only the beginning of the conversation.

People may not know they have it

The second limitation is awareness. People are not conscious of every security, health, financial, or technical problem affecting them. They usually notice a problem when it produces a visible consequence. Until then, it remains abstract. This creates an expensive challenge for a product company. Before selling the solution, you must convince customers that the problem exists. Then you must convince them that it matters. Finally, you must persuade them that your product is the right way to address it. That is a lot of education before the first transaction.

In some markets, this is unavoidable. Security products often operate this way. Preventive medicine does too. The problem can be serious even when the customer cannot see it. But from a product perspective, invisible problems create friction. You are not only competing against other companies. You are competing against ignorance, indifference, and the customer’s belief that everything is probably fine.

People live with problems

The third limitation is the one founders find hardest to accept: people tolerate problems all the time. They use slow software. They keep unreliable internet providers. They ignore broken workflows, postpone medical appointments, reuse bad passwords, and continue with systems everyone in the company openly hates. This is not necessarily irrational. People have limited time, money, and attention. Solving one problem means ignoring something else.

A founder may see a ten-minute inefficiency and imagine an obvious business opportunity. The customer may see the same inefficiency and decide that changing tools, migrating data, training colleagues, and dealing with another subscription would be worse. A problem is not enough. It needs to be important enough to displace the customer’s current priorities. This is why asking “Do you have this problem?” produces such weak validation. People will politely agree with almost anything that sounds reasonable.

The best questions are behavioral: What are you doing about it today? How often does it happen? What does it cost you? What have you already tried? Why did those attempts fail? What would make you change your current behavior? Customers reveal priorities through action, not agreement.

Necessity is different

A necessity is something people consider essential or indispensable. A problem is a difficulty, obstacle, or source of uncertainty. They can overlap, but they are not identical.

Imagine that you want to watch a movie tonight. The desire to watch it is not a problem. The problem appears when you cannot find the movie, the connection fails, or the service does not work on your television. A product designed only around the problem helps you locate or play the movie. A product designed around the recurring need tries to become the place where you naturally go whenever you want to watch something.

The first interaction is transactional. The second has the potential to become habitual. That difference matters because problems are often temporary. Once solved, they disappear. Needs and desires return.

A password recovery tool may be useful when you are locked out. A communication product can be useful dozens of times every day. One removes an obstacle. The other becomes part of how you live or work. This does not mean every company should manufacture artificial needs or engineer addiction. That would be both cynical and a very boring interpretation of the argument. It means the strongest products do not merely remove pain. They earn a recurring place in the customer’s life.

Necessities often come before problems

Needs frequently create the context in which problems appear. Eating is a necessity. An empty refrigerator is a problem. Communicating with friends is a need. Expensive, slow, or inconvenient communication is the problem. Getting work done is a need. Fragmented tools, missing information, and unnecessary coordination are the problems. When you begin with the problem, you may build a precise solution for one obstacle. When you begin with the underlying need, you have a better chance of understanding the broader behavior surrounding it. That broader view can reveal a much larger product.

The best products are often not the ones that solve a single difficulty with maximum cleverness. They are the ones that make an important activity easier, more accessible, more enjoyable, or more reliable. Over time, customers stop thinking about the original problem. They simply expect the product to be there.

Habit, networks, and default behavior

WhatsApp did not invent digital messaging, and it was certainly not the first product that allowed people to send messages over the internet. Its value grew because communication is recurring and social. As more friends, relatives, and colleagues adopted it, the product became more useful. Eventually, for many groups, not using it meant missing conversations. That is not merely problem-solving. It is a combination of habit, convenience, and network effects.

The same principle appears in many durable products. Their defensibility does not come only from features. Features can be copied. It comes from becoming the default behavior. A competitor may reproduce the interface in a few months. It is much harder to reproduce the customer’s routines, social connections, stored information, trust, brand recognition, and accumulated comfort with the product. This is why “we have better features” is rarely a satisfying strategy. Better for whom? Better at what? Better enough to make someone change?

A technically superior product can lose to an inferior one that already occupies the right place in people’s lives. Engineers dislike this fact because the compiler has never once rewarded anyone for emotional attachment. Markets are less disciplined.

The problem-solving bias

We are surrounded by the idea that good businesses begin with problems. Articles, courses, conferences, investors, and startup programs repeat it because it gives founders a simple framework. But the framework creates a bias. Teams become obsessed with identifying pain and forget to investigate desire, frequency, behavior, and attachment. They ask customers what is broken but not what they love doing. They look for frustration but ignore aspiration. They measure the severity of an inconvenience without asking whether the proposed solution could become part of a routine. A good product fits an important need in an accessible and affordable way. It delivers enough value, with little enough friction, that customers willingly return.

There is no perfect implementation of that idea. Products improve through usage, feedback, mistakes, and revisions. Features that seemed essential disappear. Minor details become central. The architecture accumulates scars. This is normal. The goal is not to predict the finished product from day one. The goal is to understand what customers consider valuable enough to repeat.

Ask what people would love to have

Finding something indispensable is harder than finding something broken. That is one reason there are so few truly excellent products. Customers will not hand you the specification. They will not say, “Please build the next iPhone.” They may not even describe the need clearly. But they will tell you what they enjoy, what they repeatedly attempt, what they spend money on, what they complain about, what they recommend to friends, and what they refuse to stop using. Listen for those signals.

A recurring behavior may suggest a product. A strange workaround may reveal an unmet need. An enthusiastic description of another tool may expose the standard your product must reach. A repeated desire may be more valuable than a repeated complaint.

Do not ask only, “What is your problem?” Ask what people wish they could do. Ask what they would love to have. Ask what already feels indispensable and why.

Then build something worthy of joining that list.