“There is a big supermarket in my neighborhood. Let me build a grocery list app that uses natural language processing to parse the items and compare prices against Amazon. It will save people so much time and money!”

For many problem solvers, we often come up with product ideas that we think will solve a problem. While many ideas never actualize, you might move on to the next step. If you think the next step is building a solution and testing, then you need to think again.

Products need to solve a problem — and a valuable one. Trying to solutionize might be tempting, but a solution to a non-problem is wasted work. The important, hard work begins with identifying the ideal customer and what valuable problem you can solve for them.

Here are the 3 questions:

1. Who are the ideal customers?

2. What problems do they have?

3. How severe are the problems?

You need to first define what this ideal customer looks like in terms of demographic, position, and customer type. For example, you might have started out wanting to solve the e-commerce logistics. There are many profiles even within. Do you want to solve for a small brand that has no logistics? A large corp with in-house last-mile delivery? The end consumer in Indonesia that takes longer to deliver to?

The more detailed and niche this profile is, the better. You don’t have to marry this profile either. You can explore this segment, do user interviews, and may realize that this is not the customer that you want to solve for.

User interview is an art. You need to be formative, not summative. You are going in to learn about this person’s behavior, preferences, and maybe pain points. You are not trying to get them to say yes or no to your product idea. No other book put it better than The Mom Test by Rob Fitzpatrick. This book guides you on how to “talk to customers & learn if your business is a good idea when everyone is lying to you.”

The summary is this: Ask the right open-ended questions with no agenda. Even for strangers, it’s easier to be polite and say yes to an idea than to tell you that the idea is useless. You may or may not find that this customer has a problem, which is great because it saved you weeks if not months of useless building.

While they may have existing solutions to the problem, you may learn that they don’t serve the user well due to these constraints:

1. Too expensive

2. Too complicated to use

3. Doesn’t have all the functionalities

By understanding the problem, and by extension how existing solutions don’t serve them, you can have a higher conviction on whether this problem space is worth your time and resources.

Having identified a problem, you now need to gauge the severity of the problem on the spectrum between nice to have to can’t live without. This ultimately decides the customer’s willingness to pay and speed of adoption.

Some questions to guide this exploration:

1. How much does this problem pain them? What is the frequency?

2. What are the consequences of having this problem? Cost, time and/or happiness?

3. Is it a mild annoyance or strong frustration?

4. Have they tried to look for a solution before?

5. Do they currently pay for a solution?

Collect anecdotes and evidence on how they tried to address this problem before. The more painful the better, as it means it’s more wanted and easier to deliver for you.

Wrapping up, before you build anything, you should have an in-depth understanding of the user, problem, and severity. Spending time on this process can save months of wasted effort down the line when you might discover that a super cool app you built has no use case or market want. Deliberate user interviews can also make the solution almost obvious, saving you guesswork and higher-cost decision-making.