Zarządzanie projektami, zespołem i analiza IT

rozwój produktu

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.

przemyslane

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ść.


Dziękuję, że przeczytałeś ❤️

Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍

6 komentarzy do “6 cech dobrego MVP

  • „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.” Panie Karolu MVP tworzy się po to w Customer Development , żeby testować na kliencie i to jak najszybciej jak można (pierwsza uwaga). Warto przypomnieć,że Start up jest po to aby stworzyć rentowny , powtarzalny i skalowalny model biznesowy , zaś MVP jest jednym z etapow i narzędzi testowania modelu biznesowego. Artykuł ciekawy polecam. Więcej u Erica Riesa i Aha Maurya-Metoda Running Lean Emotikon wink

    Odpowiedz
    • Wydaje mi się, że na kliencie chcemy przetestować funkcjonalność produktu (tzn. to, czy dobrze „wstrzeliliśmy się” w potrzeby i oczekiwania klientów). Niewygodny interfejs zniechęci użytkownika, zanim zapozna się z naszymi (niewątpliwie rewelacyjnymi) pomysłami. Tym bardziej nie chcielibyśmy testować na użytkownikach poprawności implementacji. Rozumiem, że do niezbędnego minimum ograniczamy funkcjonalność, a nie jakość.

      Oczywiście, jak często w życiu, trzeba znaleźć złoty środek, co Karol zaznaczył. A to, że w tym właśnie tkwi główna trudność, to już osobny temat 🙂

      Odpowiedz
      • Trafione w punkt. Poprawność implementacji jesteśmy w stanie przetestować sami. Nie chcemy przecież żeby użytkownicy oglądali nieobsłużone błędy, które rzucił nasz projekt.
        UX najlepiej przetestować na szerszej grupie użytkowników, ale ux’owe „babole” jesteśmy w stanie z pewnością zidentyfikować i poprawić sami.
        Wspomniany wcześniej „złoty środek” w każdym projekcie leży w innym miejscu, ważne by autor go właściwie zidentyfikował 🙂 Główna puenta to żeby nie przesadzać w jedną, ani drugą stronę 😉

        Odpowiedz
  • Zdecydowanie zgadzam się z tym co napisałeś. Wydzielenie dobrego zakresu MVP jest według mnie kluczowe i bardzo trudne. Jednak w większości projektów jest bardzo wartościowe. Nawet w projektach nie będących startupami.

    Czy macie jakieś metody na poprawne ustawianie początkowego zakresu lub tez testowanie go?

    Odpowiedz
    • Dobrze sprawdza się metoda impact mapping połączona z zasadą pareto – wszystko w granicach umiaru i zdrowego rozsądku. Każdy projekt jest niepowtarzalny, więc nie ma uniwersalnych prawd działających w każdym przypadku 🙂
      Ustanawiając zakres skoncentruj się na celu projektu – żeby nie został zatracony. Możesz kierować się checklistą z 6 opisanych przeze mnie punktów.

      Jeśli chodzi o testowanie to temat na osobny wpis 🙂 . Według mnie najlepiej sprawdza się stopniowe poszerzanie grona testerów. Można zacząć od testów wewnętrznych (zespół developerski/współpracownicy). Kolejnie rozszerzyć go na wybranych klientów. Później możesz zrobić testy zewnętrzne/otwarte – gdy masz pewność co do jakości testów funkcjonalnych. 🙂

      Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.