How not to validate the problem you are solving

Do not index

This is article #1 in my series How not to build a business. I open up about all the mistakes I made building a software as a service and all the lessons I learnt in the process.

My mistake: I did not listen to my customers

As a ‘well read’ entrepreneur versed in the Lean Startup’s principles, I was aware that a very high percentage of companies fail because they do not find a problem to solve. Convinced of my capacity to avoid being part of that group, I knew I had to interview my future clients to ensure that I was solving a real problem. Being technically savvy I had already created a prototype on Sketch of my proposed solution. I made a list of the three main problems that I thought I was solving and hit the streets knocking on restaurants’ doors to see if I could interview them about my proposed business. The main problems that I was addressing were:

Physical menus cannot be changed easily.

Managing translated versions of menus is a huge pain.

Dealing with people with allergies clutters the menu and makes it impractical.

I remember that as I went through the customer interviews, almost all restaurant owners agreed with the problems that I identified. A little bit impatiently (thinking how clever I was) I would rush to show them my prototype with a short product tour about how my digital menus would change their lives. I would leave the restaurant convinced that as soon as we launched the working version, they would already be willing customers. I was wrong.

My key learnings:

#1 Talk in terms of problems not your solution

Let’s give me some merit. I did actually hit the road. That is better than people that spend money building an app without talking to any customers. I also had prepared a set of problems. However, I was so convinced that I was right that I did not listen enough. I had reversed engineered the problems from my solution and tried to guide the conversation toward showing my solution. I went with the intention to talk but I never really listened.

When validating your problem, a practical way to address the mission is to think about the three main problems that you are trying to solve. You should not even think about the solution yet. Prioritise the problems by the acuteness of pain associated to them and go through them with your interviewees.

#2 Talk less, listen more

In my defence, I must say it is difficult to remain quiet when something excites you. As soon as I had my business idea and my prototype, I had to show it around. A good way to identify if you are talking way too much is if you are not learning anything and you are just waiting for our desired client to compliment your great idea.

You have to let the interviewee talk, after all he is the one who knows the problems best. The conversation is way less under your control. Even if you have brought your list of problems, it is very possible that the conversation meanders to a path that was unexpected. If this happens, like the senseis that teach guided meditation, do not try to control it, observe it attentively and discover new information. That is the whole point of the validation process.

Let’s compare types of questions and statements that are useful to learn with some that are not:

Wrong approach	Right approach
• Would you buy my product? • Do you think my idea is good? • Would you buy a product which did “include feature”? • How much would you pay for this “include feature”? • What would your desired or ideal product do?	• Tell me more about your problem • What makes this so painful for you specifically? • Can you elaborate about the last time that happened? • Have you tried to solve this some way? • What other things have you tried? • How are you dealing with it currently?

As you can see, the wrong questions address the future and uncertainties that have not happened yet. On the other hand, the right questions probe specifics - things that have happened in the past.

#3 Look for problems that require painkillers, not vitamins

A painkiller solves an excruciating pain, it is that kind of medicament that you cannot go without, a must-have. On the other hand, a vitamin makes you feel OK about yourself, giving you that extra amount of health - albeit mental - but in many cases you could probably go without it.

You really want to make sure that the problem you are addressing is painful and excruciating. That will give you most leverage when selling and negotiating price. The best way to ensure if the problem is real is to see if and how they have tried to solve it in the past. Is their solution inconvenient or expensive? If they have not rushed to solve it, you are probably dealing with a vitamin (or nice to have).

#4 Remove your ego from the equation

Only years after the fact, have I realised that my incapacity of listening to my interviewees was due to my ego. Even though I had read extensively about problem validation, I ended up only listening to those who told me what I wanted to hear. I had already made up my mind, I already had my solution and was looking for rational justifications. You have to try to be honest with yourself.

The process of validation is a risk reduction mechanism. You must be ready to hear what you do not want to and if that happens, you should treat it as a success. If your ego blinds you from reality, the whole process is futile and you will end up losing more money and time in the future. If it is clear that there is no problem or you are not solving anything with your solution, be quick to drop it and search for something else.

Conclusion

If you manage to confirm a painful problem, it is time to validate your solution. Feel free to check out how not to validate your solution in my other blog entry.