Zanim zrobisz bardzo dużo, zrób tyle, ile trzeba. To – w największym skrócie – idea MVP, czyli Minimum Viable Product. Warto stosować ją w praktyce. Nie tylko dlatego, że sprzyja redukcji kosztów. Również dlatego, że pomaga ustalić priorytety i oddzielić rozwiązania niezbędne od tylko wartościowych.

Minimum Viable Product (MVP) to jedno z tych określeń, które trudno przełożyć na język polski bez odrobiny gimnastyki. Termin „viable” tłumaczy się na kilka sposobów. W tym kontekście najlepiej oddają go takie określenia, jak „opłacalny”, „funkcjonalny” czy „mający szansę powodzenia”. Spośród kilku polskojęzycznych rozwinięć skrótu MVP najbardziej trafne wydaje się następujące: produkt o minimalnej niezbędnej funkcjonalności. Niezbędnej, czyli takiej, która realizuje podstawowe zadania produktu i umożliwia korzystanie z niego – bez obciążania projektu kosztochłonnymi funkcjami i rozwiązaniami dodatkowymi.

Jak to się robi? Minimum Viable Product w praktyce

No dobra, teoria jest trochę skomplikowana, a praktyka? Wręcz przeciwnie. Wyobraź sobie, że przyszedł ci do głowy wystrzałowy pomysł na serwis o, hmm, aplikacjach. By go zrealizować, możesz kupić domenę i hosting, postawić stronę na płatnym motywie Wordpressa, zlecić wykonanie projektu graficznego profesjonalnej agencji, zatrudnić ludzi od contentu, a na dokładkę specjalistów od SEO. Możesz – tylko po co? Nawet jeśli odkryłeś fenomenalną niszę, szansa, że projekt nie wypali tak szybko lub tak spektakularnie, by jego kontynuacja miała sens, jest spora. Ponieważ świetnie zdajesz sobie z tego sprawę, zamiast budować zamki na piasku, tworzysz MVP. W tym przypadku może to być fan page poświęcony danej tematyce lub prowizoryczny blog. Jeśli koncepcja zaskoczy – inwestujesz w jej rozwój. Jeśli nie – zabierasz się za inny temat, bogatszy o niezmarnowany czas i zaoszczędzone pieniądze.

Nie ma w tym wielkiej filozofii. To dość naturalna strategia, której nadano ekspercką nazwę. W „trybie” MVP zaczynało wielu gigantów IT i e-biznesu. Przykłady? Są na wyciągnięcie ręki.

1) FACEBOOK

Zaczynał jako rejestr studentów i absolwentów Harvardu, pozwalający na wyszukiwanie znajomych. Przełomową funkcją, dodaną kilka miesięcy po powstaniu serwisu, była „ściana”, na której użytkownicy mogli pisać do siebie krótkie wiadomości. Było to minimum, które okazało się kluczowe dla późniejszego sukcesu serwisu. Można je uznać za MVP przy założeniu, że twórcy mieli wizję dalszego rozwoju przedsięwzięcia.

2) GROUPON

Późniejszy lider rynku zakupów grupowych zaczynał jako prosta witryna na Wordpressie. Jej twórcy wysyłali oferty subskrybentom mailem w plikach PDF. Prowizoryczne rozwiązanie (MVP) przyniosło (nie)oczekiwane rezultaty. Dopiero wtedy twórcy Groupona zainwestowali w rozwój backendu, frontendu i systemu voucherów.

3) AIRBNB

Ta historia jest już legendarna. Brian Chesky i Joe Gebbia wynajmowali loft w San Francisco, ale nie zawsze wystarczało im na czynsz. W San Francisco to dość normalna sytuacja. Na szczęście problemy rodzą rozwiązania. Chesky i Gebbia „zainwestowali” w dmuchany materac i podnajęli miejsce noclegowe w salonie. To był ich MVP.

Produkt „minimalny”, ale skalowalny

