MVP (Minimum Viable Product) – czym jest i jak działa?

MVP (Minimum Viable Product) to najbardziej podstawowa wersja produktu, jaką można wprowadzić na rynek. Oferuje tylko niezbędne funkcje, „esencję” całego pomysłu – tak, aby był w stanie zaspokoić podstawową potrzebę użytkownika. Dlatego właśnie są to produkty minimalnie użyteczne.

Celem budowy MVP jest jak najszybsze zebranie feedbacku od potencjalnych użytkowników i zweryfikowanie, czy cały projekt ma sens biznesowy: czy wzbudza zainteresowanie i czy faktycznie trafia w założoną niszę na rynku. MVP to pierwszy mały krok, który pozwala wysondować rynek bez większego ryzyka, które dla raczkujących startupów potrafi być zabójcze. Według danych CB Insights około 42% startupów upada na bardzo wczesnym etapie właśnie z powodu braku popytu na rynku.

Możliwość weryfikacji pomysłu na produkt w warunkach rynkowych to pierwsza i najważniejsza zaleta MVP… ale nie jedyna.

Według Startup Genome startupy wykorzystujące MVP do weryfikacji swoich założeń mają o 20% większe szanse na przetrwanie pierwszych pięciu lat w porównaniu do tych, które pomijają ten krok.

Istnieje kilka metod MVP. Każda z nich w inny sposób pozwala pokazać potencjalnym klientom wartość produktu i sprawdzić, czy warto inwestować w jego rozwój.

• Single Feature MVP – typowa forma Minimum Viable Product, która oferuje użytkownikom tylko jedną funkcję, rozwiązującą jeden, konkretny problem. Co ważne, w tym zakresie produkt powinien być już w pełni funkcjonalny;
• Piecemeal MVP – podejście, w którym zamiast budować od zera własne narzędzia, wykorzystujesz produkty już obecne na rynku i za ich pomocą prezentujesz zamysł Twojego projektu;
• Concierge MVP – model, w którym tworzysz front produktu, ale wszystkie jego funkcje wykonujesz ręcznie. Przykład: wyobraź sobie MVP aplikacji dla miłośników fitness, która ma generować plany ćwiczeń na podstawie ich celów treningowych. W wersji concierge tworzyłbyś je sam – ale zaznaczając, że w pełnej wersji cały proces będzie zautomatyzowany;
• Wizard of Oz MVP – odmiana modelu Concierge. Znów, wszystkie zadania realizowane są ręcznie, ale sama aplikacja projektowana jest tak, aby użytkownik był przekonany, że wszystkie interakcje zostały już zautomatyzowane. Stąd też nazwa nawiązująca do słynnego czarnoksiężnika, który okazał się niezwykle sprytnym iluzjonistą;
• Fake Door/Landing Page MVP – podejście, w którym… nie tworzysz żadnego produktu, a jedynie stronę, na której prezentujesz swój projekt tak, jakby już był gotowy. W ten sposób nie da się co prawda dowiedzieć niczego o działaniu samego produktu, ale można za to zbadać popyt i zebrać adresy mailowe od zainteresowanych.

Po pierwsze – zdefiniuj grupę docelową i jej bolączkę. Projektowaniu MVP powinna zawsze przyświecać zasada user-first, dlatego zacznij od użytkownika. W idealnym scenariuszu przed stworzeniem minimalnej wersji produktu zespół projektowy powinien dysponować:

• user personą, czyli reprezentacją wzorowego użytkownika aplikacji;
• wynikami wstępnych badań na temat problemów grupy docelowej;
• wnioskami z analizy konkurencji.

Oczywiście duża część pomysłów, które stały za najgłośniejszymi startupami, nie wzięła się z badań rynkowych, a, po prostu, z codziennych problemów twórców albo ich znajomych; ewentualnie były rozwinięciem już istniejących projektów. Ale nie zmienia to faktu, że warto prowadzić badania w grupie docelowej i to na jak najwcześniejszym etapie – to Ci pozwoli zweryfikować czy problem, który chcesz rozwiązać… jest w ogóle realny.

Kolejnym krokiem będzie „selekcja” funkcji produktu. Załóżmy, że masz ogólną wizję tego, w jaki sposób Twój projekt ma rozwiązywać problemy klienta. Z tej wizji musisz wykrystalizować minimalny zestaw funkcji, który pozwoli użytkownikowi zrealizować jego cele. Świetnym narzędziem są tzw. user stories, czyli krótkie, pisane z perspektywy użytkownika końcowego historyjki, w których opowiada on o tym, jakie zadania chce realizować przy pomocy aplikacji.

Przy pomocy user stories możesz rozpisać całą ścieżkę swojego idealnego użytkownika i wszystkie funkcje, przez które będzie po kolei przechodził. Ale tworząc MVP, musisz wybrać te najistotniejsze – i wyciąć pozostałe. Do tego sprawdza się metoda MoSCoW. Dzieli ona wszystkie funkcje na cztery grupy:

