„Minimum viable product” to jedna z najczęściej cytowanych i najrzadziej stosowanych idei w branży. W praktyce MVP zawodzą na dwa sposoby. Albo są tak minimalne, że niczego nie dowodzą, albo po cichu rozrastają się do wersji 1.0 z rokiem funkcji, o które nikt jeszcze nie prosił. Oba scenariusze marnują jedyny zasób, którego młody produkt nie odzyska: czas na naukę.
Oto metoda, którą stosujemy z founderami i zespołami produktowymi, by ustalić zakres pierwszej wersji: małej, możliwej do wdrożenia i wciąż odpowiadającej na prawdziwe pytanie.
Nazwij założenie, które testujesz
MVP to eksperyment, a eksperyment potrzebuje hipotezy. Zanim powstanie lista funkcji, zapisz najbardziej ryzykowne założenie stojące za produktem. Zwykle jest to jedno z tych:
- Popyt: ludzie, o których myślimy, mają ten problem na tyle dotkliwie, że zmienią sposób pracy.
- Wartość: nasz sposób rozwiązania jest wyraźnie lepszy od tego, co robią dziś, łącznie z nicnierobieniem.
- Gotowość do zapłaty: oni albo ich firma zapłacą cenę, przy której biznes ma sens.
- Wykonalność: naprawdę potrafimy dostarczyć wynik, na przykład z akceptowalną trafnością AI albo na danych, do których mamy legalny dostęp.
Wybierz to, które zabiłoby produkt, gdyby okazało się fałszywe, i ustaw zakres MVP tak, żeby je sprawdzić. Produkt, którego największym ryzykiem jest gotowość do zapłaty, potrzebuje w pierwszej wersji koszyka i cennika. Produkt, którego największym ryzykiem jest wykonalność, może nie potrzebować żadnego interfejsu, tylko procesu, który udowodni, że wynik jest wystarczająco dobry.
Narysuj jedną ścieżkę, która musi działać
Następnie opisz jedną ścieżkę, którą użytkownik musi przejść, żeby test w ogóle miał sens. Nie cały produkt: jedną drogę, od pierwszego kontaktu do momentu, w którym dostaje wartość.
Dla narzędzia B2B do grafików pracy może to być: kierownik zakłada konto, importuje zespół, publikuje grafik, a pracownicy widzą swoje zmiany w telefonie. Wszystko na tej ścieżce musi działać porządnie. Wszystko poza nią to kandydat na później.
Zapisanie ścieżki jako krótkiej historii, ekran po ekranie, to też najszybszy sposób, by odkryć, że dwie osoby w zespole miały w głowie dwa różne produkty.
Zdecyduj, co zrobić ręcznie
Zaskakująco dużą część wczesnego produktu da się obsłużyć ręcznie albo gotowymi narzędziami, o ile użytkownik nie odbiera tego jako czegoś zepsutego:
- onboarding przeprowadzony przez człowieka na rozmowie zamiast samoobsługowego kreatora;
- raporty wysyłane jako arkusz lub PDF zamiast panelu analitycznego;
- rozliczenia przez fakturę albo link do płatności zamiast pełnego systemu subskrypcji;
- panel administracyjny na gotowym narzędziu zamiast własnego back office’u;
- integracje przez cykliczny eksport zamiast API w czasie rzeczywistym.
Każda z tych decyzji oszczędza tygodnie. Każda też czegoś uczy: jeśli klienci wciąż proszą o wersję samoobsługową, wiesz, co budować dalej.
Czego nigdy nie obcinać
Minimalny zakres to co innego niż niedbałe fundamenty. Niektóre rzeczy są drogie do dodania później i tanie do zrobienia dobrze od początku:
- Logowanie i uprawnienia oparte na sprawdzonym dostawcy, a nie na domowej roboty mechanizmie.
- Model danych zgodny z biznesem, zwłaszcza wokół kont, organizacji i ról. Wielodostępność (multi-tenancy) bardzo boleśnie dokłada się po fakcie.
- Podstawowa higiena bezpieczeństwa i prywatności: szyfrowane połączenia, sekrety poza kodem, dane osobowe przetwarzane z myślą o RODO.
- Analityka na tej jednej ścieżce, żeby widzieć, gdzie ludzie odpadają. Bez niej eksperyment nie ma wyniku.
- Automatyczne wdrożenia, żeby wypuszczenie poprawki trwało minuty i nikt nie bał się releasów.
- Podstawy dostępności i wydajności, które w nowym kodzie kosztują niewiele, a w starym dużo.
Wybierz nudną technologię
MVP to nie miejsce na testowanie trzech nowych frameworków. Wybierz stack, który zespół dobrze zna i który wciąż będzie rozsądny, jeśli produkt odniesie sukces. Dla wielu produktów SaaS oznacza to TypeScript z Reactem lub Next.js, zarządzaną bazę PostgreSQL i popularną chmurę. Chodzi o to, by udane MVP stało się fundamentem produktu, a nie prototypem do wyrzucenia pod presją czasu.
Najpierw ustal czas, potem zakres
Najpierw ustal ramy czasowe, a potem dopasuj do nich zakres. Kilka tygodni do pierwszych prawdziwych użytkowników to zdrowy cel dla większości MVP w B2B. Jeśli narysowana ścieżka się nie mieści, tnij wzdłuż ścieżki, a nie w poprzek: upraszczaj kroki, rób więcej ręcznie, zawęź grupę odbiorców. Nie wypuszczaj połowy każdej funkcji.
Ustal z góry, jaki wynik uznacie za sukces, jaki za porażkę i co zrobicie w każdym z tych przypadków. Wtedy premiera staje się decyzją, a nie nastrojem.
Po starcie: najpierw ucz się, potem buduj
Najcenniejszym efektem MVP nie jest kod, tylko to, czego dowiesz się w pierwszych tygodniach użycia. Rozmawiaj z każdym wczesnym użytkownikiem, z którym się da. Obserwuj analitykę na ścieżce. Prowadź krótką listę tego, o co ludzie proszą i jak często. Potem planuj wersję drugą na podstawie danych.
Jeśli przygotowujesz nowy produkt, nasz zespół SaaS i MVP może przeprowadzić z Tobą krótkie warsztaty discovery, zdefiniować ścieżkę i eksperyment, a potem zbudować pierwszą wersję z opisanymi wyżej fundamentami. Nasi projektanci UX i UI prototypują ścieżkę, zanim powstanie choćby linijka kodu. Opowiedz nam o swoim pomyśle.