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.

鈥淲ydam 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 鈥渒amieniem 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艂 鈥淛e艣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 - 鈥淐zy 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 鈥減o 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: