Choose a problem worth solving before choosing a product

Look for a recurring job, not a clever feature

A promising idea starts with a person trying to get an outcome and encountering friction. “People need an AI dashboard” names a solution. “Independent accountants spend two hours each Friday reconciling receipts from clients who use different formats” names a group, a job, a situation, and a cost that can be investigated.

Start with problems you can observe or reach. Keep a log for a week: who struggled, what they were trying to do, what happened, how often it happens, what they did instead, and what the consequence was. Search support forums, job postings, public issue trackers, app reviews, professional communities, and your own work. Treat these as leads. A complaint online does not tell you how common, urgent, or purchasable the problem is.

Narrow the first customer segment

Choose a first group you can contact and understand. Useful boundaries include role, organization type, workflow, trigger event, current tools, geography, and constraints. Avoid a segment such as “small businesses”: a two-person design studio and a regional medical supplier may share a size label but have different workflows, budgets, and obligations.

Write a one-sentence hypothesis:

When [specific situation], [specific group] needs to [complete a job], but [current obstacle] causes [consequence]. Today they use [workaround].

Keep the solution out of the sentence. It makes it easier to notice when evidence points to a different product or even a non-software fix. The GOV.UK guidance on user needs recommends starting from the user’s goal and context, then validating needs through research rather than treating proposed features as facts. Its public-service context differs from an indie business, but the problem-first discipline transfers well.

If you have several plausible groups, use the first-niche comparison workflow to compare reachability, buying path, and founder constraints before committing to one.

Score the problem with evidence

For each hypothesis, collect examples of recent behavior. Ask people to show the last time they handled the task, what tools and steps they used, how much time or money it took, what went wrong, and what they tried before. Avoid asking “Would you use this?” or pitching a feature too early; answers to hypothetical questions are cheap and often polite.

Use this evidence table. Score each dimension from 0 (no evidence) to 2 (repeated, specific evidence); the score organizes follow-up, not a scientific market verdict.

Dimension	0	1	2
Recurrence	No recent example	Happens occasionally	Happens on a known repeat cycle or trigger
Consequence	Inconvenient only in theory	Specific delay or rework	Clear lost revenue, material cost, risk, or blocked work
Workaround	None observed	A workaround exists but is easy	People spend money, effort, or reputation to cope
Reachability	Cannot name a channel	One plausible route	You can identify and contact likely users repeatedly
Change conditions	No reason to switch	Some dissatisfaction	A trigger, deadline, or cost makes action plausible

Look for disconfirming evidence. Who does not experience the problem? Which current workaround is good enough? Is the buyer different from the person who uses the product? Does the pain belong to a regulated or high-liability area that you cannot responsibly support? A strong problem may still be a poor first project if you cannot reach buyers, meet required trust standards, or afford the sales cycle.

Estimate a reachable market, not a headline TAM

For an early product, estimate the group you can plausibly serve first: number of reachable organizations or people × realistic annual spend per customer, then reduce it for eligibility, access, conversion, and capacity. Keep each assumption visible. This is a planning scenario, not a forecast.

If your customer is a local business, official sources such as the U.S. Census Bureau’s Business Builder can help explore business counts and demographic/economic data in supported geographies. Census data describes populations and industries; it does not prove that people have your specific problem or will buy. Use the equivalent official statistical agency for other countries and check data definitions, coverage, and release dates.

For a worksheet that separates eligible buyers, reachable prospects, and a near-term revenue scenario, see estimate a reachable market.

End with a testable next step

Choose the riskiest unresolved assumption and test it cheaply. If you do not know whether the problem recurs, interview and observe recent instances. If urgency is clear but buyer identity is not, ask how a purchase would be approved. If the problem and buyer are credible, test a concrete offer with a transparent price and a real next action. Record what result would make you continue, change segment, or stop in an experiment brief.

Do not total the score and call the idea validated. Continue only when evidence supports a next, costlier step. See customer interviews and MVP scope for the next parts of that path.