How to find out whether a problem could become a business

Someone describes a difficulty, and you imagine a solution. The idea seems so suitable that you want to start building. You still need to understand how that person experiences the problem, what they do about it today and what they would be willing to change.

A genuine need may not support a business. It may occur rarely, be handled adequately by an existing alternative or require support the offer cannot finance.

Investigating those conditions before building reduces reliance on assumptions. It may also reveal a solution different from your first idea.

Look for incidents rather than approval

In a hypothetical case, you are considering a service to organize billing for independent professionals. Asking "Would you use a tool that makes billing easier?" invites agreement with a generic benefit.

A more useful conversation begins with a recent incident. How did they handle the last bill? What information did they need to find? What happened when payment was late? How much work was involved, and who participated?

Answers help locate the difficulty. The main problem might be recording due dates, negotiating with clients or deciding when to request payment. A reminder tool could address one need and leave the others untouched.

Avoid presenting your solution too early. After hearing it, the person may reshape their account to discuss your idea instead of describing their routine.

Understand the alternative already in use

Even someone reporting a problem usually has a way to manage it. A spreadsheet, an existing service or a regular conversation can be laborious and still sufficient.

That alternative defines part of the comparison. A new offer must justify learning, migrating data or changing routines. Being better at one isolated function may not outweigh the cost of switching.

Observe who does the work. The user may differ from the person choosing or paying for the tool. A favorable proposal for one participant can add tasks for another.

In the billing example, a professional may value autonomy while their assistant wants a clear approval process. Understanding those differences helps shape the offer without assuming one shared preference.

Define the group of cases

Combining difficulties from very different audiences can create a long list and a confusing offer. Look for shared conditions: task frequency, work volume or a constraint in the routine.

Defining the cases tells you whom observations concern even before choosing a permanent segment. If you spoke only to people close to you who work similarly, limit your conclusion to that scope.

Look for cases where the difficulty does not occur. A process difference may reveal a simple solution or show that the problem depends on specific conditions. Those findings help assess room for an offer.

Separate the problem, solution and commitment

Consistent reports of a difficulty support investigating the problem. They do not establish that your proposed solution will work or that someone will pay for it.

A prototype can show whether someone understands the proposal. A usage test can reveal effort and suitability. An offer with clear terms lets you observe a decision different from a vague expression of interest.

Each step answers a question. Choose a test for the uncertainty you need to resolve. Building an entire platform to find out whether people need to organize due dates makes little sense if a manual demonstration can clarify it.

When payment or a real commitment is involved, explain what is being offered and what is still being tested. An experiment must consider participants' expectations.

Check whether you can deliver

The business also needs to deliver. Estimate acquisition, support and maintenance work. An apparently scalable solution may require frequent manual intervention.

In the fictional case, automated reminders might be simple. Handling billing disputes might need context the tool never receives. Identifying that limit helps define scope and price, or establish that the offer does not fit current conditions.

A pilot can reveal some of this effort. Record tasks outside the planned flow and ask which will persist as the service grows. Personally solving everything during the test can hide dependencies a future operation must sustain.

Choose a question for the next test

After a round of investigation, write what you learned and what remains uncertain. You may have a recurring problem, an inconvenient current alternative and no evidence about the offer. The next stage should then test the offer at a suitable scope.

Use the experiment worksheet to define the hypothesis and the observation that matters. Include a stopping condition. If the test contradicts expectations, examine whether the problem was less frequent, the solution failed or the offer required a change people would not accept.

That distinction lets you revise part of the idea without treating every negative response as failure of the business or every favorable signal as justification for building it all.