Find a Painful Problem Before You Choose What to Build

A practical way to turn domain knowledge into one specific customer-and-problem hypothesis that is ready for real conversations.

customer discoveryproblem selectionone-person business

The first decision is not which product to build. It is whose difficult moment you are willing to understand well enough to improve.

This guide is for a professional who knows a field—operations, education, finance, ministry, trades, healthcare administration, local services, or another practical domain—but does not yet have a committed business problem. You may have ten ideas. That is not the same as having one testable problem.

Your output is a one-sentence customer/problem hypothesis:

A specific kind of person struggles during a specific moment, currently uses a specific workaround, and suffers a meaningful consequence when that workaround fails.

That sentence is not a brand statement. It is an interview target.

Decision

Choose one person and one painful moment to investigate next. Do not choose a market because it looks large or a solution because it is exciting. Choose the hypothesis for which you have enough access and context to learn from real people.

Use four filters:

  1. Access: Can you speak with people who experience the problem?
  2. Frequency: Does the difficult moment happen often enough to remember clearly?
  3. Consequence: Does failure cost time, money, trust, safety, attention, or opportunity?
  4. Workaround: Are people already doing something—however clumsy—to handle it?

Example format — replace this with evidence from your own conversations: A broad label such as “small-business owners need better automation” fails all four filters. A narrower hypothesis such as “independent bookkeepers lose follow-up time when clients submit incomplete month-end documents through several channels” gives you a person, moment, workaround, and consequence to investigate.

Action

Make a short problem inventory from work you already understand. Write ten moments when someone:

  • waits for missing information;
  • repeats the same correction;
  • transfers data between systems;
  • worries that a task was not completed;
  • manages an exception with an improvised checklist;
  • delays a decision because the evidence is scattered; or
  • apologizes for an outcome they could not reliably control.

For each moment, write the person involved, what happened immediately before it, the current workaround, and the consequence. Avoid solution words. “Needs a dashboard” is a proposed solution. “Cannot tell which requests are waiting for approval before the deadline” is a problem you can investigate.

Score each hypothesis from 0 to 2 on access, frequency, consequence, and visible workaround. The score does not prove demand. It helps you choose where to spend your next five conversations.

Then write the strongest hypothesis in this form:

[Specific person] struggles when [painful moment] because [current workaround] breaks down, which leads to [consequence].

Prepare five last-instance questions:

  1. Tell me about the last time this happened.
  2. What triggered it?
  3. What did you do first?
  4. Where did the process slow down or fail?
  5. What happened because of that?

Ask about a real past event. Do not ask whether someone likes your idea. Do not describe a product yet. Your job is to discover whether your sentence survives contact with reality.

Artifact to keep

Create a one-page hypothesis sheet with:

  • the exact person you want to interview;
  • the painful moment;
  • the current workaround;
  • the consequence;
  • why you can reach this audience;
  • five names or roles to contact;
  • the last-instance questions; and
  • a blank section for contradictions.

The contradictions section matters. If people describe a different moment, a harmless consequence, or a workaround that works well, record it. A useful Find stage can end by killing an idea before it consumes months.

What AI can help with

AI can turn a messy inventory into candidate hypotheses, remove solution language, draft neutral interview questions, and cluster anonymized notes after conversations. It can also challenge vague words such as “busy,” “inefficient,” or “frustrating” by asking what observable event they refer to.

Use it as an editor and organizer. Give it synthetic or sanitized notes, not private customer records or identifying details.

What AI must not decide

AI must not choose the people whose problems deserve your commitment. It cannot supply demand by generating plausible personas, simulated interviews, or confident market summaries. Generated answers are rehearsal material, not customer evidence.

You remain responsible for access, consent, interpretation, and the decision to continue. If you are relying on private information learned through employment or a client relationship, stop and define a public-safe way to learn instead.

Completion signal

Find is complete when another person can read your sentence and identify:

  • exactly who you mean;
  • the real-world moment you will ask about;
  • the workaround in use today;
  • the consequence worth investigating; and
  • the people you can contact next.

You do not need proof that the business will work. You need a hypothesis specific enough to be disproved by real conversations. Take that sentence to Validate and ask for behavior, not applause.

Use the note

Return to Find

You can name the customer, the painful moment, the current workaround, and why change matters now.

Open this journey stage