Zakres MVP: jak zdecydować, co wejdzie do pierwszej wersji aplikacji

Najczęstszy problem z MVP nie jest techniczny. Lista funkcji rośnie na każdym spotkaniu, bo każda wydaje się niezbędna, a po kilku miesiącach powstaje produkt, który robi wiele rzeczy przeciętnie i nie odpowiada na najważniejsze pytanie: czy ktoś chce z niego korzystać.

Zacznij od hipotezy, nie od funkcji

Zanim spiszesz funkcje, zapisz w jednym zdaniu, co MVP ma sprawdzić. Na przykład: „Kierownicy projektów w firmach budowlanych będą co tydzień raportować postęp przez telefon zamiast wysyłać arkusze mailem.”

Do hipotezy dopisz metrykę, która ją potwierdzi albo obali. Nie „użytkownikom się podoba”, tylko zachowanie, które da się policzyć: ilu z zaproszonych użytkowników wróciło w drugim tygodniu, ile raportów powstało, ile firm chce płacić.

Jedna ścieżka od początku do końca

MVP powinno pozwolić użytkownikowi przejść jedną główną ścieżkę od pierwszego ekranu do rezultatu, dla którego w ogóle przyszedł. Lepiej, żeby jedna ścieżka działała całkowicie, niż żeby pięć działało do połowy.

Wypisz wszystkie funkcje, które przychodzą Ci do głowy, i przypisz każdą do jednej z trzech grup:

1. Niezbędne dla głównej ścieżki. Bez nich użytkownik nie dojdzie do rezultatu.
2. Do zrobienia ręcznie. Rzeczy, które na początku może wykonać człowiek za kulisami: zakładanie kont, wysyłka raportów, obsługa płatności na fakturę.
3. Na później. Wszystko inne.

Druga grupa jest najcenniejsza. Ręczna obsługa pierwszych klientów kosztuje czas, ale pokazuje, co naprawdę warto zautomatyzować.

Co zwykle można odłożyć

• Rozbudowany panel administracyjny. Na początku wystarczy prosty podgląd danych albo bezpośredni dostęp do bazy dla zespołu.
• Role i uprawnienia. Jeden typ konta często wystarczy do pierwszych testów.
• Wersje językowe. Chyba że testujesz produkt na kilku rynkach naraz.
• Powiadomienia w wielu kanałach. Mail wystarczy.
• Aplikacje natywne. Jeśli główną ścieżkę da się przejść w przeglądarce na telefonie, aplikacja w sklepie może poczekać.
• Kolejne integracje. Jedna, najważniejsza, zwykle wystarczy.

Czego nie odkładać

„Minimalny” dotyczy zakresu, nie jakości. Nawet pierwsza wersja potrzebuje:

• bezpiecznego logowania i ochrony danych, bo wyciek w MVP jest tak samo realny jak w dojrzałym produkcie,
• analityki mierzącej metrykę z hipotezy, bo bez niej MVP nic nie sprawdzi,
• dopracowanej głównej ścieżki, bo użytkownicy oceniają produkt po tym, co działa, a nie po liście planów,
• podstaw dostępności i polityki prywatności.

Najpierw prototyp

Zanim zaczniesz programować, sprawdź główną ścieżkę na klikalnym prototypie z kilkoma osobami z grupy docelowej. Zmiana w prototypie kosztuje ułamek zmiany w kodzie, a pierwsze rozmowy zwykle zmieniają kolejność ekranów i to, co użytkownik chce zobaczyć najpierw. Z kim rozmawiać i o co pytać, opisaliśmy w artykule o personach B2B.

Stały czas, elastyczny zakres

Najlepiej działa ustalenie terminu i budżetu z góry, a zakresu jako zmiennej. Jeśli coś okazuje się trudniejsze, niż zakładano, wypada z pierwszej wersji, zamiast przesuwać premierę. U nas MVP to zwykle 6–8 tygodni: jedna ścieżka użytkownika, jedna integracja i wdrożenie na produkcję.

Po premierze

Po kilku tygodniach od uruchomienia wróć do hipotezy i metryki. Są trzy uczciwe decyzje: rozwijać, zmienić kierunek albo zakończyć. Każda z nich jest sukcesem MVP, bo każda zapadła na podstawie danych, a nie przeczucia.

Jeśli planujesz produkt cyfrowy i chcesz ustalić zakres pierwszej wersji, zobacz, jak pracujemy nad aplikacjami i SaaS.