MVP – Minimum Viable Product

Looking at the market it can be said that many startups ignores reality. They are trying to postpone the inevitable — the moment when their business has to mature, make a profit and become a real, sustainable company. But how not to make the same mistake? First of all, you can not look at your idea as something better. Startup is nothing magical, it’s a simple business that sells “something” that solves the problems of other people.

Let’s assume that you are interested in education. What is wrong with the educational system and how it can be improved? As you know, is a whole bunch of such problems, and there is no chance to describe in a few sentences. All answers will be high-level, so you have to divide these concepts into smaller categories. How? Eg. “What’s wrong with kindergartens?” Or “What’s wrong with mathematics?”. This approach gives better clarity of solving problem and as you know the more problem is difficult, the more solution for it is needed. The more solution needed, it is more likely that people and businesses will be willing to pay for it.

If you already know what exact problem you want to solve, it is high time to translate it into code and put it online. Remember that to test your idea, you do not need a fully fledged service and applications. At this stage, you can enjoy the anonymity, which allows you to test your assumptions in combat conditions. This is why MVP is built — to avoid a situation where after the first tests it proves that your assumption is completely wrong and rebuild of the entire project at this stage it is very time consuming.

Prototyping

via Giphy

What is an MVP? MVP or Minimum Viable Product, is nothing but a prototype that meets the basic, but the main functional assumptions of the application / service. It’s hard to ask the question, who needs an incomplete product now, when awareness of Lean Startup and Customer Development methodologies are so common.

Consider how important is fast product testing on a small number of users, gathering information, applications, giving rapid changes, re-testing, and then refine the product and its scaling. Your hypothesis that make up the business model at this point still remains a mystery. Only at the stage of prototyping you begin to change them on the data and facts that are testing with customers.

You recognize how well you understand the client’s problems, if enough people are struggling with this problem and that this problem is so interesting that they talk about it with their friends.

If you have the necessary knowledge about application building and infrastructure or have a team that will be able to create such a project, you can do it yourself. However, if you do not have neither the knowledge nor the resources, do not try to look for people to the team by giving them a percentage of the shares in your venture. The knowledge of each expert is valuable.

Every day on the Internet there are hundreds, if not thousands of jobs in startup for shares. The percentage of enterprises that are following this path and has reached the planned effect are few and far between.

With this approach, the project can take forever to complete, or to find people to realize it, when you think that you are already half way through. Also, remember that if you have an interesting product and you are looking for a fund that would invest in you, it will be difficult to find one when giving shares for the idea, without having a prototype.

What’s next?

Sit down and start writing down in a simple words how your application or service should work.Then, think about all the options. But do not ‘scratch the surface’, just think exactly what features it has to have and how information flow should look. You should not give examples like: “such as service X,” but describe exactly designs, data, behavior needed by you. You do not need to know this, but if you take the action online it means that you already have some experience and you are not completely just off the boat at this issue.

For companies engaged in software development, the more, even incomplete, information you will bring with you to the meeting, the more accurate valuation will get and you can be more sure that the end result will be what you expect.The Cat in black is conducting mentoring and advising our customers about functionalities. It is good idea to consider this as an option when you are looking for a company you want to choose to cooperate.

Technology

When building an application one of the most important aspects is technology. This is a “heart” of your startup (if we are talking about the Internet), and its choice is one of the factors contributing to success. The most common option that you will hear of will be — “Just do it on WordPress!”. Maybe it sounds smart, but the WordPress was created for other purposes.

As you know, initially it was a platform for blogging. Now it is a CMS, which is probably base for the half of all companies websites on the Internet. We are not the enemies of WP, because we use it at work for our customers, but from our experience we can say that this is not a suitable way to build the MVP. So how to choose a programming language? You should look not only at the technological aspects, but also on the community, security, scalability and speed of deployment.

The most popular language that is choosed by young companies is PHP. Also Ruby on Rails, Java, .Net, Python and NodeJS will find their supporters. For many years, Cat in Black have done hundreds of projects. We’ve created in a PHP, for the last few years is Rais, but recently we’re delight in NodeJS and MeteorJS based on it. If someone would ask us for advise in technology choice, we would definitely advise you going in direction that will give you the most tangible benefits. In second place we put Rails and on the third place PHP (if you use the Laravel framework

How extensive MVP should be

To be honest, there is no one right answer. Sometimes even a simple, single page containing a proposal and information about the benefits may be sufficient, as well as the application form for the newsletter or submission of the initial assumptions. Another time you will need to build a service or expanded website and even A / B testing.
It is a good idea to use the video showing the essence of the problem and its solution, or to carry out a survey on the site (with registration), so that you get feedback. When creating MVP ourselves we try to offer users the main features of the service, at least the basic way.
When we were building Tap To Speak, our main objective was to quickly transfer audio between devices and a lot of powerful features to help in conducting a presentations / conferences. MVP was restricted to data sending, without which further work on the project would not make much sense.

Conclusion

  • Learn what: Customer Development, Lean Startup, Lean Analytics are,
  • enjoy anonymity,
  • continuously test your assumptions,
  • do not believe in that you know what the customer wants,
  • create a product which you would like to use,
  • do not imitate,
  • put emphasis on drawing conclusions and iterations, not on the implementation of the plans,
  • remember that the strategy of “ready, aim, fire,” or focusing on the market release date completely ignores the process of building the product with participation of the client,
  • do not forget that ideas (even the great ones) are not easily translated into growing startups,
  • ideas are fragile, but on the other hand, what comes out of them can change the world.

Good luck!

Subscribe
Powiadom o
guest

0 komentarzy
Inline Feedbacks
View all comments

Stay up to date

Subscribe to the newsletter and receive a e-book as a gift

Zero unwanted content. Only good materials in your inbox.

Leave this field blank

The administrator of your personal data is Adam Trojańczyk 
Click here to find out more about the processing of your personal data.


You May Also Like
Kiedy to oprogramowanie decyduje, czy przeżyjesz
Read more

When the software decides if you will survive

They say that two heads are better than one. So it's no wonder that many software companies are starting to take a friendlier look at software development techniques in pairs. Two people work together on a single block of code - one is the driver, the other the navigator. The driver in this process is responsible for carefully developing the code, and the navigator's job is to review and focus on the roadmap. Much research outlines the very big advantages that affect the increased productivity and the security and robustness of the software produced. But is it true for every issue?