MVP czyli Minimum Viable Product

Patrząc na rynek można powiedzieć, że wiele startupów ignoruje rzeczywistość. Próbuje odwlec to, co nieuchronne — moment, w którym ich biznes musi dojrzeć, osiągnąć zysk i stać się prawdziwą, zrównoważoną firmą. Ale jak nie popełnić tego samego błędu? Przede wszystkim nie możesz patrzeć na swój pomysł jak na coś lepszego. Startup nie jest niczym magicznym, to prosty biznes, który sprzedaje „coś”, co rozwiązuje problem innych ludzi.

Załóżmy, że interesuje Cię edukacja. Co jest złego w systemie edukacji i jak można to poprawić? Jak dobrze wiesz, znalazłaby się tego cała masa i nie ma najmniejszych szans, by opisać to w kilku zdaniach. Wszystkie odpowiedzi będą wysokopoziomowe, dlatego trzeba podzielić te pojęcia na mniejsze kategorie. Jak? Np. „Co złego jest w przedszkolach?”, albo „Co złego jest w matematyce?”. Takie podejście daje większą jasność rozwiązywanego problemu, a jak wiesz im problem jest trudniejszy, tym bardziej potrzebne jest dla niego rozwiązanie . Im bardziej potrzebne jest rozwiązanie, tym bardziej prawdopodobne, że ludzie czy przedsiębiorstwa będą gotowe za nie zapłacić.

Jeżeli już wiesz, jaki dokładnie problem chcesz rozwiązywać, to najwyższy czas przełożyć go na kod i umieścić w Internecie. Pamiętaj, że aby przetestować swój pomysł nie potrzebujesz w pełni dopracowanego serwisu i aplikacji. Na tym etapie możesz cieszyć się anonimowością, dzięki której sprawdzisz swoje przypuszczenia w warunkach bojowych. Po to właśnie buduje się MVP — by uniknąć sytuacji, gdy po pierwszych testach okazuje się, że Twoje założenie są w pełni błędne i przebudowanie całego projektu na tym etapie jest bardzo czasochłonne.

Prototypowanie

via Giphy

Czym jest MVP? MVP, w rozwinięciu Minimum Viable Product , to nic innego jak prototyp,który spełnia podstawowe, ale główne założenia funkcjonalne aplikacji/serwisu.

Ciężko już zadawać pytanie, po co komu niepełny produkt w czasach, gdy świadomość metodyk Lean Startup i Customer Development jest na porządku dziennym. Zastanów się, jak ważne jest szybkie przetestowanie produktu na małej ilości użytkowników, zebranie informacji, wniosków, szybkie wprowadzenie zmian, ponowne testy, a potem dopracowanie produktu i jego skalowanie.

Twoje hipotezy składające się na model biznesowy w tym momencie nadal pozostają zagadką. Dopiero na etapie prototypowania zaczynasz zmieniać je na dane i fakty, które testujesz wraz z klientami.

Poznajesz, czy dobrze zrozumiałeś problemy klienta, czy wystarczająco dużo osób zmaga się z takim problemem i czy ten problem jest tak interesujący, że rozmawiają oni o nim ze swoimi znajomymi.

Jeżeli posiadasz niezbędną wiedzę odnośnie budowania aplikacji i infrastruktury lub posiadasz zespół, który będzie w stanie pociągnąć taki projekt, to możesz go realizować we własnym zakresie. Jeżeli jednak nie posiadasz ani wiedzy, ani zasobów, nie próbuj szukać ludzi do zespołu udzielając im procent udziałów w swoim przedsięwzięciu. Dobra wiedza każdego eksperta jest cenna.

Każdego dnia w Internecie pojawiają się setki, jak nie tysiące ofert pracy w startupie za udziały. Odsetek przedsięwzięć, które idąc tym torem osiągnęło planowany efekt można policzyć na palcach. Przy takim podejściu łatwo możesz ciągnąc projekt w nieskończoność, lub szukać kolejnych osób do realizacji, gdy wydaje Ci się, że już jesteś na półmetku.

Pamiętaj też, że jeżeli masz ciekawy, godny zainteresowania innych produkt i szukasz funduszu, który chciałby w Ciebie zainwestować, trudno będzie go znaleźć dając udziały za pomysł, bez posiadania prototypu.

Co dalej?

Usiądź i zacznij spisywać w prosty sposób działanie Twojej aplikacji lub serwisu. Następnie zastanów się nad wszystkimi jego opcjami. Ale nie rób tego po łebkach, tylko przemyśl dokładnie, jakie funkcje ma posiadać i jak ma wyglądać przepływ informacji. Nie powinieneś dawać przykładów w stylu: „taki, jak serwis X”, tylko opisać dokładnie potrzebne według Ciebie widoki, dane, zachowania. Nie musisz się na tym znać, ale skoro podejmujesz się działań w Internecie to znaczy, że posiadasz już jakieś doświadczenie i nie jesteś zupełnie zielony w tej kwestii. Dla firm zajmujących się tworzeniem oprogramowania, im więcej informacji, nawet niepełnych, przyniesiesz ze sobą na spotkanie, tym dokładniejszą dostaniesz wycenę i tym większą masz pewność, że efektem końcowym będzie to, czego oczekujesz. W Czarnym Kodzie prowadzimy mentoring i doradzamy naszym klientom odnośnie funkcjonalności. Warto rozważyć to jako opcję, gdy poszukujesz firmy, z którą masz zamiar współpracować

Technologia

Podczas budowania aplikacji jednym z ważniejszych aspektów jest technologia. To całe serce Twojego startupu (o ile mówimy o Internecie) i jej wybór jest jednym z czynników przyczyniających się do odniesienia sukcesu. Najczęstszą opcją jaką uda Ci się usłyszeć będzie — „Coś Ty! Zrób to na WordPressie”. Może to niegłupie podejście, ale sam WordPress został zbudowany do innych celów. Jak wiesz, pierwotnie była to platforma do prowadzenia blogów. Obecnie zaś jest to CMS, na którym stoi pewnie co druga firmowa strona w Internecie. Nie mamy nic do WP, bo sami z niego korzystamy, w pracy dla naszych klientów, ale z doświadczenia możemy powiedzieć, że do budowania MVP on się nie nadaje.

Jaki więc wybrać język programowania? Powinieneś patrzeć nie tylko na aspekty technologiczne, ale także na społeczność, bezpieczeństwo, skalowalność i szybkość wdrażania. Najbardziej popularnym językiem, który wybierają początkujące firmy jest PHP. Swoich zwolenników znajdziesz także w Ruby on Rails, Javie, .Net, Python i NodeJS.

Przez wiele lat w Czarny Kod wykonaliśmy setki projektów. Tworzyliśmy w PHPie, przez ostatnie lata w Raisach, ale ostatnimi czasy lubujemy się w NodeJS i opartym na nim MeteorJS. Jeżeli mielibyśmy doradzać wybór technologii to zdecydowanie pójście w tym kierunku da Ci najbardziej wymierne korzyści. Na drugim miejscu stawiamy Railsy, na trzecim PHPa (o ile skorzystasz z frameworka Laravel).

Jak bardzo rozbudowane powinno być MVP

Tak naprawdę nie ma jednej dobrej odpowiedzi. Niekiedy może wystarczyć nawet prosta, pojedyncza strona zawierająca propozycję, oraz informację o korzyściach, a także formularz zapisu na newsletter lub złożenie wstępnego założenia. Innym razem potrzebne będą zbudowanie serwisu lub rozbudowanej strony, a nawet testy A/B. Warto użyć materiałów wideo pokazujących istotę problemu i jego rozwiązanie, lub przeprowadzić ankietę na stronie (wraz z rejestracją), dzięki którym otrzymasz informację zwrotną.
Gdy sami tworzymy MVP staramy się zaoferować użytkownikom główne funkcje serwisu, chociaż w podstawowy sposób.

Gdy budowaliśmy Tap To Speak naszym założeniem był szybki transfer dźwięku pomiędzy urządzeniami oraz dużo rozbudowanych funkcji, które mają pomóc w prowadzeniu prezentacji. MVP ograniczyliśmy do przesyłania danych, bez których dalsza praca nad projektem nie miałaby większego sensu.

Konkluzja

  • Dowiedz się, czym jest Customer Development, Lean Startup, Lean Analytics,
  • ciesz się anonimowością,
  • nieprzerwanie testuj swoje założenia,
  • nie wierz w to, że wiesz czego chce klient,
  • ale stwórz taki produkt, z którego sam chciałbyś korzystać,
  • nie naśladuj,
  • kładź nacisk na wyciąganie wniosków i iteracje, a nie na wykonywanie planów,
  • pamiętaj, że strategie typu „gotów, cel, pal”, czyli nastawienie na termin premiery rynkowej, zupełnie ignorują proces budowania produktu z udziałem klienta,
  • nie zapominaj, że idee (nawet te świetne) nie dają się łatwo przetłumaczyć na rozwijające się startupy,
  • idee są kruche, ale to co się z nich wywodzi, z drugiej strony, może zmienić świat.

Powodzenia!

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?