How to build the right thing for the right people

How do you make sure that what you build will solve a problem for the right people, and they will pay you for it?

Customer Development is the precursor to Product Development. It is simply the practice of identifying, understanding, and relating to your customers. Before you even have a product.

Customer Development is similar to selling, in some ways. You're trying to understand the customer and their world, so that you can solve their problem using your product. Only, at this point, you don't have a product. You don't even completely know what it will be yet. You just have a hypothesis.

Your hypothesis could be in the form of an idea, a belief, or a problem. You hypothesise that this thing needs changing, and that people will pay you to do it. There's a chance that you're right, but most likely you're, at best, just partly right. Or totally wrong.

You may have the right audience, but they place a different importance on solving the problem than you imagine. You may have the problem definition just right, but it's actually not the right person to buy it.

The point is, no matter how good the idea is, it still needs to be validated to ensure that it has a chance of landing. You could build and launch your product to find out--which is what some people do--but that's expensive, and risky.

How do you validate your hypothesis, then? The only way is to literally talk to the people you think will be your customer. The people who are feeling the problem you believe exists, and will (hopefully) pay you. Asking a friend doesn't count, unless they are in the group of people who would buy it.

But there's a catch. You can't just ask people for their opinion, because people naturally lie. It's not that they are bad people, or are intentionally misleading you. They just want to protect your feelings and avoid conflict.

You need to be a little bit sneaky. Without sharing your idea or your hypotheses, you should ask them about their world, their challenges, their constraints, their feelings, and their perspective. You need to get to know them. The conversation should be entirely about them, not you. And, definitely not your idea.

People want to please. They don't want to offend or upset you. This is nice, but it's terrible for validation. Don't listen to opinions.

What should you be asking? Simply ask them about their past experiences. "Tell me about the last time you did X." "How did you try to solve it last time?" "What is the workaround you use now?" "How much does that cost you? Time or money"

Past experiences don't lie. If the person talks about the future, as in "I would buy X", then take it with a grain of salt. That's a nice signal of their enthusiasm, but definitely not validation. Past experiences don't lie, but future predictions often do.

I personally had many interviews where people would say something like "I wish someone would build X. This would solve my problem!".

Is this validation for my idea to build X? No. Upon doing some quick searching online, I found that it actually already exists, and the person actually didn't try to solve it themselves. If they don't take the time to search for it, then they certainly don't care enough to pay you.

Validation is when a person cites your problem as being top of mind, and either tried and failed to solve it themselves, or currently uses some workaround which costs them more than you want to charge. eg. "I currently spend around 4 hours doing this every week". So $50/month is probably going to be fine.

If you have repeated conversations with a similar outcome, then you can consider this a strong sign of validation and get started. Keep having these conversations all throughout your product development--or for the lifetime of your product--to continuously validate your hypotheses and solve real problems for your users.

In the beginning, for a startup, it's all about de-risking. Identifying where the risks are and trying to mitigate them. Building first and launching before validating, is simply saving up all the market risk until the launch date. At which point you'll find out if you hit the mark or not. Customer Development is a way of reducing this market risk by deeply understanding your users before you even write a single line of code.

Originally published at sneub.com -- check it out for more articles like this

Everything I learned on this topic came from reading The Mom Test and from putting those lessons into practice over the course of more than 100 user interviews. This article just touches lightly on the topic. To learn even more, I highly recommend reading the book.