6 cech dobrego MVP

Dzisiejszy wpis w tematyce startupowej. Opiszę sześć najważniejszych cech, które według mnie powinno posiadać dobre MVP. Jeśli masz w planach lub pracujesz nad własnym projektem ten post jest dla ciebie obowiązkowy 🙂

MVP (ang. minimum viable product) – jest to wersja produktu, która posiada minimalne funkcjonalności, umożliwiające wprowadzenie na rynek. Ta wersja ma zweryfikować przydatność twojego produktu, zweryfikować założenia funkcjonalne oraz przybliżyć lub oddalić założenia finansowe względem produktu.

Wracając do głównego wątku wpisu, możemy wyróżnić 6 najważniejszych cech dobrego MVP:

1. rozwiązujące problem

Nasze MVP musi rozwiązywać problem, dla którego zostało stworzone. Inaczej mówiąc, po skorzystaniu z naszego projektu, użytkownik musi mieć możliwość osiągnięcia celu w jakim go użył. Kilka wpisów wcześniej wyjasniałem różnice między celem i zakresem w projektach IT.
Zamiast skupiać się nad „wodotryskami UX” i przepięknym logo, postaraj się osiągnąć funkcje pozwalające zrealizować cel projektu. Jeśli twój produkt będzie oszczędzał czas klienta, zwiększał jego wydajność, poprawiał jakość pracy (lub realizował inny cel projektowy) – ma szansę zaciekawić. Nawet jeśli funkcje poboczne (nie realizujące bezpośrednio celu projektu) i wizualne nie będą doskonałe masz szanse dokonać sprzedaży. W przeciwnym wypadku – jeśli projekt będzie dopieszczony wizualnie, ale nie ułatwi nikomu życia to naszymi użytkownikami w większości będą znajomi, którzy będą zaciekawieni losami projektu ponieważ znają nas osobiście.
Nie popadajmy w kolejną skrajność wydając MVP „wyciosane z drewna”, którego interfejs wygląda jak kokpit Boeinga – wszystko z umiarem.

2. przemyślane

Myślę, że poniższy obrazek wam wszystko wyjaśni.

Projekt musi być poddany analizie. Brzmi banalnie, ale moim zdaniem jest to najtrudniejszy krok podczas product developmentu. Na obrazku widzimy skomplikowane i funkcjonalne produkty (apple/google), które są niezwykle proste w obsłudze i intuicyjne. Nie mam tutaj na myśli samego UX.

Zrzut ekranu z aplikacji „twojej firmy” wygląda jak kokpit samolotu. Mamy mnóstwo przycisków – podejrzewam, że oprócz autora każdy miałby problem z używaniem aplikacji oraz „odczytaniem” do czego służy, w czym pomoże – jaki rozwiąże problem. Wynika to z braku wystarczająco dogłębnej analizy. Możemy uzyskać taki efekt gdy nie wydzielimy procesów w aplikacji – którędy użytkownik będzie się poruszał, co mu będzie potrzebne (w jakim momencie) i od czego zacznie. Jest to niezwykle istotne żeby użytkownik prawidłowo odczytał projekt – wywnioskował do czego służy oraz zachęcił go prostotą do użycia (zaangażował).

Pamiętaj, że użytkownicy nie chcą oceniać kunsztu programistycznego tylko to jak bardzo będzie im ułatwiał życie. Mi osobiście zdarzyło się kilka razy wejść na stronę startupu i nie wiedzieć „po co” został stworzony. Główna idea i cel projektu powinien być szybko odczytywalny.

3. tanie

Dobrze, jeśli MVP jest tanie, ponieważ nie wiemy czy projekt się przyjmie. Ryzyko jest niezbędne, ale musi być przemyślane. Jeśli da się osiągnąć cel tańszą metodą, w której zachowamy wymierną jakość (wciąż akceptowalną) – zdecydujmy się na to. Jeśli będzie odpowiednio duży popyt na nasz produkt, będą pieniądze na inwestycje i poprawienie jakości. Nie bójmy się zaciągać długu technologicznego – może się zdarzyć, że nigdy nie będziemy musieli go spłacać jeśli projekt nie wypali. Natomiast jeśli będziemy musieli go spłacać to w pewnym sensie będzie to powód do radości ponieważ produkt wymaga wyższej jakości spowodowanej zaangażowaniem użytkowników.

4. na tu i teraz

