4. Jak stworzyć dobre MVP?

Jednak czym tak naprawdę jest to MVP, czyli Minimum Viable Product.

Jak pomaga on przetestować rynek pod kątem zapotrzebowania na to, co chcemy mu dostarczyć?

Bazując na własnych doświadczeniach Radek i Marta Jakubowska opowiedzą o projekcie Deliver in Person, gdzie zbudowali POC oraz MVP dla startupu logistycznego na rynek australijski.

Ilona z kolei opowie o tworzeniu MVP wewnątrz istniejącego już produktu.

W ramach odcinka “Jak stworzyć dobre MVP?” poruszamy takie zagadnienia jak:

• jak wyglądał proces badawczy i walidowanie założeń w projekcie Deliver in Person,

• jak projektant UX może wesprzeć proces tworzenia MVP oraz pomóc zaprojektować odpowiednie miary,

• jak zarządzić MVP, które okazuje się dużym produktem w podejściu waterfall,

• jak stworzyć listę funkcjonalność, za które użytkownicy naprawdę chcą zapłacić.

Rozmowę możesz też posłuchać na Youtube:

Zachęcamy Cię do subskrybowania naszego podcastu, jeśli interesuje Cię tematyka doświadczeń klientów w świecie cyfrowym i tego, jak design może wspierać osiąganie celów biznesowych.

Będziemy Ci wdzięczni za udostępnienie linku do tego odcinka osobom, którym może on w jakiś sposób pomóc w rozwijaniu biznesu lub własnych kompetencji.

Podcast możesz posłuchać na:

• Spotify

• Apple Podcasts

• Youtube

• Anchor

• Pobierając mp3

• Google Podcasts

