This article is part of my toolkit newsletters🚀 where I share resources about building things. Join me :) Note: As a , I build things full-time, whether it’s a , 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 product builder venture newsletter micro-products rapid MVP technique. This is a follow-up post of my series. multi-part Product Guide The first step in validating a product idea is not to build a MVP. Rather, it is to validate the about the problem and the customer. By validating these two components, you will be able to move closer towards building the right MVP. untested assumptions Today, I'll go over the step-by-step process for validating a problem. So that you can figure out whether a problem is , your idea, and create something for. worth solving de-risk people want to pay 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: How intense is the problem? Intensity: What is the cost of the problem? Pain level: How big is the problem? Market potential: 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 . Here are some examples: most frequently Customer Segment 1: Difficulty losing weight due to lack of time for exercise Problem: Busy professionals aged 25-40 who work long hours Target Customer: High-income, demanding job, typically eats out, may be willing to pay more for convenience User Persona: Customer Segment 2: Difficulty losing weight due to lack of time for exercise Problem: Stay-at-home parents with young children aged 30-45 Target Customer: prepare homemade meals every day, limited time for fitness activities, may be interested in affordable solutions User Persona: 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: (insert the problem) 🤔 We think that (accomplish a task, do certain things, have a need) 🥹 Customer want to (insert the experiment you want to run) 🚀 We can verify this by designing a test (insert the validated result) ✅ If the result is (insert the invalidated result) ❌ But if the result is (proceed, pivot or change) ⏭️ We will 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 the problem you want to solve HAVE Your target users find the problem to seek a solution PAINFUL ENOUGH Your target users encounter the problem to require a solution FREQUENTLY ENOUGH Your target users indicate that they would be to pay for such solution to solve their problem WILLING Here’s an example of the test result: (busy professionals often struggle to find time to exercise) 🤔 We think that (lose weight) 🥹 Customer want to (interview 20 busy professionals) 🚀 We can verify this by designing a test (16/20 said they have neglected their health due to lack of time to exercise) ✅ If the result is (only 10/20 said they have neglected their health due to lack of time to exercise) ❌ But if the result is (take the 16/20 result) ⏭️ We will proceed if (10/20 result) ⏭️ We will pivot if Step 5: Refine the problem statement Problem validation is an iterative process, Here are some scenarios of when to refine the problem statement: not a one-time event. (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 in a way that accurately reflects the pain points that your target users are experiencing. refine the problem (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 is that they: bigger problem 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: your problem statement to reflect the new insights you have gained pivot consider changing your to address the new problem statement product direction or change the if you have not found a valid problem to solve product idea entirely 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.

Built 11 MVP, no funding. Apps on Product Hunt #1 & Lifehacker. Product consulting US/APAC cos. 👋About: whizzoe.com

2021 - HackerNoon Contributor of the Year - VENTURE-CAPITAL

2022 - HackerNoon Contributor of the Year - Ecommerce

2022 - HackerNoon Contributor of the Year - Entrepreneurship

2022 - HackerNoon Contributor of the Year - Software

Get Product Building Guides

Nominated for 2022 - HackerNoon Contributor of the Year - Ecommerce

Nominated for 2022 - HackerNoon Contributor of the Year - Software

Nominated for 2022 - HackerNoon Contributor of the Year - Entrepreneurship

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

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

Too Long; Didn't Read

Zoe Chew

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Zoe Chew

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES