Zdjęcie główne artykułu pochodzi z picjumbo.com
Wprowadzenie. Kto, co, po co, dlaczego?
O metodzie Lean Startup napisano bardzo wiele. Jej autor, kalifornijski biznesmen, wykładowca i bloger Eric Ries, uważany jest powszechnie za jednego z najważniejszych “praktykujących” teoretyków biznesowych młodego pokolenia (“praktykujących” — tj. faktycznie odnoszących sukcesy w biznesie). Choć na chwilę obecną zajmuje się on — oprócz prowadzenia szeroko zakrojonej działalności inwestycyjnej — głównie doradztwem biznesowym, w przeszłości (współ)prowadził m.in. firmę IMVU, której produkt w krótkim czasie stał się jednym z najbardziej popularnych i najbardziej dochodowych tzw. wirtualnych światów; poznał również smak biznesowej porażki, kiedy w wyniku pęknięcia bańki internetowej upadł jego pierwszy startup, There, Inc.
Doświadczenia te — oraz wiedzę o biznesie — zebrał i przedstawił w książce pt. „Metoda Lean Startup. Wykorzystaj innowacyjne narzędzia i stwórz biznes, który odniesie sukces”. Pozycja ta bardzo szybko trafiła na listy największych bestsellerów. Stała się też jednym z podstawowych punktów odniesienia dla przedsiębiorców działających w Dolinie Krzemowej. Na chwilę obecną zyskuje też coraz większą popularność w Europie (głównie w Niemczech i Wielkiej Brytanii, gdzie startupowe ekosystemy są szczególnie dobrze rozwinięte). O jednej z pierwszych polskich implementacji pisałem zaś wcześniej w tym krótkim case study.
Lean Startup: metoda prowadzenia biznesu? A może… eksperymentów?
O początkach i założeniach metody Lean Startup pisałem wcześniej bardzo obszernie w tym artykule; tu chciałbym skupić się na najważniejszym z jej aspektów. Kluczem do właściwego zrozumienia metody Riesa jest zrozumienie, czym jest MVP (skrót od angielskiego minimum viable product — produkt o minimalnej funkcjonalności, choć zarówno w samej książce, jak i w prasie pojawiają się czasem też inne przekłady tego terminu).
Jak sama nazwa wskazuje, MVP jest produktem. Tym, co różni MVP od innego rodzaju produktów, jest — po pierwsze — stopień jego dopracowania i gotowości do dystrybucji, po drugie zaś — jego przeznaczenie. Jeśli chodzi o to pierwsze, to — jak sama nazwa wskazuje — MVP przeważnie są produktami bardzo niedopracowanymi. Sam Ries pisze, że zdarzało mu się oferować klientom produkty, których instalacja — bo chodziło o program komputerowy — mogłaby grozić awarią ich komputerów. Ogólnie rzecz biorąc: chodzi o produkt, nad którym wciąż trwają prace, produkt, który w każdym innym wypadku określilibyśmy mianem wersji beta (albo nawet alfa). Produkt o minimalnej funkcjonalności.
W metodzie Lean Startup nie chodzi jednak o to, by sprzedawać niedorobione produkty. Cel jest inny: jest nim… eksperymentowanie. Prowadzenie eksperymentów — na naszych klientach. I to — ni mniej, ni więcej — właśnie za pomocą naszego produktu. Nasz produkt o minimalnej funkcjonalności staje się tutaj eksperymentem, środkiem do celu (gdzie celem jest rozpoznanie potrzeb klientów).
Jak bezpiecznie eksperymentować na swoich klientach? Jest to dość skomplikowane. Podstawy jednak są dość proste. Chodzi o wypuszczenie produktu z jednoczesnym zapewnieniem sobie dostępu do informacji zwrotnej (w postaci innej niż postać feedbacku — ten w metodzie Lean Startup się bowiem nie sprawdzi!). O informację tego rodzaju najłatwiej — ma się rozumieć — w branży usług i IT: to właśnie dlatego metoda Lean Startup jest tak popularna w Dolinie Krzemowej. Upewniwszy się, że mamy do nich dostęp, możemy przejść do eksperymentów: wdrażania kolejnych wersji naszego produktu i próbkowania reakcji klientów.
Tworzenie-pomiar-uczenie się
W metodzie Lean Startup nie chodzi — naturalnie — o prowadzenie eksperymentów w ciemno, bez planu. Plan, i owszem, musi być. Musi on jednocześnie wpisywać się w szerszy framework, określany przez Riesa mianem pętli tworzenie-pomiar-uczenie się.
Choć brzmi to dość technicznie, ten akurat aspekt LS nie jest zbyt skomplikowany. W praktyce chodzi tu o postępowanie w myśl schematu:
1. Tworzymy produkt o minimalnej funkcjonalności i udostępniamy go klientom.
2. Prowadzimy pomiar: sprawdzamy reakcje klientów na produkt. Jeżeli jest to program komputerowy, usługa — lub program oferowany na zasadach usługi (w tzw. modelu SaaS: Software as a Service) — to nie powinniśmy mieć żadnych problemów z dostępem do informacji o tym, co nasi klienci robią z produktem: które funkcje się sprawdzają, które nie, które są ignorowane, które wykorzystywane są w jakiej kolejności, itp. itd. Są to kluczowe informacje, pozwalają nam one bowiem zrozumieć, w jaki sposób klient rzeczywiście korzysta z naszego produktu.
3. Uczymy się. Zdobyte wcześniej dane poddajemy interpretacji — tak zdobyte wnioski mogą stanowić dla nas wskazówkę, co w danym produkcie powinniśmy zmienić, zmodyfikować, poprawić.
4. Wprowadzamy do produktu poprawki. Pętla się zamyka — w istocie znów jesteśmy w punkcie pierwszym, tworzymy.
5. Wypuszczamy kolejną wersję naszego MVP.
Postępowanie w ten sposób nie tylko pozwoli nam szybko dopracować nasz niedopracowany wcześniej produkt, ale, co ważniejsze — co, być może, najważniejsze — dopracować go w odniesieniu do potrzeb klientów. Jak pisze Ries, zmiany możemy wprowadzać nawet kilka(dziesiąt) razy dziennie; pracując w IMVU, sam postępował on w ten sposób. Dodatkowo możemy też udostępniać różnym grupom klientów różne wersje tego samego produktu. To pozwoli nam sprawdzić, która wersja sprawdza się lepiej — testujemy w ten sposób przydatność i popularność alternatywnych rozwiązań.
Postępując w myśl tej zasady, powinniśmy zwrócić uwagę na przynajmniej parę istotnych kwestii, wśród nich zaś — następujące:
1. Przy testowaniu MVP bardzo duże znaczenie ma zastosowana przez nas metoda pomiaru. W zależności od produktu i branży, metoda ta będzie się, co oczywiste, różnić; to mówiąc, musimy dobrać tę odpowiednią. W przeciwnym wypadku skończymy z dużą ilością niezinterpretowanych danych, które do niczego nie będą nam potrzebne.
2. Tzw. interpretowalność danych też ma znaczenie. Zebrawszy dane, musimy mieć możliwość przełożenia ich na język wniosków, te zaś — na język procesu produkcyjnego. Chodzi wszak o to, by przekazać pracującym nad produktem osobom, co mają w nim zmienić. Informacje muszą być więc możliwie zwięzłe i precyzyjne.
3. Nie wszystkie ze zgromadzonych przez nas danych są nam potrzebne. Załóżmy, że prowadzimy internetowy serwis Video-On-Demand (coś podobnego do Netflixa). Choć obserwowanie rosnącej ilości fanów w mediach społecznościowych może sprawiać nam przyjemność, prawdziwą miarą naszego sukcesu będzie czas, jaki spędzają nasi klienci, oglądając udostępniane przez nas na stronie treści. (Mówiąc zaś o social mediach: miarą sukcesu naszych socialmediowych kanałów komunikacji też będzie raczej konwersja wejść na fanpejdż na wejścia na stronę — nie ilość “polubień”.)
4. Nie wszystkie dane wolno nam gromadzić.
5. Chociaż nie musimy informować naszego klienta o szczegółach naszych działań, musimy umieścić w umowie informację o tym, że produkt, który oferujemy, przesyła do nas informację zwrotną. (Serwisy www stanowią tu przeważnie wyjątek.)
6. Musimy pamiętać, iż naszych eksperymentów nie prowadzimy w warunkach izolowanych. Na działania klientów mogą mieć więc wpływ czynniki niezwiązane z naszym produktem. Trzeba założyć tu odpowiedni margines błędu — i nie działać pochopnie!
Nie tylko dla startupów
Metoda Lean Startup nie jest, wbrew nazwie, propozycją wyłącznie dla startupowców. Implementować może ją każdy, kto chce wprowadzić na rynek nowy produkt bądź usługę. Wśród firm, które postępowały w ten sposób, znajdują się również giganci rynku (choć trudno powiedzieć, jak wiele z nich wdrażało założenia Riesa w pełni świadomie). To mówiąc, najlepsze efekty zastosowania rozwiązań Riesa widać w małych przedsiębiorstwach i startupach. Dlaczego?
Jest tak z kilku powodów. Po pierwsze: ponieważ metoda ta opracowana została z myślą o minimalizacji ryzyka porażki produktu. Choć wypuszczając gotowy produkt po dwóch latach prac, możemy mieć pewność, iż to, co oddajemy klientom, jest dobre, nigdy nie będziemy mieć pewności, czy sami klienci zechcą to kupić. Zarazem — narażeni jesteśmy na poważne problemy związane z płynnością finansową. Jeżeli większość naszych środków przeznaczyliśmy na prace produktowe i działania promocyjne, to jeśli klienci pomimo tego nie zechcą kupić naszego produktu, jesteśmy skazani: w większości wypadków nie będzie nas bowiem stać na dalsze prace, wprowadzanie kolejnych modyfikacji, powtórną premierę, kolejną promocję. Wypuszczając MVP — i żądając za nasz produkt pełnej ceny! — możemy dać sobie więcej czasu. Zwiększa się nasza płynność finansowa (bo produkt zarabia). Zdobywamy pierwszych klientów. Jednocześnie zaś dostosowujemy to, co sprzedajemy, do potrzeb kolejnych. Jeżeli nawet nasz produkt nie zdobędzie popularności, jakiej potrzebuje, wciąż możemy go poprawiać, tak długo, jak długo będzie trzeba — w razie konieczności możemy zaś wycofać się z całego przedsięwzięcia i spróbować czegoś innego.
Oddanie klientom MVP daje nam też możliwość podjęcia interesujących działań marketingowych, mających na celu zbudowanie wokół naszego produktu społeczności użytkowników. Choć działanie w myśl metody Riesa nie stoi w zasadniczej sprzeczności z żadnymi działaniami marketingowymi, są takie, które czyni dużo skuteczniejszymi. Są to przeważnie działania związane z budowaniem bardziej bezpośredniej, partnerskiej relacji z klientami, którzy mają poczucie, że ostateczny kształt produktu zależeć będzie również od nich (choć, co ważne, niekoniecznie od tego, co nam o nim powiedzą!). Relacje takie preferuje również wiele (o ile nie większość) startupów — nie wspominając o małych przedsiębiorstwach.
Nie zapominajmy też, iż zaproponowany przez Riesa specyficznie startupowy modus operandi polegający na próbkowaniu rynku za pomocą produktu jest czymś, co mali przedsiębiorcy implementują — w tej czy innej postaci — od lat. W tym sensie metoda Lean Startup stanowi po prostu teoretyczne opracowanie tych działań. A choć, jak pokazuje historia niektórych naprawdę wielkich przedsiębiorstw, teoria dość często rozmija się w biznesie z praktyką, to wiedza teoretyczna zawsze jest wartościowa. Nawet jeśli znajomość teorii Riesa nie zmieni niczego w sposobie, w jaki dotychczas prowadziliśmy naszą działalność, może rzucić nowe światło na to, dlaczego zdecydowaliśmy się w ten sposób działać. Głębsze zrozumienie powodów naszych nierzadko intuicyjnych i ryzykownych decyzji pozwoli nam zminimalizować ryzyko w przyszłości — i podejmować kolejne działania już bardziej świadomie.
Przykładowe MVP, które odniosły sukces, to, m.in.: Airbnb; Facebook (choć zasadniczo jest bezpłatny, niektóre z jego funkcji, takie jak promowanie postów, dostępne są tylko odpłatnie; to kwalifikuje go jako MVP); Google (chodzi o przeglądarkę — pozostałe z usług Google są sporne); Minecraft (modelowe MVP); Spotify (produkty oferowane na zasadzie tzw. freemium także mogą być MVP); Uber (przykład MVP na pograniczu branży IT oraz usług). Takie przykłady można by mnożyć. MVP jest coraz więcej.
Jeśli idzie o Polskę, to MVP, które odniosło największy sukces, oferuje, jak sądzę, LiveChat. Spośród najnowszych MVP warto natomiast wspomnieć o Spontime — zaprojektowanej przez Karolinę Demiańczuk mobilnej aplikacji, która szturmem zdobywa rynek, zarówno polski, jak i zagraniczny.
MVP a wersja beta — podobieństwa i różnice
Co tak właściwie różni MVP od wersji beta produktu? Różnic jest kilka (tak jak zresztą i podobieństw). Ponieważ zagadnienie to dość często budzi kontrowersje, poniżej wzmiankuję kilka najważniejszych różnic — te, na które zwraca się uwagę najczęściej.
1. MVP oferowane jest jako gotowy, pełnoprawny, ukończony produkt. Tymczasem betę oferujemy jako betę, wprost mówiąc testerom, iż nie mają do czynienia z wersją ostateczną. (Choć w praktyce nic nie stoi na przeszkodzie, by zakomunikować klientowi, że ma do czynienia z MVP, produktem, nad którym wciąż trwają prace, w większości wypadków się tego nie robi.)
2. Sprzedając MVP, żądamy za nie pełnej ceny. Bety przeważnie nie sprzedajemy w ogóle: częściej płacimy ludziom, by ją dla nas testowali. W rzadszych przypadkach, kiedy dostęp do bety jest płatny, cena przeważnie jest wyższa od ceny końcowej produktu.
3. MVP aktualizujemy bardzo często. Prawie codziennie wprowadzamy jakieś poprawki. Betę oddajemy klientom w postaci, w jakiej mają ją testować, nie zmieniając nic na bieżąco — dopiero po okresie testów zbieramy informację zwrotną, usuwamy błędy i poprawiamy produkt.
4. Jeżeli oddajemy klientom MVP, to robimy to, ponieważ chcemy, żeby produkt powiedział nam coś o nich. Jeżeli oddajemy im betę, to chcemy, by to oni powiedzieli nam coś o produkcie.
5. W przypadku bety istotny jest feedback. Testując MVP, nie musimy zwracać uwagi na informację zwrotną o tej postaci — mamy bowiem dostęp do innych, mniej problemowych źródeł.
6. Każda kolejna wersja MVP może być tą ostatnią. Podobnie: każda kolejna aktualizacja. Wersja beta natomiast z definicji nigdy nie jest wersją ostateczną.
7. Beta przeważnie jest bardziej dopracowana od wczesnych wersji MVP (i dużo mniej dopracowana od wersji późniejszych).
8. Ostateczna wersja MVP może w niczym nie przypominać tej pierwszej. Ukończona wersja normalnego produktu przeważnie zachowuje natomiast wiele podobieństw do wersji beta.
Podsumowanie
Choć nie ma w biznesie “metody na sukces”, jest wiele metod zmniejszania ryzyka. A chociaż żadna z nich nie jest metodą niezawodną — działalność biznesowa niejako z samej swojej definicji wiąże się z ryzykiem — niektóre metody są lepsze od innych. Metoda Lean Startup jest jedną z najnowszych i najbardziej nowatorskich odpowiedzi na zmiany, które zaszły na rynku od 2001 roku; od metod konkurencyjnych różni się m.in. tym, że rozwiązuje problemy, które tamte pomijają (lub których nie rozpoznają jako problemów). Działanie w dynamicznych warunkach rynkowych XXI wieku wymaga od przedsiębiorców elastyczności i otwartości na eksperymenty; choć dotarcie do klientów na pozór stało się łatwiejsze, w istocie jest trudniejsze — przez wzgląd na wzrost konkurencji. Z tego też względu coraz więcej firm decyduje się na wypuszczanie produktów o minimalnej funkcjonalności; z czasem dopracowują one swoje MVP, czyniąc je produktami, które dominują daną branżę.
—
Przemysław Wierzbicki
Doktorant UŁ (historia i filozofia nauki, metodologia)
Content writer w: Elephate. Tłumacz-freelancer. In spe: pisarz (powieść – w toku). Na bieżąco z technologią. Nadto: wielki fan seriali.
