Customer Development - Przygotowanie do MVP

Autorzy: Tomasz Soroka

05.07.2016

W poprzednim tygodniu udało nam się zweryfikować nasz pomysł na biznes i doprecyzować jego założenia. Użytkownikiem naszego portalu będą osoby prywatne szukające nieruchomości do kupna lub sprzedaży. Klientem, który będzie nam płacił będą biura nieruchomości, którym zaoferujemy możliwość hurtowego umieszczania ofert na portalu. Nadszedł teraz moment na to, abyśmy zajęli się tworzeniem wersji startowej naszego produktu.

Na tym etapie największe wyzwanie z jakim się spotykamy to określenie jakie funkcjonalności powinna zawierać pierwsza wersja naszego produktu. Na tym etapie najczęściej przyjmujemy jedno z dwóch podejść:

- upubliczniamy projekt jak najczęściej, gdy tylko możemy coś pokazać. Przy każdej kolejnej porcji funkcjonalności uaktualniamy nasz produkt (podejście to nazywane jest ‘realease early – release often’),

- rozbudowujemy projekt bardzo mocno, wierząc w to, że zbyt okrojony produkt może zrazić potencjalnych klientów i zniweczyć naszą szansę na sukces – prowadzi to najczęściej do tego, że publikacja produktu bardzo się opóźnia, a ilość funkcjonalności które powstały znacznie wykracza ponad to co konieczne.

Obydwa podejścia nie są idealne – albo publikujemy za mało, albo za dużo.

 

Metodyki Lean Startup i Customer Development uczą nas jak najlepiej przygotować wersję 1.0 naszego produktu. Jednym z podstawowych założeń jest to, że uczymy się od klientów najwięcej po jego publikacji – powinniśmy dążyć do tego, aby opublikować nasz produkt tak wcześnie jak się da. Z drugiej strony, aby móc uczyć się od klientów (i co najważniejsze testować sprzedaż) powinniśmy zaoferować im funkcjonalności za które będą chcieli zapłacić.

 

Aby odpowiednio wybrać funkcjonalności do wersji 1.0 (Minimal Viable Product – MVP) powinniśmy:

  1. Skupić się na funkcjonalnościach które rozwiązują założone przez nas problemy (poczynając od problemu numer 1)
  2. Zrezygnować z funkcjonalności które klienci określają jako przydatne i niepotrzebne – naszym celem powinno być zrealizowanie funkcjonalności, które klienci określili jako wymagane
  3. Zastanowić się,które z dodatkowych funkcjonalności sugerowanych przez klientów powinny zostać zrealizowane – i czy koniecznie powinny być zrealizowane od razu?.

 

Musimy pamiętać o tym, że naszym celem jest przygotowanie produktu, za który klienci będą chcieli zapłacić – tylko w ten sposób możemy sprawdzić ostatecznie nasze poziomy cen.

 

Powinniśmy zastanowić się też na tym, w jaki sposób będziemy monitorować zachowanie naszych klientów – zaraz po uruchomieniu produktu bardzo ważne dla nas będzie monitorowanie, np.: ilu klientów zainteresowało się naszym projektem, ilu z nich ściągneło plik instalacyjny, ilu z nich się zarejestrowało, ilu kupiło nasze rozwiązanie. Dodatkowo dobrze by było udostępnić naszym klientom łatwą możliwość zgłaszania uwag do projektu (np. formularz kontaktowy w aplikacji).

 

Ważne jest bardzo, aby na każdym etapie przygotowania wersji 1.0 minimalizować potencjalne straty. Należy się zastanowić, czy np. optymalizacja działania skryptu na chwilę obecną jest nam potrzebna? Raczej wątpliwe jest, żeby na samym początku nasz projekt miał problemy wydajnościowe (oczywiście nie należy tutaj popadać w skrajność w drugą stronę).

Przypomnijmy sobie Lean Canvas, który zakończył poprzedni artykuł:





Rozwiązanie problemów, na które zwrócili uwagę „early adopters” to:

 

  • strona WWW z ofertami sprzedaży nieruchomości
  • wyszukiwarka pozwalająca odnaleźć właściwą nieruchomość
  • możliwość publikacji zdjęć danej nieruchomości
  • stworzenie eksporterów ofert z najpopularniejszych programów dla agencji nieruchomości

 

Nasze rozwiązanie ma być komplementarną odpowiedzią na problemy, które zdefiniowaliśmy w boksie „PROBLEM”

 

Oprócz tych głównych problemów oraz rozwiązania, rozmówcy sugerowali nam także podczas spotkań kilkanaście innych problemów oraz sposobów rozwiązań. Zróbmy wszystko, aby ich w pierwszej wersji produktu nie implementować. Jeżeli problemy te są jednak dla klientów ważne, powinniśmy zastanowić się głęboko, czy w takim razie Lean Canvas nie powinien być przebudowany, tak aby je uwzględnić, gdyż może są ważniejsze od wyżej wymienionych.

  

