Finding a Problem Worth Solving

Every real business starts with a real problem — not a clever idea. A painful, provable, already-costing-people-something problem. Not a feature you think would be "cool to build."

The mistake almost everyone makes

Most first-time founders start with a solution: "I want to build an app for X." That's backwards, and it's why most first ideas die quietly a few months in — there was never a problem urgent enough for anyone but the founder to care about.

The founders who build things people actually pay for start the other way around: they notice something broken, annoying, or expensive in their own life or someone else's — then they figure out what to build.

The three-question test

Before you spend a single hour building anything, a problem has to pass three tests:

1. Does it happen often? A problem someone hits once a year is a bad business. A problem someone hits every day is a good one.
2. Is it painful enough that people already spend time or money on a bad workaround? If nobody's doing anything about it today — not even a clunky spreadsheet or a WhatsApp group — it might not be painful enough yet.
3. Can you find at least 10 real people who have this exact problem right now, and will talk to you about it? If you can't name them, you don't have a problem yet — you have a guess.

Real examples, not hypotheticals

• Airbnb: the founders were broke, rent was due, and a design conference had sold out every hotel room in San Francisco. They put an air mattress in their living room to make rent that month. That wasn't a clever business plan — it was a problem they were personally living through (a fully booked city with no affordable option), solved for themselves first.
• Dropbox: Drew Houston kept forgetting his USB drive and losing work between computers. Existing sync tools were clunky. He didn't set out to build "a cloud storage company" — he was fixing something that was genuinely annoying him, repeatedly, before it became a product.

Neither of these started with "let's build an app." They started with a specific, recurring, personally-felt annoyance.

Where to actually look for problems

• Your own frustrations over the last 30 days — what did you complain about, more than once?
• Complaints from people close to you — family, coworkers, classmates. What do they redo by hand every week?
• Places where people are already paying for a bad workaround — a spreadsheet holding together a business process, a paper form, a WhatsApp group doing the job of real software.
• Tasks people describe as "annoying but I just deal with it."

The trap: "everyone needs this"

If your answer to "who has this problem?" is "everyone" — you haven't talked to anyone specific yet. Real problems live in specific people doing specific things at specific moments: small shop owners in Nairobi tracking inventory on paper, not "African businesses." The narrower and more specific you can get, the more likely you're describing something real.

This week's practical exercise

Before your next tutor session:

1. Write down three problems — things you or someone close to you has actually run into in the last 30 days. Not ideas for apps. Actual annoyances.
2. For each one, run it through the three-question test above. Be honest — most will fail at least one question, and that's the point of the exercise.
3. Pick the one that passed all three, and write one sentence naming exactly who has this problem (not "everyone" — a specific kind of person, in a specific situation).

Bring this to your tutor session — you'll talk through it together and refine it before the next module, where you'll actually go talk to some of those people.