How to Find Problems Worth Solving Before Choosing a Product

How to find problems worth solving for a startup is a different challenge from coming up with startup ideas. You can think of dozens of possible apps, platforms and AI tools, but that does not mean people have a strong enough reason to use or pay for them.

A business opportunity starts with a problem that matters to a specific group of people. It affects something they need to accomplish, creates a meaningful consequence and gives them a reason to look for a better way.

The mistake many first-time founders make is choosing a solution before understanding the problem. They decide to build a dashboard, automate a workflow or launch an AI assistant, then search for people who might want it.

Reverse that process.

Understand the problem first. Find out who experiences it, how often it happens, what it costs and what people already do to deal with it. Only then should you start choosing a product.

This guide gives you a practical problem-quality framework for evaluating opportunities before committing to a build.

What Makes a Problem Worth Solving?

A problem worth exploring is more than an inconvenience or an interesting observation.

It should have a specific context, affect an identifiable group and create a consequence that people care enough to address.

For a software startup, investigate five things:

1. A specific person or group: Who repeatedly experiences the problem?
2. A clear task or outcome: What are they trying to accomplish?
3. A meaningful consequence: What happens when the task goes wrong or takes too long?
4. An existing workaround: What do they currently do to deal with it?
5. A reachable buyer: Who can decide to spend money or authorize a change?

These are investigation criteria, not a guarantee that a startup will succeed.

The UK Government’s guidance on learning about users and their needs recommends understanding who users are, what they are trying to do, how they currently do it and what problems prevent them from achieving their goals. It also distinguishes evidence from assumptions.

That distinction matters. A founder’s belief that a workflow is frustrating is an assumption until research supports it.

Problem vs Solution: Start With the Right Question

A solution describes what you want to build. A problem describes what someone is struggling to accomplish.

Consider these examples:

Solution-led thinking	Problem-led thinking
Build an AI invoice assistant	Small agencies struggle to track invoice status across clients and payment channels
Build a project management dashboard	Teams lose track of ownership when tasks move between departments
Build an analytics platform	Store owners cannot identify which daily transactions need attention
Build an automation tool	Operations staff repeatedly transfer information between disconnected systems

The solution-led statements already contain a product idea. The problem-led statements describe a situation that still needs investigation.

A useful test is to remove the product or technology from your description.

Ask:

• Who is experiencing the difficulty?
• What are they trying to accomplish?
• When does the problem happen?
• What happens when they fail?
• How are they dealing with it today?

A strong problem statement should remain understandable even when you remove every mention of your proposed product.

Paul Graham makes a similar argument in his essay How to Get Startup Ideas: look for real problems rather than simply trying to invent startup concepts. This is a useful founder perspective, not a formula that guarantees a successful company.

The 7 Tests for Finding Problems Worth Solving

Use the following tests to investigate a candidate problem. They are designed to help a solo founder separate a genuine opportunity from an interesting but weak observation.

1. Identify the Exact Person Experiencing the Problem

Start with a specific group instead of saying that everyone has the problem.

“Businesses need better reporting” is too broad to investigate.

It does not tell you which businesses, which people, which reports or which decision is being delayed.

A more useful starting point might be:

“Operations managers at small e-commerce businesses struggle to reconcile orders from multiple sales channels before preparing their weekly reports.”

Now you have something to research.

You can identify people who match that description, find out where they work and ask about the process.

Define your initial segment using details that matter to the problem:

• Industry or type of business.
• Company size or operating scale.
• Job role.
• Specific workflow.
• Existing tools or processes.
• Conditions that trigger the problem.

Avoid creating an overly narrow segment just to make the problem sound unique. The segment should reflect meaningful differences in how people experience the problem.

What to do: Write down one initial customer segment. Do not combine several unrelated groups into a single average customer.

2. Test How Often the Problem Happens

Frequency helps you understand whether the problem is part of someone’s normal workflow or an occasional inconvenience.

Ask about actual events instead of asking whether people think the problem happens frequently.

For example:

• When did this last happen?
• How many times did it happen recently?
• Is it part of a daily, weekly or monthly process?
• Does it happen only at a specific stage?
• What conditions make it more likely?

A problem that happens repeatedly may create accumulated effort. A problem that occurs only occasionally might still matter if the consequences are severe.

Do not reject a low-frequency problem automatically. A serious compliance failure, financial error or operational interruption may justify attention even when it happens infrequently.

Think about frequency together with consequence.

Frequency	Consequence	What to investigate
Frequent	Minor	Does the repeated effort add up to a meaningful cost?
Frequent	Serious	Does the user have an urgent need for a better process?
Rare	Minor	Is this problem important enough to deserve a product?
Rare	Serious	What is the risk or financial exposure when it happens?

