Etap projektu:
MVP to skrót od Minimum Viable Product.
Przez wielu, termin ten rozumiany jest jako pierwsza, minimalna wersja produktu, który chcemy wydać.
Popularnym pomysłem jest przekucie naszego pomysłu w tak oszczędną i tanią wersję produktu, aby można było go szybko wypuścić na rynek. Głównie po to, aby sprawdzić czy ktoś będzie go używał.
Ten artykuł opowie Ci o tym, dlaczego MVP wcale nie musi być zaprogramowanym produktem. Nie potrzebujesz nawet linijki kodu, aby sprawdzić czy Twój pomysł ma sens.
Rozpocznijmy od historii. Poznaj Marka - Foundera Startupu.
Marek miał pomysł na startup i mocno w niego wierzył. Naprawdę mocno.
Prosty koncept - aplikacja, która po wpisaniu słów piosenki podpowiada jej autora i tytuł.
Czy to pomysł dobry czy zły - nie mi oceniać. Ważne, że Marek postanowił odejść z pracy etatowej i założyć swój startup. Zaczyna się jego wielka przygoda…
Zaczął w pocie czoła rysować, szkicować i opowiadać znajomym o pomyśle. Usłyszał też gdzieś o koncepcie Minimum Viable Product.
“Wydam na początku podstawową wersję aplikacji i zobaczymy co się stanie” - pomyślał.
Poprosił więc różnych deweloperów o wycenę jego aplikacji - minimalnej wersji, bo ma być mała (i najlepiej tania 😀 ).
Po paru miesiącach pracy i dodawaniu dodatkowych funkcjonalności w locie (bo wstyd wydać taką niekompletną aplikację), Marek wrzucił swoją aplikację na App Store i Google Play.
I pewnie się domyślasz, że… nikt z niej nie korzystał.
Ta opowieść wydarzyła się naprawdę tysiące razy.
To dość standardowy sposób działania. Pojawia się pomysł na start-up, a my, porwani naszą fantazją zaczynamy tworzyć jego podstawy. Trochę poczytamy, zobaczymy co dzieje się u konkurencji, a może nawet weźmiemy udział w jakimś programie akceleracyjnym.
Masa czasu i pieniędzy wydana, żeby ostatecznie odbić się od rynku i czasami dowiedzieć, że to co stworzyliśmy jest bez sensu.
Niestety większość startupów upada z prostego i błahego powodu. Nikt nie potrzebuje ich produktu. Rynek nie załapał, nikogo to po prostu nie interesowało.
W utrudnionych warunkach rynkowych (które prawdopodobnie nadchodzą) kontekst ten jest jeszcze silniejszy, ponieważ ludzie płacą jedynie za produkty i usługi, których naprawdę potrzebują. Za coś co realnie naprawia ich problem, pomaga im z tak zwanym “kamieniem w bucie”*
Zastanówmy się jeszcze raz jak wygląda zazwyczaj projekt MVP.
Nabudowujemy materiały, grafikę, koncepcje produktu. Tworzymy to wszystko bardzo mocno wierząc, że po prostu komuś pomożemy (a najlepiej jeśli coś jeszcze na tym zarobimy 💸).
Niestety nasza wiara często nie wystarcza, bo razem z tworzeniem konceptu, rośnie ryzyko. Ryzyko związane między innymi z tym, że naszego produktu po prostu nikt nie potrzebuje, a my jeszcze tego nie wiemy.
W tym klasycznym modelu pojedynek z rynkiem (🥊) odbędzie się dopiero na samym końcu. I często okaże się, że niestety to my będziemy ofiarą Knockoutu.
Jeśli tworzysz produkt innowacyjny, budujesz start-up lub nawet aplikację podobną do konkurencji - parę Twoich pierwszych pomysłów i hipotez będzie nieprawdziwych. Zgadza się - to możliwe, że nikogo nie ruszy Twój pomysł na 💥ekstra💥 funkcjonalność.
Dostaniesz parę ciosów od rynku, a niektóre koncepcje legną w gruzach.
Ale to całkowicie normalne, a tak właściwie otrzymywanie tych ciosów jest celem projektu samym w sobie.
Najnormalniejszą rzeczą na świecie jest fakt, że pare razy zbudujesz coś co nie jest zgodne z tym jak myśli Twój użytkownik i co uważa za wartościowe. To co stworzysz może być też chociażby nie wpasowane w proces i realia jego życia. Lub w niczym nie jest dla niego lepsze od dostępnych alternatyw.
Sztuką jest jednak otrzymywać wspomniane ciosy możliwie wcześnie (i tanio), a także sterować swoim konceptem w odpowiednim kierunku. Jednym słowem, dostawać w głowę, ale tak, żeby mocno nie oberwać. Odkrywać swój produkt razem z ludźmi i ich reakcjami.
Jest, odbijanie się od użytkowników, kontakt z nimi i uczenie się wcześniej i szybciej.
Wyobraź sobie, że możesz w miarę obiektywnie dowiedzieć się jaka jest perspektywa Twoich użytkowników oraz czy chcieliby i czy umieliby używać Twojej aplikacji. Jeszcze przed fazą programowania, która jest absolutnie najdroższa.
Pomóc mogą nam tutaj metody związane z projektowaniem User Experience oraz researchem, przykładowo:
Taki projekt mógłby wyglądać przykładowo tak:
Takich metod jest sporo, a każda z nich ma prosty cel - zweryfikować pewne przypuszczenia na temat projektu dzięki otwartości na feedback. Dużo wcześniej, niż klasycznie miałoby to miejsce.
Każdy z elementów pokazanych na grafie (wywiady, testy, itp.) rozumieć można jako Minimum Viable Product. MVP w tej definicji nie jest ukończonym projektem. Ono jest narzędziem, które pozwoli Ci dowiedzieć się kolejnej, najważniejszej rzeczy o Twoim użytkowniku, rynku lub projekcie.
Definicja ta pochodzi bezpośrednio z Lean Management i zachęca ona do zdefiniowania najbardziej ryzykownych hipotez (przypuszczeń) o Twoim pomyśle, aby następnie weryfikować każdą z nich najłatwiejszym możliwym sposobem. A zazwyczaj stworzenie zaprogramowanego produktu jest najdroższym i najtrudniejszym sposobem na zweryfikowanie hipotezy.
Jak mogłoby to wyglądać w praktyce?
Wróćmy do naszego startupowego Marka. Pamiętasz jego koncept? Jego aplikacja miała po wpisaniu SŁÓW piosenki podpowiadać autora i nazwę.
Możliwe, że przyjdzie Ci do głowy, że koncept jest irracjonalny, bo zazwyczaj piosenkę się słyszy, a jeśli z jakiegoś powodu znamy tekst to wystarczy go wygooglować. Poza tym, korzystanie z tej aplikacji często kończyło by się tak:
I właśnie to w projekcie Marka jest najbardziej ryzykowną hipotezą - czy ludzie potrafiliby wymienić słowa piosenki oraz czy do rozpoznania jej tytułu użyliby aplikacji (może mają jakąś niezawodną alternatywę)?
Marek mając te wątpliwości mógłby wyłapać perspektywę użytkowników chociażby poprzez:
+ Zapytanie paru osób co zrobiłyby jeśli usłyszałyby piosenkę i chciały poznać jej tytuł (tutaj jest to bardzo proste, ponieważ grupa docelowa jest niezwykle szeroka),
+ Stworzenie prostego prototypu aplikacji i poproszenie kogoś o wykorzystanie go (w tym momencie bardzo szybko by się dowiedział, że ktoś kto słyszy piosenkę niekoniecznie może uchem szybko wyłapać jej tekst),
I to tylko dwa przykłady z wielu. Zarówno pytania do rozmowy, jak i prototyp aplikacji, można w tej terminologii nazwać MVP. Pozwoliły one startupowemu Markowi obniżyć bardzo istotne ryzyko i przybliżyć się do użytkowników. A o to w tym wszystkim chodzi.
Myśl o tym, żeby badać cokolwiek przed wydaniem produktu może rodzić u Ciebie parę pytań:
Tym cytatem otwieramy konkurs na Top10 mitów na temat tworzenia produktów cyfrowych.
To prawda - klienci nie są innowatorami. A my wcale nie będziemy prosili ich o wymyślanie produktu i sugerowanie nam co warto stworzyć. To co jednak klienci wiedzą na pewno to:
- Co realnie ich irytuje,
- Jak wyglądają ich procesy związane z naszym produktem,
- Jakie widzą alternatywy i z jakich alternatyw korzystają,
- Czy potrafią użyć przykładowo naszej aplikacji, jeśli damy im ją do ręki. A tego nie sprawdzamy poprzez pytanie, a obserwowanie podczas testu użyteczności jak rzeczywiście to robią.
Jeśli kreowanie produktu byłoby tak proste jak zapytanie dwóch klientów jaką chcą aplikację to nie musiałbym pisać tekstu, który właśnie czytasz. Obiektywne złapanie perspektyw jest sztuką pracy strategicznej.
A jeśli chodzi o Pana Henry'ego, jeśli zapytałby co irytuje klientów, prawdopodobnie wspomnieliby o tym, że konie są wolne. A to w roli innowatora leży już wymyślenie rozwiązania problemu, czyli samochodu. Pssst… Nie ma dowodów, że Henry Ford kiedykolwiek to powiedział 😉
U podstaw, badanie Twoich użytkowników dostarcza Ci ogromnej wiedzy o nich. W ten sposób wykształca się u Ciebie intuicja projektowa, a Twoja głowa wypełnia się obrazami osób dla których tworzysz produkt. Samo w sobie jest to niezwykle cenne, ponieważ w konkretnych momentach możesz zadać sobie samemu pytanie - “Czy osoba X, którą poznałem, wiedziałaby jak użyć tej funkcji?”
Nie jest też oczywiście tak, że zerojedynkowo dowiesz się, że Twój produkt ma sens lub nie. Głównie zajmujemy się obniżaniem ryzyka, a nie uzyskaniem całkowitej pewności.
Jeśli chodzi o bardzo ważne konkrety to dowiedzieć możesz się między innymi:
Niekoniecznie. Rzeczywiście warto rozumieć niektóre elementy, aby Twoje działania były rzetelne. Bardzo mocno jednak wierzę, że nawet niekompetentne poszerzanie wiedzy będzie zawsze lepsze, niż całkowite zamknięcie w Twojej głowie, gdzie czekają na Ciebie jedynie Twoje perspektywy.
Wiadomym jest, że najłatwiej jest skorzystać z usług agencji, która zajmuje się tym profesjonalnie. Taka agencja jednak i tak powinna zaimplementować Cię w proces i odkrywać świat Twojego produktu razem z Tobą, ponieważ ostatecznie to Ty podejmujesz decyzje strategiczne. Wiedza, którą właśnie zdobywasz przyda Ci się więc niezależnie od drogi, którą podejmiesz.
Zdecydowanie nie. Klasyczne podejście, czyli jak najszybsze zrobienie i wydanie Minimalnej Wersji Produktu to także jedna z dróg, którą możesz podjąć. Obarczona jest ona pewnym ryzykiem, ale jeśli chcesz je podjąć lub przykładowo jesteś bardzo blisko swojej grupy docelowej, znasz ją i rozumiesz - możesz to zrobić.
Artykuł ten pokazuje po prostu alternatywną drogę działania. Drogę dla osób bardziej analitycznych i chcących zrobić to “po bożemu”. Chcących statystycznie zwiększyć swoją szansę na sukces.
Jeśli ta droga jest dla Ciebie ciekawa i zastanawiasz się jak ją podjąć to są dwie podstawowe opcje:
1. Napisz do nas. Regularnie prowadzimy startupy i większe firmy przez tę drogę. Pierwsza konsultacja jest darmowa, a my chętnie porozmawiamy w trakcie niej jak możemy pomóc w Twojej sytuacji.
2. Jeśli chcesz zrobić to samodzielnie, metodologii i książek, które promują to podejście jest multum:
- Lean UX,
- Podręcznik Startupu,
- Badania jako podstawa projektowania User Experience.
- Zainspirowani.
(Gorąco zachęcam do przeczytania tych pozycji!)
Sporym problemem jest jednak to, że wiedzy w książkach i internecie jest MASA i czasem ciężko się w tym odnaleźć. Pojawiają się w sieci chociażby takie terminy jak Design Thinking, Double Diamond, Product Discovery czy Customer Development.
Jeśli jesteś startupowcem, managerem lub projektantem UX, najprostszym rozwiązaniem będzie subkrybcja naszego newsletterra, gdzie regularnie pokazujemy jak użyć odpowiednich narzędzi w Twoim produkcie oraz jak zorganizować cały proces Discovery.
CEO Dragon Scale. Pasjonat Product Discovery, Leanu i inteligentnego tworzenia produktów cyfrowych.
Co tydzień jeden poradnik. Jego cel? Pozwolić Ci tworzyć lepsze produkty i lepiej podejmować decyzje.