Jestem niemal pewien, że prawie wszyscy słyszeliście o koncepcji MVP. Istnieje jednak duże prawdopodobieństwo, że większość z was uważa MVP za coś wysoce teoretycznego, co rzadko znajduje praktyczne zastosowanie w prawdziwym świecie. Prawda jest jednak taka, że przykłady minimalnych wersji produktu są wszędzie wokół nas, a wiele światowej sławy produktów programistycznych zaczynało jako MVP.
Jako starszy menedżer produktu z doświadczeniem w tworzeniu MVP chcę podzielić się kilkoma historiami sukcesu, aby pokazać wam, jak cenna jest ta koncepcja, jeśli jesteście przedsiębiorcą prowadzącym mały startup.
Czym jest MVP?
Minimalny produkt nadający się do wprowadzenia na rynek jest jednym z kluczowych elementów metodologii Lean Startup tworzenia produktów autorstwa Erica Riesa.
Kluczowa idea stojąca za Lean i MVP jest taka, że startupy nieustannie upadają, a aby ograniczyć to ryzyko, należy najpierw stworzyć bardzo małą wersję produktu zawierającą jego podstawowe funkcje, sprawdzić, czy klienci jej potrzebują, i potwierdzić, że pomysł biznesowy działa, zanim rozpocznie się prace nad ostatecznym produktem.
Przyjrzyjmy się teraz historiom niektórych z najbardziej udanych przykładów MVP.
Przykład nr 1: nietypowy format tworzenia MVP przez Dropbox
Zacznijmy od platformy, której prawdopodobnie wielu z nas używa do przechowywania cyfrowych kopii ważnych dokumentów lub jako firmowej przestrzeni na wszystko, nad czym wspólnie pracuje zespół.
Przechowywanie danych w chmurze stało się integralną częścią naszego życia i obecnie jest standardem zarówno w zastosowaniach osobistych, jak i zawodowych. Nie było tak jednak w 2007 roku, kiedy Drew Houston postanowił założyć Dropbox.
Chociaż Dropbox nie był wówczas pierwszą usługą przechowywania danych w chmurze na rynku (istniały już Box i Amazon S3 oferujące taką usługę), to właśnie on zapewniał płynne doświadczenie synchronizowania plików z chmurą.
Drew opracował interesujące rozwiązanie do przechowywania danych w chmurze. Zamiast zmuszać użytkownika do ręcznego przesyłania i pobierania plików, Dropbox tworzył na komputerze folder, którego zawartość była synchronizowana z chmurą. Wystarczyło więc dodawać pliki do tego folderu lub je z niego usuwać, a resztą zajmował się Dropbox.
Dziś wydaje nam się to czymś oczywistym, ale wtedy było czymś niezwykłym.
Stworzenie tak płynnego doświadczenia oznaczało jednak, że zespół Drewa musiał opracować aplikacje komputerowe dla wielu systemów operacyjnych oraz stworzyć złożony mechanizm synchronizacji plików, który wykonywałby wszystko za użytkownika w tle.
Oznaczało to, że Drew nie mógł opracować wersji MVP Dropboxa jako aplikacji, ponieważ nawet przy najmniejszym zakresie funkcji potrzebna byłaby w pełni działająca infrastruktura serwerowa, a jej stworzenie zajęłoby jego zespołowi dużo czasu.
Bardzo zależało mu jednak na uzyskaniu wczesnych opinii zarówno od użytkowników, jak i inwestorów, ponieważ pomogłoby mu to uniknąć kosztownych błędów w procesie tworzenia aplikacji i zbudować coś, co pokochaliby użytkownicy rynku.
Dlatego zastosował bardzo nietypowe podejście. Jego MVP było filmem demonstracyjnym. Tak, po prostu stworzył film objaśniający działanie produktu, w którym pokazał płynne doświadczenie synchronizowania plików z Dropboxem.
Kiedy Drew zaczął pokazywać ten film swojej grupie docelowej, reakcja była znacznie lepsza, niż mógł się spodziewać. Ruch na stronie Dropboxa wzrósł do kilkuset tysięcy odwiedzin, a lista oczekujących na wypróbowanie wersji beta powiększyła się do 75 000 osób.
Wnioski z historii Dropboxa
Prawdopodobnie najważniejszy wniosek, jaki możemy wyciągnąć z historii Drewa i jego zespołu, jest taki, że w świecie startupów programistycznych trzeba myśleć nieszablonowo i nie pozwalać, aby ograniczenia techniczne nas powstrzymywały.
Drew wiedział, że dalsze działanie bez poznania potrzeb użytkowników byłoby fatalnym błędem. Musiał więc znaleźć alternatywne rozwiązanie dla w pełni funkcjonalnego MVP.
Tak naprawdę nie ma znaczenia, czym jest twoje MVP. Może to być makieta lub szkielet aplikacji mobilnej albo fikcyjna strona internetowa zbudowana na WordPressie. Dopóki wybrany typ MVP pomaga uzyskać opinie i przetestować założenia, wszystko jest w porządku.
Drugi wniosek jest taki, że nie ma usprawiedliwienia dla pomijania etapu nauki i nieudoskonalania produktu w kolejnych iteracjach.
Have an account? Log In
Przykład nr 2: nieistniejące zaplecze techniczne Amazona
Zanim Amazon stał się gigantem wśród firm programistycznych, słynnie rozpoczął działalność jako księgarnia internetowa.
Interesującą częścią historii początków Amazona było to, że wizja Jeffa Bezosa dotycząca Amazona nie ograniczała się do sprzedaży książek w internecie. Jego ambicje były znacznie większe niż zostanie największą księgarnią internetową na świecie (co możemy zobaczyć po rozmiarach Amazona dzisiaj).
Powód, dla którego zdecydował się rozpocząć od książek, był całkiem pragmatyczny — książki łatwo było znaleźć i tanio wysyłać na cały świat.
Stworzenie sklepu internetowego jest dziś niezwykle łatwe dzięki Shopify, WooCommerce i wielu innym gotowym narzędziom. Jednak w 1994 roku, gdy Bezos zakładał Amazon, musiał stworzyć cały sklep, w tym zarówno interfejs użytkownika, jak i zaplecze, od podstaw.
Jeff nie miał możliwości zainwestowania w budowę całego sklepu internetowego. Zamiast tego przyjął podejście „Czarnoksiężnika z krainy Oz” do prowadzenia startupów. Miał już gotowy interfejs użytkownika — sklep internetowy, w którym można było przeglądać książki, dodawać je do koszyka i składać zamówienia.
Nie było jednak zaplecza ani automatycznego przetwarzania tych zamówień. Gdy ktoś kupował książkę w Amazonie, Jeff osobiście kupował ją w tradycyjnej księgarni i wysyłał klientowi za pośrednictwem publicznej poczty.
Oprócz umożliwienia Jeffowi rozpoczęcia działalności bez dużej inwestycji początkowej, takie podejście pozwoliło mu również wcześnie uzyskać opinie użytkowników zarówno na temat prowadzonej strony internetowej, jak i całego procesu sprzedaży produktów online.
Jeff stale uwzględniał opinie użytkowników w swojej usłudze i w 1999 roku Amazon przekształcił się w coś, co jest nam bardziej znane.
Oprócz wcielania w życie opinii użytkowników Jeff zaczął również realizować swoje większe ambicje, dodając do strony internetowej nowe kategorie produktów. W 1999 roku Amazon sprzedawał już muzykę, filmy, elektronikę, zabawki i inne rodzaje produktów.
Lekcje wyciągnięte z historii Amazona
Jeff należy do grona założycieli starej szkoły, którzy rozpoczynali działalność swoich firm „w garażu rodziców”. Chociaż zastosował podejście „Czarnoksiężnika z krainy Oz”, ponieważ po prostu nie było go stać na w pełni rozbudowaną stronę internetową, ostatecznie postąpił zgodnie z najlepszą praktyką, najpierw sprawdzając, czy model biznesowy działa, a dopiero potem budując produkt.
Przykład nr 3: MVP Zappos z ujemnym przepływem gotówki
Kontynuujmy temat pionierów handlu elektronicznego i porozmawiajmy o Zappos — ogromnym sklepie internetowym specjalizującym się w odzieży i obuwiu, który oferuje dziesiątki tysięcy produktów i wygenerował przychody rzędu kilku miliardów.
Historia Zappos zaczyna się w 1999 roku, gdy jego założyciel Nick Swinmurn spędził dużo czasu na poszukiwaniu konkretnej pary butów, którą chciał kupić w pobliskim centrum handlowym, ale nie mógł jej znaleźć. Szybko zdał sobie sprawę z problemu sklepów stacjonarnych — zawsze mają one ograniczony wybór dostępnych modeli obuwia, ponieważ utrzymywanie dużego asortymentu zwiększałoby koszty przechowywania i magazynowania w każdym pojedynczym sklepie.
Dlatego marki obuwnicze zazwyczaj wolały prezentować i sprzedawać wyłącznie najpopularniejsze i najbardziej powszechne modele w większości prowadzonych przez siebie średnich i małych sklepów, a bardziej niszowe modele udostępniać tylko w największych placówkach.
Oznaczało to, że jeśli ktoś chciał kupić coś nietypowego, nie mógł znaleźć tego w lokalnym centrum handlowym i musiał podróżować na dużą odległość do najbliższego sklepu, który oferował jego ulubioną markę.
Sklep internetowy z drugiej strony może prezentować użytkownikom mieszkającym w dowolnym miejscu nieograniczoną — przynajmniej teoretycznie — liczbę produktów, niezależnie od tego, czy mieszkają w małym mieście z niewielkim centrum handlowym, czy w ogromnym obszarze metropolitalnym z wielkimi sklepami.
Podobnie jak Jeff w przypadku Amazona, Nick nie miał możliwości finansowych, aby od podstaw zbudować cały sklep internetowy. Chociaż teoretycznie mógł poprosić inwestorów o te środki, nie chciał ryzykować, że jego sklep internetowy upadnie, a pieniądze inwestorów zostaną ostatecznie utracone.
Dlatego obrał tę samą drogę co Amazon i uruchomił stronę internetową opartą na podejściu „Czarnoksiężnika z krainy Oz”. Nick odwiedzał lokalne centra handlowe, fotografował wszystkie dostępne tam buty i publikował te zdjęcia jako produkty na sprzedaż w swojej witrynie MVP.
Gdy użytkownik składał zamówienie na Zappos.com, Nick jechał do sklepu sprzedającego dany model w lokalnym centrum handlowym, kupował go i wysyłał klientowi pocztą. Jak można się domyślić, Nick nie osiągał zysku, prowadząc sklep w sposób oparty na podejściu „Czarnoksiężnika z krainy Oz”. W rzeczywistości tracił pieniądze.
Jednak na tym etapie Nickowi najbardziej zależało nie na wyniku finansowym. Chciał uzyskać dwie rzeczy — opinie klientów i potwierdzenie słuszności swojego modelu biznesowego.
Jak możemy zobaczyć na podstawie przychodów ze sprzedaży i liczby produktów dostępnych na Zappos.com, model biznesowy Nicka działał i doprowadził do ogromnego sukcesu.
Wnioski wyciągnięte z Zappos
Zappos i sposób, w jaki Nick prowadził wersję concierge MVP, uczą nas czegoś bardzo ważnego o startupach — dopuszczalne jest ponoszenie strat.
W porządku, pozwólcie, że wyjaśnię. Ogólnie rzecz biorąc, firma nie powinna przynosić strat. Jeśli jednak znajduje się na etapie MVP, działanie ze stratą jest akceptowalne, ponieważ produkty MVP nie mają przynosić pieniędzy. Ich celem jest natomiast uzyskanie opinii klientów i zweryfikowanie pomysłu na startup.
Przykład nr 4: strona docelowa Buffer przed rozpoczęciem prac nad produktem
Tak jak my, menedżerowie produktu, postrzegamy Jira lub Monday.com jako niezbędne elementy naszego zestawu narzędzi, tak menedżerowie mediów społecznościowych uważają Buffer za niezbędny element codziennej pracy.
Zanim jednak Buffer stał się w pełni rozwiniętą platformą do zarządzania mediami społecznościowymi, rozpoczął działalność jako aplikacja zawierająca jedną funkcję.
Wspomnianą funkcją była możliwość planowania przez użytkowników wielu postów na Twitterze. Chociaż istniały już klienty Twittera oferujące tę funkcję, Joel Gascoigne, współzałożyciel i dyrektor generalny Buffer, chciał sprawić, aby planowanie było przyjemne, tworząc płynne i łatwe w obsłudze doświadczenie użytkownika wokół procesu planowania.
W szczególności miał w głowie interfejs użytkownika, który pozwalałby planować dużą liczbę tweetów jednocześnie, zamiast robić to osobno dla każdego tweeta (tak działała ta funkcja we wspomnianych wcześniej klientach Twittera).
Joel wiedział, że jego pomysł może łatwo zakończyć się niepowodzeniem, dlatego zdecydował się stworzyć najbardziej minimalny wartościowy produkt, jaki można sobie wyobrazić. Nie była to działająca aplikacja, lecz prosta strona docelowa.
Osoby odwiedzające stronę docelową czytały o funkcjach Buffer i klikały przycisk rejestracji. Zamiast uzyskać dostęp do aplikacji, użytkownicy Buffer widzieli jednak wiadomość informującą, że produkt nie jest jeszcze gotowy, oraz prośbę o pozostawienie adresu e-mail, aby zespół Buffer mógł powiadomić ich, gdy produkt będzie gotowy do użycia.
Liczba użytkowników, którzy pozostawili swoje adresy e-mail, aby uzyskać dostęp do Buffer (a było ich wielu), była dla Joela sygnałem, że warto poświęcić czas i pieniądze na stworzenie tego produktu.
Oprócz określenia poziomu zainteresowania swoim produktem Joel wykorzystał również zebraną listę adresów e-mail, aby skontaktować się z użytkownikami, porozmawiać z nimi, dowiedzieć się więcej o tym, jak planowali korzystać z jego narzędzia do planowania, oraz dokładniej zbadać frustracje, których doświadczali podczas korzystania z innych aplikacji.
Wnioski wyciągnięte z Buffer
Czy kiedykolwiek udało Ci się zdobyć listę osób zainteresowanych Twoim produktem? Najważniejszą korzyścią, jaką uzyskujesz, jest możliwość zdobywania wiedzy. Zgadzam się, te osoby będą również Twoimi przyszłymi pierwszymi użytkownikami, ale pieniądze, które najprawdopodobniej dzięki nim zarobisz, będą niewielkie. Z drugiej strony wnioski, które wyciągniesz, są bezcenne.
Przykład nr 5: wersja beta Spotify
Usługa przesyłania strumieniowego, która prawdopodobnie odtwarza teraz w tle Twojego laptopa playlistę do pracy w stylu lo-fi, rozpoczęła działalność w 2008 roku, gdy Daniel Ek i Martin Lorentzon postanowili zmierzyć się z interesującym problemem istniejącym wówczas w branży muzycznej.
Problem polegał na tym, że jeśli chciałeś posłuchać piosenki, musiałeś ją kupić (a w 2009 roku kosztowała od 1 do 2 dolarów). Oznaczało to, że musiałeś albo wydać setki lub tysiące dolarów, aby stworzyć obszerną playlistę zawierającą wszystko, co lubisz, albo ograniczyć się do kilku piosenek, na których zakup mogłeś sobie pozwolić.
Daniel i Martin mieli rewolucyjny pomysł, który rozwiązywał ten problem — usługę przesyłania strumieniowego działającą jak bufet „jesz, ile chcesz”, w której płaciłoby się miesięczny abonament i słuchało dowolnej liczby piosenek.
W przeciwieństwie do wielu wcześniejszych przykładów MVP zespół stojący za Spotify rzeczywiście stworzył w pełni działający prototyp oprogramowania, który rozdystrybuował wśród blogerów muzycznych w ramach testów beta.
Źródło: Prototypr
Inżynierowie Spotify nie stworzyli jedynie wersji produktu zawierającej podstawową funkcjonalność — przez wiele miesięcy udoskonalali infrastrukturę i zmniejszali opóźnienia, aby przesyłanie strumieniowe ze Spotify przypominało odtwarzanie piosenki zapisanej na dysku twardym urządzenia użytkownika.
Rozdystrybuowana przez nich wersja beta odniosła ogromny sukces i wkrótce tysiące użytkowników zaczęły korzystać z tego nowego, rewolucyjnego sposobu słuchania muzyki.
Wnioski wyciągnięte ze Spotify
Spotify jest doskonałym przykładem tego, że nie należy zapominać o literze V w MVP. Chodzi o to, aby miniwersja produktu była opłacalna, a tym samym wartościowa, na rynku.
Co więcej, warto poświęcić miesiące na wdrażanie jednej funkcji, jeśli uważasz, że jej brak zaszkodzi głównej propozycji wartości, jaką Twój produkt oferuje potencjalnym użytkownikom.
More Articles
Przykład nr 6: testowanie metodą konsjerża w Airbnb
Nasz ostatni przykład udanego MVP dotyczy platformy Airbnb związanej z podróżami i zakwaterowaniem.
Ich historia zaczyna się w 2007 roku, kiedy współzałożyciele Brian Chesky i Joe Gebbia zdali sobie sprawę, że nie mają wystarczająco dużo pieniędzy, aby opłacić czynsz za mieszkanie w San Francisco.
Aby pokryć koszty czynszu, wkrótce postanowili wynajmować materace w swoim mieszkaniu jako miejsca do spania dla uczestników konferencji projektowej, która odbywała się w tym czasie w mieście.
Zrobili więc zdjęcia swojego mieszkania i umieścili je na niewielkiej stronie internetowej, którą stworzyli dla swojej „usługi zakwaterowania”. Pomysł zadziałał, a zespół Airbnb postanowił go skalować i stworzyć na jego podstawie firmę, wykorzystując swoją stronę internetową jako platformę, na której ludzie mogliby znaleźć i zarezerwować pobyt w czyimś domu.
Podobnie jak Amazon i Zappos, zastosowali podejście MVP „czarnoksiężnika z krainy Oz”, ponieważ pierwszym zakwaterowaniem oferowanym na ich stronie było ich własne mieszkanie.
Następnie nadal tworzyli coraz bardziej zaawansowane wersje swojego MVP (którym była funkcjonalna strona internetowa z działającym mechanizmem rezerwacji), wykorzystując je do weryfikowania swojego ogólnego pomysłu na produkt, a w szczególności jednej hipotezy — że ludzie będą skłonni wynajmować swoje mieszkania innym za pieniądze.
Wnioski z Airbnb
Czasami MVP nie jest jednorazowym przedsięwzięciem i ostatecznie tworzysz różne wersje swojego MVP (za każdym razem dodając nowe funkcje), które wykorzystujesz do zbierania opinii klientów i zdobywania wiedzy na temat różnych aspektów swojego produktu i modelu biznesowego.
Chodzi przede wszystkim o tanie testowanie modelu biznesowego.
Jak pokazują opisane powyżej historie sukcesu, MVP nie jest tylko kolejnym pojęciem z podręczników zarządzania produktem. To coś rzeczywistego, a tworzenie MVP pomogło wielu znanym produktom cyfrowym zweryfikować ich założenia, zanim ich założyciele i zespół odpowiedzialny za rozwój produktu rozpoczęli wielomiesięczną, ciężką pracę nad ich budową.
Aby uzyskać więcej podobnych informacji, nie zapomnij zasubskrybować naszego biuletynu!
