Jak prawidłowo określić zakres funkcjonalności MVP?

MVP Development - czym jest?

MVP Development jest najlepszym sposobem na stworzenie nowego produktu lub weryfikację założeń biznesowych. Polega na stworzeniu aplikacji, która posiada wyłącznie najważniejsze funkcjonalności - i rozwiązuje najważniejsze problemy docelowych użytkowników. Poprzez stworzenie MVP aplikacji możemy niskim kosztem określić rzeczywisty odbiór oraz faktyczne potrzeby użytkowników, a dzięki informacjom zwrotnym - regularnie wprowadzać zmiany tak, aby dalszy kierunek rozwoju projektu był uzasadniony biznesowo.

Poprzez ograniczenie ilości funkcjonalności możemy ograniczyć zarówno koszt, jak i czas realizacji potrzebny na wykonanie MVP - nie idąc na kompromis kosztem jakości aplikacji. W zależności od złożoności projektu i ilości funkcjonalności, stworzenie MVP aplikacji może zajmować od 2 tygodni do kilku miesięcy.

Podstawowymi założeniami MVP są stosunkowo niskie koszty wejścia na rynek, szybki time-to-market i możliwość weryfikacji Twojego pomysłu biznesowego. Dlatego ważne jest określić odpowiedni zakres funkcjonalności MVP, aby spełniał te założenia. Jeśli w zakresie MVP pojawi się za dużo funkcjonalności, które bardzo często nie są konieczne dla projektu, koszt i czas realizacji ulegnie wydłużeniu. Przy określaniu zakresu MVP powinniśmy dobierać w pierwszej kolejności zadania i funkcjonalności, które można określić jako „low effort, high impact”. Prawidłowo określony zakres MVP pozwala na zrealizowanie projektu dużo mniejszym kosztem i pozwala na szybsze rozpoczęcie pracy nad product-market fit – szybko dowiemy się, z jakich funkcjonalności korzystają użytkownicy i czego im brakuje w aplikacji.

Dlaczego tak ważne jest odpowiednie określenie zakresu funkcjonalności MVP?

MVP można określić jako aplikację, która spełnia wyłącznie najważniejsze potrzeby użytkowników lub rozwiązuje ich najbardziej istotne problemy. MVP powinno być pełnoprawną aplikacją, która będzie dopracowaną pod względem technicznym i designowym. W MVP nie mogą pojawić się odnośniki do nieistniejących grafik, niedziałające funkcjonalności i tym podobne błędy. Dlatego właśnie odpowiednio określony zakres funkcjonalności MVP jest bardzo ważny, aby móc spełnić wszystkie z powyższych wymagań w stosunkowo krótkim czasie (projekty MVP development, w zależności od scope, z reguły trwają ok. 1-3 miesięcy, oczywiście zdarzają się wyjątki jak na przykład projekty związane z AI/ML (sztuczna inteligencja oraz uczenie maszynowe), które trwają o wiele dłużej).

Jeśli zawrzemy w MVP za dużo funkcjonalności, które nie są krytyczne do rozwiązania problemów i potrzeb użytkowników, przesuniemy tylko time to market i zwiększymy koszt projektu. Niepotrzebnie zwiększa to ryzyko inwestycji w projekt MVP, który z reguły powinien nie cechować się wysokim kosztem i powinien być zrealizowany w krótkim czasie. Duże ilości projektów aplikacji w ogóle nie wchodzi na rynek lub wchodzi za późno, ponieważ specyfikacja “nie-MVP” jest za duża. W rzeczywistości bardzo często da się stworzyć aplikację, z trochę mniejszą ilością funkcji i do tego mniejszym kosztem, która równie dobrze spełni wszystkie założenia projektu.

Na czym trzeba się skupić podczas określania scope MVP?

Przy określaniu zakresu funkcjonalności MVP ważne jest, aby skupić się przede wszystkim na użytkowniku. Podejście „user first” można określić jako podstawowe założenie MVP. Dlatego zanim w ogóle zaczniemy myśleć o tym, która z funkcji powinna się znaleźć w MVP, powinniśmy przeprowadzić chociaż wstępne badania użytkowników i ich problemów. Pomocne jest tutaj stworzenie user personas – reprezentacji idealnych użytkowników aplikacji, w której możemy określić ich najpowszechniejsze problemy i wyzwania, które chcemy rozwiązać przy pomocy naszego MVP. Na tej podstawie powinniśmy zastanowić się, jak chcemy rozwiązać te problemy i zaprojektować odpowiednie funkcjonalności. Jeśli Twój produkt będzie zawierał funkcjonalności rozwiązujące ich problemy lepiej i szybciej niż istniejące rozwiązania, to prawdopodobnie będą musiały się znaleźć w specyfikacji projektu i będą niezbędne.

