What makes a useful product worth building?

A practical way to judge whether a product solves enough of a real problem to justify the time, money and risk of building it.

Most products that fail were not badly made. They were built well, for a problem that was not quite big enough, or not quite real enough, for the people they were meant to serve.

That is an uncomfortable idea for anyone who enjoys making things. It means the most important product decision often happens before any design work starts: deciding whether the thing deserves to exist at all.

This article sets out the questions GoCore uses to make that decision. None of them are new, and none of them guarantee success. Together, they make it harder to fool ourselves. They cover the problem, the people who have it, the evidence that it matters, the economics of solving it and the honest outcomes at the end of the process.

Start with the problem, not the product

An idea for a product usually arrives fully formed: a device, an app, a better version of something that already exists. It is tempting to start refining it straight away.

A more useful first step is to set the product aside and describe the problem it would solve, in plain language and without mentioning the solution. Who has this problem? What happens when they run into it? What does it cost them in time, money, frustration or risk?

If that description is vague, the product will be too. If it is specific, it becomes a reference point for every later decision.

A simple problem statement

A short template helps keep the description honest:

[Who] struggles to [do what] when [situation], which costs them [time, money, risk or frustration]. Today they [current workaround].

For example, as an illustration: “Small workshop owners struggle to keep track of when equipment needs servicing when they are busy with production, which leads to breakdowns at the worst moments. Today they rely on memory and a wall calendar.”

Notice what the statement does not contain: no app, no sensor, no product at all. It describes a situation that can be checked against reality. If the people described do not recognise the situation, the idea needs rethinking before anything is designed.

Who has the problem?

A problem is only worth solving if specific people have it, and if they can be reached.

Be specific about the person. “Businesses” or “consumers” is too broad. “Owners of small food-manufacturing businesses with five to twenty staff” is specific enough to find, observe and talk to.

Distinguish the user from the buyer. In many products, especially for businesses, the person who suffers the problem is not the person who pays to fix it. A technician may feel the pain; a manager approves the purchase. Both need to be convinced, for different reasons.

Estimate how many there are. A problem that affects a handful of people can support a hobby or a custom service, but not usually a product business. Rough numbers are enough at this stage: how many people or businesses have this problem, and how many might realistically be reached?

Ask how they buy. Do they search online, ask peers, rely on suppliers or follow formal procurement? The answer affects whether a product can reach them affordably.

Four questions about the problem

Once the problem is written down, four questions do most of the work.

How often does it happen? A problem people face every day is very different from one they face once a year, even if the yearly one is more dramatic. Frequency shapes how much attention a solution will get and how quickly people learn to rely on it.

How much does it hurt? Some problems are mildly annoying. Others stop work, waste materials or create safety risks. The more serious the consequences, the more effort people will make to adopt something better.

What do people do about it today? Almost every real problem already has a workaround: a spreadsheet, a manual check, an extra step, a person who “just knows”. Workarounds are good evidence that a problem is real. They also set the bar a new product has to clear, because people will compare it with what they already do, not with nothing.

Would they change? A better solution is not enough on its own. Switching takes time, money, training and trust. A product has to be clearly better than the current workaround by a margin large enough to justify that effort.

SignalWeaker caseStronger case
FrequencyOccasional or seasonalDaily or weekly
SeverityMild inconvenienceLost time, money, materials or safety
Current workaroundNone, or people don’t noticeClumsy, costly or error-prone
Willingness to change“Nice to have”Actively looking for something better

No single row decides the answer. A problem that is rare but severe can still justify a product. A problem that is frequent but trivial usually cannot.

The job behind the purchase

A useful way to think about this, popularised by the late Harvard professor Clayton Christensen, is to ask what “job” a customer is trying to get done. People do not want a drill; they want a hole, and often they want the shelf the hole will hold up. Framing the problem as a job keeps attention on the outcome the customer wants, rather than on features. It also reveals competitors that are not products at all: doing nothing, asking a friend, or hiring someone.

Evidence over enthusiasm

Every founder believes in their idea. That belief is useful for persistence and unreliable as evidence.

The most valuable evidence comes from the people who have the problem. Watching how they work, asking what they did the last time it happened, and seeing which workarounds they use reveals far more than asking whether they would like a new product. People are generous with hypothetical enthusiasm and much more careful with their actual time and money.

Asking better questions

The way questions are asked changes the answers. Some practical habits help:

  • Ask about the past, not the future. “When did this last happen, and what did you do?” is far more reliable than “Would you use a product that…?”
  • Ask about cost. “What did that cost you?” brings out whether the problem genuinely matters.
  • Avoid pitching. Once the idea is described, people tend to be polite about it. Describe the problem first, and listen.
  • Look for workarounds. If someone has built a spreadsheet, hired help or bought something imperfect, the problem is real to them.
  • Listen for emotion. Frustration, worry and relief signal problems people care about.

Rob Fitzpatrick’s book The Mom Test is a useful guide to this style of conversation. Its central idea is that good questions are ones that even someone who wants to be nice to you cannot answer misleadingly.

A ladder of evidence

