MVP dla startupu: co zmieścić w pierwszej wersji produktu

MVP (minimum viable product, czyli minimalna wersja produktu) to najmniejsza wersja, w której prawdziwy użytkownik przejdzie cały główny proces. Sprawdzisz w niej, czy ktoś chce z produktu korzystać, a najlepiej za niego zapłacić. W pierwszej wersji muszą być: jeden kompletny proces, niezbędne do niego konta i role, prosty panel administratora i dane o użyciu produktu. Raporty, automatyzacje, dodatkowe role i integracje na zapas mogą poczekać. Poniżej pokazujemy, jak wyznaczamy tę granicę, na przykładzie dwóch produktów, które zbudowaliśmy: INVENTA Licenses i Offer Exchange.

Jak znaleźć główny proces produktu?

Zanim zaczniesz wypisywać funkcje, zapisz jedno zdanie: „Użytkownik X robi Y, żeby osiągnąć Z”. Wszystko, co jest potrzebne do Y, wchodzi do MVP. Wszystko inne trafia na listę „później”.

Dwa przykłady z naszych realizacji:

• Offer Exchange: firma wysyła zapytanie ofertowe do grupy handlowców, zbiera oferty, porównuje je i składa zamówienie. To jest cały proces. Handlowiec dostaje e-mailem unikalny link do formularza ofertowego.
• INVENTA Licenses: dystrybutor przydziela klientowi licencję czasową, a klient loguje się w aplikacji VR. Aplikacja sprawdza konto i ważność licencji przez REST API (interfejs, przez który aplikacja pyta serwer o dane). Bez tego łańcucha aplikacji VR nie da się sprzedawać na licencjach.

Zwróć uwagę na link dla handlowców w Offer Exchange. To dobry wzór myślenia o MVP. Zanim zaplanujesz rejestrację, profil i panel dla drugiej strony procesu, sprawdź, czy nie wystarczy jej formularz pod unikalnym adresem. Druga strona dostaje wtedy dokładnie tyle, ile potrzebuje, żeby odpowiedzieć.

Zakres pierwszej wersji

Obszar	W MVP	Może poczekać
Główny proces	kompletny, ze wszystkimi krokami	warianty i wyjątki, które zdarzają się rzadko
Konta i role	tylko role, bez których proces nie działa	role dodawane na zapas, rozbudowane uprawnienia
Panel administratora	zarządzanie kontami i podstawowymi danymi	raporty, wykresy, eksporty
Płatności	jeśli testujesz, czy klienci zapłacą	automaty rabatowe, wiele walut
Powiadomienia	e-mail w najważniejszych momentach procesu	SMS, powiadomienia w przeglądarce
Integracje	tylko te, bez których produkt nie ma sensu	integracje na wypadek przyszłych pytań klientów
Pomiar	podstawowe dane o użyciu	rozbudowana analityka

Jak wyglądały pierwsze wersje naszych produktów

Offer Exchange zaczął od zbierania ofert i porównywarki. Pozostałe funkcje, w tym zamówienia i płatne subskrypcje, doszły w kolejnych wersjach. INVENTA Licenses zaczęło od modułu bez interfejsu graficznego, który komunikował się z aplikacjami VR przez API. Panele dla klientów, dystrybutorów i administratora powstały później. Zbudowanie pierwszej wersji trwało do 6 tygodni, razem ze spotkaniami z klientem.

Nie wszystko w pierwszej wersji się udało. W Offer Exchange porównywarka zestawiała na początku tylko sumy całych ofert, a nie ceny poszczególnych produktów. To był błąd w założeniach, a nie świadome uproszczenie. Wniosek dla MVP: zanim zaprojektujesz główną funkcję, sprawdź z kilkoma użytkownikami, na jakim poziomie szczegółu podejmują decyzję.

Ile ról użytkowników potrzebuje MVP?

Tyle, ile wymaga model biznesowy. Każda rola to osobne widoki, uprawnienia i testy, więc to jeden z głównych czynników kosztu. Piszemy o tym we wpisie o cenie aplikacji webowej.

INVENTA Licenses ma trzy panele (klienta, dystrybutora i administratora) i tu każdy z nich jest uzasadniony. Licencje sprzedają dystrybutorzy, więc to oni muszą zakładać konta klientom i przydzielać licencje. Klient potrzebuje miejsca, w którym zobaczy swoje aplikacje i ważność licencji oraz poprosi o nowe. Administrator zarządza całością. Gdyby produkt był sprzedawany bezpośrednio, panel dystrybutora byłby zbędny.

Czy MVP powinno mieć płatności?

To zależy od tego, co chcesz sprawdzić. Jeśli główne pytanie brzmi „czy ktoś za to zapłaci”, płatności powinny być w pierwszej wersji. Deklaracje w ankietach niewiele mówią.

Offer Exchange pokazuje model, który dobrze się do tego nadaje. Z aplikacji można korzystać bezpłatnie z limitami liczby zapytań w miesiącu, odbiorców zapytania i produktów. Limity zwiększa jedna z trzech płatnych subskrypcji, a płatności i fakturowanie obsługuje Stripe. Użytkownik może zacząć za darmo. Moment, w którym dochodzi do limitu, jest naturalnym miejscem na decyzję o zakupie.

Jeśli płatności nie są tym, co testujesz, na początku wystarczy ręczne fakturowanie kilku pierwszych klientów. Integrację z bramką płatności dodasz, gdy będzie wiadomo, jaki model cenowy działa.

Technologia w pierwszej wersji produktu

Przy MVP często pada zdanie „zrobimy szybko, potem przepiszemy”. Rzadko się to udaje, bo po starcie przepisywanie konkuruje z nowymi funkcjami, o które proszą klienci. Do tego w MVP zbierają się prawdziwe konta, licencje i dane, których nie wyrzucisz.

Dlatego MVP budujemy w tych samych technologiach co pełne produkty: Next.js, React, TypeScript i PostgreSQL (w Offer Exchange także .NET Core). Wdrażamy je w kontenerach Docker za serwerem Nginx. Skracamy zakres, ale fundamentów nie upraszczamy. Model danych, uprawnienia i kopie zapasowe bazy robimy od razu porządnie.

Kilka rzeczy, których pilnujemy przy pierwszej wersji:

• model danych na wyrost tam, gdzie zmiana jest droga, na przykład licencja przypisana do konta i do konkretnej aplikacji zamiast do samego konta,
• API z numerem wersji już w pierwszym wydaniu, jeśli korzystają z niego aplikacje zainstalowane u klientów, jak aplikacje VR w INVENTA Licenses,
• panel administratora wystarczający, żeby obsłużyć klientów bez programisty,
• pomiar użycia, bo bez niego po kilku miesiącach nie wiesz, co rozwijać.

Więcej o tym, jak prowadzimy takie projekty, piszemy na stronie o budowie platform SaaS i MVP.

Plan na kolejne wersje

Lista „później” jest równie ważna jak zakres MVP. Spisz ją od razu i przy każdej pozycji zanotuj, jaki sygnał od użytkowników sprawi, że ją zrealizujesz. Dzięki temu po starcie rozwijasz produkt według tego, co rzeczywiście się dzieje. Najgłośniejsza prośba przestaje wyznaczać kierunek. O tym, jak pracujemy w kolejnych etapach projektu, piszemy we wpisie o tym, jak powstaje oprogramowanie na zamówienie.

Jeśli budujesz własny produkt i zastanawiasz się, co zmieścić w pierwszej wersji, napisz do nas. Pomożemy wyznaczyć zakres MVP i wycenić go etapami.