Warto również zbadać bezpośrednią konkurencję i ich rozwiązania – chociażby czytając opinie użytkowników na marketplaces pokroju G2 czy Producthunt – i określić lepsze rozwiązanie, które skuteczniej będzie adresować problemy użytkowników. W taki sposób będziemy mogli określić niezbędne minimum funkcjonalności i zrezygnować z części projektu , które tylko wydłużą proces tworzenia MVP i zwiększą jego koszty.

Jak zdecydować, które z funkcji aplikacji powinny się znaleźć w Twoim MVP?

Aby zminimalizować time-to-market i jak najszybciej zacząć pracę nad osiągnięciem product-market fit, należy określić niezbędne funkcjonalności do spełnienia potrzeb użytkowników, nad którymi zaczniemy pracę. Sposobów na to, jak te funkcjonalności odkryć jest wiele i w zależności od grupy docelowej - jedna metoda będzie bardziej skuteczna od drugiej. Poniżej przedstawiamy kilka najpopularniejszych, warsztatowych metod priorytetyzacji.

Techniki priorytetyzacji, które można wykorzystać podczas określania zakresu funkcjonalności MVP.

User Story Mapping

Jest to jedna z najpopularniejszych technik używanych do kategoryzowania funkcjonalności MVP. Jest też jedną z najbardziej wydajnych, ponieważ bierze pod uwagę wszystkich interesariuszy produktu .

Aby określić najważniejsze i mniej ważne funkcjonalności przy pomocy User Story Mapping, powinniśmy przeanalizować wszelkie cele, jakie użytkownik chciałby osiągnąć przy pomocy aplikacji, zapisując je w formie „historyjek” i ścieżki podróży przez funkcjonalności.

W przykładowym określeniu celu użytkownika można posłużyć się aplikacją, która ma umożliwiać porównanie cen hotelów na całym świecie i umożliwić zarezerwowanie hotelu w danym terminie. Cel użytkownika – „zarezerwować hotel” - rozbijany jest na kilka kroków:

Określenie szczegółów podróży – kierunek, data, ilość osób: „Jako użytkownik chciałbym określić lokalizację, do której się wybieram, aby zarezerwować hotel w danym miejscu.”

Porównanie hotelów i cen – umożliwienie użytkownikowi dokonania wyboru spośród wielu opcji, skracając wysiłek do minimum – „Jako użytkownik chciałbym porównać kilka ośrodków jednocześnie, aby wybrać dla siebie odpowiedni hotel.”

Porównanie opinii poprzednich gości hotelu i szczegółów oferty – „jako użytkownik chciałbym sprawdzić opinie o hotelu, aby sprawdzić, czy hotel będzie dobry dla mnie”

Umożliwienie użytkownikowi rezerwacji hotelu – „jako użytkownik chciałbym szybko zarezerwować pokój, aby nie dzwonić bezpośrednio do hotelu i dokonać rezerwacji szybciej.” Następnie każdy z tych kroków trzeba uporządkować od najważniejszych do tych mniej ważnych. Dzięki temu możemy określić, które z funkcji powinny znaleźć się w MVP, a które powinny zostać dodane później.

MosCoW Matrix

MoSCoW jest techniką analizy biznesowej pozwalającą na ustalenie wymagań i priorytetu wszystkich funkcjonalności aplikacji MVP. Polega na przyporządkowaniu każdej funkcjonalności do odpowiedniej kategorii priorytetu:

Must haves – czyli funkcjonalności, bez których Twoje MVP nie będzie miało prawa odnieść sukcesu. W przypadku omawianym powyżej byłaby to sama wyszukiwarka hoteli w danej lokalizacji z rozbudowanym filtrowaniem.

Should haves –funkcjonalności, bez których MVP będzie używane, ale użytkownicy ich potrzebują. Przykładem byłoby tutaj wyświetlanie opinii użytkowników o danych hotelach lub lista korzyści pokroju darmowego Wi-Fi.

Could haves – wszelkie funkcjonalności, które są przydatne dla użytkownika, ale nie są konieczne do korzystania z produktu. Jednoczesne wyszukiwanie hoteli w kilku lokalizacjach czy terminach lub trendy cen mogłyby być funkcjonalnością could-have. Nie są to funkcjonalności krytyczne dla użytkowników i mogą być zrealizowane później.

Won’t haves – funkcjonalności, które wnoszą najniższą wartość dodaną dla użytkowników lub nie są najważniejsze, a zajmą dużo czasu, aby je zrealizować. Te funkcjonalności absolutnie nie powinny się znajdować w zakresie MVP. Należy pamiętać, że można je dodać w późniejszych etapach developmentu, jeżeli faktycznie będzie taka potrzeba. Dobrym przykładem takiej funkcjonalności byłyby wirtualne spacery po hotelach – byłaby to ciekawostka dla użytkownika, ale w kontekście pozostałych funkcjonalności porównywania hoteli ma ona niski priorytet.

Feature Priority Matrix