Większość udanych biznesów ma podobną historię. A wiele nieudanych to efekt przeinwestowania na starcie bez opracowania produktu o minimalnej niezbędnej funkcjonalności. Lekcja z podobnych „case'ów” jest prosta: zanim wydasz środki, upewnij się, że pomysł jest warty inwestycji, testując go na rozwiązaniu możliwie najprostszym. Jednak MVP nie zawsze oznacza biznes rozwijany w garażu. Ten standard wdrożeniowy stosują również duże korporacje. Świetnym przykładem jest Zynga. Firma, zanim zabierze się za tworzenie nowej gry, analizuje zainteresowanie jej koncepcją wśród swoich użytkowników, których kusi możliwością darmowych testów. Jeśli pomysł okazuje się niewypałem, Zynga zwyczajnie nie zabiera się za jego realizację.

MVP może być zatem zmyślnie opracowanym testem danego rozwiązania, a nie produktem, który od początku przynosi rezultaty biznesowe. W obszarze projektowania aplikacji rolę MVP może spełniać np. makieta – jeśli naszym celem jest przetestowanie rozwiązań z zakresu UX lub zaprezentowanie koncepcji inwestorowi. „Minimalnym produktem” może być również aplikacja. Może, jeśli unikniemy sytuacji, w której zamiast aplikacji spełniającej wymagania minimalnej niezbędnej funkcjonalności, stworzymy zwykłą atrapę.

O tym, jak będzie, decyduje właściwe zrozumienie idei MVP oraz założeń przedsięwzięcia. Załóżmy zatem, że mamy do wykonania produkt w pełni funkcjonalny w zakresie podstawowej funkcji, powiedzmy, sprzedażowej. I załóżmy, że realizujemy to zadanie, tworząc aplikację, która obsłuży transakcje przeprowadzane przez maksymalnie stu klientów, przy okazji podsunie im kilka rekomendacji zakupowych, zaoferuje możliwość wystawienia komentarza i uszczęśliwi paroma innymi funkcjami. I co? No właśnie – atrapa. Jeśli produkt obfituje w liczne funkcje dodatkowe, ale nie jest skalowalny w zakresie funkcji podstawowej, nie spełnia założeń MVP. Niezbędna funkcjonalność nie oznacza częściowej sprawności, tylko pełną sprawność w zakresie podstawowej funkcji – w tym przypadku pełną skalowalność.

Prościej? Założeń MVP nie będzie spełniało krzesło na dwóch nogach. Będzie je spełniało krzesło „czworonożne”, które nie zostało poddane zabiegom wykończeniowym, takim jak lakierowanie, malowanie czy tapicerowanie.

Co może pójść źle, czyli jak obchodzić się z MVP

MVP to, wbrew pozorom, prosta koncepcja, a jednocześnie bardzo przydatne narzędzie w realizacji projektów. Jego skuteczność zależy jednak od właściwej identyfikacji celów i interpretacji założeń przedsięwzięcia. Zaniedbania na tym polu mogą prowadzić do błędów i wypaczeń. Tak, jak w przypadku tworzenia rozwiązań nieskalowalnych w sytuacji, gdy skalowalność jest kluczowa dla rozwoju przedsięwzięcia.

Realizacje w trybie MVP wiążą się również z innym, mniej oczywistym ryzykiem. Hasło „MVP” może skłaniać do pewnej nonszalancji, która objawia się odezwą „aaa, to tylko MVP”. W domyśle: „skoro tak, to może nie trzeba się tak bardzo przykładać do realizacji”. Dlatego w pracy zespołu kategorią MVP należy posługiwać się z dużą ostrożnością. Oczywiście takich obaw nie ma, jeśli zespół jest dobrze zmotywowany i tryska energią.

Ale w tej sytuacji możliwe jest przegięcie w drugą stronę: interpretacji MVP jako produktu finalnego, który musi zostać dopieszczony do imentu. To pozornie lepszy wariant rozwoju wydarzeń, ale również pomija istotę sprawy i wiąże się z dodatkowymi (niepotrzebnymi) kosztami czasowymi oraz finansowymi.

Reasumując, warto myśleć o MVP jako o pojęciu biznesowym, a nie technicznym. Z technicznego punktu widzenia ten termin jest niedostatecznie precyzyjny, choć z biznesowego wybitnie przydatny.

Jeśli szukasz partnera, który zrealizuje twój projekt z dbałością o jego bezpieczeństwo – porozmawiajmy!