How to turn a problem into a business idea

A pain is not yet an idea

Most people stop too early. They notice that something is annoying — invoicing is tedious, finding a reliable tradesperson is hard, onboarding new staff is chaotic — and treat that observation as the idea. But 'invoicing is tedious' describes a feeling shared by millions of people with completely different situations, budgets and tools. You cannot build for all of them, and you cannot test a feeling.

The work of turning a problem into a business is mostly the work of narrowing it. Each stage below removes ambiguity until you are left with something specific enough to put in front of ten real people and get a clear yes or no.

Stage one: write a sharp problem statement

A sharp problem statement names a specific person, a specific situation, what goes wrong, and what it costs them. A useful template is: '[Role] at [type of organisation] struggles to [task] when [trigger], which costs them [time, money or risk] because [current workaround].'

Compare two versions. Vague: 'Small businesses find bookkeeping hard.' Sharp: 'Owners of two-to-five-person cleaning companies spend Sunday evenings matching card payments to jobs, because their booking tool and their bank do not talk to each other, and mistakes mean chasing clients for money weeks later.' The second version tells you who to call, what to ask about, and what a solution would have to touch.

If you cannot fill every slot in the template, the gaps are your research list. A missing trigger means you do not yet know when the problem bites. A missing cost means you do not yet know if it matters.

Stage two: find who pays

The person who feels a problem is not always the person who can spend money to fix it. In a business, the user, the buyer and the approver can be three different people with three different priorities. In a household, the person who notices the problem may not control the budget.

Map the roles explicitly before you go further:

Stage three: describe the job to be done

The jobs-to-be-done idea, associated with Clayton Christensen and others, is that people 'hire' a product to make progress in a particular situation. Framing the problem as a job keeps you focused on the outcome the customer wants rather than the features you might build.

Write the job as: 'When [situation], I want to [motivation], so I can [expected outcome].' For the cleaning company owner: 'When a week of jobs is finished, I want to know which ones have been paid, so I can chase the rest before I forget who owes what.' Notice that the job says nothing about software, bank feeds or dashboards. That freedom matters: the best solution may be much smaller than the one you first imagined.

A job also reveals your real competition. The cleaning company owner is currently hiring a spreadsheet, a Sunday evening and their own memory. Any solution has to be clearly better than that combination, not merely better than other software.

Stage four: sketch the smallest solution

Only now should you sketch a solution, and the sketch should be deliberately rough: a few sentences and perhaps a hand-drawn screen. The aim is to describe the minimum that would complete the job, not the full product.

• Input — What does the customer give you? A bank export, a calendar, a photo, a form?
• Transformation — What do you do with it that they currently do by hand?
• Output — What do they get back, and where do they see it? An email, a list, a reminder?
• Manual first — Could you deliver this by hand for the first five customers to prove the output is valuable before automating anything?
• Replacement — What does the customer stop doing or stop paying for once they adopt it?

Stage five: choose your wedge

A wedge is the narrow entry point where you can win decisively before expanding. It combines one tightly defined segment with one use case that segment urgently needs. Big markets are entered through small doors.

Good wedges share a few traits: the segment is reachable through a channel you can actually use, the use case is painful enough that people switch quickly, and success there gives you something — data, reputation, integrations — that makes the next segment easier. For the illustrative cleaning company tool, the wedge might be 'payment matching for residential cleaning companies using one specific booking tool', which sounds tiny but gives you a clear integration, a community to reach and a single message to test.

Resist widening the wedge to make the idea feel bigger. A wedge that tries to serve every small service business at once has no clear channel, no clear message and no reason for anyone to pick it over a general tool.

Pressure-test the result before you move on

At the end of the five stages you should be able to say, in two sentences, who you serve, what job you do for them, what they stop doing, and why you can reach them. If any part of that feels hand-wavy, go back to the stage that produced it rather than pushing ahead to build.

A few questions catch most weak spots. Would the person in your problem statement recognise themselves in it? Does the buyer have budget today, or would they need to invent a new line item? Is the job frequent enough that the customer will notice your product working, or does it happen once a year? And does your wedge give you a credible next step, or is it a dead end once the first segment is served?

None of these questions need a perfect answer at this point. They need an honest one, written down, so that your customer conversations can test it directly rather than drift into general feedback.

Questions