Frequency alone does not establish demand. It is one part of the problem.

3. Understand What the Problem Actually Costs

This is where an interesting complaint becomes a more serious business question.

A problem may cost money directly, but not every cost appears as an invoice.

Look for these types of consequences.

Type of cost	What to investigate
Time	How much time is spent repeating or fixing the task?
Direct money	Are people paying for manual services, tools or extra labour?
Lost revenue	Are delays or mistakes causing missed sales or unpaid work?
Operational risk	Can the process create errors, missed deadlines or compliance exposure?
Opportunity cost	What useful work gets delayed because people are handling this problem?
Customer impact	Does the problem affect service quality, delivery or retention?

Do not assume that all inconvenience can be translated into money. Ask people to describe the actual consequence and use figures only when you can identify their source.

Estimate the time cost

For repetitive work, you can create a simple estimate:

Annual time cost = Events per week × Minutes per event ÷ 60 × Hourly labour cost × Working weeks per year

Consider this clearly hypothetical example:

A small agency spends 30 minutes reconciling invoice statuses twice per week. Assume the relevant employee cost is ₹500 per hour and the process occurs for 48 working weeks.

• Time per week: 2 × 30 minutes = 60 minutes.
• Time per year: 1 hour × 48 weeks = 48 hours.
• Illustrative annual labour cost: 48 × ₹500 = ₹24,000.

These figures are assumptions for the calculation, not customer-reported data, a market benchmark or evidence that the agency would pay ₹24,000 for software.

The actual estimate requires verified frequency, labour cost and working periods. It also does not include other expenses or prove that a software product can eliminate the work.

The point is to understand the scale of the existing problem before designing a solution.

4. Find Out What People Already Do to Work Around It

Existing workarounds are particularly useful because they show what people actually do when the problem occurs.

People rarely wait for a startup to appear before trying to manage an important problem.

They may already use:

• Spreadsheets.
• Shared documents.
• Email chains.
• Messaging groups.
• Manual copy-and-paste processes.
• Freelancers or consultants.
• Existing software they find difficult to use.
• Additional staff or repeated support requests.

A workaround does not automatically prove that a software opportunity exists. It shows that someone is spending effort to manage a situation.

Investigate the workaround in detail.

Question	What you want to learn
What do you use today?	The current alternative
Who performs the work?	The person carrying the burden
How does the process work?	The actual workflow
What breaks or gets delayed?	The weak point
Have you tried another option?	Previous attempts
Why did you stop using it?	Switching barriers or missing functionality
What happens when nobody handles it?	Consequences of leaving the problem unresolved

Do not assume that spreadsheets mean the market needs a new SaaS. A spreadsheet may be perfectly adequate for the task.

Your job is to understand what the current workaround fails to do and whether that failure matters enough to trigger a change.

5. Find Out Who Owns the Budget

This is especially important when researching problems inside businesses.

The person experiencing a problem may not be the person who can authorize a purchase.

For example:

• An employee experiences the difficulty.
• A team lead decides whether a process should change.
• An operations manager evaluates alternatives.
• A finance manager controls the spending approval.
• An owner or director makes the final decision.

These roles can overlap, especially in a very small business, but do not assume that they are always the same person.

Ask:

• Who is responsible for this process?
• Who decides whether a new tool can be introduced?
• Does the business already spend money to manage this task?
• Which budget would pay for a solution?
• Is a purchase made by an individual or approved by a team?
• What would have to happen before a new tool could be adopted?

For business software, identify the user, the person who pushes for change and the person who can approve the spending.

A user who loves the idea may still be unable to purchase it. On the other hand, a budget owner may care about the consequences of the problem more than the interface or feature list.

If nobody has an obvious budget, that does not automatically mean the problem is worthless. It means you need more evidence about the buying process, urgency and ability to pay.

6. Check Whether Existing Solutions Already Handle the Problem

Before deciding that a market gap exists, investigate what customers can already use.

Competitors are not limited to startups with the same product idea.

Include:

• Direct software competitors.
• Broader platforms with overlapping functionality.
• Manual services.
• In-house processes.
• Consultants and agencies.
• Existing tools used in an unusual way.

The Small Business Administration’s guidance on competitive analysis explains why analysing competing businesses and their market segments matters when assessing a business opportunity.

Look at what existing alternatives do well, where they fall short and which customers they serve.

A product may already solve the problem for large enterprises but be too expensive or complicated for small businesses. Another tool may be excellent at the main workflow but lack an integration important to one specific group.

That could reveal a more focused opportunity.

However, do not confuse “I can build a cleaner interface” with a genuine unmet need.

