Start with the problem: how to validate an idea before you build

Most products that struggle after launch were not badly built. They were built around an assumption that was never properly tested. This article outlines how we help founders move from an idea to a clearly defined, validated problem — and why that shift improves every decision that follows.

Why ideas are not enough

Ideas tend to arrive fully formed: a name, a feature list, a picture of the finished product. That clarity can be misleading. An idea is a hypothesis about what people want, and hypotheses often feel most convincing before they have been tested.

A problem is different. It already exists, whether or not you build anything, and someone is losing time, money or opportunity to it today. Anchoring a product to a real problem shifts the question from “will people like this?” to something far more useful: “how significant is this problem, and for whom?”

Look for friction in existing workflows

Valuable problems are often accepted as “just how things are done”. They appear as spreadsheets that hold critical operations together, messaging groups standing in for proper systems, and manual approvals that slow everything down.

During the strategy stage, we look for that friction deliberately. It most often appears as:

• Workarounds — processes people have improvised because no suitable solution exists.
• Repeated complaints — the same frustration, in different words, from different people.
• Expensive delays — moments where a slow process quietly costs money every week.
• Trust gaps — places where people double-check, chase or verify because they can’t rely on the system.

Workarounds are the strongest signal. When people invest effort in solving a problem imperfectly, they are showing you it is worth solving properly.

“If people are not already working around a problem, it may not be significant enough to build a product around.”

Interview for evidence, not approval

Presenting your solution too early undermines research. Once people hear the idea, they tend to respond politely — agreeing it sounds useful — and the conversation stops producing reliable information.

Focus instead on past behaviour. Ask people to describe the last time the problem occurred, what they did about it and what it cost them. Specific, recent examples are far more reliable than opinions about the future. Ten well-run interviews will usually teach you more than weeks of internal discussion, and often reveal a sharper problem than the one you started with.

Write the one-sentence problem

Before design begins, we summarise what we have learned in a single sentence: [who] struggles to [do something] because [reason], and it costs them [time, money or opportunity].

Writing that sentence requires clear decisions about who you are serving and what you are solving. Once agreed, it becomes the reference point for every decision that follows — which features to prioritise, what to leave out and how to measure success.

Assessing whether a problem is worth solving

Not every problem justifies a product. Those worth building for usually share several characteristics:

• It happens often — weekly or daily, not once a year.
• It costs something real: money, hours, customers or peace of mind.
• The people who have it can also pay to fix it, or influence who does.
• Existing solutions are clumsy, expensive or simply ignored.

If a problem meets most of these criteria, it is worth pursuing. If it meets only one, continue researching — a stronger opportunity is often close by.

What changes when you get this right

Teams that start with the problem build less and build better. Scope discussions become simpler because the problem defines what matters. Design decisions become clearer because they are made for a specific user with a specific need. And launch becomes easier, because you are offering a solution to a problem people already recognise.

The advantage is not a cleverer idea, but a deeper understanding of the people you are building for.

Further reading: How to Get Startup Ideas — Paul Graham