Wracając do naszej wersji MVP – od czego zacząć budowanie rozwiązania? Według metodyki Lean Canvas, cykl powinien wyglądać następująco:

W pierwszej kolejności powinniśmy skupić się na stworzeniu makiet, które odwzorują funkcjonalności, jakie chcemy zawrzeć w MVP.

Dlaczego makiety a nie od razu programowanie? 

Makiety dadzą nam odpowiedzi na wiele pytań, które pozwolą nam jeszcze bardziej zmniejszyć ilość funkcjonalności, jakie powinniśmy zawrzeć w wersji MVP.

Na przykład:

Dla portalu nieruchomości stworzyliśmy makietę prezentacji oferty, wyszukiwarki, oraz listy wyników wyszukiwania. Użyliśmy do tego celu prawdziwych danych, tak aby makiety jak najlepiej odwzorowywały rzeczywistość.

Z makietami udaliśmy się do kilku klientów, tak aby zweryfikować założenia do MVP. Okazało się, że trafiliśmy na biura, które korzystają z różnych programów do wpisywania ofert. Pojawił się problem.

Problem dotyczy parametrów, którymi opisywana jest nieruchomość – przykładowe z nich to.

  • lokalizacja
  • opis
  • zdjęcia
  • informacje o balkonie

 

Okazało się, że programy różnie zapisują lokalizacje, które są potrzebne do odwzorowania w portalu, aby umożliwić wyszukiwanie nieruchomości. W programie X do prowadzenia biura nieruchomości ulice są przypisywane do dzielnic, w drugim Y  przypisywane są bezpośrednio do miast z pominięciem dzielnic. Dodatkowo w programie Y ulice mogą być wpisywane ręcznie co powoduje ich duplikowanie.

 

Problem pojawił się wtedy gdy, pokazaliśmy w firmie korzystającej z programu X formularz do wybierania lokalizacji, które nas interesują.

Drugi problem to parametr „informacje o balkonie” – w programie X parametr balkon jest zero-jedynkowy (tak/nie), w programie Y parametr ten jest opisywany tekstowo (brak, mały, loggia). Wiele innych parametrów również jest problematycznych, gdyż ich wartości są inaczej uwzględniane w każdym z programów.

Całe szczęście, że problem pojawił się na etapie makiet, gdy jeszcze nie ponieśliśmy wydatków na kwestie tworzenia oprogramowania.

Co zrobić? Wykonaliśmy szybkie badanie rynku i okazało się, że programu X używa 50% agencji nieruchomości, program Y używany jest przez około 10%. Należy odpowiedzieć sobie na pytanie, czy na pewno w wersji 1.0 produktu chcemy od razu móc obsłużyć 10% agencji, które używają programu Y – czy skupić się tylko na agencjach używających programu X. 

Odpowiedź nie jest prosta – CD podpowiada, żeby skupić się na użytkownikach programu X o ile koszt stworzenia mechanizmu odpowiedniego również dla Y jest duży. W naszym wypadku dokładnie tak jest, gdyż integracja ofert z obu programów wymaga wiele pracy związanej z wykonaniem silnika, który będzie potrafił uwspólniać dane ofert z obu programów. Poza tym warto zastanowić się, czy mechanizm nie musi być uniwersalny, tak aby działały z portalem także inne programy, do użytkowników których nie udało nam się dotrzeć, więc tworzenie silnika już teraz jest ryzykowne i może okazać się, że przy trzecim programie będzie trzeba go mocno przebudować.

 Silnik ten jest dużym kosztem  - przyda się w późniejszym okresie, ale nie jest krytyczny, jeżeli MVP skierujemy do agencji pracujących na programie X, który stanowi 50% rynku.

Po podjęciu decyzji o skupieniu się na agencjach pracujących na programie X powinniśmy zmodyfikować Lean Canvas – klientem nie są agencje nieruchomości, lecz agencje nieruchomości pracujące na programie X. Modyfikujemy także makiety i znowu umawiamy się na  spotkania z potencjalnymi klientami, aby dowiedzieć się, czy nasza propozycja rozwiązania jest odpowiednia.

Przygotowując się do budowy  MVP, pracujemy w pętlach:




Każda z pętli składa się ze stawiania hipotez, szukania odpowiedzi oraz pomiaru :

Podsumowując:

  • Czym jesteśmy bliżej klientów, którzy zapłacą za nasze rozwiązanie, tym ryzyko popełnienia błędu jest mniejsze.
  • Czym mniej wydamy pieniędzy do momentu, gdy zaczynamy zarabiać, tym lepiej dla nas – szanse na przetrwanie i sukces zwiększają się