• Transkrypcja rozmowy

  Ilona: Cześć! Dziś będziemy zajmować się tematem MVP. Jest to taki temat, którym zajmujemy się praktycznie codziennie, dlatego, że w naszej pracy pomagamy startupom oraz firmom budować produkty od zera. Wielu naszych klientów używa tego sformułowania. Mamy poczucie, że warto jest ten temat poruszyć. Warto jest wejść trochę głębiej w to, jak projektanci pomagają budować MVP. Jak ten proces wygląda? Wielu naszych klientów zadaje nam pytanie, ile to będzie trwało i kiedy nadejdzie ten dzień zero, w którym będą mogli obserwować efekty i podjąć dalsze decyzje do rozwoju produktu. Jest to dla nas ważne, dlatego postanowiliśmy poruszyć ten temat.

  Co to jest MVP?

  Ilona: Zaczynając od samego początku: co to właściwie znaczy MVP? Trzyliterowy skrót z angielskiego oznacza minimum viable product. Odszyfrowując to i tłumacząc na język polski, najzwyczajniej w świecie jest to minimalna wartość produktu. Oznacza to, że budujemy usługę cyfrową albo produkt cyfrowy, który spełnia minimum wartości dla użytkownika.

  Radek: Nie tylko cyfrowy…

  Ilona: Dokładnie. MVP kojarzy się głównie ze światem cyfrowym, ale budowanie minimalnej wartości produktu może wiązać się również z budowaniem produktu realnego, namacalnego, takiego, który możecie kupić w zwykłym sklepie. Ja dodałabym do tego od siebie taką wisienkę na torcie, że MVP to taki produkt, który dostarcza wartość i użytkownicy są skłonni zapłacić za ten produkt. Wtedy uważam, że faktycznie MVP ma odhaczone wszystkie ważne elementy.

  Rodzaje MVP

  Ilona: To, co bym chciała zrobić na samym początku, to powiedzieć, że MVP możemy podzielić na dwie kategorie. Pierwsza kategoria, to kiedy zaczynamy od pustej kartki i budujemy całkowicie nowy produkt, czyli budujemy również brand wokół tego. A druga kategoria, to gdy budujemy w istniejącym produkcie coś nowego, jakiś ficzer albo usługę. Wtedy mamy już markę, która za nami stoi, ale budujemy coś nowego, więc też używamy tej metodyki.

  Od czego zacząć budowanie MVP?

  Ilona: Kiedy decydujemy się na budowanie MVP, warto, żebyśmy odhaczyli sobie kilka punktów. Po pierwsze: kiedy zaczynamy, wiemy, dla kogo budujemy, kim jest nasza persona. To jest super kluczowe, bo jeżeli decydujemy się na zbudowanie MVP i mówimy do wszystkich, to jest bardzo duże prawdopodobieństwo, że poniesiemy klęskę, bo ciężko będzie nam zaprojektować komunikację, czy ścieżkę dla wszystkich.

  Radek: I to jest bardzo trudne w pracy z klientami, którzy mają podejście na zasadzie: słuchaj, to jest rozwiązanie dla wszystkich, naprawdę nie potrafię określić grupy docelowej. Niestety, to się często zdarza i to jest ogromna bariera i ogromny problem w procesie budowania MVP. 

  Ilona: Tak, to jest pierwszy punkt, który ja zawsze przed budową MVP muszę odhaczyć. Po prostu nie zaczniemy takiego projektu, jeżeli nie będziemy wiedzieć, do kogo mówimy. Druga rzecz, na którą bardzo zwracam uwagę, to jest to, czy wiemy dokładnie, którą bolączkę adresujemy oraz w jaki sposób chcemy ją zaadresować. Może być tak, że tych bolączek mamy kilka i może będziemy chcieli zaadresować więcej niż jedną. OK, ale wybierzmy konkretnie, na które problemy odpowiada nasz produkt, czyli to, co będziemy budować, żebyśmy wiedzieli, co sprawdzamy. Jeżeli dojdzie do momentu, w którym powiemy sobie: Czy to jest OK?, Czy to odniosło sukces?, Czy projekt, który zrobiliśmy, osiągnął te cele, które sobie założyliśmy?, to musimy od czegoś się odbić. Na samym początku musimy wiedzieć, od czego się odbijamy i jakie bolączki adresujemy.

  Radek: Rozmawialiśmy trochę o tym w poprzednim odcinku, który dotyczył propozycji wartości dla klienta. Rozmawialiśmy o kanwie, modelu, propozycji wartości. Zapraszamy do słuchania odcinka 3.

  Ilona: OK. I trzecia rzecz, którą też sobie checkboxem odhaczam przed tym, jak przystąpimy do budowania MVP: musimy wiedzieć, po co to robimy. MVP służy nam do sprawdzenia, czy robimy produkt; czy wizję, którą mamy przekształcamy w projekt i czy robimy to w odpowiedni sposób. Czyli na samym końcu tego procesu, który jest iteracyjny, musimy mieć jakąś metrykę, która nam powie: w prawo, w lewo. Albo się wycofujemy.

  Radek: Albo zawracamy i pivotujemy.

  Ilona: Dokładnie. Żeby to podsumować — pamiętajmy: wiemy, do kogo mówimy, wiemy, jaką bolączkę adresujemy i wszyscy w zespole wiedzą, po co to robimy, jaka jest metryka sukcesu.

  Dlaczego MVP jest potrzebne?

  Ilona: No właśnie, to po co budować MVP?

  Radek: MVP buduje się w takim momencie, kiedy chcemy wystartować z jakimś produktem lub usługą i nie jesteśmy tak naprawdę pewni, czy duża idea, którą mamy jest warta poświęcenia czasu i pieniędzy. Tak jak powiedziałaś wcześniej, MVP jest tylko małą reprezentacją całego produktu, całego brandu. To, co robi MVP, to wybiera małą część, ale tę część kluczową dla tego produktu, która rozwiązuje największe bolączki, problemy klienta docelowego. Tę część, za którą klient jest w stanie zapłacić. I pytanie, dlaczego robimy tylko mały kawałek? Dlatego, że jak wspomniałem, nie chcemy wyrzucić za dużo pieniędzy. Nie chcemy stracić za dużo czasu na budowanie czegoś, co jest ogromne.

  MVP vs podejście waterfallowe

  Takim procesem, który jest trochę odwrotny do tego, czy też stoi w kontrze do procesu budowania MVP, jest podejście waterfallowe, gdzie buduje się wielki produkt, wielki brand, który ma masę funkcjonalności, jest bardzo skomplikowany, wymaga bardzo dużego nakładu pieniędzy, pracy i technologii. Zazwyczaj takie projekty waterfallowe, kiedy wychodzą na rynek, bardzo często są pewnego rodzaju klęską. Nie wszystkie oczywiście.

  MVP pozwala sprawdzić, czy idziemy w dobrym kierunku, czy to, co nam siedzi w głowach, rzeczywiście rezonuje z rynkiem i potrzebami klienta. Po to budujemy MVP, żeby eliminować ryzyka, które wynikają z tego, czego nie wiemy.

  Ilona: I tak naprawdę nasi klienci, czyli osoby, które na koniec dnia płacą za nasz produkt, to oni głosują swoimi pieniędzmi: tak, chcę tego, potrzebuję tego, róbcie to dalej, czy nie.

  Myślę, że ważnym aspektem w przypadku MVP, który odróżnia budowanie takiej minimalnej propozycji wartości od waterfallowego podejścia jest czas. Jesteśmy w stanie wyjść na rynek, w o wiele krótszym czasie niż dowożąc duży produkt z wieloma funkcjonalnościami, który może i jest potrzebny, ale z tego całego produktu najbardziej adresują trzy, cztery funkcjonalności, a reszta to jest dodatek, który sprawia, że aplikacja jest w jakiś sposób wyjątkowa. Jeżeli będziemy to robić 2-3 lata, to w pewnym momencie może się okazać, że zabrakło nam pieniędzy; jesteśmy w połowie robienia ficzerów i teraz nie wypuścimy czegoś takiego na rynek. Tak więc warto sobie określić, jakie konkretnie funkcjonalności powinny się zawierać w tej minimalnej propozycji wartości.

  Radek: I tak jak powiedziałaś, trzeba wybrać tę grupę, która rzeczywiście ma te potrzeby, której te trzy funkcjonalności rozwiążą problem. I oczywiście w każdym biznesie chodzi o to, żeby dotrzeć do jak najszerszego segmentu, ale w procesie MVP idziemy krok po kroku do kolejnego segmentu, poszerzając tę grupę, dając im konkretne rzeczy, które rozwiązują ich problemy. Jesteśmy w stanie rzeczywiście osiągnąć tę skalę i naturalny sposób przyrastania.

  Ilona: Jedna rzecz mi się przypomniała, o której rozmawialiśmy w tym tygodniu, a mianowicie wykorzystywanie ficzerów per użytkownik. Są badania, które wysyłałam ci w tym tygodniu, które pokazują to, że ponad albo równo 50% ficzerów w produktach cyfrowych nie jest używanych, albo jest używanych bardzo rzadko przez użytkowników. Czyli mówimy o prawie połowie funkcjonalności. Pomyślmy, ile to jest pieniędzy wydanych na zaprogramowanie, przetestowanie i wdrożenie tych funkcjonalności, jeżeli to jest prawie połowa. Można by tego uniknąć, robiąc tylko część funkcjonalności, albo udając tę funkcjonalność, sprawdzając, czy użytkownicy będą w stanie za to zapłacić.

  POC, czyli Proof of Concept

  Radek: Wiesz, jakie hasło mi się kojarzy z tym udawaniem? POC. Czyli coś, co jest jeszcze przed MVP. To jest takie właśnie udawanie produktu. POC, czyli Proof of Concept, to jest taki etap w procesie powstawania produktu, kiedy walidujemy naszą ideę jeszcze przed budowaniem prawdziwie funkcjonalnego produktu.

  Robimy to na zasadzie tworzenia fasady i takiego „teatru”, czyli makiet, które są nieruchome. Tworzymy landingi, tworzymy kampanię internetową, kampanię Google’ową, czy też pokazujemy nawet taki prototyp (a w zasadzie makietę) jakimś użytkownikom na testach korytarzowych i pytamy się ich o zdanie.

  I to jest, wydaje mi się, taki pierwszy krok do MVP, który warto zrobić. Ja bardzo lubię robić POC dlatego, że w takiej pierwszej warstwie odziera właśnie ideę z takiego pięknego snu. I  to jest fajne, że wtedy zazwyczaj właściciele produktów bardzo szybko są w stanie trochę otrzeźwieć. Obudzić się, że ta idea nie do końca rezonuje i trzeba ją może jeszcze przed tym, zanim zaczniemy nawet tworzyć MVP, czyli te pierwsze funkcjonalności, coś działającego… Już na tym etapie idei mogą trochę zejść na ziemię.

  POC oraz MVP na timeline

  Ilona: Gdybym miała umieścić na timelinie, co mniej więcej, po czym występuje. To w przypadku robienia nowych produktów, czy w przypadku startupów, czy firm, które wychodzą z jakąś nową funkcjonalnością, dobrze jest na początku porozmawiać z grupą docelową, dowiedzieć się więcej, znaleźć insighty, znaleźć te bolączki, o których ja już dzisiaj wspominałam.

  Następnie zrobić POC — Proof of Concept, które polega na przykład na zbudowaniu samej makiety i znowu zwróceniem się do tych użytkowników, pokazanie im tego, przetestowanie. POC można testować nie tylko na makietach, ale też sfejkować trochę jakąś funkcjonalność. Tak jak powiedziałeś o teatrze, bardzo spodobała mi się ta metafora. Widziałam to na niejednym polskim portalu czy w niejednym polskim produkcie. Ostatnio próbowałam pobrać fakturę z mojego konta z Allegro. Kliknęłam, pobierz fakturę i dostałam informację: ta usługa nie jest jeszcze dostępna. I wtedy się zaśmiałam, że zrobili Fake Door. Klikając, dałam im do zrozumienia, że bardzo tego potrzebuję, zróbcie to, proszę.

  I dalej, po tym, jak mamy to potwierdzenie od rynku w postaci POC, czyli tego sfejkowanego kontentu, bierzemy się do zbudowania MVP. Jakbym miała to pokazać na timeline to jest to przyrostowe. POC jest mniejsze niż MVP.

  Radek: POC można również robić na zakodowanej wersji beta aplikacji, jeśli rzeczywiście jest zespół i są możliwości. Ja miałem okazję robić takie testy przy okazji projektu Deliver In Person, ale to wynikało z tego, że rzeczywiście zespół szybko poszedł do przodu i można było już testować to na żywym organizmie. Także podejścia są różne. Ja proponuję zazwyczaj to robić na makietach, żeby nie tracić czasu, żeby iść do przodu jak najszybciej, ale są różne sytuacje.

  Strategia MVP — przykłady

  Ilona: Chciałabym trochę głębiej i szerzej porozmawiać o procesie powstawania minimalnej wartości produktu. Przygotowując się do tego odcinka, chcieliśmy dać jak najwięcej realnych przykładów. Ja będę dzisiaj opowiadać o przykładzie powstawania MVP dla istniejącego produktu, który zrobił dodatkową usługę.

  Radek: A ja opowiem o kejsie startupu, który miałem okazję projektować.

  Ilona: Super dobra, no to zaczynamy.

  Case #1 Deliver in Person

  Radek: Chciałbym dzisiaj powiedzieć o projekcie Deliver in Person. Jest to startup australijski, dla którego mamy przyjemność pracować już od marca zeszłego roku. Deliver in Person to w zasadzie nawet nie produkt cyfrowy, tylko ekosystem produktów cyfrowych, który usprawnia dostarczanie paczek na końcowym etapie zwanym Last Mile Delivery.

  W skład tego ekosystemu wchodzą aplikacje mobilne dla odbiorcy paczek, dla kuriera i dla sklepów, które te paczki wysyłają, tak, żeby pomóc im organizować całą wysyłkę. Tutaj ten ekosystem był strasznie duży i wiedzieliśmy od początku, że aby w ogóle ruszyć z MVP, trzeba zbudować każdy z tych produktów — aplikację dla kuriera, dla odbiorcy i dla sklepu. Nie mogliśmy sobie pozwolić na to, żeby testować wszystkie te rzeczy, więc zaczęliśmy od założenia, co jest najbardziej ryzykowną częścią tego produktu dla biznesu. Uświadomiliśmy sobie, że jeśli kurierzy nie będą chcieli rozwozić paczek, jeśli nie zaspokoimy ich problemów i potrzeb, nie dostarczymy im produktu czy też funkcjonalności, które będą spełniały ich potrzeby, to nigdy nie dotrzemy do odbiorców paczek. Z kolei, jeśli nie dotrzemy do odbiorców paczek, to nigdy nie dotrzemy sklepów, w których kupują odbiorcy.

  Ważna rzecz jeszcze, której jeszcze nie powiedziałem, to jest to, że ci kurierzy mogą korzystać z Delivery in Person na zasadzie modelu Uberowego. Czyli masz samochód, masz trochę czasu i możesz w dowolnie wybranym przez siebie czasie wejść w ten samochód, zalogować się do aplikacji i zgłosić się, że jesteś chętny na to, żeby rozwozić paczki.

  Tutaj trochę ten proces POC nałożył się z procesem MVP dlatego, że mieliśmy już wydewelopowaną wersję beta. Postanowiliśmy więc przetestować ten produkt na żywym organizmie. Co to znaczy? Przeprowadziliśmy z kurierami test. W zasadzie z kierowcami samochodów, którzy korzystają z aplikacji typu Uber, Bolt. Oni nie są jeszcze kurierami, ale to właśnie w tę grupę chcemy uderzyć. Chcieliśmy sprawdzić, jesteśmy w stanie dotrzeć, do tych obeznanych z tymi aplikacjami, którzy są trochę przekonani do tego modelu.

  Zrobiliśmy test w terenie. Stworzyliśmy prototypy realnych paczek i zaprosiliśmy kierowców do rozwożenia tych paczek przy użyciu właśnie tej aplikacji. Całe doświadczenie było odgrywane: logowania się do systemu, szukania zlecenia, odbioru paczki, wożenie jej z punktu A do punktu B. Udało nam się nie tylko potwierdzić, jakie są ich obawy, czy rzeczywiście ta aplikacja spełnia ich potrzeby w tym zakresie, ale czy w ogóle są zainteresowani czymś takim.

  Udało nam się też wyłapać takie rzeczy jak, co w tych funkcjonalnościach jeszcze nie działa i nad czym trzeba popracować. Więc z jednej strony chcieliśmy dowiedzieć się, czy w ogóle ta idea ich kręci. Co prawda już trochę wiedzieliśmy, bo zrobiliśmy ogromny desk research. Mieliśmy bardzo silne przekonanie, że to jest potrzebne, ale jeszcze potrzebowaliśmy to oczywiście zderzyć z użytkownikami.

  Mieliśmy trochę POC i wstęp do MVP. I oczywiście wielu rzeczy się nauczyliśmy. Dzięki temu wiele kwestii mogliśmy poprawić i zaaplikować w realne MVP. Co nam ciekawego wyszło to to, że kierowcy, którzy jeżdżą w tym modelu Uberowym, mieli już doświadczenie z rozwożeniem takich paczek. Dla nich kolejna taka aplikacja byłaby czymś bardzo fajnym, bo też w jakiś sposób optymalizowałaby ten proces, ale też zapewniałaby poczucie bezpieczeństwa w tym zakresie. Jeśli oni wozili do tej pory ludzi i do tego są dostosowani to przewóz kluczy czy paczek z niewiadomym składem, mógł się wydawać ryzykowny, ponieważ nie ma na to w żaden sposób procedur. Aplikacja rozwiązywałaby tę obawę.

  Ciekawa rzecz była jeszcze taka, że mieliśmy jedną osobę, która była nowa, świeża. I ona na przykład miała ogromne obawy, żeby np. zostawić paczkę pod drzwiami, co jest też procesem  dostarczania tych paczek. Ci, którzy już kiedyś wozili paczki, nie mieli żadnych problemów, wiedzą jak to jest, ufają.

  Także dobrze, że to zrobiliśmy. Mieliśmy duży problem z tym, jak rozgryźć to, że kurierzy będą się bali tak zostawiać te paczki pod drzwiami. Zaprojektowanie systemu, który by w jakiś sposób ich chronił, było strasznie karkołomne dla nas. Bardzo dużo czasu spędziliśmy na tym.

  Ilona: Pamiętam też, co się wydarzyło po tych testach, które swoją drogą według mnie były genialne, bo pokazywały użytkownika w jego realnym środowisku, a bardzo mało jest takich testów. Z naszego doświadczenia wiemy, że klienci niestety bardzo rzadko godzą się na takie testy, a one przynoszą bardzo dużo wiedzy i nauki.  Pamiętam, że po tych wnioskach, które zostały zaimplementowane już do wersji beta, klient zatrudnił u siebie kurierów, żeby jeszcze dopracować i przetestować ten model przed wejściem na rynek, przed wypuszczeniem aplikacji.

  Co w ogóle mam na myśli, mówiąc przed wejściem na rynek i przed wypuszczeniem aplikacji do App Store’a? W dużym skrócie to był dzień zero. A przed tym, żeby te procesy logistyczne dopracować, zatrudniono jeszcze kilka osób, które przechodziły ten proces codziennie i codziennie dawały feedback: co nie działa, co trzeba poprawić, co jest zbędne, a co niezbędne i trzeba to jak najszybciej dorobić przed startem aplikacji.

  Więc ten proces badawczy był bardzo fajny. Poczynając od desk researchu, o którym mówisz. Potem badania terenowe — absolutnie genialne. Pamiętam filmiki, które później oglądałam. Ja nie uczestniczyłam bezpośrednio w badaniu, ale oglądałam filmiki i robiło to niesamowite wrażenie. Na koniec zatrudnienie kilku osób, żeby to nie były testy jedno-, dwu-, trzydniowe, ale żeby ktoś pojeździł cały miesiąc i powiedział, co można zoptymalizować. To są bardzo ważne pytania, na które odpowiemy sobie tylko i wyłącznie takimi testami.

  I co? Aplikacja jest dostępna, prawda?

  Radek: Jest dostępna. Niestety, my nie możemy z niej korzystać, bo to nie jest na rynek Polski, ale jeśli ktoś jest w Australii i ma okazję skorzystać z Deliver In Person, to zapraszam. Mam nadzieję, że chętnie się podzieli feedbackiem, bo myślę, że my prędko nie pojedziemy do Australii, chociaż bardzo byśmy chcieli. 

  Myślę, że kluczowym insightem i wnioskiem z tego jest to, żeby patrzeć na to, co może przynieść największe ryzyka biznesowe i to testować. W tym przypadku naszym głównym ryzykiem biznesowym mogło być to, że ta aplikacja mogła nie być dopasowana do kurierów i to było absolutnie najważniejsze.

  Jak długo trwa proces MVP?

  Ilona: A teraz Radku jeszcze cię zapytam o to, ile trwa taki proces. To jest pytanie, które dostajemy chyba najczęściej w przypadku współpracy przy nowych produktach: No ale kiedy właściwie to będzie na rynku?

  Radek: Na to pytanie nie ma odpowiedzi jednej i słusznej. Mogę powiedzieć, ile to trwało przy DiP-ie. Pytanie, czy moglibyśmy to zrobić lepiej i szybciej? Myślę, że moglibyśmy to zrobić lepiej i szybciej, ale również moglibyśmy to zrobić o wiele gorzej i wolniej. My DiP-a  zaczęliśmy w marcu 2021. Testy robiliśmy chyba po dwóch, trzech miesiącach. I takie pierwsze MVP,  które nie było wydane, hulało jeszcze na przełomie roku. W związku z tym, że to jest cały ekosystem, to cała machina musiała być dopracowana. Więc prawie rok nam zajęło, żeby ten cały ekosystem wydewelopować.

  Ilona: Aplikacja ujrzała światło dzienne pod koniec czerwca 2022 roku i w tym momencie zbieramy feedback i cały czas rozwijamy ten produkt. Możemy powiedzieć, że w tym wypadku, gdzie mieliśmy trzy aplikacje i cały ekosystem, to od powiedzmy pierwszych testów koncepcji i desk researchu, do wydania tego na App Store minął rok i 3 miesiące.

  Oczywiście tutaj ciężko zliczyć też osoby, które w tym uczestniczyły, bo to nie byliśmy tylko my i nasz zespół, ale oczywiście grono programistów i osoby biznesowe. Myślę, że czas, który jest potrzebny do stworzenia MVP, to taka wypadkowa zasobów, zakresu, okoliczności i pieniędzy, więc może to trwać różnie.

  Case #2 B2B

  Radek: No dobrze, Ilona ja powiedziałem o Deliver In Person. O czym ty byś chciała dzisiaj powiedzieć?

  Ilona: Ja powiem o produkcie z trochę innej strony. Przed tym, jak zaczęliśmy pracować razem, miałam przyjemność rozwijać produkt dla klientów B2B, który pomagał klientom w zarządzaniu sprzedażą. Klientom, którzy prowadzą sklepy w marketplace’ach, ale również klientom, którzy posiadają swoje własne sklepy, więc muszą zarządzać sprzedażą, która spływa z różnych źródeł.

  Korowa funkcjonalność tego produktu była oparta na wspieraniu sprzedaży. Na tym ten produkt zarabiał od dziesięciu lat i tyle ta firma jest na rynku. Powstał koncept rozszerzenia tych funkcjonalności o nową usługę i była to usługa marketingowa. Ponieważ ta usługa miała być adresowana do tych samych klientów, pierwszym etapem była analiza biznesowa, czyli zrozumienie jak w ogóle wygląda to środowisko. Ile klienci są skłonni zapłacić za taką usługę? Z jakich innych usług teraz korzystają?

  Było to połączenie takiej analizy biznesowej i researchu UX-owego. Mówiąc analiza biznesowa, mam na myśli wszystkie wyliczenia: co jest dostępne na rynku, jakie są cenniki, jaki jest w ogóle potencjał wzrostu tego rynku. Po drugiej stronie analiza UX, czyli: Jakie w ogóle są te narzędzia?, Jaką funkcjonalność mają te narzędzia, z których klienci dzisiaj korzystają?, Jakie mają słabe punkty?, Co my możemy zrobić u siebie, czego oni nie mają?, Co przekonałoby klientów, żeby jednak korzystali z naszego rozwiązania?

  To też sytuacja, o tyle charakterystyczna, że to nie był przełomowy produkt, coś nowego, coś, czego nie było na rynku tak jak w twoim przypadku. Takiej usługi w Australii przedtem nie było. Byli zwyczajni kurierzy, ale to było coś nowego. Nastąpiła zmiana nawyków. Robisz coś w określony sposób i nagle przychodzi firma DiP i pokazuje ci, że możesz robić to inaczej.

  Radek: Kluczową wartością było to, że Delivery In Person dostarcza paczki tego samego dnia.

  Ilona: Tak, dla nas to jest oczywistość, a w Australii jest to bardzo dużą wartością, ponieważ jak się możecie domyślać kilometry dzielące miasta… nawet w miastach dzielnice są o wiele większe niż w Polsce czy chociażby w Europie.

  Wracając do produktu, który, miałam okazję budować. Tutaj sytuacja była trochę inna, bo istniały już produkty, które spełniały tę potrzebę i adresowały takie bolączki użytkowników. I teraz pytanie brzmiało, jak my to zrobimy, żeby jednak chcieli korzystać z usługi, która jest oferowana przez firmę, w której pracowałam.

  Na pierwszym etapie była właśnie bardzo duża analiza biznesowa i UX, rozmowy z klientem. Po czym został zbudowany onboarding. Ja miałam przyjemność projektować onboarding dla użytkowników i pierwszy dashboard marketingowy z tym naszym MVP. Czyli była analityka, ale to była bardzo podstawowa analityka i my dopiero (oczywiście podglądając też konkurencję) na podstawie zebranych informacji na temat naszego onboardingu i na temat zbudowanego powiedziałabym POC… Bo ten onboarding i ten pierwszy dashboard naprawdę były bardzo skromne, ale dzięki temu, że już to zbudowaliśmy i w międzyczasie, czyli zanim zostało wypuszczone, zanim zostało zakodowane, były testy na makietach i wtedy sprawdzaliśmy, zadawaliśmy pytania użytkownikom, o to, czego im brakuje. Oczywiście nie w taki sposób: Hej, powiedz mi, czego ci brakuje, bo to jest dosyć tendencyjne.

  Cel był taki, żeby dowiedzieć się, czego im brakuje. Bez jakich funkcjonalności nie wyobrażają sobie pracy, w jaki sposób w ogóle oni widzą wartość w takich narzędziach analitycznych. To było robione już na ekranach. Po czym, kiedy został wdrożony system, były ankiety pytające użytkowników o wartość i dodatkowe ficzery. Miałyśmy wdrożony dashboard w Google Analitics, gdzie również obserwowałyśmy użytkowników i ich przepływ — kto się zapisuje, a kto nie. Poza tym były jeszcze landing page w samej aplikacji i taki marketingowy landing page, na który był drivowany ruch.

  W ten sposób, mając wszystkie te elementy, byliśmy w stanie zebrać bardzo obszerny feedback do zbudowanego MVP i zdecydować o tym, czy dalej rozwijać ten produkt. Co ważne jest to produkt SaaS-owy, za który płaci się subskrypcję, więc bardzo ważnym czynnikiem była w tym wypadku retencja i sprawdzanie wskaźnika churn — ilu użytkowników rezygnuje, a ilu użytkowników zostaje.

  Mówię o wskaźniku churn nawiązując do pytania, o to ile trwa budowanie MVP. Różnie, bo jeżeli nasz produkt ma, powiedzmy 3-miesięczny trial, to dopiero dostaniemy odpowiedź na nasze pytanie po tym, jak miną te 3 miesiące. Musimy więc wziąć sobie czas zbudowania produktu, zaprojektowania produktu, wdrożenia, zebrania feedbacku i dopiero w danych finansowych zobaczymy, w którą stronę iść.

  W tym wypadku projekt od takiej analizy biznesowej i researchów, do wdrożenia takiego naprawdę skromnego onboardingu i pierwszego dashboardu to było około 6 miesięcy, więc w tym wypadku to było szybciej niż Deliver In Person. Musimy jednak pamiętać, że tam był już gotowy ekosystem, ci użytkownicy już byli. Trzeba było tylko ich zachęcić do tego, żeby weszli na ten nowy produkt i kliknęli START, mówiąc już tak bardzo obrazowo. Mieliśmy całą bazę, do której uderzaliśmy, więc ten marketing był o wiele prostszy.

  Niemniej jednak bardzo ciekawe było przeglądanie feedbacku użytkowników. Jedno z pytań brzmiało: Dlaczego jeszcze nie nie skorzystałeś z usługi? Było to zapięte na landing page’u i jedna z odpowiedzi brzmiała: bo jest za drogo. Tam nie było jeszcze cennika, więc od razu byłam w stanie dowiedzieć się, że jedną z obaw użytkowników przed dołączeniem, jest obawa o cenę i obawa o to, że prawdopodobnie ta usługa będzie droga. To są rzeczy, których dowiadujemy się dzięki temu, że w projekcie uczestniczy projektant user experience, który pomaga nam nie tylko zbudować produkt, ale też go zmierzyć i zebrać feedback.

  Radek: I też przełożyć na rozwiązania to, co mówią użytkownicy, bo w tym wypadku ta odpowiedź została z interpretowana jako obawa, którą można zaadresować w produkcie, designie czy też komunikacji.

  Jak uświadomić klientowi co jest ważne?

  Radek: Porozmawiajmy trochę o wilku w owczej skórze. Zdarza się, że ktoś przychodzi i mówi, zrobimy MVP. A przychodzi tak naprawdę z waterfollowym podejściem. Mam wrażenie, że to jest bardzo częsta sytuacja, że bardzo dużo osób nie wie, co to znaczy MVP. I są takie sytuacje, gdzie się realizuje projekty, które rzeczywiście mają zapięte budżety, szczególnie te, które są z przetargów, wynikają z jakichś dofinansowań. I pytanie do ciebie, jak zarządzić takim projektem? Czy ty masz jakieś odpowiedzi na to?

  Ilona: Wiesz, co to jest bardzo trudne, bo, ciężko jest przestawić myślenie kogoś z tego, że robi MVP na to, że jego oczekiwaniem jest realny produkt. Jeszcze gorzej jest w momencie, kiedy my naprawdę zaczęliśmy robić MVP, ale w trakcie są dokładane funkcjonalności. To jest taki niekończący się projekt, gdzie miało być MVP, ale jeszcze zróbmy to, a jeszcze zróbmy tamto i w końcu po roku budzisz się i się okazało, że byłeś w projekcie waterfallowym. To jest bardzo trudne. Myślę, że warto, żebyśmy my jako UX designerzy myśleli krytycznie i zadawali pytania: Po co? Po co to robimy? Jaką to wartość przyniesie? Ile to będzie trwało?

  Radek: Jaką to wartość przyniesie użytkownikowi? Czy użytkownicy rzeczywiście będą tego chcieli? Czy rzeczywiście to jest to, co buduje wartość tego produktu?

  Ja przypominam sobie taką sytuację, kiedy robiłem projekt bardzo mocno związany z innowacją i technologią. Dotyczył on urządzenia, tak bardzo ogólnikowo mogę powiedzieć o nim. Ten projekt był finansowany z funduszy państwowych, więc miał totalnie ograniczony budżet, wymagania doprecyzowane przed samym rozpoczęciem tego projektu, ale na szczęście mieliśmy takiego bardzo fajnego ownera tego produktu, który rozumiał MVP.

  To, co my zrobiliśmy razem, to przede wszystkim taki bardzo doprecyzowany proces buy a feature z użytkownikami, żeby upewnić się w tym, że jeśli wyrzucimy coś z tej naszej listy wymagań, to jesteśmy pewni, że ten produkt dalej przyniesie tę wartość. Ja bardzo polecam proces buy a feature, bo to rzeczywiście pomaga nam się upewnić, co jest ważne. Chodzi tu nie tylko o zamknięte projekty, ale też o takie, w których klient może sobie pozwolić na totalny luz w podejściu do projektowania. To mu uzmysławia pewne rzeczy. Możemy mu wtedy powiedzieć: Słuchaj, ale klient za to nie zapłaci.

  Buy a feature

  Radek: Buy a feature to takie ćwiczenie, które wykonujemy z użytkownikiem docelowym. Na początku tworzymy listę funkcjonalności i przeznaczamy pewną pulę wirtualnych pieniędzy użytkownikom, za którą mogą kupić te funkcjonalności. Każda z tych funkcjonalności ma swoją cenę. Czasami różnicuje się te ceny. Jeśli coś jest ekstra to warto, żeby miało to wyższą cenę. Zwłaszcza jeśli już coś wiemy na temat tych funkcjonalność. Wiemy, że one są jakimś prawdziwym dodatkiem, jakimś pegazem na tej liście. Przez tę symulację, trochę jak w prawdziwym życiu, użytkownicy muszą odpowiedzialnie podjąć decyzję, za co chcą zapłacić. To jest bardzo silnym i twardym argumentem dla właściciela produktu, że rzeczywiście, nie są tymi funkcjonalnościami, które użytkownicy chcą.

  Ilona: Świetna technika do tego, żeby uzmysłowić klientowi, co tak naprawdę jest ważne, bo ja też rozumiem to, że w trakcie projektowania i w trakcie trwania procesu projektowania może to się trochę zagubić.

  Rola projektanta w projekcie

  Teraz ci przypomnę nasz projekt. Kiedy my robimy coś dla siebie, naszą stronę, czy jakieś materiały i w pewnym momencie już tak długo na to patrzymy, że już nie widzimy niektórych rzeczy. Więc fajna jest ta perspektywa i dobrze, że projektanci UX są w takim procesie i wspierają klienta, wspierają właściciela produktu, żeby złapać tę perspektywę z boku. Dla mnie w procesie budowania MVP projektanci są mostem między klientem, który za to płaci, product ownerem, a właśnie tym użytkownikiem, który będzie korzystał z produktu.

  Radek: Pokazałem właśnie przykład narzędzia. My mamy narzędzia i jedną rzeczą są narzędzia, które są gotowe do wzięcia, a drugą rzeczą jest to, że my tak samo, jak możemy projektować rozwiązania, możemy tez projektować narzędzia, możemy projektować miary, którymi potem mierzymy sukces.

  Wracając jeszcze do tego wilka w owczej skórze, czyli do projektów, które nie są MVP, a są po prostu wielkimi, kompleksowymi produktami. Takie procesy jak buy a feature pomagają pokazać klientowi, że może nie potrzebujemy tego wszystkiego. Pomagają trochę klientowi czy też ownerowi, zdjąć z siebie odpowiedzialność, bo czasami wydaje mi się, że to jest też taka obawa, że jak nie zrobimy tego wszystkiego, to produkt nie odniesie sukcesu. To pomaga zdjąć taką obawę, że jeśli nie napchamy tego wszystkimi funkcjonalnościami, to to będzie klęska.

  Ilona: Badania są przede wszystkim po to, żeby zminimalizować ryzyko.  Tak samo, jak robimy analizy finansowe czy analizy rynku, żeby dowiedzieć się, zebrać informacje, tak samo badania służą nam do tego, żeby zebrać informacje.

  Myślę, że kolejną rzeczą, którą warto wspomnieć, to jest też perspektywa, którą dajemy founderowi czy product ownerowi. Nawiązując do tego, co powiedziałeś, mamy nie tylko warsztaty buy a feature.  Na przykład w trakcie przygotowywania i projektowania MVP, jednym z elementów może być przeprowadzenie wywiadów IDI. To są takie wywiady z użytkownikiem face 2 face i one właśnie są w tej metodzie jakościowej.

  Tutaj dużą pułapką jest to, że jeżeli osoby z firmy związanej z produktem, same chciałaby takie badania przeprowadzić, to tutaj dużą pułapką jest brak obiektywizmu i naprowadzanie użytkowników na taką odpowiedź, jaką chcemy uzyskać. Jest to dużym zagrożeniem w przypadku MVP, bo tak jak sobie powiedzieliśmy na początku, robimy to po to, żeby potwierdzić czy idziemy w dobrym kierunku. Jeżeli będziemy trochę mitygować to dochodzenie czy idziemy w dobrym kierunku, właśnie pod postacią tendencyjnych pytań, to tak naprawdę to nasze MVP może odnieść klęskę.

  Kolejna rzecz, która dla mnie jest super ważna w kontekście tego, o czym rozmawiamy, to jest wizualizacja. Poruszyłeś ten temat w przypadku POC, gdzie robimy makietę, robimy jakiś flow, pokazujemy temu klientowi ostatecznemu, jak mogłoby to wyglądać i na tej podstawie zbieramy feedback. Tak samo jest w przypadku MVP. Czyli to nasze MVP, o ile nie jest produktem backendowym, chociaż i w takim wypadku warto jest zrobić landing page, to klient, ten końcowy użytkownik, ma to zwizualizowane i wie, o co chodzi. Nie, używamy tylko opisu słownego, tak jak w tej pierwszej części, tylko faktycznie mamy już całe to doświadczenie narysowane. Mamy też odpowiednią komunikację i tutaj rolą projektantów jest to, żeby pomóc wydobyć te właśnie najważniejsze funkcjonalności i pokazać je w odpowiedni sposób. Tak to zaprojektować, żeby było widać, co jest ważne. Żeby użytkownik wiedział jakie akcje powinien wykonywać. Sukcesem MVP, to, że na koniec dnia powiemy, że to jest sukces, też świadczy o tym, czy ten produkt, ta minimalna propozycja wartości będzie użyteczna.

  Kiedy MVP jest sukcesem?

  Radek: Czy sukcesem jest to, że rzeczywiście ten produkt, to MVP będzie przydatne? Czy to, że się w ogóle czegoś dowiemy?

  Ilona: Przede wszystkim zebranie informacji i odpowiedzenie na pytania, które sobie postawiliśmy na samym początku. Masz rację, trochę mnie złapałeś ze słówko, bo trochę pomyślałam o Happy Path, że robimy i od razu nam się udaje, a nie zawsze może tak być.

  Radek: Czasami Happy Path jest taka, że wcześniej dowiemy się, że coś nie działa i możemy zareagować, zanim wydamy masę kasy i stracimy dużo czasu.

  Ilona: Tak więc też kluczowe w budowaniu MVP jest testowanie.

  Radek: Myślę, że warto jeszcze powiedzieć o tym, że MVP wzięło się ze świata produktów cyfrowych, ale podejście MVP, podobnie zresztą jak podejście design thinking czy user-centered design, to są takie rzeczy, które są adaptowalne wszędzie.

  Powiedziałaś, że MVP również można używać w kontekście produktów namacalnych, takich, które można kupić w sklepie: urządzeń, produktów spożywczych. Ja właśnie miałem okazję projektować taki produkt spożywczy. To był mój dyplom, robiłem wegańskie jajko i jak sobie możesz wyobrazić, pomysłów na to wegańskie jajko miałem mnóstwo. W ogóle na cały brand, który się nazywał Alter Egg. Uważam, że to jest świetna nazwa. Wegańskie jajko, roślinne jajko ii ja miałem bardzo dużo pomysłów na ten produkt. Robiłem masę prototypów, między innymi była to jajecznica. Wymyślałem jakieś jajka, które miały się wylewać niczym takie jajko płynne. Na bazie badań i rozmów z użytkownikami uznałem, że najlepszym pomysłem była taka sypka forma jajka — proszku, do którego można dodać wody i użyć na przykład do wypieków i upiec ciasto bez użycia prawdziwego jajka.

  Pomysł na cały brand zawierał w sobie płynne jajko, jajko, jajecznicę, jajko na twardo… Pomysłów była masa i ja pitchowałem dwa razy ten pomysł. Pitchowałem z moim MVP, czyli tym proszkiem. Nie pokazywałem całego produktu. Podjąłem decyzję, że ja nie będę robić tych innych rzeczy, bo po prostu nie mam na to czasu, nie mam pieniędzy. To mi pozwoliło przejść dalej, byłem na rozmowach z inwestorami. To, co mnie zatrzymało to po prostu moja osobista decyzja, że ja nie chcę tego teraz robić, bo jestem w innym miejscu.

  Natomiast poznałem dużo osób, które właśnie działały w tym świecie, w tej branży i przynosiły takie MVP. Na przykład poznałem dziewczynę, która robiła wyroby z sezamu i ona też miała pomysł na całą gamę produktów — batoniki, sezamki (choć to już istnieje)… Jej propozycja wartości była taka, że to wszystko było bio. To wszystko było takie bardzo zdrowe i ona wyszła z kremami sezamowymi. To było coś, co ona mogła zrobić w domu, coś, co mogła zrobić szybko, przetestować z użytkownikami i prawdopodobnie było to coś, co wypełniało pewną lukę. To też są MVP. To wszystko są MVP i myślę, że warto, myśleć o MVP na zasadzie, że to jest pewna uniwersalna zasada, uniwersalny proces, który można zaaplikować wszędzie.

  Podsumowanie

  Dlaczego my tutaj dzisiaj dyskutujemy? Dlaczego w ogóle taki pomysł tego tematu? Ponieważ warto myśleć o MVP w kontekście współpracy z projektantami, ponieważ my jako projektanci jesteśmy najbliżej użytkownika i my jesteśmy w stanie wyłapać, co jest tą minimalną wartością dla użytkownika. Zanim biznes poświęci pieniądze. Zanim technologia zmarnuje czas na development i zbudujemy coś, czego tak naprawdę użytkownicy nie chcą.

  Dziękuję bardzo. Do usłyszenia w następnym odcinku.

Do usłyszenia!

Radek & Ilona

Subscribe for weekly dose of inspiration