Feature Priority Matrix jest zdecydowanie jedną z prostszych metod, która pozwala określić priorytet funkcjonalności w zakresie prac MVP. Często używa się również nazw takich jak „Impact/Effort” czy „Value/Complexity” Matrix. Feature Priority Matrix jest w zasadzie dwuwymiarowym wykresem, na którym zamieszcza się funkcjonalności wedle wysiłku wymaganego do wdrożenia i złożoności funkcjonalności oraz wartości generowanej dla użytkowników i wpływu na aplikację.

Korzystając z Feature Priority Matrix podczas określania zakresu projektu MVP możemy połączyć wysiłek na wykonanie funkcjonalności z jej wartością dla użytkowników – i na tej podstawie zadecydować, jakie i w jakiej kolejności powinniśmy wykonać funkcjonalności. Podstawowymi elementami, które powinniśmy wziąć do oceny funkcjonalności są:

Wysiłek wymagany do wdrożenia funkcjonalności – czy zadanie w projekcie jest ciężkie w realizacji? Jak dużo czasu i środków powinniśmy przeznaczyć?

Wpływ na użytkowników – czy użytkownicy skarżą się na brak funkcjonalności? Jak bardzo istotne będzie umieszczenie funkcjonalności dla użytkowników?

Dobrym sposobem jest przypisanie skali punktowej (np. od 1 do 5) do wysiłku i wpływu – dzięki czemu stworzymy prostą miarę informującą o priorytecie danej funkcjonalności. Tak zmapowane punkty umieszcza się na wykresie, który następnie dzieli się na cztery kategorie:

Przy planowaniu zakresu prac nad MVP należy pamiętać, że dodawane do zakresu funkcjonalności mogą znacznie rozminąć się z oczekiwaniami i potrzebami użytkowników. Najprostszym sposobem na ograniczenie ryzyka jest rozpoczęcie projektu od kilku, absolutnie koniecznych funkcjonalności, bez których użytkownicy nie będą używać aplikacji – a następnie rozwijać projekt o nowe elementy, aby osiągnąć product-market fit.

Z tego względu zdecydowana większość projektów IT, w szczególności projektów MVP jest dzielona na etapy i zarządzana przy pomocy zwinnych metodyk prowadzenia projektów – aby szybko i sprawnie dopasować zakres funkcjonalności do realnych potrzeb użytkowników. Inwestycja znacznych środków w aplikację mającą kilkadziesiąt funkcjonalności i wymaga roku pracy dziesięcioosobowego zespołu praktycznie zawsze można podzielić na mniejsze etapy. Podejście iteracyjne do realizacji MVP daje nam przede wszystkim możliwość szybszego osiągnięcia product-market fit – i ogranicza koszt ewentualnej porażki projektu.

Z pewnością po wydaniu MVP priorytety mogą się zmienić i funkcjonalności mogą zmienić swoje miejsca w tabelach po weryfikacji z użytkownikami. Dlatego warto cyklicznie stosować te metody priorytetyzacji po otrzymaniu informacji zwrotnej od użytkowników, gdyż ich potrzeby mogą się różnić od tego, co zakładaliśmy w fazie planowania.

Podsumowanie

Błędnie określony zakres funkcjonalności MVP jest częstym powodem niepowodzenia projektów, co może prowadzić do zbyt dużych kosztów, a czasem nawet do upadków startupów. W części przypadków, poprzez złe planowanie prac, startupowe projekty mogą nawet nie dotrzeć do użytkowników przez brak finansowania – które jest ciężko uzyskać bez zademonstrowanej trakcji projektu. Z tego względu zakres funkcjonalności MVP powinien być możliwie najmniejszy. Powszechnie powtarzającymi się przyczynami źle określonego zakresu prac projektów MVP jest brak zainteresowania i zbadania realnych problemów i potrzeb użytkowników, a następnie tworzenie specyfikacji na podstawie niepotwierdzonych danych - “tak mi się wydaje” może często nie być poprawnym uzasadnieniem.

Podstawową rzeczą, która trzeba zapamiętać próbując określić zakres prac swojego MVP to podejście “user first”. Trzymanie użytkownika w centrum uwagi i budowanie funkcjonalności na podstawie jego problemów i wyzwań jest mimo wszystko najbardziej skuteczną metodą planowania funkcjonalności, jednak wymaga dobrze przeprowadzonej analizy potrzeb użytkowników. Trafne określenie potrzeb klientów, a co za tym idzie - odpowiednich funkcjonalności, pozwala odpowiednio oszacować budżet potrzebny do realizacji projektu.

Najczęściej głównymi potrzebami startupów w fazie pre-seed jest krótki time-to-market, osiągnięcie product market fit i przez to – zbudowanie trakcji, która przekona inwestorów do finansowania projektu. Wszystkie te cele mogą zostać osiągnięte przez rozpoczęcie prac od MVP.

Możemy pomóc Ci z Twoim MVP - stworzyliśmy już wiele takich aplikacji. Jeżeli chciałbyś/chciałabyś dowiedzieć się jak jako iMakeable możemy pomóc, zapraszam Cię na naszą podstronę dedykowaną właśnie MVP Developmencie.