Are People Willing to Pay for Your Product? Here's How to Find Out

Note: This article is part of my toolkit newsletters🚀 where I share resources about building things. Join me :)

As a product builder, I build things full-time, whether it’s a venture newsletter, micro-products or coaching founders to build tech products. For fun, I built an AI article tool, event app, meal box app, SaaS tracker, sneaker app, using my rapid MVP technique.

This is a follow-up post of my multi-part Product Guide series.

The first step in validating a product idea is not to build a MVP. Rather, it is to validate the untested assumptions about the problem and the customer. By validating these two components, you will be able to move closer towards building the right MVP.

Today, I'll go over the step-by-step process for validating a problem. So that you can figure out whether a problem is worth solving, de-risk your idea, and create something people want to pay for.

Step 1: Problem discovery

Start by exploring your personal interests and experiences.

What problems are you passionate about solving? It can be healthcare, productivity, no-code, workflow automation, and so on.

What pain points have you experienced that a product or service could potentially solve?

Next, write down these problems and rank them by:

• Intensity: How intense is the problem?
• Pain level: What is the cost of the problem?
• Market potential: How big is the problem?

You can use Google Trends, market research and existing statistics to get a sense of the severity of the problems.

Then, narrow down to one to two problems you’re interested in learning more about.

Step 2: Who has the problem?

Now figure out who are the target audience who is experiencing the problem in Step 1.

Remember that one problem can affect multiple types of potential customers.

These customers may have different needs, preferences, and behaviors.

To truly understand who you’re solving the problem for, you want to map out the unique characteristics for each customer segment.

I’d recommend to prioritize on the customer segment that encounters the problem most frequently. Here are some examples:

Customer Segment 1:

• Problem: Difficulty losing weight due to lack of time for exercise
• Target Customer: Busy professionals aged 25-40 who work long hours
• User Persona: High-income, demanding job, typically eats out, may be willing to pay more for convenience

Customer Segment 2:

• Problem: Difficulty losing weight due to lack of time for exercise
• Target Customer: Stay-at-home parents with young children aged 30-45
• User Persona: prepare homemade meals every day, limited time for fitness activities, may be interested in affordable solutions

Step 3: Create a problem hypothesis

Every unvalidated problem is merely an assumption.

We think that people HAVE this problem, but we could be wrong!

To validate a problem, we need to turn it into a hypothesis statement.

Here’s my template:

🤔 We think that (insert the problem)

🥹 Customer want to (accomplish a task, do certain things, have a need)

🚀 We can verify this by designing a test (insert the experiment you want to run)

✅ If the result is (insert the validated result)

❌ But if the result is (insert the invalidated result)

⏭️ We will (proceed, pivot or change)

Note: Map out each hypothesis statement for each customer segment you’ve identified in Step 2.

Step 4: Test the problem hypothesis

During the pre-MVP stage, conducting user interviews is an effective way to validate your assumptions about the problem. To start, consider interviewing 10 to 20 individuals to determine whether:

• Your target users HAVE the problem you want to solve
• Your target users find the problem PAINFUL ENOUGH to seek a solution
• Your target users encounter the problem FREQUENTLY ENOUGH to require a solution
• Your target users indicate that they would be WILLING to pay for such solution to solve their problem

Here’s an example of the test result:

• 🤔 We think that (busy professionals often struggle to find time to exercise)
• 🥹 Customer want to (lose weight)
• 🚀 We can verify this by designing a test (interview 20 busy professionals)
• ✅ If the result is (16/20 said they have neglected their health due to lack of time to exercise)
• ❌ But if the result is (only 10/20 said they have neglected their health due to lack of time to exercise)
• ⏭️ We will proceed if (take the 16/20 result)
• ⏭️ We will pivot if (10/20 result)

Step 5: Refine the problem statement

Problem validation is an iterative process, not a one-time event. Here are some scenarios of when to refine the problem statement:

(1) Account the feedback from target users:

By actively listening to target users, you may uncover specific language or themes that they use to describe their problem.

If this happens, it's important to refine the problem in a way that accurately reflects the pain points that your target users are experiencing.

(2) Invalidated a problem:

For instance, you may have started with the assumption that customers:

• struggle to find time to exercise

But during user interviews, you discovered that the bigger problem is that they:

• struggle with finding the motivation to work out

If the original problem hypothesis has been invalidated, you need to pivot your problem statement or change the problem direction or product idea entirely.

In such a scenario, you need to:

• pivot your problem statement to reflect the new insights you have gained
• consider changing your product direction to address the new problem statement
• or change the product idea entirely if you have not found a valid problem to solve

Takeaway 🚀

The problem validation process is a crucial step in determining whether people are willing to pay for a product idea. This is because:

• if the problem isn’t big enough = not many people are willing to pay
• if the problem isn’t painful enough = not many people are willing to pay
• if the problem is big enough with no viable solutions = people are likely to pay

[1] Find me on Twitter / LinkedIn 🔥

[2] Get my product-building teardown — Join my newsletter 🚀

Also published here.