Table of Contents
Creating something new is always risky. Fortunately, there is a way to lower this risk. How? You can build an MVP, or minimum viable product, and test your idea first. This article will teach you the first three steps to build an MVP, the right way.
How to Build an MVP (Minimum Viable Product) the Right Way Part 2.
No.1: Find viable problem to solve
No successful product is built for the sake of building it. Each of them is built to solve a specific problem. Yes, there are some products that succeeded even though they were not built as a solution to any specific problem, or with a specific goal. However, these products are a minority.
In most cases, products that doesn’t solve any problem fail, miserably. That said, please don’t assume that having a problem to solve guarantees anything. It doesn’t. Product solving a problem can fail just as easily as product that doesn’t solve anything. Product solving a problem has some advantage the another has not.
Products solving a problem are usually easier to outline, plan, build, pitch and sell. All these things can make a big difference. The biggest impact on product’s success has the ability of the product to solve given problem. The better the product solves a given problem the better the chance it will find its customers, and succeed.
Start with the problems you have
This why it is the problem where you have to start, when you decide to build an mvp. A good place to start is by taking a look at the problems you currently have. Many products you are using today started this way, as a solution to a problem the creator himself had. Think about problems you are having right now.
Think about your personal challenges. What are some things you could solve that would make your life easier? Is there anything that you could do better if you only had the right tool? Is there something you wish would exist? Can you actually create this thing? Can you scratch that itch, solve that problem, by yourself?
The majority of us have some problems. Unfortunately, we usually rather wait for someone else to solve those problems for us. Why wait? If you have a problem you can solve it by yourself. There is another reason to start with your problems when you want to build an MVP. It is easier to stick with something that solve a problem you yourself have.
There is something you need to be clear about. It takes time to build an MVP. How much depends on the type of MVP you want to build and how complex it will be. You can build an MVP in a few hours and you may also need days or weeks to build an MVP. In case of something really complex may take even months build an MVP. Take this into consideration.
Make sure the problem is worth solving
Solving your own problems is a good start, but it can still lead to dead end. Why? With this approach, you may not build something nobody wants. However, you may build something only you want to use. And, that, is almost the same. No customers. No users. No traction. Slow death. This is why you have to make sure the problem is worth solving.
This means one thing specifically. Does anyone else have the problem you want to solve? Are they willing to pay for the solution? This is what it means to have a “viable” problem. You are not the only person having this problem. If you solve it, there will be other people who might be interested in using your product, and paying for it.
So, if you have a problem to solve in mind, or few of them, try to find people having the same problem and ask them if they are willing to pay for the solution. If you find those people you may have a viable problem and a good starting point to build an MVP. If you can’t find any? Save this problem for later and, for now, look for another problem to solve.
Find viable problem by talking with people
Another well-tested way to find problems to solve is by talking to people. So, if you can’t find any problem you have you could solve, talk to other people. If you have problems to solve, but none of them is viable, the same thing. Talk to other people. This is often why entrepreneurs dedicate some amount of time to networking.
Yes, they want to create partnerships and talk about business. However, they also want to understand what problems other people have. They can then solve these problems by building and selling products and services, i.e. build businesses. It is also why many startups started at schools and on university campuses, dormitories.
These places make it incredibly easy to meet people from diverse environments and with different problems and needs. The only thing you have to do, basically, is to find a table, start conversation and just listen. Sooner or later, it is very likely you will find either a problem to research or at least some inspiration.
So, if you don’t know what problem to solve, start talking to people. If you are not sure your problem is viable, start talking to people. What if you don’t like talking with people? Get used to it. If you want to build something other people will use you will come in contact with them, at least occasionally.
Focus on one problem
More is not always better. This is especially true if you want to build an MVP. Trying to solve multiple problems at once will not be beneficial. It will be detrimental for a couple of reasons. First, it will take more time to build an MVP. The more problems you want to solve the more robust your solution will be.
Bigger things take more time to build. This is bad because you need to build an MVP, something to test your idea, quickly and ship it. The purpose of MVP is to test the concept of your solution. It is to build only the initial version, something that works, something you can ship to your customers and user so you can get feedback.
It is not to create the whole thing, with all possible features, polished to perfection. This is much more doable when you focus on one problem. The second reason solving more problems at once is a bad idea is that it will, theoretically, make it harder to test what works and how well and what doesn’t.
The more problems you try to solve the more variables you have to work with. Then, when something doesn’t work as expected or your customers/users are not happy, it will be harder to figure out the root cause of the problem. The amount of variables also increases number of things that can go wrong. This increase is often not linear, but exponential.
Third, trying to solve multiple problems at once will make it harder to find the right type of customer/user for your product. Many people think that solving more problems is better because you can find more potential customers. This is true. However, there is a difference between potential customer and a die hard fan.
This is what we need to distinguish. Your main concern should not be everyone who can possibly use your product. Or, everyone on the planet. Your main concern, and target market, should be people who will love your product. Your main concern should be the people who will use your product every day, or as often as possible.
This is much harder to achieve when you are trying to focus on multiple problems, i.e. pleasing different types of people. This is why many successful products are focused on solving single problem. It is easier to solve one problem and do it really well. This helps you create product people love. This is just one step from turning these people into fans and evangelists that will spread the word about your product.
So, yes, solving multiple problems can open you to bigger market. However, is this really better? Is it really better to theoretically have a lot of people who sort of like your product and might think about trying it? Or is it better to have fewer people who are a die hard fans, who love your product and use it every day?
No.2: Understand the problem you want to solve
You have a problem to solve and you know it is viable. Meaning, if you build something that solves it, there will be people who might be interested in it. The next step is understanding that problem. This step, understanding the problem, is just as important to build an MVP as finding viable problem to solve.
Getting to the roots of the problem, and knowing it through and through, will help you a lot. It will help you outline and plan your solution. It will help you find the most difficult parts of the problem, and focus on them. It will help you find the must-have features your solution and what are the nice-to-have.
Thanks to this, you can build an MVP faster than you would otherwise. Instead of trying to build all theoretically relevant and certainly useful features you can choose specifically only those that matter the most. One of the reasons to build an MVP is to be able to gather feedback on your product from potential customers.
This is much harder if you have nothing to show, if you are still working on yet another “necessary” feature. When it comes to MVP, speed matters. Your main goal is to build something as fast as you can so you can ship it. Then, you can start gathering feedback and use that feedback to fix, improve and polish your product.
Understanding the problem will also help you identify your customers and users better. This, will help you in two ways. First, you will be more likely to build something specific segment of people might really want to use. Second, you will also find people who might be interested in testing your product, giving you feedback to help you improve it.
Don’t get stuck, researching the problem forever
There are many ways in which taking the time to understand the problem you want to solve can help you. On the other hand, there are basically no downsides. What can you lose by doing more research on chosen problem? You will not build an MVP that will not work because you have more information about the problem. Rather the opposite.
The more information you have about the problem the better positioned you are to build an MVP that works. The only thing you can “lose” is time. However, even this is debatable. Yes, you may lose some time doing more research, but you may also save some time in the future by using the extra information to prevent potential problems.
In sum, the amount of time lost and saved will be relatively balanced. Unless, of course, you get stuck in research. The problem with research is that there is always something more to learn. This makes it easy to get stuck. Then, it doesn’t matter how much information you have. You will never build an MVP, or anything, just by doing the research.
The solution is simple, and hard. You have to know when enough is enough. Do you understand the problem enough you can describe it in a few simple sentences and anyone can understand it? When you talk with other people having this problem, will your find common ground? Will your words match what they think, approximately?
Next, the solution. Do you understand the problem enough you can outline your solution and create a step-by-step plan to build it? If you answered “Yes” to these questions, you know enough. If you are not 100% sure, that’s also good. Remember, when you want to build an MVP, speed matters. Get enough information so you can get to work and ship.
No.3: Identify your ideal customer/user
You know what problem you want to solve. You also did the research to really understand the problem. The next step is identifying your customer. Just as you have to be specific about the problem you want to solve you also has to be specific about for whom you are solving this problem. So, for whom do you want to build an MVP?
Focus on people who will want to use your product every day
One thing we have to make clear is that “Everyone” is not an acceptable answer. We already briefly discussed this, in the “Focus on one problem” part. To remind you, it is a bad idea trying to build something everyone sort of like. A better approach is to narrow your focus on people who will love your product.
You are looking for people who will want to use your product every day. People who will be a die hard fans. This is the kind of people, customers and users, you should focus on. Why? First, these people will help you the most. Anyone who tried to build an MVP will tell you that it is hard to get useful feedback from people who don’t care.
Well, this is not true. It is almost impossible. When people don’t really care about your product they will not “waste” their time talking with you. When something doesn’t work they simply move on and trying something else. Die hard fans will not. When something breaks, they will not switch to something else.
Instead, they will help you figure out what’s not working. They will give you feedback. They will communicate with you. They will also help you test your attempts to fix the problem. Imagine having a team of dedicated testers who are willing to help you build and improve your product. The best part? The will do it for free.
This is the second also the second reason why you should focus on die hard fans. Die hard fans will forgive you, a lot. When you build an MVP, especially the very first version, it is not really anything stable. That ting is full of bugs and there are many things that work just by happenstance. You are actually happy the whole thing holds together.
It is no wonder something breaks when some tries to use it for the first time. When this happens, when something breaks, die hard fans will not throw your product away. They will not leave you. Die hard fans will have patience with your product. They will continue using it and help you with it, despite the issues.
Third, die hard fans will help you spread the word about your product. It doesn’t matter how much you spend on marketing. Nothing can beat positive word-of-mouth. Nothing can beat enthusiastic people talking about your product. So, stop looking for everyone. Instead, look for those die hard fans. Look for people who will love to use your product.
Create a customer/user profile based on the problem
When you want to find the right people to reach to, one tool that can help you is customer profile. If you did the research you should know a lot about the problem. This should also help you figure out what type of people could have this very problem. Think about the people you talked with during your research.
Think about the people you think could have this problem. Is there some general characteristic, theme, topic or interest all these people could have in common? Are there some channels where you could find these people? Online or offline, are there some places where these people could hang out or spend their time?
What about their behavior, motivations, daily activities or other frustrations? Is there anything you can think of that could help you describe your ideal customer/user? Use everything you know about the problem and also what you’ve learned from your past conversations with people you’ve reached out to so far.
Remember, the more specific you can get about your ideal customer/user the better. Being specific will help you focus on the people for whom your product will be the right fit. It will help you find people who will most likely appreciate and use product. People who will most likely become your die hard fans.
Conclusion: How to Build an MVP (Minimum Viable Product) the Right Way
Now you know the first three tips/steps that will help you build an MVP the right way. Next steps? Apply what you’ve learned today. Start by finding a problem that is worth solving. It has to be a problem other people have and they are willing to pay for the solution. When you find that problem, make sure you understand it.
Also, always focus on just one problem. No more. Don’t try to chase multiple ideas, at least not at the same time. If you want to solve multiple problems, do it individually, with separate product as a solution for each problem. This will allow you to perfect each of your solutions and keep it lean.
And as the final step, identify your ideal customer/user. Focus on people who will want to use your product every day, people who will love your product, people who can potentially become your die hard fans. After that? Wait for the part 2.
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
<-- ### Links: -->