Finding and Validating an Opportunity

Most people who want to start a business begin with an idea, and most ideas feel convincing from the inside. But conviction is free and evidence is not. A venture survives only if enough people have a problem they will pay to solve, and pay you more readily than they pay the alternatives they already use. Founders who skip that check can spend months building something elegant that nobody asked for. Separating a real opportunity from a pleasant idea, and testing it before betting on it, is one of the few skills that meaningfully improves the odds in a game where outcomes vary and most ventures are hard.

An opportunity is a problem worth solving

An idea describes a product; an opportunity describes a problem. "An app that reminds you to drink water" is an idea. The opportunity, if one exists, is that some group struggles badly enough with the problem that they would change their behaviour and pay to fix it. The useful shift is from "what could I build" to "whose problem is this, how painful is it, and what do they do about it today." Painful, frequent, costly problems make better opportunities than mild, rare, cheap ones.

Validation before building

Validation means gathering evidence that a need is real before building the thing that serves it. Eric Ries popularised this as the Lean Startup and the build-measure-learn loop: treat each assumption as a hypothesis, run the cheapest test that could disprove it, and learn from the result. A minimum viable product, or MVP, is the smallest thing that produces real learning — a landing page, a service done by hand, a single feature — not a shrunken version of the finished product. The point is to discover you are wrong while being wrong is still cheap.

Talking to customers

Nothing substitutes for talking to the people who have the problem, and the skill is asking about behaviour rather than fishing for approval. "Would you use this?" invites politeness; "walk me through the last time you faced this" invites facts. What people already do, and what they have already paid to do it, tells you far more than what they say they might do.

Suppose you think small landlords struggle to track rent. Instead of building software, you make a one-page site describing it and ask ten landlords to walk you through how they handle rent today. Eight use a spreadsheet and are content; two describe real pain and ask when they can start. In a week, for almost nothing, you have learned the problem is real but narrow — enough to keep probing, not yet enough to build.

Now imagine skipping that. The idea feels obvious, so you spend six months building a polished platform, launch, and wait. A few sign-ups trickle in and stop. The product works perfectly; the problem was simply not painful enough for most landlords to leave their spreadsheet. Building first turned a cheap question into an expensive answer.

Analyses of failed startups — most famously the founder post-mortems collected by CB Insights — repeatedly find that a leading reason ventures fail is building something with no real market need. This is a well-documented pattern rather than a precise law, and the exact figures vary between studies and years. Yet the recurring theme is striking: capable teams, real funding, and working products still fail when the underlying need was assumed rather than verified. The lesson is not that ideas are worthless, but that unexamined ideas are dangerous.

• "If I build it, they will come." Distribution and demand do not appear on their own; most good products still have to earn their audience deliberately.
• "A survey saying people like the idea is validation." Stated interest is cheap and polite; real evidence is behaviour, effort, or money.
• "An MVP is just a cheap version of the finished product." An MVP is the smallest test that produces real learning, which is often not a full product at all.
• "More features will fix weak demand." If the core problem is not painful, adding features rarely makes people care.

You will be shown several startup pitches and asked to judge, for each, what evidence would tell you whether a real need exists, then design the cheapest test to find out.

Think Like a Maester: Fall in love with the problem, not your solution. The problem is what the customer will pay you to remove; the solution is just your current guess at how.

1. What is the difference between an idea and an opportunity?
2. What does the build-measure-learn loop try to achieve?
3. Why is a minimum viable product not simply a smaller product?
4. Why is "would you use this?" a weak question to ask a customer?
5. What do startup post-mortems repeatedly identify as a leading cause of failure?

Finding an opportunity means locating a problem painful enough that people will pay to solve it; validating means gathering evidence of that need before building the solution. Cheap tests, honest customer conversations, and a genuine minimum viable product let you discover you are wrong while it still costs little. Outcomes vary and most ventures are hard, but testing before building is one of the few habits that reliably improves the odds.

• Value Creation
• Marketing and Reaching Customers