• must have – bez nich produkt nie może istnieć; muszą znaleźć się w MVP;
• should have – wnoszą wartość do produktu, ale nie definiują jego funkcjonowania; trzeba je wdrożyć na kolejnych etapach;
• could have – również mogą być wartościowe, ale można je pominąć, jeśli np. na drodze stoją zbyt wysokie koszty;
• won’t have – nie wnoszą do produktu większej wartości niż koszty ich wdrożenia; pomijamy je.

Jeśli tworzysz aplikację do zamawiania jedzenia, funkcjami must have byłyby: opcja wyszukiwania restauracji, panel do składania zamówień oraz system płatności. Opcja założenia konta prawdopodobnie trafiłaby do szufladki should have, a system kuponów i program lojalnościowy – do could have.

Dopiero gdy masz już jasny obraz, co powinno trafić do MVP, a co nie, można przejść do projektowania. I tutaj jedna rada: używaj jak najprostszych narzędzi. MVP aplikacji dziś najczęściej powstają w programach no-code/low-code (np. Bubble lub Glide); tak jest i szybciej, i taniej, a generowany w nich kod bez problemu powinien poradzić sobie z podstawowym zestawem funkcji.

Od wersji MVP zaczynały się historie wielu spośród królujących obecnie aplikacji i usług. A oto trzy z nich.

1. Spotify

Czy wiesz, że pierwsza wersja największej platformy streamingowej powstała w 2006 roku? Był to okres, w którym wiele firm próbowało wybić się na streamingu… co nikomu się w pełni nie udało. Daniel Ek i Martin Lorentzon zaczęli więc od bardzo prostej aplikacji desktopowej, która umożliwiała strumieniowe przesyłanie muzyki… i nic poza tym. Najpierw trafiła do ich przyjaciół, a gdy zebrała pozytywny feedback – twórcy rozesłali link do aplikacji największym szwedzkim blogerom muzycznym.

Na co warto zwrócić uwagę: MVP Spotify posłużyło twórcom nie tylko do tego, aby wybadać grunt pod cały projekt, ale także by ocenić, czy są w stanie zapewnić stabilny przesył danych przy coraz większej liczbie użytkowników i rosnącej bibliotece utworów.

2. Uber

Najpopularniejsza aplikacja do zamawiania przejazdów zaczynała z kolei jako… usługa SMSowa. Tak – aplikacja UberCab, bo tak dokładnie nazywała się pierwsza iteracja Ubera, umożliwiała zamawianie taksówek przez SMSy. Firma nie miała ani własnej floty pojazdów, ani pracujących dla niej kierowców; po prostu łączyła podróżnych z lokalnymi taksówkarzami.

Na co warto zwrócić uwagę: UberCab działał wyłącznie na terenie San Francisco i mogli skorzystać z niego jedynie użytkownicy iPhone’ów. Ograniczenie skali działania aplikacji na pewno pomogło w tym, aby projekt w ogóle się urzeczywistnił – trudno wyobrazić sobie, by taka aplikacja od pierwszego dnia objęła, powiedzmy, całą Kalifornię.

3. Dropbox

Historia Dropboxa jest dowodem na to, że MVP wcale nie musi być funkcjonalnym produktem. Może być po prostu… krótkim filmem-prezentacją, demonstrującym jak ma działać docelowy produkt. Tak właśnie w 2007 roku zrobił Drew Houston, który swoją wizją zainteresował kilkadziesiąt tysięcy osób, czekających z niecierpliwością na prawdziwą, działającą już wersję Dropboxa.

Na co warto zwrócić uwagę: większość startupów wydaje od 10 000 USD do 50 000 USD na swoje MVP. Minimum Viable Product Houstona nie kosztował prawdopodobnie więcej niż kilkaset dolarów na zbudowanie prostej strony i czas poświęcony na nagranie filmu.

A co po wydaniu pierwszej wersji produktu? Najważniejsze będzie zebranie informacji zwrotnej z rynku. Bez niej dalsze rozwijanie MVP byłoby trochę projektowaniem w ciemno, prawda? Sposoby na weryfikację projektu są różne.

• Jeżeli produkt jest funkcjonalny – możesz w zasadzie od samego początku go sprzedawać, nawet w wersji beta. Trudno o lepszy wyznacznik, czy pomysł się przyjął, czy nie;
• jeśli nie jesteś w stanie spieniężyć produktu na tym etapie, spróbuj inaczej oszacować popyt. Możesz na przykład opublikować landing page, na którym zainteresowani będą mogli zostawić swojego maila, albo wypuścić krótką kampanię w social mediach i ocenić zainteresowanie na podstawie jej zasięgów i zaangażowania odbiorców;
• Jednak podstawą powinny być ankiety i wywiady z użytkownikami. To one dadzą Ci wgląd w to, jak wcześni użytkownicy oceniają produkt i – przede wszystkim – jakie dostrzegają w nim problemy.