ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

ONLINE I GOTOWI NA PROJEKT

O czym jest ten artykuł?

Dlaczego tworzenie Twojego wymarzonego produktu na oślep to prosta droga do knockoutu.

Czego się dowiem?

Dowiesz się czym jest MVP, jak prawidłowo je zrozumieć i stworzyć, jak testować swój produkt.

Z jakim narzędziem połączyć?

Rozpocznij od wywiadu, to genialne narzędzie na początek.

Podstawowa definicja MVP

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.

Dlaczego startupy upadają?

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.

Brak potrzeby rynkowej notowane jest jako druga najczęstsza przyczyna niepowodzenia startupów (CBinsights).

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”*

(*Czy istnieje coś bardziej irytującego, niż kamień drapiący Cię w stopę? Kto nie zechciałby zapłacić i naprawić tego problemu? Podobnie jest z produktami, za uleczenie frustracji jesteśmy w stanie zapłacić najwięcej.)

Klasycznie rozumienie Minimum Viable Product jest ZEPSUTE

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.

pojedynek-z-rynkiem-grafika

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.

knockout-gif

Startup jako organizacja skazana na porażki

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.

Porażka jest nieodłącznym elementem poszukiwań modelu biznesowego
- Podręcznik Startupu - Steve Blank & Bob Dorf
ryzyko-projektowe-ux

Jaka jest alternatywa i czym realnie jest MVP?

Ale czy jest jakaś alternatywa?

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:

ryzyko-projektu-ux-grafika

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.

czym-jest-mvp

MVP - Jak dokładnie to zrobić?

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:

mem-ux-szukanie-utworu

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.

Czy klienci wiedzą czego chcą?

Myśl o tym, żeby badać cokolwiek przed wydaniem produktu może rodzić u Ciebie parę pytań:

A czy klienci wiedzą czego chcą?. A tak w ogóle to czy Henry Ford nie powiedział “Jeśli zapytałbym ludzi czego chcą, powiedzieliby, że szybszych koni”

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ł 😉

Co konkretnie da mi badanie?

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:

  • Czy warto tworzyć produkt dokładnie w takiej formie jak zaplanowałem czy może warto dokonać lekkiego / mocniejszego pivotu*.
    (*Pivot - skręt produktu, projektu w trochę inną stronę, korygowanie swojego kierunku)
  • Czy dla któregoś z segmentów Twój produkt nie jest WYJĄTKOWO wartościowy.
  • Czy ludzie potrafią używać mojego produktu?

Czy to jest trudne? Czy muszę być badaczem / strategiem UX?

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.

Czy testowanie, pytanie i badanie to jedyna droga?

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.

Lub sprawdź metody badawcze:

AUTOR: WIERZBIAŃSKI FILIP

CEO Dragon Scale. Pasjonat Product Discovery, Leanu i inteligentnego tworzenia produktów cyfrowych.

Poradniki produktowe

Co tydzień jeden poradnik. Jego cel? Pozwolić Ci tworzyć lepsze produkty i lepiej podejmować decyzje.

Zapis do newslettera
Jeśli zamierzamy pojedynkować się z rynkiem to warto odbyć runde treningową wcześnie i szybko. Dowiedz się czym NAPRAWDĘ jest MVP.
Poradnik do techniki
Do artykułu
Jak wprowadzić produkt lub nową funkcję na rynek, jednocześnie weryfikując zapotrzebowanie? Zobacz jak robili to najlepsi.
Do artykułu
Poradnik do techniki
Co zrobić, aby wyjść z pętli "Zrobimy MVP i zobaczymy"? Poznaj 4 kroki, aby wstąpić na oświeconą drogę walidacji.
Poradnik do techniki
Do artykułu
Sprawdź jakie są konkretne różnice między pracą Product Designera oraz UXa. Spoiler: próbują oni osiągnąć inny cel.
Poradnik do techniki
Do artykułu
Wielki pojedynek narzędzi do UX/UI i makietowania. Czy Figma da radę w każdym projekcie?
Poradnik do techniki
Do artykułu
Rodzaje User Onboardingu, sposoby implementacji i wartość dla użytkownika. Pierwsze wrażenie zdecydowanie ma znaczenie ;)
Poradnik do techniki
Do artykułu
Jak zbierać i analizować informacje o konkurencji (i dlaczego jest to ważne!).
Poradnik do techniki
Do artykułu
Sprawdzone źródła i ich weryfikacja, zalety Desk Researchu oraz jak wykonać go krok po kroku.
Poradnik do techniki
Do artykułu
Do czego służy Customer Journey Map i jak wykorzystać ją w swoim projekcie.
Poradnik do techniki
Do artykułu
Piszemy jeszcze ten artykuł...
Regularnie opisujemy metody projektowe na For The User. W tym czasie, wyślemy Cię do przydatnych artykułów w innych częściach internetu: