When you start a business, you often wonder how to find out if your idea has a place in today's market, if the product or service you are going to market is solid enough to stand up to the inclemencies of a law of supply and demand as ruthless as the one we live in today.
In this article we are going to talk about the guidelines and techniques that we should take into account to validate our product/service, to see its viability and not to bet all our effort and money on something that might not have a market or that needs to pivot in a direction we did not foresee.

What is a product or service?
Before we get straight to the point, let's make sure we share certain terms and concepts. First of all, we need to understand what a product or service is. Here there are two points that are the ones that generate the most debate (in the good sense of the word) between me and the entrepreneur when we talk about it.
On the one hand, it must be understood that a product or service are, always, the solution to a problem that we have detected in the market. In other words, if your product is not able to solve something, we cannot say that it is a product in itself and, of course, it will not have any commercial value.
An example I like to give is Dropbox. I'm of an age when I lived in a time when if you wanted to share information with a client and it was too big (about how many GB, for example), the only way to do it was to take an external hard drive, copy all the information there and send it by courier to the client's offices.
It sounds like something from prehistoric times, but for a while it was the only realistic solution. Mail services only let you send a limited number of megabytes. There were no options such as Wetransfer or Google Drive. So someone thought it would be great to have a hard drive in the cloud and also be able to share it with anyone. That's when the idea of creating Dropbox was born. They had detected a problem and wanted to solve it.
And this is when someone tells me that Netflix doesn't solve any problems and it is a product. It is easy to reach that premise, but the reality is that it does. It solves the problem of where to occupy our leisure time, how to distract ourselves, relax, experience certain emotions, etc. We are human beings, and humans have certain needs, however primal they may seem. So yes, any product that solves a problem for us, even if it is an apparently primitive one, can be considered a fully-fledged product.
Let's go to the second point. Your product is not only what you sell, but also how you sell it, to whom you sell it... let's go, the business model. If you have created an innovative sneaker for runners, or a software that helps manage household finances, a service where you teach languages to other people... these things, by themselves, are not the product. The product is the whole box: what you sell, who you sell it to, how you reach those customers, what prices you set, what guarantee policies you offer... Everything, as a whole.
Going back to the example of Netflix, HBO, Prime or similar. What do they sell? Audiovisual content in digital format. Is that the product? No. The product is the platform where they sell it, its functionalities, the business model (subscription), the after-sales service, etc, etc, etc, etc. Because if the product were only their movies or series, they would not be so successful, since most of them can be consumed through other channels, such as, for example, buying them on DVD/Blu-Ray, or through methods more typical of people who wear an eye patch and a wooden leg.
A very clear example I have with my parents: we gave them the series Game of Thrones in DVD format. They started watching it, enthusiastically. When they were halfway through the series, their internet provider happened to give them six months of HBO. From that moment on, they never watched the series on DVD again, and finished it on the streaming service. Why? Because it was more convenient, simpler... If the product was the audiovisual item itself, they wouldn't have cared which of the two systems to use, but the product is more complex and really encompasses many other things.
Imagine you sell sneakers, is it the same to sell them to the general public as to focus on selling only to the general public? runnersIs adopting a low-price strategy the same as adopting a retail pricing strategy? premiumIs it the same if you sell them in a physical store as if you sell them online? When you put the whole business model together, that's when you really see what the product is really like.
The form that, personally, convinces me the most when trying to represent these two points (as well as helping us to define our product) is the Lean Canvas, This aspect will be dealt with in another article.
Having clarified these two points, we are now ready to talk about the product validation. And this is where we bring to the fore two different conceptions, both referring to the product, but at very different times. We are talking about the validation of the problem and validation of the solution. We will talk about the first one right now, and about the second one in the next article.
Did we solve a problem worth solving?
At this point in the article we have already seen that the purpose of a product/service is to solve or mitigate a problem. We have to be very clear about which problem we believe that our product solves. Yes, I said «we believe». It is very easy to get lost in our idealized assumption that the problem we have identified exists, because, in reality, it may not be true. Therefore, our future business must be based on three principles:
1. Solve a problem
We have already talked about it, so I won't go any further. If there is no problem to solve (or mitigate), our business idea has no place in the market.
2. That there are people who need this problem to be solved.
It is true that sometimes, objectively speaking, our product solves a problem and even so there is no commercial route because it is a problem whose resolution is not relevant to the public. It is also necessary to find prototypical customers who need the detected problem to be solved.
3. That those persons are willing to pay for the resolution.
And, of course, solving problems for people who need it falls short without the third aspect: they must be willing to pay for it. Because there are many products that solve the first two points but fall down on the third. Users must be willing to pay for the resolution of the problem and, if this is not the case, either the project must be abandoned or a profit model must be devised that does not require the user to pay for it.
Validating the problem
Well, we have already stated the three requirements, so what do we do now? Well, let's try to validate the problem before we spend energy and money on the solution. We're going to take these three requirements and we're going to look for people who will allow us to evaluate whether our product has a possible commercial life.
«Why are we doing this? It's very clear to me that my idea is going to work.»
I have heard this phrase a hundred times. It is logical to think that we have a good (or great) idea, that it is going to work because certain people have reaffirmed it to us, and that the company has a good (or great) idea, and that it is going to work. Fulanitos Corporate Let's face it: out of every ten companies that are registered in Spain, half of them are dissolved before they reach one year of life, and after three years only one remains standing.
The data is bad. The venture capital that many entrepreneurs rely on can be harmful because money is wasted because we jump too quickly into creating the solution and trying to monetize it before we have even made sure that the problem we are trying to solve exists. That's why validating the problem comes first, because it allows us to take fewer risks. We should start getting answers before we have put all our eggs in the basket.
I was once told by an entrepreneur that he didn't want to get these answers because he was afraid that the result would be that his idea should not go forward. I want to see it the other way around: don't spend money or sleep on something that seems to have no path. The disappointment and pain when you close a business is much greater. In addition, most of the time, the conclusions are not that you have to stop, but that you have to rethink strategies or business model. Many times we discovered that we were not targeting the right sector, that the price was not the right one, that the right customer segment is very different from the one we thought?
Well, now let's get down to business. Our product is going to need a continuous learning system. We will never stop iterating on it, and we will always be improving. Basically, we will follow the following infinite loop:

