W swojej dotychczasowej karierze spotkałem się z dziesiątkami koncepcji na MVP, które przygotowali przedstawiciele startupów lub firmy planujące stworzyć cyfrowe produkty jako nowe komponenty ich modelu biznesowego. W znakomitej większości przypadków nowo tworzony produkt był MVP tylko z nazwy, a cała idea lean startup była implementowana niepoprawnie lub była całkowicie ignorowana.
Poniżej przedstawiam zestawienie najczęstszych błędów popełnianych podczas definiowania MVP dla nowych produktów cyfrowych.
1. Brak jasnych założeń dotyczących grupy docelowej oraz wartości, które mają być jej dostarczone
Założenia dotyczące grupy docelowej oraz wartości dostarczanych tej grupie wydają się wielu twórcom nowych produktów tak oczywiste, iż w większości przypadków nie są one wprost zapisane w kontekście definicji MVP. Z moich obserwacji wynika, iż jasna definicja grupy docelowej oraz wartości stanowi solidny fundament pod wszystkie dalsze rozważania dot. MVP. Jej brak powoduje, że częściej pojawiają się wątpliwości w procesie decyzyjnym dot. zakresu funkcjonalnego MVP.
Z drugiej strony, zdefiniowanie tych założeń może pomóc w odkryciu pomniejszych grup docelowych i ich wartości, których obecność w modelu biznesowym naszego produktu nie jest oczywista.
Dobrym sposobem na zdefiniowanie grupy docelowej i wartości jest zapisanie modelu biznesowego w formie tzw. Business Model Canvas. Trzeba pamiętać, że bardzo często założenia dot. grupy docelowej są kluczową hipotezą, którą chcemy przetestować za pomocą naszego MVP.
2. Brak hipotezy, którą MVP ma pomóc zweryfikować
MVP to narzędzie do testowania hipotez dot. tworzonego produktu. MVP bez hipotezy nie ma racji bytu. Zaskakujące w tym kontekście jest to, że w przypadku większości MVP nikt nie definiuje żadnych hipotez. W takiej sytuacji ryzyko zdefiniowania zakresu produktu wykraczającego poza niezbędne minimum jest ogromne. Szczególnie jeżeli mówimy o pierwszym MVP, który najczęściej służy do weryfikacji fundamentalnych hipotez dot. grupy docelowej i jej zapotrzebowaniu na wartości dostarczane przez nasz produkt.
Jasno postawiona hipoteza pozwala nie tylko na odpowiednie ograniczenie zakresu funkcjonalnego naszego produktu, ale przede wszystkim pozwala zdecydować o formie produktu i kanale jego dystrybucji, co zawsze ma znaczący wpływ na czas i koszt wytworzenia MVP.
3. Nieuwzględnienie kanału pozyskania użytkowników w hipotezach dot. MVP
Paliwem każdego produktu cyfrowego są kanały pozyskania użytkowników. Bez użytkowników produkt nie będzie funkcjonował, a użytkownicy nie pojawiają się znikąd.
W praktyce oznacza to, że istnienie odpowiednio skalowalnego kanału pozyskania użytkowników może być kluczową hipotezą stawianą naszemu MVP. Jeżeli jest tak w przypadku naszego produktu, to może to mieć ogromny wpływ na jego postać. W tej sytuacji naszym MVP może być tylko namiastka lub atrapa produktu wraz z odpowiednimi działaniami marketingowymi w kanale, którego skuteczność chcemy zweryfikować.
Brak uwzględnienia kanałów pozyskania użytkowników w rozważaniach na temat MVP może prowadzić do sytuacji, w której powstanie produkt, dla którego pozyskanie użytkowników nie będzie możliwe. Ryzyko finansowe tego typu inwestycji będzie wtedy ogromne. Dodatkowo należy pamiętać o wpływie kanałów pozyskania użytkowników na sama postać tworzonego produktu. Piszę o tym w następnym punkcie.
4. Brak uwzględnienia wpływu zakładanego kanału pozyskania użytkowników na funkcjonalność produktu
Definiując postać lub zakres funkcjonalny produktu należy pamiętać o tym, iż założone kanały pozyskania użytkowników mogą mieć wpływ na postać naszego produktu. Przykładem tutaj może być aplikacja webowa typu marketplace, dla której SEO stanowić będzie naturalny kanał pozyskania użytkowników. W takim przypadku konstrukcja produktu nie pozwalająca na indeksowanie treści dostępnych w wyszukiwarkach będzie oznaczała, iż ten kanał w ogóle nie zadziała.
Innym przykładem będzie produkt, w którym zakłada się pozyskanie użytkowników za pośrednictwem treści udostępnianych w social media. Kanał ten nie zadziała, jeżeli w produkcie brak będzie możliwości udostępniania treści zoptymalizowanej pod tym kątem. Tego typu błędy podczas definiowania postaci produktu cyfrowego zdarzają się nierzadko, w szczególności w przypadku, gdy mowa jest o drugorzędnym kanale pozyskania użytkowników.
5. Brak określonego sposobu pomiaru współczynników pozwalających na weryfikację hipotezy
Hipoteza stojąca za naszym MVP jest nic nie warta, jeżeli nie mierzymy wskaźników pozwalających na zweryfikowanie jej prawdziwości. Co gorsza, możemy wtedy nie zdawać sobie sprawy z tego, iż nasza hipoteza jest w ogóle niemożliwa do obiektywnego zweryfikowania.
Pamiętać trzeba, iż możliwość pomiaru odpowiednich wskaźników wymaga zawsze odpowiedniego wdrożenia metody i narzędzi ich pomiaru. W przypadku produktów cyfrowych pomiar wskaźników odbywa się zazwyczaj za pomocą odpowiednich narzędzi analitycznych (jak choćby Google Analytics czy Mixpanel). Jeżeli te narzędzia nie zostaną odpowiednio przygotowane, możemy bezpowrotnie stracić możliwość pomiaru wskaźników naszego MVP podczas zaplanowanej kampanii promującej nasz produkt.
Należy zawsze dążyć do tego, aby pomiar wskaźników odbywał się w sposób zautomatyzowany, powtarzalny i skalowalny. W praktyce wiele tych samych wskaźników będzie wykorzystywanych wielokrotnie do weryfikacji hipotez na różnych etapach życia produktu.
6. Uwzględnianie w zakresie funkcjonalnym MVP wartości, które nie są w zbiorze wartości dostarczanych przez produkt
Twórcy produktów cyfrowych nie rzadko przejawiają tendencje do rozbudowywania funkcjonalności produktu bez solidnych przesłanek wynikających z modelu biznesowego lub oczekiwanego User Experience. Bardzo często zdarza się, że MVP są pełne dodatkowych funkcjonalności, które nie dość, że nie wnoszą nic w kwestii weryfikacji założonych hipotez, to jeszcze powodują dostarczanie wartości, których nie ma w definicji potrzeb założonej grupy docelowej.
Problem naturalnie pojawia się w sytuacji, w której grupa docelowa oraz dostarczane jej wartości nie są jasno zdefiniowane (patrz p. 1). Brak wtedy jasnego punktu odniesienia pozwalającego utrzymać zakres funkcjonalny produktu w niezbędnych ryzach.
Co zaskakujące, problem ten pojawia się także wtedy, gdy grupa docelowa oraz wartości jej dostarczane są jasno zdefiniowane. Wynika to z faktu, iż wielu twórców aplikacji koncentruje się tak mocno na warstwie funkcjonalnej produktu, iż całkowicie zapominają o weryfikacji swoich pomysłów z fundamentalnymi założeniami dot. produktu.
Jeżeli grupa docelowa oraz dostarczane jej wartości zostały zdefiniowane w formie Business Model Canvas, to nie można zapominać o każdorazowej weryfikacji nowych założeń funkcjonalnych z tym modelem.
7. Niejasna forma definicji zakresu funkcjonalnego MVP
Nawet Ci twórcy MVP, którzy definiują jego zakres poprawnie metodycznie, mają problem z wyborem odpowiedniej formy opisu zakresu funkcjonalnego MVP. Dlatego w praktyce każdy MVP to trochę inne podejście do sposobu sformułowania wymagań jemu stawianych. Szczególnie widoczne jest to w obszarze wymagań definiujących funkcjonalność produktu.
Istnieje wiele sposobów na skuteczne opisanie funkcjonalności MVP. Osobiście polecam zastosowanie do tego tzw. User Stories (patrz https://en.wikipedia.org/wiki/User_story). Pozwalają one na bardzo zwięzłe opisanie wymagań funkcjonalnych produktu z jednoczesnym zachowaniem jasnego kontekstu korzyści i potrzeb użytkowników. Zastosowanie User Stories jako formy opisu wymagań funkcjonalnych pozwoli Ci także lepiej ustrukturyzować prace developerskie nad produktem (w szczególności, gdy Twój zespół developerski będzie pracował zgodnie z metodyką Scrum).
–
Łukasz Korol
CTO, założyciel i współwłaściciel agencji Code & Pepper
Odpowiedzialny za realizację projektów mobilnych i webowych w Wielkiej Brytanii, USA, Szwajcarii, Holandii i Polsce, współpracujący z międzynarodowymi agencjami takimi jak Mediablaze (UK), La Moulade (UK), Flipside Group (UK), Digital Chefs (Netherlands) oraz z klientami bezpośrednimi m.in. Christian Louboutin (USA) i LocalBini (Szwajcaria). Twórca wielu międzynarodowych starupów. Jego projekty otrzymały międzynarodowe nagrody takie jak Awwwards, One Page Love Award, CSS Design Award or CSS Winner. Historia Łukasza oraz całej agencji Code & Pepper została opisana w najnowszej książce Filipa Springera – „Miasto Archipelag”.
