Victor Hugo once said: “No force on earth can stop an idea whose time has come”. I decided to start the second part of my large MVP-development material with this quote because this is, perhaps, the only case when it is really hard to screw up.
However, mundane and realistic ideas are always at risk of failure due to poor management and implementation. And that isn’t all the challenges yet.
In order to minimize this risk, I have provided you with a list of steps that will help you create an MVP that is as close to ideal as possible.
The main objective of creating an MVP is to verify your initial hypotheses in the most effective way. The first step in achieving this goal is to formulate a problem statement clearly. In essence, the problem statement determines the gap that exists between the current and ideal state of things in the target market (e.g. its conditions, products’ quality, service timings, etc.). In order to reveal this gap correctly, you need to ask yourself two main questions:
Is the problem defined?
To answer this question, entrepreneurs can use the principle of Five W’s (Who, What, When, Where, Why). Answers to these questions will help you determine the environment in which the problem exists, who exactly has this problem, how it affects these people and why.
After that, it is necessary to determine the conditions to which you will strive. Bridging the gap between the two “poles” will be your task.
It is very important to define the problem accurately because this will help you minimize expenses and make your MVP successful. For better understanding, let’s review some examples of both poor and good problem statements.
Workflow Optimization System
Poor: We wish to create a system in which each individual worker will be able to understand his tasks and his contribution to the overall work plan. Are you feeling this? That it is a poor example? It really is. That is because we voice the problem right away in terms of a solution. We immediately described what we want to see in our system, without explaining what problems it will solve. And this is a fundamentally false approach to the problem statement. We don’t indicate any details of the problem or a gap between the poor and better state of things.
Let’s try to turn this problem statement into a good one.
Good: The situation is this: in the working process, builders have to use 2-3 or even more systems at the same time to coordinate their work since none of the existing systems is suitable for all employees.
This situation causes a number of problems. In addition to the obvious work progress slowdown and increased risk of errors, it also forces workers to spend time learning how to work with all systems, instead of learning to interact with one. Also, the input of certain data into each individual system takes time and interferes with data integration. The risk of errors and data loss when transferring between the systems increases too.
It sounds like a good problem statement now. We can understand that the builders really need a single system that will solve several of the priority problems described above, and bring them real benefit.
Telemedicine app for poor regions
Poor: There is a serious healthcare problem in African countries. We need to create a telemedicine system so that everyone can have access to a wide base of doctors. And again, not the best example. It isn’t clear what the problem is exactly. Is there a lack of doctors? Is it about people having no access to them? Or is it that you need to ride real far and families have no opportunities to do that? Is it about a particular country or about the continent at all? Let’s tweak this example a bit.
Good: In most small cities of the Democratic Republic of Congo, there is a critical shortage of doctors and healthcare specialists. Because of this, with the slightest suspicion of a disease in a child, parents are forced to take him to the long road to the capital and spend a lot of time in long lines.
This is a much more correctly formulated problem statement. First, we indicated a specific country – Congo – thereby identifying, at least approximately, the target audience and making the task realistic. Secondly, we outlined a concrete example with a family and a sick child, as well as the situation they are facing.
Finally, we explained the real need for a telemedicine system that would bring real benefits to all participants of the process – both doctors and patients.
The labor market proposals analyze system
Good: Yes, here we have only a good example, to consolidate your understanding of the thesis.
Let’s take a look at the construction market. The situation is that when searching for a new employer, contract workers have no way to find out the real working conditions, payment size and the level of production culture in the company. Everyone who was looking for work faced this situation. Everything seems to be fine, but who knows what kind of staff there is and what money they are ready to pay. Some of these questions can only be answered after a series of interviews. And you have to work in a new place for some time to find out the answers to all the questions above. Thus, unless you have good friends in the company, you run the risk of miscalculating with the choice of a job and wasting a lot of time and effort in vain.
Well, that sounds like a good problem statement. Everyone came across this, everyone went through it. Everyone is aware of this problem. It remains only to find a solution, which will be your task. Maybe it is possible to create some kind of system in which employees, on condition of anonymity, will be able to contribute personal and, most importantly, honest feedback on working in a particular company. It has no matter for now, since problem solving isn’t a part of problem statement.
Is the problem validated?
Once you have identified the problem, you need to make sure that it is validated. Often, this is done with the help of problem interviews with potential customers and everyone who is facing the problem you’ve identified.
You need to have compelling evidence that people are really experiencing this problem. In order to determine it, you should evaluate how large the problem is, as well as how often people experience this issue and how much damage it causes. Perhaps, someone has already implemented solutions to this problem, so appreciate the advantages & disadvantages of these methods. Finally, try to predict whether the problem is so serious that people will be willing to pay for solving it.
It’s worth noting that the problem statement doesn’t determine how to solve this problem. Rather, you become aware of the gap between the existing and the ideal state of things and begin to look for ways to reduce it.
Define which hypothesis to test
Of course, an MVP is one of the tools for testing hypotheses. However, this isn’t the best way. This is due to the fact that problem interviews with potential clients remain an efficient way to test the hypothesis of a problem. The result of these interviews will be the validation or refutation of the hypothesis. You don’t need to develop an MVP, a landing page or anything else for this.
In addition to problem interviews, there are also solution interviews. You show the client a ready-made solution to the problem that you validated and discussed earlier. The customer uses your solution, and then you should ask a series of questions about whether they will continue using it to solve the problem and what is missing in this product. But most importantly, you should offer them to buy this product. And it isn’t about your first earnings. This is done to reveal the client’s sincere attitude to your product. When people are offered to spend money, they reveal their true reasons and become frank about the product.
Note that solution interviews are conducted when you already have an MVP. And this is one of the best methods to promote your product.
Now, let’s get back to the section title. In order to determine which of the hypotheses to test, you need to know what hypotheses exist. There’s a classification of hypotheses by the RAT method — Riskiest Assumptions and Tests. According to it, there are several types of standard hypotheses:
- The hypothesis that money and uptrend exist in the market. This is the most understandable one. If this hypothesis is confirmed, it is clear that you need to enter this market.
- The hypothesis that there is a sufficiently large solvent customer segment on the market that is ready to buy products.
- The hypothesis that you are able to create a product that will solve the problems of a particular customer segment and this product will be bought.
- The hypothesis that the unit economics will converge, so a separate unit of a product or service will be profitable.
The trick of this method is that one hypothesis confirms the previous one. Thus, if you check the fourth hypothesis, then you automatically check the third one. And so on.
Of course, there are more targeted hypotheses, but this is a conversation for another day. The main thing to understand here is that you can check only the 2nd and the 3rd types of hypotheses using an MVP. Therefore, when deciding on which hypothesis you will validate, you should fold back the 1st and the 4th types — they don’t suit you.
Defining a hypothesis is an essential element when working with your MVP. If you are undertaking the development process, then you must first understand why you are doing this. You are doing this in order to test your hypotheses. That is why the process of hypothesis definition should be approached as seriously as the process of problem statement.
Let’s look at the Instagram MVP. Instagram appeared as another “check-in” Foursquare-like application. At the time of its launch (October 2010), there was a large number of photo editors and photo-sharing applications, including full-fledged social networks like Facebook.
Nevertheless, the hypothesis was stated. Instagram had its Unique Selling Proposition (USP): it combined both photo-sharing and photo-editing options. And although its editing features included only a few filters, the idea was backed up by talented people and artists, who knew how to work with photos. In a month, Instagram had 1 million users. Artists were creating their accounts to demonstrate their talent while other people were trying to take beautiful photos on their own (or just to see how others did it). The hypothesis that photo-sharing and photo-editing options combined in one application would be successful was confirmed.
Today, Instagram is a full-fledged social network and trading platform with a messaging system, a web version, and so on.
Decide which features to build
Having successfully identified the problem and hypothesized how you can solve it, you should decide what functionality your MVP will have.
As you remember, our task is to confirm the hypothesis with minimal effort and cost. So, the first question that you should ask yourself is whether you need to develop any feature to test your hypothesis. The truth is that in almost 90% of cases you do not need to. Why? Because sometimes it is enough to hold a problem interview. Therefore, once again: discard everything that is unnecessary, including features, and focus on the most important processes.
Below, we will provide you with 4 ways to make it happen.
- Focus on minimum functionality to test the hypothesis.
Reducing the MVP development costs should be your main goal from the very beginning. It is important to remember the three main stages here — build, measure, learn. And iterate. The functionality of your product should be sufficient to pass the measure and learn stages. Therefore, make sure that you have a working feedback form configured to receive user testimonials.Of course, the minimum functionality is unique in each case. However, regardless of the scale of your MVP, it should be sufficient to go through all the MVP stages, bring benefits to users, and draw the necessary conclusions.
- Consider manual solutions.
Any work must be paid. Completing any task takes time. Think well, maybe you do not need to develop anything in order to test your hypothesis. Maybe you need a short presentation or a Google form for user feedback or orders. Such a form is enough for any kind of delivery service, for example. It will help you check your idea and whether it will be popular.
- Try to use existing platforms.Another good idea is to use ready-made solutions. These options will help you achieve maximum cost savings and launch your MVP without writing a single line of code. Of course, these solutions are not suitable for every case, but you should definitely consider them.These can be website builders, like Weebly, Wix or Jimbo, which allow you to build a site without actually developing and code writing.Let’s say you don’t need development at all. Turn to large online communities like Facebook, LinkedIn, and Instagram, or extremely popular messengers like WhatsApp, Viber, and Telegram. Perhaps one promo post aimed at the right target audience will be enough for you to test your hypothesis.Online platforms like Zapier allow you to integrate a large number of web applications into a single chain. For example, you can configure your Google docs, Mailchimp and Instagram ads to get handy data directly to the tables. Platforms like Shopify provide a full range of services to the e-commerce segment. Regardless of what stage your business is at, you will be provided with support.AirTable is one of the best services for creating flexible databases in the form of tables, and more. Real-time contact and customer management, flexible checklists for your colleagues to timely track changes are also available.Sharetribe offers its users an easy way to launch and configure their own online marketplaces. Fill out the form, submit the payment, and let the service do the rest for you.What I’m trying to say is that there’s a huge number of solutions created to facilitate your work. Of course, many of them take money for this. However, working with such platforms will significantly reduce your development expenses. Thus, you will quickly confirm your hypothesis. And that is exactly what our goal is.
- Other options to cut development costs. In addition to all of the above, I want to list a few more options to reduce development costs.
If you aren’t a developer, you can use no-coding platforms such as Bubble.io, Dropsource (only mobile), AppSheet, KissFlow, and so on. All of these workplaces are designed to help people find new solutions to cut costs. This is good for simple web or mobile applications, you may say. And what should I do if I still need some development to be done? I would say that most likely, WordPress is enough for you to start. This is an absolutely unique CMS that anyone can master. The scope of application varies from blogs to full-fledged information resources to online stores to learning management systems. Also, check UI libraries like Material Design or Bootstrap. Whether you’re a skilled developer yourself or you are about to hire one, these libraries will be a great support. Skilled developers can appreciate full back-end services like Firebase. Such services are used by a huge number of people to create a Google-trusted back-end infrastructure. Add Parse, Auth0, Wix, and Weebly here. All these services will help developers to significantly reduce their time costs.
My point is: you don’t have to deal with complex and expensive development tasks if you don’t want to. First of all, you must figure out what exactly you need. Use Google, look for solutions. This will help you decide which features you need to create and which features are already made.
Platforms to analyze metrics and get feedback
Since one of the most important stages in launching any MVP is gathering customer feedback, you need to use platforms for analytics and user behavior tracking.
You should collect and evaluate all incoming information, but don’t rely on it too much. Yes, you will receive data at the MVP stage, however, most likely, it will be not enough to draw any serious conclusions.
Using screen recording applications like Hotjar or Logrocket is also a good idea at the MVP stage. But here’s a catch, screen-recording makes sense when your site really has some functionality and users know why they get there. Otherwise, it makes no sense for you to look at how the user pokes in various sections of your site and doesn’t understand what is happening.
NPS services like SatisMeter allow you to create simple surveys for clients and get clear answers as to whether you are moving in the right direction or not.
Building an MVP
So, where are we now? We have discussed all the key elements of creating an MVP, from stating and validating a problem to measuring user feedback. This manual should be your guide.
Finally, I would like to give you some tips regarding the development process itself. The MVP design issue causes wide controversy. It is important to remember that the design isn’t needed in 90% of cases because it isn’t an integral part of the MVP. Instead, it’s better to focus on testing your hypothesis.
Also, I advise you to involve a full-stack developer who can do coding for both the front-end and back-end parts (if necessary). It will be simpler and cheaper than turning to several devs. Besides, you will eliminate the communication problem between them.
To understand how fast you need to work, try the following schedule:
- In a week, there should be something released for the prod. Of course, it won’t be a ready-made working solution (MVP), but you must show the first results, at least purely visual.
- Within a month, you should have something that the client can use, something that brings value. This will allow you to start receiving early feedback about what is missing and what needs to be improved.
The MVP development is fundamentally different from the standard product development. In the latter case, several obvious and consecutive phases can be distinguished, for example:
- A sort of discovery phase: you are determined with the market, audience and so on.
- UX-phase where the designer creates the first mock-ups of the future product.
- The development phase, where all the main work on creating the product is done.
- The testing phase, where QA-specialists test the developed product, report bugs and send them for a fix.
During the MVP development process, these are all unnecessary steps that should be abandoned. It isn’t your mission to release a quality feature-rich product. Your task is to check the hypothesis and do it fast. Therefore, you get rid of QA, a well-thought-out UX design, as well as cut the development costs.
The MVP success: how to measure?
I’ve mentioned that the key task in developing an MVP is to build a hypothesis that you can eventually confirm or deny. For simplicity, let’s use a simple HADI formula, where H is for Hypothesis, A — Action, D — Data, I — Insight. At the first stage, you trot a hypothesis. Then, you take measures to check it (by building an MVP). The Data stage implies collecting and analyzing the information that you’ve received (i.e. gathering user feedback). Insight requires you to make a decision regarding your hypothesis.
So, a successful MVP should either confirm or refute your hypothesis. This is the key point. What you may think is whether a failed MVP is actually a success. If the result of your efforts shows that your product turned out to be useless, this is also a successful MVP. You saved yourself from large expenses for developing a full-fledged product. You gained this knowledge by investing $10,000, and not $100,000.
The MVP’s success is about acquiring knowledge, new information. It can be the knowledge that your product is needed and will be used. Or, the knowledge that the problem really exists, but it cannot be solved with the help of your or anyone else’s MVP.
Based on this, the MVP failure is the lack of any knowledge after the development. If you’ve launched your MVP and haven’t learned anything, then it is a complete failure.
Confirming or refuting your hypothesis is a separate issue that doesn’t affect the overall success of your MVP. Your hypothesis may fail, but the MVP may be quite successful. More on this below.
Having decided on whether your MVP is successful or not, you will come to the obvious question — what to do next?
Next steps after developing an MVP
This issue should be approached from two perspectives: either your MVP is a success or not. Let’s start with the worst-case scenario.
The hypothesis was not confirmed
First of all, don’t despair, it is already a positive experience. Remember that you have saved yourself from spending huge amounts of money in vain. Therefore, you have saved some resources and can invest them to explore another direction.
To begin with, decide what exactly wasn’t confirmed — the hypothesis of the problem (you initially identified the problem incorrectly) or the hypothesis of the solution (there was a problem, but your method didn’t work). This is very important because your further actions depend on it.
If you were unable to confirm the hypothesis of the problem, then go and find a new one.
If you couldn’t confirm the hypothesis of the solution, then don’t despair. You found the right direction and the real problem. You only need to come up with the right solution. Take a step back and come up with a new method.
The hypothesis was confirmed
- Continue working on your MVP taking into account user feedback. This is your way if you don’t have a clear answer to the question of whether the hypothesis of your solution has been confirmed. Continue working with your MVP if you feel that you’ve found the right path and there is potential. User feedback should be your guide in this matter. Take it into account and try to change something in your MVP, while not taking up the development of a full-fledged product and not quitting on the already created MVP.
- Transforming your MVP into a product. The transformation of your MVP into a product implies the development of an existing project or platform into a full-fledged system. That is, you don’t change the platform, you don’t create a completely new structure, interface or approach. All you need to do is take the already created MVP, supplement it with content and all the necessary features, and turn it into a full-fledged product. In my opinion, this is the ideal scenario. You not only confirmed your hypothesis and gathered the necessary data but also made sure that the already created structure was enough for a full-fledged product. Often, this is a more cost-efficient and positive option than the next one.
- Quit on your MVP and start building a product. Your MVP is successful, you are confident in the future of your project, and you may have even received outside investment. However, you understand that you need a different and more complex technology to develop a full-fledged product. Moreover, you need to abandon everything that has already been done. What you need to do is take all the available data, early adopters and investments and develop a completely new system or product, but the essence will be the same. This option is well suited if you’ve received outside investment, or if your initial MVP was a kind of Facebook community or a simple landing page. This was enough for you to validate the hypothesis, but, of course, this wasn’t enough to provide users with value and solve their problem.
Wow, it looks more like a novel than an essay now. Let’s sum things up.
I hope that the work I have done writing this article will really help you benefit from the Lean Startup concept. Of course, this isn’t a panacea and any business is always at great risk. Yet, I’m sure, after reading this article, you have become aware of the advantages that the MVP brings. And it isn’t only about minimizing risks or resources. If you think about it, the rules of Lean Startup, MVP or HADI can be transferred to any life situation. This method helps to approach the solution of any problem correctly.
I expect this article to become your guideline at the initial stages of your journey as an entrepreneur. I am waiting for your comments, questions, and suggestions because I’m sure that each individual experience is unique.