Before You Build a Business Idea, Test the Customer Problem

You have a business idea. You can explain the product, picture how it would work, and list a few reasons people should buy it.

But there's a question worth answering before you spend months building it: Are customers actually struggling with the problem you think you're solving?

A solution can sound impressive and still address something customers barely care about. They might already have a workaround or recognize the inconvenience without considering it a priority.

Before investing heavily in development, branding, or marketing, test the problem itself.

Your Business Idea Is a Hypothesis, Not Evidence

Consider a hypothetical founder planning an appointment-management app for independent service providers.

The concept seems straightforward: automate booking confirmations, reminders, and scheduling updates so business owners spend less time managing appointments.

Sounds useful, right?

Maybe. But several questions remain unanswered.

What if these businesses rarely experience scheduling problems? What if their existing tools work well enough? What if missed appointments are frustrating, but collecting payments is their biggest operational headache?

Here's another possibility: What if the scheduling problem is real, but business owners don't consider it important enough to pay for a solution?

The idea isn't necessarily bad. It simply hasn't been tested against the customer's experience.

Keep three things separate:

• The problem: What difficulty does the customer actually experience?

• The evidence: What specific experiences or behaviors show that the difficulty matters?

• The solution: What could improve the situation?

These elements are connected, but they aren't interchangeable. A plausible solution doesn't prove that the problem deserves attention.

Stop Pitching. Start Investigating.

One of the easiest ways to undermine customer discovery is to turn the conversation into a sales pitch.

Imagine asking a business owner:

"Would you use an app that automatically handles your appointment scheduling?"

They might say yes. You're describing something convenient, and agreeing costs them nothing.

But that answer doesn't tell you whether they need the app, would change their current process, or would pay for it.

Instead, ask about what they've already experienced:

• "When was the last time scheduling caused a problem?"

• "What happened, and how did you deal with it?"

• "What are you using to manage appointments today?"

• "Which part of the process creates the most difficulty?"

These questions focus on actual experiences rather than reactions to your proposed product.

If someone says scheduling isn't a problem, resist the urge to convince them otherwise. That might be the most useful information you hear.

Separate What Customers Say From What You Assume

Customer conversations can create false confidence when founders interpret every complaint as support for their idea.

Here's a hypothetical example.

A business owner says:

"Sometimes customers message me late at night, and I don't respond until the next morning."

A founder might immediately conclude that the business needs automated appointment scheduling.

But the customer didn't say that.

They described a delayed response. They didn't say they lost bookings, that customers complained, or that they wanted automation.

A simple way to avoid jumping to conclusions is to separate three things:

Said: What the customer actually reported.

Inferred: What you think that information might mean.

Next check: What evidence could confirm or challenge your interpretation.

For the hypothetical business owner, the notes might look like this:

• Said: "I usually reply to appointment requests the next morning."

• Inferred: Delayed replies might cause lost bookings.

• Next check: Ask whether a recent booking was lost because of a delayed response.

The method makes your assumptions visible before they become expensive decisions.

You don't need a complicated research system. You need to recognize the difference between what you've learned and what you're guessing.

Four Tests to Decide Whether a Problem Matters

Not every inconvenience deserves a business.

Customers can complain about something and still have no intention of changing how they handle it.

To determine whether a problem is worth pursuing, examine four factors.

1. Frequency: How Often Does It Happen?

A recurring difficulty may deserve more attention than an occasional inconvenience.

But frequency isn't everything. A rare problem can still matter enormously if the consequences are serious.

Ask when the problem last occurred and whether similar situations have happened before.

2. Consequences: What Happens When It Occurs?

A missed appointment might waste preparation time, create additional work, or result in lost revenue.

Those outcomes aren't equivalent.

Don't assume the financial or operational impact. Ask customers what actually happened and whether they can identify a specific consequence.

3. Current Behavior: What Are Customers Already Doing?

Customers rarely wait for a founder to arrive before dealing with a problem.

They improvise. They use spreadsheets, messaging apps, notebooks, or manual processes.

A workaround can reveal an opportunity, but it can also show that the current approach is good enough.

Find out what customers have already tried, why they continue using it, and what would justify changing it.

4. Priority: What Else Competes for Their Attention?

A problem doesn't exist in isolation.

A business owner might dislike managing appointments but be far more concerned about inconsistent sales, staffing, or cash flow.

If scheduling isn't a priority, even an excellent scheduling product may struggle to earn attention.

Your job isn't to convince customers to care more. It's to understand what they already care about and why.

Turn What You Learn Into a Business Decision

After several conversations, review what you've learned. Look for repeated experiences, meaningful differences, and evidence that contradicts your original assumptions.

Three decisions can guide your next move.

1. Keep investigating.

Choose this when customers repeatedly describe a problem, but its consequences or importance remain unclear.

Your next step might be to investigate the cost, observe the existing process with permission, or speak with customers who experience the problem differently.

2. Narrow your customer group.

Choose this when the problem matters to some customers but not others.

For example, a hypothetical business managing dozens of appointments each day may face different scheduling challenges from one handling only a few each week.

Instead of building for every service provider, investigate which group experiences the most meaningful difficulty.

3. Reconsider the problem.

Choose this when customers consistently report that the problem is minor, adequately handled, or less important than another challenge.

This doesn't mean abandoning the entire business idea. It means questioning whether your original assumption justifies further investment.

There's no universal number of interviews that automatically validates a customer problem. A handful of conversations may expose weak assumptions, but they cannot establish demand across an entire market.

The goal isn't to collect enough positive comments to feel confident. It's to gather enough relevant evidence to make a sensible next decision.

Know What Customer Interviews Cannot Prove

Interviews are useful, but they have limits.

People may forget details or describe what they intend to do rather than what they actually do. Someone who enthusiastically discusses a problem may still have no interest in purchasing your solution.

That's why interviews shouldn't be your only evidence.

Once you understand the problem, you may need to observe real behavior, test a small prototype, or see whether customers make a meaningful commitment to a proposed solution.

Some ideas involve unfamiliar technology or emerging needs that customers struggle to describe. In those situations, problem discovery and prototype testing may need to happen together.

For sensitive, regulated, or high-stakes situations, testing may require additional safeguards or specialist review.

The distinction is between building to learn and building because you've already decided your assumptions are correct.

Build With Evidence, Not Just Enthusiasm

A promising business idea often begins with noticing something that could work better. That's a worthwhile starting point, but it isn't proof that customers need a solution.

Before committing significant resources, make sure you can explain the problem without mentioning your product. Understand who experiences it, what happens when it occurs, and why solving it matters more than competing priorities.

Sometimes the right next move is to build a prototype. Sometimes it's to narrow your audience. And sometimes it's to admit that the problem you wanted to solve isn't the one customers actually have.

You don't need perfect certainty before taking action. You need to know what you've learned, what you're still assuming, and what deserves to be tested next.

About the author: Jay Scott Kirk Lee is a Canadian entrepreneur with a background in sales, marketing and business development.