Try to identify the specific situation in which current alternatives fail.

For the wider process of gathering recurring customer complaints and extracting opportunities from them, use the existing guide to finding SaaS ideas from customer complaints.

7. Look for Evidence That Could Prove You Wrong

This is one of the most important tests.

Founders naturally notice information that supports their idea. A good research process also looks for evidence that challenges it.

Ask yourself:

• Are there people in the target segment who do not experience the problem?
• Do some customers already solve it easily?
• Is the problem actually caused by poor training rather than poor software?
• Does it happen only under unusual conditions?
• Is the problem painful for users but unimportant to the business?
• Are current alternatives good enough?
• Is the buyer unwilling or unable to change the process?

For example, you may discover that a workflow looks inefficient from the outside, but the business deliberately keeps it manual because the volume is low and automation would introduce additional risk.

That finding could save you from building something nobody needs.

Keep positive, negative and mixed evidence together. Do not remove an interview or observation because it contradicts your first idea.

How to Research a Problem Before Choosing a Product

Once you have a candidate problem, combine desk research with conversations and observation.

The UK Government’s user research discovery guidance recommends understanding how people currently complete a task, where they experience difficulty and what happens across the full process.

A practical approach for a solo founder is to work through these stages.

Start with existing evidence

Look for information that helps you understand the current situation.

You might examine:

• Public customer reviews.
• Community discussions.
• Existing product documentation.
• Support discussions you are legitimately allowed to access.
• Search queries related to the workflow.
• Public competitor pricing and feature information.
• Your own experience with the problem.

Record the source and what it actually demonstrates.

For example, a public complaint may show frustration, but it does not automatically establish how frequently the problem happens or who would pay to solve it.

If you want a repeatable way to organize these observations, use the evidence-backed idea backlog.

Talk to people who actually experience the problem

Interviews help you understand the circumstances behind a problem.

The important thing is to learn about past behaviour, not pitch your proposed product.

The National Council for Voluntary Organisations’ guidance on asking good user research interview questions recommends open questions, avoiding leading questions and asking about real behaviour rather than relying on predictions of future behaviour.

Use questions like these:

1. Can you describe the last time this problem happened?
2. What were you trying to accomplish?
3. What caused the difficulty?
4. What did you do to handle it?
5. How much time or money did that process involve?
6. Who else was affected?
7. What happened when the problem was not resolved?
8. Have you tried another way to solve it?
9. Who decides whether the process or tool can change?
10. What would make you consider switching from your current approach?

Avoid questions like:

• Would you use an app that solves this?
• Do you think this is a good startup idea?
• Would you pay for an AI tool that does this?
• Do you like the product I am planning to build?

These questions invite hypothetical answers and compliments. They do not establish that the problem is important enough to change behaviour.

The UK Government’s in-depth interview guidance also recommends using open, neutral questions, allowing participants to describe real experiences and obtaining informed consent where appropriate.

Do not follow a universal interview quota

You will sometimes see startup advice recommending a fixed number of customer interviews.

There is no single number that proves a problem is real for every market and customer segment.

For context, the US National Science Foundation’s National I-Corps programme requires its participating teams to conduct at least 100 customer interviews during its seven-week training programme. That is a specific programme requirement, not a universal rule for every early-stage founder.

See the NSF National I-Corps requirements.

For your own research, focus on whether the evidence is becoming clearer. Are you hearing the same problem described independently? Are you learning more about the workflow, consequences and buyer? Are new conversations revealing important contradictions?

If the answers are still changing, continue investigating.

A Copyable Problem Evidence Worksheet

Use this worksheet to keep your research separate from your assumptions.

Field	What to record
Candidate problem	A short description without a proposed solution
Target segment	Who experiences it
Specific situation	When and where it happens
Recent incident	A real example of the problem
Frequency	How often it occurs
Consequence	Time, money, risk, delay or other impact
Current workaround	What people do today
Existing alternatives	Tools, services or manual processes
User	Who experiences the problem
Buyer	Who approves or controls spending
Evidence source	Interview, observation, public source or company record
Contradictory evidence	What challenges the problem hypothesis
Remaining assumption	What is still unproven
Next research action	What you need to investigate next

Use one record per observation or interview. Do not combine different people into one fictional customer story.

A candidate problem becomes more useful when you can trace its claims back to specific evidence.

How to Write a Strong Problem Statement

Once you have enough evidence to describe the problem, write it in a way that keeps the customer and situation at the centre.

Use this template:

[Specific type of customer] struggles to [complete a task] when [situation or trigger], which leads to [observable consequence]. Today, they [current workaround]. The problem matters because [cost, risk or lost opportunity].

Here is an illustrative example:

