Defining the Problem

From Research to a Sharp Problem

Interviews, surveys, and competitive analysis produce a pile of raw observations. The final, crucial discovery step is turning that pile into a single, sharp problem statement the whole team can rally around. Skip this step and teams argue in circles about solutions before they even agree on the problem.

A well-defined problem does three things: it names a specific user, describes their real need in their own terms, and points to evidence rather than opinion. A vague problem ("users want a better experience") cannot be solved. A sharp one ("first-time Konga shoppers abandon checkout because they don't trust it will arrive") can be.

---

Anatomy of a Problem Statement

A useful template:

[User] needs [need] because [insight], but currently [current experience / obstacle].

Example, at a Nigerian logistics startup: "Small business owners shipping across cities need to know exactly when a package will arrive, because late deliveries damage their relationship with their own customers, but currently our tracking page only updates once a day, forcing them to call our support line for updates."

Notice this statement does not mention a solution. It stays entirely in problem space. That discipline matters: naming a solution too early ("we need a live tracking map") narrows the team's thinking before alternative solutions have even been considered.

---

Jobs to Be Done (JTBD)

The Jobs to Be Done framework, popularised by Clayton Christensen, reframes the problem around the progress a customer is trying to make in their life, not the product category. The classic line: "People don't want a quarter-inch drill, they want a quarter-inch hole."

The JTBD format: "When [situation], I want to [motivation], so I can [expected outcome]."

Example: "When I receive my salary at the end of the month, I want to automatically set some aside before I'm tempted to spend it, so I can build savings without relying on willpower." This is the real job behind features like PiggyVest's "AutoSave" or a bank's automatic round-up savings feature — customers are not buying a savings account, they are hiring a product to protect their future self from their present self.

JTBD is powerful because it reveals competitors you might otherwise miss: the "job" of protecting savings from temptation is also done by an ajo group, a locked fixed deposit, or asking a trusted relative to hold the money.

---

Opportunity Sizing

Not every well-defined problem is worth solving right now. Before committing a team, estimate the size of the opportunity:

A rough sizing exercise: if Flutterwave discovers that 15% of merchants who see a failed transaction never retry, and those merchants process an average of ₦200,000 a month, the revenue at risk is a concrete, calculable number — far more persuasive to stakeholders than "some merchants seem unhappy."

---

Bringing It Together

A strong discovery process moves through a clear sequence: gather evidence through interviews and data (Lesson 1–2), understand the competitive and behavioural landscape (Lesson 3), and finally distill everything into one sharp, solution-free problem statement sized by real impact. Only then is a team ready to start designing solutions — with confidence that they're solving something real, for real people, that is actually worth the effort.