Evidence varies in strength. Roughly, from weakest to strongest:

  1. Opinions: “That sounds like a great idea.”
  2. Stated intentions: “I would probably buy that.”
  3. Observed behaviour: the person already spends time or money on a workaround.
  4. Small commitments: they give time for a follow-up, introduce a colleague or join a trial.
  5. Real commitments: a pre-order, a deposit, a letter of intent or a paid pilot.

The higher up the ladder the evidence sits, the more it can be trusted. An idea supported only by opinions has not yet been tested.

Small tests before big builds

Small tests help too. A rough prototype, a simple demonstration or a manual version of a service can show whether the core idea holds up before serious money is spent. The aim is not to prove the idea right. It is to find out, as cheaply as possible, where it is wrong.

Some common forms:

  • A sketch or mock-up shown to potential users, to test whether the idea makes sense to them.
  • A manual service that delivers the outcome by hand, to test whether people value it before automating it.
  • A simple landing page describing the offer, to test whether people are interested enough to register or enquire.
  • A rough working prototype, to test whether the core function is technically possible.

Each test should be designed to answer one question. Prototyping is covered in more detail in a separate article, Notes on prototyping early.

Can it be made and sold at a sensible price?

A real problem and an interested customer are necessary but not sufficient. The product also has to be deliverable at a price customers will pay, with enough margin to sustain a business.

Early, rough estimates are enough:

  • What would it cost to make or deliver each unit? Materials, labour, packaging, freight, hosting or support.
  • What would customers pay? Anchor this to the cost of the problem and the cost of current workarounds, not to hope.
  • What margin is left? GoCore’s series on financial statements explains why consistently healthy gross margins matter so much; see Gross margin: the quickest test of pricing power.
  • What would it cost to reach each customer? Marketing and sales costs can quietly consume the margin.

If the numbers only work under optimistic assumptions, the idea may need redesigning before it is built.

Can we build it, and should we?

Feasibility and fit matter too.

Technical feasibility. Is the core function achievable with available technology, skills and budget? A quick test of the hardest part is often worth more than months of work on the easy parts.

Regulation and safety. Some products must meet mandatory safety standards or other regulatory requirements before they can be sold. Electrical products, children’s products, food, medical and safety-related products are common examples. Understanding these requirements early avoids expensive surprises.

Fit with the builder. Does the team have, or can it obtain, the skills, relationships and patience the product needs? An idea that is right for one business may be wrong for another.

Usefulness is not the same as novelty

New technology makes it easy to build things that are impressive but not useful. The test is not whether something is clever. It is whether someone would miss it if it disappeared.

Some of the most useful products are not novel at all. They take a familiar task and make it more reliable, simpler, safer or cheaper. That kind of improvement rarely makes headlines, but it is often what people value most. And because useful, unglamorous products serve lasting needs, they are often the ones that remain valuable for years.

A simple scorecard

Bringing the questions together, a simple scorecard can help compare ideas. Score each from one (weak) to five (strong):

QuestionScore
The problem is specific and recognised by the people who have it
It happens often, or has serious consequences
Current workarounds are clumsy, costly or error-prone
People are willing to change
Evidence sits high on the ladder
The economics work at a realistic price
It is feasible to build and compliant to sell
The need is likely to last

The total matters less than the pattern. A low score on any one line is worth investigating, because it may be the reason the idea eventually fails.

Deciding to build

After working through these questions, there are three honest outcomes.

The first is to build: the problem is real, the evidence is reasonable and the proposed solution is clearly better than what people do now. The second is to keep exploring: the problem looks real, but something important is still unclear. The third is to stop, which is a perfectly good result. Stopping early is far cheaper than discovering the same answer after a product has been built.

Set stopping rules in advance

It helps to decide, before testing, what result would end the idea. For example: “If fewer than five of the twenty people we speak to describe this problem without prompting, we stop.” Setting the rule in advance prevents the natural tendency to reinterpret disappointing results as encouraging ones.

Common mistakes

Falling in love with the solution. The problem deserves the attention first.

Treating compliments as evidence. Polite enthusiasm costs nothing.

Talking to the wrong people. Friends and family rarely have the problem, and rarely tell the truth about it.

Ignoring the current workaround. It is the real competitor.

Skipping the economics. A loved product that cannot be made profitably is not a business.

Building everything before testing anything. Test the riskiest assumption first.

Questions to ask

  • Can the problem be described without mentioning the product?
  • Who exactly has it, how often, and what does it cost them?
  • What do they do about it today, and why would they change?
  • What evidence exists beyond opinions?
  • Can it be made, sold and supported at a price that works?
  • What result would make us stop?

Bringing it together

A useful product solves a real, specific problem for people who can be reached, clearly better than their current workaround, at a price that sustains a business. Most of the work of deciding whether to build it happens before any design: describing the problem, finding the people who have it, gathering evidence that climbs above opinion, and checking that the economics hold.

GoCore applies the same questions to its own future product ideas, and they are a useful check for any business weighing up a new product or improvement before committing time and money to it.

Need practical engineering, manufacturing or process support? KEVOS can help move the work forward.