Wszyscy niejednokrotnie słyszeliśmy te wymówki: Szkoda czasu, deadline nas goni, zróbmy to w MVP i poprawimy później.I co? Wypuszczamy na produkcję, marketing i biznes zadowolone, raz-dwa i problem z głowy. Możemy zabrać się za kolejny projekt. Ale czy na pewno?

Szczerze mówiąc (chociaż z perspektywy czasu wstyd się przyznać), sam niejednokrotnie wpadałem w pułapkę takiego myślenia.  Wydaje mi się, że nie do końca rozumiałem prawdziwe znaczenie pojęcia MVP. Zbyt kuszące okazywało się też skorzystanie z jego niezwykłej mocy do zamykania zalegających na biurku spraw.

Minimum Vaiable Product

Pojęcie Minimum Viable Product (MVP), czyli Minimalnego, zdolnego do życia (funkcjonalnego) produktu, stworzył Frank Robinson w 2001 roku. Do dziś pozostaje ono jedną z najpopularniejszych technik wdrażania nowych usług i produktów przez start-up'y, a także duże firmy.

Minimum Viable Product (MVP) jest techniką wdrażania, w której nowy produkt lub strona www jest tworzona z wystarczającą ilością funkcjonalności zdolną do zaspokojenia pierwszych użytkowników. Ostateczny produkt z kompletnym zbiorem funkcjonalności jest tworzony dopiero po uwzględnieniu opinii użytkowników.

Brzmi super, prawda? Po co właściwie przeciągać wdrożenie produktu w nieskończoność, skoro i tak zawsze ktoś będzie niezadowolony (biznes, marketing, użytkownicy)? Reid Hoffman – założyciel LinkedIn'a – i inni mądrzy ludzie grzmią przecież, że: Jeżeli nie jesteś zakłopotany pierwszą wersją swojego produktu, znaczy że wdrożyłeś go za późno!

Faktycznie, w branży usług innowacyjnych, ale również coraz częściej w e-commerce, istnieje przekonanie, że zacofanie lub stagnacja technologiczna przynoszą straty. Słyszymy, że bardzo łatwo przegapić szansę na rozwój i przyciągnięcie nowych klientów, kiedy masowo powstające start-up’y  odnoszą tak spektakularne sukcesy. Trzeba utrzymać ich tempo, a przecież lepiej średnio niż w ogóle, prawda?

Niestety, w wielu przypadkach takie rozumowanie nie przynosi oczekiwanych efektów. Stworzony produkt nie wzbudza większego zainteresowania użytkowników lub obserwujemy tendencję spadkową. Wreszcie dochodzimy do wniosku, że nie warto go dalej rozwijać. Usprawiedliwienie jest proste: cóż, takie jest ryzyko start-up'owego podejścia.

Z perspektywy moich doświadczeń, jak również „historii porażek” (nie tylko na polskim rynku), można dojść do wniosku, że śmierć produktów realizowanych w MVP wynika z trzech zasadniczych powodów:

Błędne rozumowanie

Pierwszą z przyczyn jest nie tyle błędne rozumienie pojęcia MVP, co samego kontekstu jego powstania. Minimum Viable Product, jak również ustalenie wizji produktu (Product Vision), są ściśle powiązane z metodologią Scrum Agile. Oznacza to, że stosujemy je tylko wówczas, gdy jesteśmy pewni i mamy zasoby na długotrwałe i systematyczne doskonalenie naszej usługi.

MVP ma miejsce głównie na samym początku kreowania koncepcji, kiedy chcemy przetestować zainteresowanie publiczności i zebrać dane do wykonania następnych kroków. Jest to nic innego jak eksperyment.

Technika ta z oczywistych przyczyn nie sprawdzi się w przypadku „doraźnych” landing page'y lub pojedynczych usług, gdyż jedyne co otrzymamy, to wątpliwej jakości produkt.

Biznes, pieniądze, KPIny...

Każdy produkt ma swoje założenia, cele i osobę odpowiedzialną za ich wdrożenie. Mowa tu o Product Ownerzei tak zwanym back logu, czyli liście zadań i funkcji oczekujących na wdrożenie. W perspektywie realizacji narzuconych z góry KPI'ów bardzo często zapomina się, że zysk ze sprzedaży jest ściśle i proporcjonalnie związany z zadowoleniem naszych użytkowników i zaspokojeniem ich potrzeb.

Niestety zdarza się, że celów biznesowych jest więcej i mają wyższy priorytet niż potrzeby i zadowolenie klientów. W efekcie dostarczamy produkt zaspokajający potrzeby wyłącznie stakeholderów, a nie użytkowników. Bardzo ciekawym przykładem tego zjawiska jest poniższa grafika:

Grafika: Henrik Kniberg.

Zlećmy to na zewnątrz...

Trzecim i najważniejszym powodem porażki przy zastosowaniu MVP jest niewystarczające testowanie lub jego brak. To naprawdę zadziwiające jest, jak niewiele firm przeprowadza wewnętrzne badania z użytkownikami.

Najczęściej przyczynami nie-testowania są braki zasobów, czasu, pieniędzy, a także kompetencji w zespołach do przeprowadzenia takich badań. Popularną praktyką jest zlecanie testów użyteczności firmom zewnętrznym, co niesie za sobą ryzyko złego doboru metody testów albo przedstawienia ich wyników w postaci nieczytelnej prezentacji w Power Poincie.

Pamiętajmy jednak, że badania użyteczności zlecane na zewnątrz, jak również focusy i testy A/B przeprowadzane na etapie wstępnego kreowania usługi są niewymierne. Z prezentacji lub tabelki niewiele dowiemy się o tym, jak użytkownicy w rzeczywistości korzystają z naszego MVP, jaki jest kontekst ich działań, czego od niego oczekują i jakie motywacje i emocje im towarzyszą przy korzystaniu z naszej usługi. Takie wnioski wyciągniemy jedynie w trakcie obserwacji.