Reid Hoffman, założyciel LinkedIna, powiedział kiedyś: „jeśli nie jesteś zawstydzony pierwszą wersją swojego produktu, to oznacza, że wypuściłeś go za późno”. Dlaczego to stwierdzenie ma sens? Po co wypuszczać na rynek niedoskonały produkt? A także czym jest MVP i jak je zbudować.
Między innymi na te pytania odpowiedział Adam Trojańczyk, CEO Inwedo. Adam związany jest z branżą IT od 2004 roku. Pracował z dziesiątkami firm z USA, Europy, Japonii, Australii i Meksyku. Współtworzył wiele startupów. Jest inżynierem i humanistą. Był mentorem i ekspertem w programach akceleracyjnych Startup Spark i S5. A także działa społecznie.
W rozmowie ze mną Adam opowiada o MVP. Jeśli jesteś związany ze środowiskiem startupowym, to wiesz, czym jest MVP. Jeśli jednak jest to dla Ciebie nowe pojęcie, cierpliwości – za chwilę się dowiesz.
Zgadzasz się z tym, co Reid Hoffman powiedział o pierwszej wersji produktu?
Wypuszczenie produktu na bardzo wczesnym etapie pozwala szybko uzyskać informacje zwrotne od użytkowników i ewentualnie dokonać iteracji. Czekanie aż osiągnie on „doskonałość” może spowodować nie tylko opóźnienie wejścia na rynek, ale także może oznaczać, że miesiącami produkowaliśmy coś, z czego nikt nie będzie chciał korzystać.
Dzięki informacjom pozyskanym od realnych użytkowników produktu, możemy na bieżąco wprowadzać modyfikacje, weryfikować nasze założenia, dodawać nowe rozwiązania, o których wcześniej nawet nie byliśmy w stanie pomyśleć. Możemy też wykonać zwrot i zacząć pracować nad innym rozwiązaniem.
Dlaczego nie warto wchodzić na rynek z gotowym cyfrowym produktem?
Myślę, że najlepszą odpowiedzią będzie przykład z życia wzięty.
Jakiś czas temu pracowałem z jednym ze startupów nad zbudowaniem bardzo zaawansowanego urządzenia do detekcji anomalii. Miało ono w sobie zawierać szereg czujników, których zadaniem była analiza otaczającego ich środowiska na hali produkcyjnej i wykrywanie możliwych defektów w wyprodukowanych towarach.
Ilość parametrów do opomiarowania była tak duża, że w już na etapie założeń czujnik puchł w nieskończoność. Widząc to, zdecydowaliśmy wspólnie, że wypuścimy produkt na bardzo wczesnym etapie, żeby sprawdzić, czy nasze koncepcje są słuszne.
Urządzenie było niesamowicie brzydkie i zapakowane w mały, przezroczysty plastikowy pojemnik ze sklepu z narzędziami. Ostatecznie jednak sprawdzenie go w warunkach niesymulowanych pozwoliło nam zebrać ogrom informacji zarówno z hali produkcyjnej, jak i od użytkowników końcowych.
To przełożyło się na zmianę koncepcji produktu końcowego, który ostatecznie trafił tylko do jednej branży i mierzył dwie najważniejsze wartości.
Wcześniejsze wypuszczenie produktu (oczywiście również cyfrowego) na rynek ma także jeszcze jedną zaletę. Możliwość szybszej monetyzacji. Z raportu „The 20 Reasons Startups Fail” wynika, że:
- 29% startupów upada, bo kończą się im pieniądze,
- 18% startupów upada przez problemy z kosztami i złym cennikiem.
Nie ma rozsądnego powodu, aby zwlekać z momentem pozyskania pierwszych użytkowników. Im wcześniej zaczniemy to robić, tym wcześniej przyciągniemy klientów, a wraz z nimi potrzebne nam do dalszego rozwoju środki finansowe oraz dane, z których będziemy mogli wyciągnąć wnioski. Klienci upewnią nas także co do kierunku działań.
Oprócz powyższych argumentów istnieje jeszcze jeden czynnik ryzyka, który wiąże się z dążeniem do wejścia na rynek z ostatecznym, „doskonałym” produktem. Może się okazać, że nie będzie on odpowiadać rzeczywistym potrzebom użytkowników, a to jest jednoznaczne z faktem, że nasze zasoby zostaną zmarnowane.
Skoro nie potrzebujemy skończonego, gotowego produktu, aby zacząć, to potrzebujemy czegoś minimalnego, np. MVP. Jak Ty definiujesz MVP?
Definicji MVP jest wiele. Najczęściej można spotkać się z opisem, że jest to wersja produktu z zestawem podstawowych funkcji stworzona przy minimalnym nakładzie pracy, która pozwala nam na pozyskanie danych i informacji o naszych użytkownikach, a także od naszych użytkowników.
Natomiast najbliższe mojemu sercu jest stwierdzenie, że MVP jest swego rodzaju eksperymentem, nad którym pracujemy. Dzięki niemu możemy sprawdzić, czy damy radę zrealizować postawione przed nami tezy i założenia. Jeżeli nie, to albo będziemy wiedzieć, że coś jest niemożliwe do wykonania, albo że należy to robić w inny sposób.
Kiedy wiele lat temu ten model wprowadzania produktów na rynek stał się popularny, wywrócił do góry nogami tradycyjne podejście. Dzięki niemu firmy zaoszczędziły ogromne ilości pieniędzy, czasu i co ważne zminimalizowały ryzyko porażki.
Żeby czytelnicy lepiej zrozumieli tę definicję, czy możesz przytoczyć historie founderów, którzy właśnie zaczynali od MVP? Jak wyglądały ich wczesne produkty?
Z najbardziej znanych przykładów można wskazać firmy Dropbox i Airbnb.
Pierwsza zamiast tworzyć gotowy produkt, wypuściła film demonstracyjny pokazujący, jak będzie on działał. Na podstawie reakcji rynku founderzy zdecydowali się kontynuować rozwój.
Airbnb zaś było początkowo prostą stroną internetową z kilkoma zdjęciami mieszkań dostępnych na wynajem krótkoterminowy, np. dla uczestników takich wydarzeń jak konferencje czy zjazdy. Była to alternatywa dla młodych ludzi, nieskorych do wydatków na noclegi w drogich hotelach. Wkrótce ta sama grupa docelowa zaczęła szukać podobnych ofert również na wakacje i baza noclegowa zaczęła się rozrastać zarówno, jeśli chodzi o standard miejsc, jak i ich dostępność w różnych krajach.
Powyższe przykłady dotyczą znanych zachodnich firm, ale mogę podzielić się także osobistą historią sprzed wielu lat. Pracowałem w polsko-amerykańskim zespole nad naszym własnym startupem.
Stworzyliśmy aplikację dla uczestników konferencji. Nasze narzędzie zmieniało smartfon w mikrofon, co rozwiązywało logistyczny problem z jego przekazywaniem wśród osób, które chciały zadać pytanie prowadzącym prelekcję lub warsztat.
Rynek był bardzo podekscytowany rozwiązaniem, jakie zaproponowaliśmy. W przypadku naprawdę dużych imprez, takich jakie organizuje się np. w Las Vegas, gdzie na konferencji potrafi być 100 000 osób, brak konieczności biegania z mikrofonem to ogromne odciążenie.
Zrobiliśmy naprawdę minimalistyczny produkt. Nie nazwę go brzydkim, lecz właśnie po prostu minimalistycznym, bo spełniał tylko jedno założenie. Chcieliśmy jak najszybciej przetestować, czy to, co proponujemy, ma sens. I okazało się, że nie miało.
Publiczność zupełnie nie chciała korzystać z naszego rozwiązania, jednak dzięki małemu nakładowi pracy i szybkiemu uzyskaniu informacji zwrotnej, dowiedzieliśmy się, że problemy nie leżą bezpośrednio w narzędziu. Program nie stał się popularny, ponieważ większość uczestników konferencji boi się braku anonimowości i odczuwa strach przed zadawaniem pytań publicznie. Ten ostatni argument, wedle badań, był na pierwszym miejscu największych obaw wśród respondentów.
Dodatkowo okazało się, że firmy organizujące większość wydarzeń wcale nie narzekają na problemy związane z logistyką podczas przekazywania mikrofonu. Narzekają natomiast na małe zaangażowanie publiczności, które prowadzi z kolei do niskiego stopnia zadowolenia z udziału w imprezie.
Uzyskanie tych informacji pozwoliło nam całkowicie zmienić sposób, w jaki postrzegaliśmy nasz produkt i zaoferować zupełnie odmienne rozwiązanie. Z narzędzia do przesyłania dźwięku zrobiliśmy potężny instrument do zwiększania zaangażowania widowni.
Zaproponowaliśmy nie tylko komunikację dźwiękową, ale również tekstową, która pozwala uczestnikowi zadać pytanie anonimowo i nie zmusza go do udzielania wypowiedzi na forum grupy. Umożliwiliśmy przeprowadzanie ankiet i sondaży podczas wydarzeń oraz, co ważne, identyfikację uczestników na sali.
Na kolejnej konferencji, na której testowaliśmy usprawnione i dopracowane rozwiązanie, ilość pytań zadanych przez publiczność zwiększyła się z zera do dokładnie 912.
Gdybyś miał wymienić etapy, przez jakie należy przejść, aby zbudować MVP, to jakie etapy byś wskazał?
Wyróżniłbym cztery główne etapy:
1. Upewniamy się, że rozumiemy potrzeby klientów
Możemy być bardzo podekscytowani swoim pomysłem, twierdząc, że rozwiązuje on najbardziej palące problemy naszej grupy docelowej. Jednak w rzeczywistości klienci mogą nie potrzebować naszego rozwiązania lub go nie doceniać.
Wiele firm nieprawidłowo ocenia potrzeby odbiorców i rynku. Tworzy produkty i usługi, których potem nikt nie używa lub kieruje je do grupy docelowej, której zwyczajnie na nie stać.
Kiedy spojrzymy na raport „The 20 Reasons Startups Fail” możemy zauważyć, że aż 42% młodych firm upada z powodu braku zainteresowania ich produktami czy usługami. Zanim więc przejdziemy do działania, powinniśmy dokładanie zbadać rynek, potrzeby klientów i przestać opierać się na opiniach własnych czy znajomych. Zdecydowanie lepszy jest bezpośredni kontakt z potencjalnymi klientami w celu zrozumienia ich potrzeb i, co ważne, problemów.
2. Definiujemy problem
Następnie, kiedy wydaje się nam, że znamy już potrzeby naszych klientów i wyznawania, przed jakimi stoją, powinniśmy zastanowić się, które z nich są najbardziej palące. To zaprowadzi nas do pewnych hipotez, pomoże zdefiniować największe bolączki, a także wyłoni potencjalne rozwiązania.
Zanim jednak przejdziemy do realizacji planów, warto upewnić się, że odkryty problem jest wystarczająco istotny, by go rozwiązywać. Pomocne może być zadanie sobie trzech prostych pytań:
- Czy nasz pomysł może rozwiązać problem klienta lub czy zaspokoi on jego potrzebę?
- Czy wystarczająco dużo osób ma ten problem lub potrzebę? Wystarczająco dużo to tyle, by można było na naszym produkcie zarobić.
- Czy problem lub potrzeba są tak ważne, by klient po ich rozwiązaniu lub zaspokojeniu podzielił się opinią z bliskimi? A może są tak palące, że już się nimi podzielił z otoczeniem?
Jeżeli jesteśmy w stanie odpowiedzieć 3 × tak, możemy przejść do kolejnego etapu.
3. Proponowanie rozwiązań i budowa MVP
Kiedy wydaje się nam (bo przecież nie mamy pewności), że wiemy już, jaki problem chcemy rozwiązać, zaczynamy od wyboru kluczowych funkcjonalności, które go wyeliminują. Skupiamy swoją uwagę tylko na tym, co jest absolutnie niezbędne, aby zwalidować nasz pomysł. Koncentrujemy się jedynie na wartości dla użytkowników. Kiedy już je wybierzemy, możemy przejść do budowy naszego MVP.
To, jak powinno wyglądać rozwiązanie od strony graficznej, zależy zdecydowanie od naszej grupy odbiorczej. Cześć osób nie będzie w stanie docenić szorstkiego minimalizmu, część zaś uzna go za zaletę. Niezależnie od tego, którą opcję wybierzemy, pamiętajmy, że MVP nie jest tożsame z bylejakością.
4. Wdrożenie, zbieranie opinii, zwroty, iteracje i dostosowywanie
Kiedy udostępnimy MVP wybranej grupie odbiorców, zacznijmy jak najszybciej zbierać od nich informacje zwrotne. Możemy gromadzić je poprzez rozmowy, ankiety, badania czy specjalne narzędzia analizujące zachowania użytkowników. Im więcej danych zbierzemy, tym lepiej zrozumiemy, co sądzą oni o naszym produkcie.
Informacje te pomogą nam w podjęciu decyzji co do dalszego skalowania lub zmiany naszego produktu w zależności od reakcji klientów. Kiedy wprowadzamy zmiany, następnie znów je analizujemy i znów podejmujemy kolejne decyzje.
Warto dodać, że na tym etapie powinniśmy cechować się wręcz niezdrową obsesją na temat potrzeb naszych użytkowników, ponieważ niezaspokojenie ich będzie jednym z największych źródeł naszych problemów.
Jakie cele należy zdefiniować dla MVP?
Gdybym miał wymienić ich kilka, to wskazałbym:
- weryfikację hipotez – to przede wszystkim odpowiedź na pytanie, czy istnieje zapotrzebowanie na oferowane przez nas rozwiązanie oraz czy spełnia ono oczekiwania użytkowników;
- zrozumienie użytkowników – musimy wiedzieć, czy rozumiemy ich preferencje, potrzeby, zachowania oraz to, które z naszych funkcji są dla nich najważniejsze;
- politykę cenową i pozyskanie pierwszych klientów – MVP powinno przyczynić się do jak najszybszego udrożnienia kanałów sprzedażowych, wypracowania odpowiedniego modelu biznesowego i próby monetyzacji;
- określenie kierunku rozwoju – na podstawie informacji zwrotnych od użytkowników jesteśmy w stanie określić, które funkcje warto dodać w przyszłych wersjach naszego produktu, by utrzymać obecnych i ściągnąć nowych klientów.
Niezależnie od tego, jakie cele wybierzemy, powinny być one przede wszystkim mierzalne. Jeżeli takie nie będą, to nigdy nie dowiemy się, czy już ich nie osiągnęliśmy.
Jakie trzy błędy najczęściej popełniają przedsiębiorcy, tworząc MVP? Oraz jak nie dopuścić do ich popełnienia, a jeśli już się je popełniło, to jak je naprawić?
Nie mam rzetelnych danych, by móc z pełnym przekonaniem odpowiedzieć na to pytanie. Natomiast kierując się swoim doświadczeniem, wskazałbym na nadmiar funkcji, brak otwartości na informacje zwrotne lub złą ich interpretację.
Zdarza się, że przedsiębiorcy nie potrafią zrezygnować z ważnych z ich (i tylko ich) punktu widzenia funkcjonalności i próbują dostarczać produkty maksymalnie nimi przepełnione. To kompletnie zabija całą ideę MVP. Dodatkowo wydłuża proces walidacji i wejścia produktu na rynek, a także zwiększa koszty, które to przekładają się z kolei na zmniejszenie możliwości wykonania zwrotu czy iteracji.
Drugim problemem jest brak otwartości na rozmowy z użytkownikami. Najczęściej objawia się on tym, że mimo jasnej informacji zwrotnej od klientów co do danej funkcjonalności, przedsiębiorca upiera się przy swoim, twierdząc, że wie lepiej, co jest potrzebne jego użytkownikom. Tym samym wchodzi na równię pochyłą wiodącą go ku upadkowi. Wedle raportu Startup Genome taki los czeka aż 9 z 10 startupów.
Pozostaje jeszcze kwestia złej interpretacji danych. Przyczyny tego problemu mogą być różne. Często jest to brak odpowiednich narzędzi, czasem doświadczenia, a niekiedy nawet usilne próby potwierdzania własnych przekonań. To wszystko może prowadzić do nieodpowiednich decyzji biznesowych, nieosiągania założonych celów, a także do utraty zaufania klientów.
Pytałeś mnie też, jak naprawić popełnione błędy. Jeśli jesteśmy na rynku nowi i tworzymy nasze pierwsze rozwiązania, to możemy cieszyć się anonimowością w branży i tym, że ludzie jeszcze nie kojarzą naszej marki.
Daje nam to możliwość uczenia się bez ponoszenia wysokich kosztów za popełnione błędy. W przyszłości niestety nie uda się tych kosztów uniknąć. Firmy, które mają już wypracowaną pozycję na rynku, muszą być gotowe na to, że każde przedsięwzięcie, jakiego się podejmą, może przynieść im nie tylko straty finansowe, ale też wizerunkowe.
To kolejny argument za tym, by wypuszczać w świat produkty minimalnie gotowe. W tym wypadku poniesione porażki oznaczają mniej dotkliwe konsekwencje, niż gdy dotyczą ukończonych projektów, których start często poprzedza ogromna, napompowana fajerwerkami premiera.
Z drugiej strony to nie wstyd, kiedy coś nam nie wypali. To normalne, że czasem, mimo że wydawać się mogło, że wszystko zrobiliśmy poprawnie, jednak coś poszło nie tak. Grunt to umieć przyznać się do winy. Jak mawia Lech Kaniuk: „Najwyżej jak się nie uda, możesz napisać o tym książkę”. Spróbujmy jednak wyeliminować ryzyko porażki na samym początku, a potem zobaczmy, co się wydarzy.
Kiedy możemy powiedzieć, że nasze MVP spełniło swoją funkcję i teraz możemy iść o krok naprzód, np. wypuścić finalną wersję produktu (o ile w przypadku cyfrowych produktów możemy w ogóle mówić o finalnej wersji)?
MVP spełniło swoje założenia, kiedy potwierdzimy lub obalimy nasze początkowe hipotezy i zrozumiemy, które kierunki rozwoju produktu są najbardziej obiecujące. A jeżeli już ktoś nam za to zapłacił, to możemy być przekonani, że to najlepszy moment, by zrobić krok w kierunku produktu finalnego.
Na koniec chciałbym zapytać Cię o minimalizowanie zasobów. A mianowicie, jak ograniczyć zasoby ludzkie, finansowe i technologiczne, tworząc MVP?
Przede wszystkim warto skupić się na tym, o czym opowiadałem już wcześniej. Na kluczowych funkcjonalnościach naszego rozwiązania.
Warto też skorzystać z gotowych narzędzi czy rozwiązań low-code. Należy też unikać skomplikowanej infrastruktury. Jeżeli jednak nasze narzędzie jej wymaga, to możemy próbować minimalizować koszty, dołączając do specjalnych programów dla startupów oferowanych przez dostawców usług chmurowych.
Warto też pamiętać, że gdy decydujemy się nawiązać współpracę z zewnętrznym podmiotem (np. podwykonawcą), powinien to być profesjonalista w swojej dziedzinie. Zatrudnienie kogoś jedynie ze względu na cenę to zdecydowanie proszenie się o kłopoty w przyszłości.
