![thumbnail](https://ipfs.pics/ipfs/QmYq5xu4N98WUJMjwjaGwaCZpgPWzNyhsrAkLaGvLS3uC1)

3 years ago, I realized that I had a dream - I wanted to build something important and significant on my own. I wasn't sure whether I was ready, but I decided to quit my dream job at [Opera Software](http://www.opera.com/) and create [my own startup](http://spistresci.pl/) - a search engine and price comparison website for books and ebooks. I found people who decided to help me.

With the limited resources that we had, I was sure that the effectiveness of our work would be crucial for whole project. I wanted to build something, what at the same time could:
- prove that my product is better than existing solutions
- persuade a lot of users that this project is cool and useful
- help me find investors for faster growth

**I was sure** that I understood what _Minimum Viable Product_ is - **I was wrong!**

# This seems to be straightforward, right?

Let's start with a definition. The first one is very simple:

> A Minimum Viable Product is the smallest thing you can build that delivers customer value 

The second definition is from Eric Ries, an entrepreneur and author of The Lean Startup, which [explains](http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html):

> The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Those two definitions suggest that your first version of a product - which will help you test your idea - should be as simple as possible and at the same time should provide users maximum customer value. There is some problem with those definitions -  **they suggest, that you have to build something**, but the truth is that at the beginning **you should avoid building a product at all**, because you can and you should test your idea without that.

# Validation of your idea without building anything

![](https://ipfs.pics/ipfs/QmdcvYnisfSCfhf8B17Ttj8eGjoyStpLG3zoyQLkJQQ8aZ)

[image credit](https://www.productplan.com/product-managers-12-great-customer-interview-questions/)

If you want to be a business owner, then you should be at the same time very skeptical and very optimistic. You should be prepared for the worse, but you should hope for the best. Skepticism is important because you should test your every assumption that you can make money on something, but optimism is needed to find a way to prove that your skepticism was **in this particular case** unnecessary.

I can recommend you an article _"[15 ways to test your minimum viable product](http://thenextweb.com/dd/2014/11/12/15-ways-test-minimum-viable-product/#gref)"_. There are 8 items from article which could be used in an MVB instead of MVP:

* Customer interviews
* Landing Pages
* Ad Campaigns
* Fundraising
* Explainer videos
* Manual-first (aka “Wizard of Oz”) MVP
* Digital & Paper prototypes
* Pre-order pages

Those techniques can save you months of unnecessary work and tons of money. If you want to build a business, you should first validate your idea with at least one technique described there.

### Minimum Viable **Business** - first, MVP - later

MVB is a new term. For me it is helpful because it helps me split the idea of building a company into: "research & planning" - MVB and "actual implementation" - MVP. I am a software developer, and most of the projects I've started because I wanted to learn something about programming in the process of doing that - how to implement this functionality, how to use that library, etc.

It would be a great outcome, if one of my projects just took off, and became very successful. But this would assume, that I had really great idea in first place, and that I had implemented this flawlessly - sadly this scenario is very unlikely to happen. You don't know what the market wants.

**Businesses are not born _automagically_.** If you focus on building a product, you can build one, even a great one... but this does not necessarily mean that you will be able to earn anything from that. If at some point you will decide to create a business, then you have to start thinking as a business owner, not like a developer, who loves to learn new things. 

If you know the product which you want to build, you will need funding or a business to be able to exist and grow. Then before building a product you should focus on building a business. Don't get me wrong - this doesn't mean that you have to create a company. You should focus on validation, whether your business actually has a chance to be a successful business or at least will be able to support the development of a solution which your product is supposed to solve.

# Being sure that there is demand for a product like yours

![](https://ipfs.pics/ipfs/QmYFS77UHgh1i3MX3LZigt3YK9RhNs6v9BoKNMhS8za8P1)

In the case of our startup I was sure that there is demand a for a price comparison website like ours. Why did I think so? Because just in Poland I already have 4 competitors, which like me, focused on a niche - books and ebooks. According to me, each of them were doing great, but I was sure that I could do something better.

I have to admit, I didn't conduct proper research. I didn't check exactly how many customers they have, and I didn't even try to ask them about their profits. I was sure that if someone else is doing this, they have to be earning some money from that. That wouldn't make much sense if that not were true, right?

In the 90's a lot of companies were sure that Virtual Reality (VR) is the future. The giants like Nintendo, Atari, Sega invested tons of money in VR because their competitors were doing the same. No one wanted to be left behind. Even right now, we are not 100% sure that there is demand for VR, which companies can offer to customers.

So, before you invest most of your assets in the development of your product, check one more time whether there is demand for that, and whether your product will be able to make money for own development.

Then and only then, you can start thinking about how to build the first minimal version of your product - which one more time, will confirm that your assumptions wereactually correct. Do you see the pattern?

# What MVP is not

![what MVP is not](https://cloud.githubusercontent.com/assets/201263/17837782/e5b66880-67bc-11e6-91b9-98528f299eff.gif)

I can agree that it is necessary in the process of creating an MVP to discuss the importance of particular features. Some teams that try to prepare an MVP, after a lot of time spent on arguing about which features are worth to include or exclude from their _minimum viable product_, having such list defined, finally decide to start building a product.

There are a few problems with this approach. First of all, MVP is not a strict plan for the first few months of development. It is also not a list of chopped out features, and for sure it's not a demo with a bunch of cool features which would present how awesome your project is.


## MVP is more like a process, which can save your business

With a list of [top reasons why startups fail](https://www.cbinsights.com/blog/startup-failure-reasons-top/) I will try explain how MVP could save your project from failing.

![](https://ipfs.pics/ipfs/QmZJujupvcbNUXDY2BSkw6TjM4mXW6CpELbcwubbbojX5i)

But how can one single MVB or MVP do so much? The truth is, it can't!

#### No Market Need

It is extraordinary that as many as 42% of startups fail because of a wrong assumption at the beginning. Inexperienced founders have a tendency toward wishful thinking. They are so sure that their idea is good that they tend to ignore a need to do a proper research.

> MVB/MVP tests are designed not just to answer technical questions about the product, but also to test fundamental business hypotheses about the viability of the market it exists in.

MVB as a cure for the "no market need" problem should be like a bait - it should check how many users your product will be able to attract. Not only that, you also have to be sure that those users are your target (with specific needs and funds that they are willing to spent on things that your product can provide).

#### Ran Out of Cash

This also happened to us. Right now I think that *running out of cash* is always an *outcome, not a reason* itself.

*I wanted to build a product for myself, so I started only with my own savings and my own time.* I didn't validate whether anyone would be interested in funding my work in advance (investors, crowdfunding, [FFF](http://lexicon.ft.com/Term?term=3-Fs))

*I consider myself as a customer, so I decided to build a few features, because I thought that they were cool.* I wasted too much time on the development of things that were not crucial, and spent too little time on features that could help us monetize a service.

*I spent too much time and money which was required to implement some features that should not have even existed in the first version of our product.* I decided that to outperform our competitors we were going to integrate more bookstores than others. Because of that we needed to spend:
* much more time on integration of those bookstores
* much more time on performance optimization
* much more money on servers that were needed to handle updates from those bookstores

#### Get Outcompeted, Poor product, Ignore Customers

If your startup was outcompeted, probably you did something wrong. Of course, you can always say that your opponent had the "first move advantage", but that would be an excuse only in case that either of you did not make any mistakes.

You should not try to build a perfect product just at the beginning. If this is even possible, for sure it is too expensive. Most mistakes can be corrected, so success at the end depends on speed, performance, and good research about things which are not perfect. In all this cases to make progress you need to work closely with your customer. You should make your product iterations as short as possible, and after each iteration, you should check feedback from your users.

This means, that you should have a separate MVP of each feature! Even if you think that you already know, that specific feature is needed and desired by customers, you should first implement a small part of it - 20%, and at the same time try to bring 80% of feature value to the table.


## MVP is different for each industry

I think one explanation for why there is so much confusion with MVP is that it looks quite different for different companies.

![](https://ipfs.pics/ipfs/QmXzRpm68e3Y8fCtmi1haYp1TCMn2vXtBJnQcDDoe6nJyG)

If you want to build a great restaurant, it is obvious that a location in the city center can be too expensive at the beginning. Antique furniture probably will also be out of your reach. It is a better idea, to start with something smaller. In theory, a food truck could be ideal, but I would recommend something smaller, like inviting your friends for a dinner.

But if you are a software developer, you don't want to rebuild your product over and over again from scratch. You want to start with a foundation...

### MVP for software developers

First of all, if you are a programmer, that means that you are probably a very technical person. Even if your target market is other programmers, who can understand the meaning of returned errors, you should make your MVP reliable and usable.

![](http://panthersoftware.com/2014/11/20/mvp-for-stakeholders-project-managers-and-architects/images/mvp-pyramid.png)

You have to remember that there is still a very high probability that your users actually need something slightly different than you initially had in mind. This means that you have to be flexible, and, more importantly, your **code also has to be flexible**!

I will not argue that each project should be covered by unittest with a 100% rate, but if you are wondering **how to build a flexible code**, unittests are the answer.

Each software has some kind of core. In most cases this is the most complicated part of the system, where a lot of optimization and tweaks will be added later. Your core does not have to and in fact should not be perfect, but you should cover all cases handled by your code with unittests. Only with a bunch of well-written unittests you will be able to completely rewrite you code to meet new business criteria... without destroying everything in the process.

# Don't be afraid to find the right wall

![](https://ipfs.pics/ipfs/QmZS2gkLqMtMVV3FbjVW98jLmxvZriQbH5JG2KzSr5QAS1)

MVP in theory is an easy concept, but in practice it is extremely difficult to master. We want to take action and build great products! It is very difficult to convince ourselves that we all should inititially research more because we are afraid of giving up on our initial idea...just like all those naysayers saidthat we may end up like all those naysayers said - by giving up an initial idea.


But the truth is, your idea didn't came from nothing. You are a deep well of experience and unique knowledge. Even if, by your research, you realize that your idea business is not possible, you gain ever more unique knowledge that your competitors will not have. But if you are able to listen to what smart people say about your product, even if your initial idea was terrible, you will find out what you will have to do to make their life better. Don't be afraid to find the right wall, especially after learning about tool which will help you find it.


------------

During the creation of this article I realized how many things about MVP I want to describe. I decided to split everything into parts. In the next part I will describe a few ways of how you actually can plan and design your own MVP.

If you want to learn how to build your own MVP or if you are interested in one of #programming #startup #entrepreneur, you might want to follow [my account](https://steemit.com/@noisy). I post one article on every Monday :)

Note: Article was [liveblogged](https://www.livecoding.tv/noisy/videos/) and after that was corrected by profesional English teacher hired on italki - [Nikki](https://www.italki.com/teacher/1359638) and [James](https://www.italki.com/teacher/2830764).