Small agencies struggle to keep invoice statuses consistent across different client payment channels, which creates extra reconciliation work and delays their weekly financial reviews. Today, staff update spreadsheets and check payment notifications manually. The problem matters because the team spends time reconciling information that could otherwise be used for client work.

This is a hypothetical example, not a verified customer interview or a claim about the agency market.

Notice what the statement does not contain:

• A product name.
• A feature list.
• A preferred technology.
• An AI claim.
• A predetermined solution.

You are defining what needs to be understood, not deciding what to build.

A Worked Problem-Cost Example

Let’s apply the framework to the hypothetical agency invoice-reconciliation problem.

Step 1: Identify the user

The person doing the reconciliation is the operations employee or finance administrator.

Step 2: Identify the situation

Invoice statuses have to be checked across different client payment channels before the agency prepares its weekly financial review.

Step 3: Test frequency

Ask how often the reconciliation process happens and whether it is required for every client or only certain accounts.

Step 4: Estimate consequences

Suppose, purely for illustration, the task takes 30 minutes per session and happens twice each week.

The illustrative annual time calculation in this example is 48 hours for one employee over 48 working weeks.

Step 5: Audit the workaround

The employee currently uses a spreadsheet and checks several payment notifications.

Step 6: Identify the buyer

The agency owner or finance decision-maker may have authority to change the workflow or approve a tool. This still needs to be confirmed.

Step 7: Look for contradictory evidence

Perhaps the agency has very few invoices, and the spreadsheet takes almost no effort to maintain. In that case, the problem may not be important enough to justify a separate product.

The example gives you a way to structure research. It does not establish that the agency needs software or would pay for it.

When Should You Pursue, Investigate or Reject a Problem?

At this stage, you do not need a complicated numerical score.

Use the evidence to make one of three decisions.

Decision	What the evidence looks like	What to do next
Pursue further	Specific users describe a meaningful problem, actual workarounds and clear consequences	Continue toward problem validation
Investigate further	The problem exists, but its frequency, cost, user group or buyer is unclear	Gather more targeted evidence
Reject or reframe	The problem is minor, rare without meaningful consequences, already handled well or has no reachable group that cares enough to change	Stop or look for a different problem

A problem that deserves more research is not automatically a bad idea. It simply means that the evidence is not strong enough yet.

Once a problem passes this first quality test, move to the next stage rather than immediately starting development.

Our guide on how to validate a Micro-SaaS idea without building it explains how to investigate demand before committing to development.

When the evidence supports a specific opportunity, you can use the SaaS MVP scoping guide to decide which part of the problem your first version should solve.

Common Mistakes When Searching for Startup Problems

Starting with an exciting technology. Wanting to build an AI product or automation platform is not evidence that customers need one.

Treating every complaint as a business opportunity. A complaint can be valid without being costly, recurring or important enough to pay to solve.

Confusing frequency with urgency. A frequently occurring minor inconvenience may matter less than a rare but serious failure.

Talking only to enthusiastic friends. People who want to encourage you may not represent the target customers or buyers.

Asking whether someone would use your product. Past behaviour and actual workarounds are more useful than hypothetical enthusiasm.

Ignoring the person who approves spending. A user can experience a problem and still have no authority to purchase a solution.

Assuming manual work always needs automation. Sometimes a manual process is simple, inexpensive and appropriate for the current scale of the business.

Ignoring evidence that contradicts your hypothesis. Research is useful only when it can change your mind.

Frequently Asked Questions

Final Takeaway

Finding problems worth solving is about understanding what people struggle with before deciding how technology should help them.

Start with a specific customer group. Investigate the task, frequency and consequences. Understand the workaround. Identify who experiences the problem and who can authorize a purchase. Keep contradictory evidence visible.

Only then should you choose a product direction.

A startup does not need the most complicated idea or the newest technology. It needs a problem important enough for a specific group of people to care about solving.

Continue with the IndieOS Ideas guides to move from problem discovery to evidence-backed validation and product decisions.

---

Sources and further reading

1. GOV.UK: Learning About Users and Their Needs — understanding user goals, current behaviour and problems before designing a solution.
2. GOV.UK: User Research in Discovery — research through observation, interviews and existing evidence.
3. GOV.UK: Using In-Depth Interviews — planning and conducting interviews using open, neutral questions.
4. NCVO: Asking Good User Research Interview Questions — avoiding leading questions and hypothetical answers.
5. Paul Graham: How to Get Startup Ideas — a founder’s perspective on starting from real problems.
6. NSF I-Corps: National Teams Applicants — programme-specific customer discovery requirements.

Sources checked on 2 November 2026. Framework recommendations are editorial guidance, not a guarantee of startup success.