The Product Was Beautiful. Nobody Wanted It.

Some businesses fail long before they run out of money.

The warning appears much earlier, at the point when enthusiasm for an idea begins to replace curiosity about the people expected to use it.

In this illustrative startup scenario, the mistake is easy to miss. A founder has an exciting application idea. A developer is hired. The designer produces beautiful screens. Branding looks impressive, the features work and the launch announcement attracts congratulations.

The product goes live and a few friends register. Some promise to recommend it. Two weeks later, very few people return. After several months, meaningful usage is still difficult to find.

The founder begins looking for the problem. Perhaps the adverts were not good enough. Maybe the logo needs improvement. Perhaps people simply do not appreciate innovation.

Weak usage can have several causes, including poor distribution, difficult onboarding or unsuitable pricing. One uncomfortable possibility deserves investigation: the founder may have misunderstood demand before the first line of code was written.

What if the founder built a solution before understanding whether enough people wanted the problem solved in that particular way?

Being able to build is only one answer

The ability to build a product answers a technical question: can this thing be made?

A business needs answers to several other questions. Who experiences the problem? How often? What does it cost them? What are they doing about it today? Why would they change their behaviour? What would make the new option worth paying for?

A good interface can make the value easier to understand and the product easier to use. It cannot, by itself, establish how much customers care about the problem or what they will give up to solve it.

The distinction matters because building can create emotional commitment. After months of work and significant spending, criticism begins to feel like an attack on the founder's judgement. New features become easier to justify than difficult conversations with potential customers.

A problem can be real and the solution still be wrong

Suppose small businesses struggle to keep track of customer orders. That problem can be genuine. But it does not automatically follow that every business wants a standalone mobile application.

Some may be comfortable with an existing messaging platform and a spreadsheet. Others may be willing to pay for a simple dashboard. A more complex system might suit larger organisations but create unnecessary work for smaller ones.

The right answer depends on workflows, habits, costs, trust and the consequences of switching.

This is where founders need to distinguish three things: the existence of a problem, the attractiveness of the proposed solution and the customer's willingness or ability to adopt it.

Evidence for one is not automatically evidence for the others.

Compliments are not demand

One of the easiest traps in early product development is mistaking politeness for validation.

Friends may say an idea is brilliant. Prospective users may express enthusiasm during a conversation. Someone might even say, “I would definitely use that.”

Those reactions can be encouraging. They are not the same as repeated usage, a credible purchase commitment or a customer changing an existing process to adopt the product.

A better investigation asks about behaviour rather than hypothetical enthusiasm.

When did this problem last happen? What did it cost? What solution did you use? What was frustrating about it? Have you paid anyone to help? What would make switching worthwhile?

Answers anchored in actual behaviour are often more useful than general praise.

Build the smallest useful test

Validation does not always require building a complete application.

A founder can learn through structured conversations, a manual service, a clickable prototype, a small pilot or a limited paid offering. Each method answers a different question. A prototype may reveal confusion about how something works; it does not prove that someone will pay for it.

For the order-tracking idea, a small pilot could help a few businesses manage real orders using a simple existing tool. Observe whether the arrangement saves work, whether people keep using it and whether they will pay for it at a stated price. Agree what the pilot includes before it begins.

Decide in advance what you need to learn. If people praise the idea but continue using their old method, investigate why. If they use it repeatedly but decline the price, that points to a different question. Neither result should be hidden beneath a count of registrations.

The objective is not to guarantee success. No early test can do that. The objective is to learn something consequential before committing resources that are difficult to recover.

Customers cannot always describe a new possibility before they encounter it. Observation, prototypes and trials can help them experience it. Their behaviour then gives the founder something more substantial to examine than an imagined future response.

The question worth asking before building

One question can change the starting point of product development: “What is the person trying to achieve, and what is making that difficult today?”

That question changes the conversation. It moves attention away from the founder's excitement and towards the customer's reality.

A product can be technically excellent, beautifully branded and sincerely built, yet still be commercially unconvincing. That is not a contradiction. Those qualities solve different problems.

The ability to build something is not the same as the judgement to know whether it should be built.

Before the next product launch, make space for an uncomfortable question: who needs this badly enough to change what they already do?

I explore ideas about business, judgement and building useful things in my newsletter. Join here.