Wbrew pozorom selekcja funkcji, które będzie zawierało MVP nie jest łatwa. Bardzo często autorowi wydaje się, że wszystko jest niezbędne, tym samym opóźniając datę wyjścia na rynek. Taka sytuacja może być niebezpieczna przede wszystkim z dwóch powodów:

• ktoś może wyjść z alternatywnym rozwiązaniem przed nami 😉
• stworzymy produkt według naszych indywidualnych potrzeb, zamiast według potrzeb klientów/użytkowników docelowych.

Funkcje, które wydają się nam, że są absolutnym niezbędnikiem mogą okazać się zupełnie niepotrzebne lub zrealizowane w niewłaściwy sposób. Najcenniejsze co możesz dostać to feedback od użytkowników końcowych. Czym wcześniej go będziesz dostawał, tym twoja droga do dobrego produktu będzie krótsza. Należy więc unikać sytuacji gdy zamkniemy się w pokoju na 6 miesięcy i wyjdziemy z niego mówiąc „skończyłem, zobaczcie!” 😉

Nie popadajmy też ze skrajności w skrajność, wydzielając integralny core naszego projektu, czyniąc go tym samym bezużytecznym – musimy zachować odpowiedni balans. Dobrą metodą do nadawania priorytetów zadaniom jest metoda impact mapping oraz zasada pareto (nie musimy się trzymać sztywno proporcji 80/20) – wspomniane metody opisze w kolejnych wpisach.

Nasz produkt musi być adekwatny do swojego stadium – czyli startu. Każdy twórca ma wizję jak projekt będzie wyglądał za rok czy dwa, ale teraz nie ma sensu jej implementować. Być może tory twojego MVP poprowadzą go zupełnie inną drogą lub wraz z cyklem życia produktu zmienisz swoją wizję. Dostosuj swój projekt do wizji, którą masz na uruchomienie projektu.

5. szybkie, korzystające z gotowych rozwiązań

Jeśli wykorzystasz gotowe rozwiązania – szybciej stworzysz produkt. To główna idea tej cechy. Funkcje poboczne (nie realizujące bezpośrednio celu projektu) można zrealizować za pomocą gotowych rozwiązań. Ktoś „poświęcił” swoje życie by zrobić perfekcyjną usługę mailingową, silnik wyszukiwarki lub inne biblioteki/frameworki. Twórcy gotowych rozwiązań każdego dnia udoskonalają swój produkt, rozwiązali mnóstwo problemów, które występują na drodze realizacji tych funkcjonalności. Skorzystaj z ich doświadczenia i produktu – oszczędzisz czas i pieniądze. Jeśli jakaś funkcja nie jest twoim rdzeniem biznesu, nie skupiaj się nad nią przesadnie – ktoś kto poświęcił całą uwagę tylko jej, zapewne zrobił ją lepiej. Zwróć szczególną uwagę na swoje kluczowe funkcje, których nie da się zastąpić gotowymi rozwiązaniami. Pamiętaj, że nawet gdy wymyślisz koło na nowo, nie będzie bardziej okrągłe niż istniejące.

6. przetestowane

Przetestuj swoje MVP najlepiej jak potrafisz. Nie mówię tutaj o zwykłym przeklikaniu. Zastanów się podczas testów czy coś można usprawnić – podejdź do tego iteracyjnie. Wciel się w postać klienta, który, twoim produktem będzie chciał rozwiązać konkretny problem, nie chodzi tylko o suchą checklistę czy coś działa czy nie. Produkt musi być wygodny i użyteczny. Każde testy powinny być podsumowane analizą, z której wyciągasz wnioski. W idealnej sytuacji, produkt jest gotowy gdy nie ma już żadnych sugestii podczas testów, nie masz pomysłu jak go usprawnić. Jednak idealny świat jest fikcją. Uznaj, że twój produkt jest przetestowany gdy lista rzeczy do poprawki jest akceptowalnie krótka. Nie bądź przesadnym perfekcjonistą bo twój proces testowania będzie jak metoda rekurencyjna bez zdefiniowanego warunku końca – nieskończony 😉

Podsumowanie

Znajdź balans pomiędzy jakością a czasem realizacji – zbyt duże przechylenie w jedną lub w drugą stronę będzie niekorzystne dla startującego projektu. Najważniejsze, żebyś sam rozumiał jego cel, wtedy będzie on odzwierciedlony w twoim MVP. Nie nastawiaj się na perfekcje tylko na użyteczność.