In this phase, we will be learning about the problem. And, specifically, we will be focusing on risk-based learning:
- Product-related risks: how our potential customers react to the problem we have detected.
- Market-related risks: how our potential customers are currently solving this problem.
- Risks related to the customer segment: who are the potential customers and is this customer segment viable in terms of scope and in economic terms?
We must try to discover all of this in this phase and, to do so, we are going to perform... drum roll... !interviews!
Yes, the so-called interviews. There is no better way to understand a potential customer than by talking to them. What they can tell you face-to-face (or even in a video call) is far more valuable than ten impersonal surveys. Therefore, the right way to learn about problems will be to ask questions to those users who, in our opinion, fit what we consider to be the prototypical user of our product or service.
And since interviewing is an art, we will need a script or structure that will allow us to draw conclusions about the three types of risks we mentioned earlier in this article. For this post, I'm going to apply the interview model Lean Startup, with some nuances of my own, because I think it is quite coherent. This does not mean that it is compulsory to do them this way, but it is important to have a proven methodology behind them because we cannot afford to do the interviews badly.
So the structure we would work with would be as follows:
Welcome
Let's be polite and thank the interviewee for attending to us. Also, let's take the opportunity to make a very brief summary of the problem we are trying to solve.
Demographic information
Before continuing, we must obtain demographic data from our interviewees. This is important because it will later help us to group responses according to patterns and draw conclusions about our final prototypical customer.
What information to ask for? Well, it will depend on the type of product or service, but personal aspects such as age, if they work and in what, hobbies and where they live are usually fixed questions. Then come other questions about habits that have to do with our product. For example, if we think about the case of Dropbox, some of the questions could be: «Do you usually share files online?«, «How often?«.
History of the problem
Basically it is to make the client understand the main problems we want to solve but, instead of listing them, we tell them in story format, explaining how we have come to the conclusion that the problem exists and how we want to shape the solution in the future.
Questions about the problem
It's time to address the problem directly and start asking questions about it. In the Dropbox case, some relevant questions could be: «Do you feel limited when it comes to file sharing?«, «Do you find file sharing via e-mail easy enough, and is there any aspect of it that bothers you?«.
We evaluate competence
It is time to see if these interviewees are already solving the problem in some way. They may even surprise us with solutions that would never have occurred to us and that are within our direct competence. While the interviewee is telling us how he or she is solving this problem (and if he or she is not solving it, it is also important to know, because it may mean that we are dealing with a problem that is not worth solving), we have to be attentive to what he or she says and how he or she says it.
We must try to understand what is most important to him, what frustrates him the most. We need to understand how significant it is for him that someone solves these problems. It is not the same as a “we have to solve it” as a “it wouldn't be bad to solve it” or a “it's okay if we don't solve it”.
We say thank you, we throw the cane and we try to attract other interviewees.
We thank the interviewee. We ask him/her if he/she would be interested in testing, free of charge, our solution in the future, when we have it ready, and, after that, to come back for an interview with us. Finally, we ask him/her to introduce us to more people who have the problem we are trying to solve.
We document
Take time to document the answers, write down everything you consider relevant and, when you have done many interviews, compare and draw conclusions.
What's next?
When we have enough information from the interviews (quantitative and qualitative), it will be time to draw conclusions. If things have gone well, we will have this data:
- We will know the demographic profile of our early adopter.
- We verify that there is a problem that needs to be solved and is worth solving.
- We will know how potential customers are currently solving the problem (competition).
If we come to the conclusion that we are ready to move forward, we need to begin to plan our solution validation, This will be discussed in a later article.
Conclusions
Before taking unnecessary risks we must face a validation that our idea can work. It is worth investing time in this as we can discover key aspects of our product before investing large amounts of time and money in it. It is important to focus on the problem we are solving and see if the market requires a solution like the one we have in mind.
It is possible that the type of your product will save you this step. It does not make as much sense to conduct interviews if, for example, you sell sneakers or toothbrushes. However, in these cases, it is interesting to do a little market research and study your competitors. Look at those websites that sell a similar product to yours. Look at their prices, what they offer and how, if they advertise, what customer segment they target, etc...
In ehe next article We will talk about how to validate the solution, i.e., once the problem validation phase is over, what we have to do to validate that our product or service really solves it.

