Co Twój SaaS-owy MVP powinien — i czego nie powinien — zawierać przy starcie

Słowo „minimum" w minimum viable product to ta część, którą wszyscy ignorują. Założyciele przytakują idei zaczynania od małego, a potem wręczają specyfikację z czterdziestoma ekranami, trzema rolami użytkowników, silnikiem rozliczeń, panelem analitycznym i „a, i ma się integrować ze wszystkim". To nie jest MVP. To pełny produkt z optymizmem podkręconym do maksimum. I jest to najczęstszy powód, dla którego pierwsze starty pojawiają się z opóźnieniem, ponad budżet i jakimś cudem wciąż bez tej jednej rzeczy, której klienci naprawdę chcieli.

Pomogłem sporej liczbie małych firm i samodzielnych założycieli wypuścić ich pierwszy produkt programistyczny. Część techniczna rzadko jest tym, na czym ludzie się potykają. Trudną częścią — za każdym razem — jest decyzja, czego nie budować jeszcze. MVP to nie mniejsza wersja produktu Twoich marzeń z losowo zeszlifowanymi funkcjami. To świadomy zakład: najmniejsza rzecz, jaką możesz postawić przed prawdziwymi użytkownikami, dowodząca, że główny pomysł jest wart więcej Twoich pieniędzy i czasu.

To więc przewodnik, który chciałbym, żeby więcej założycieli przeczytało przed napisaniem specyfikacji. Bez żargonu, bez teatru „move fast and break things". Po prostu praktyczny sposób na wyznaczenie granicy między tym, co należy do pierwszego wydania, a tym, co może — i powinno — poczekać.

Czym MVP właściwie jest (a czym nie)

Wyprostujmy definicję, bo większość zamieszania zaczyna się tutaj. MVP to najmniejsza, najprostsza wersja Twojego produktu, która pozwala prawdziwej osobie zrobić tę jedną wartościową rzecz, którą obiecuje Twój produkt — i pozwala Ci dowiedzieć się, czy wróci, by zrobić to ponownie. Tyle. To narzędzie do nauki, które akurat składa się z działającego oprogramowania, a nie okrojony start gotowego produktu.

Kluczowe słowo to viable (zdolny do życia). Częstym błędem jest odczytanie „minimum" i wypuszczenie czegoś tak ubogiego, że zawstydza użytkownika — pół-przepływu, który się zawiesza, rejestracji prowadzącej do pustego ekranu. To nie jest minimum-viable, to minimum-zepsute. Drugą porażką jest przeciwieństwo: produkt tak „kompletny", że jego budowa zajęła rok, a do tego czasu wydałeś swoje rezerwy na udowodnienie domysłu, który mogłeś przetestować w osiem tygodni.

Oto test mentalny, którego używam. Dla każdej funkcji na liście zapytaj: gdybyśmy to usunęli, czy użytkownik nadal mógłby osiągnąć ten jeden główny rezultat, dla którego istnieje produkt? Jeśli odpowiedź brzmi tak, to prawie na pewno nie jest to MVP. To pytanie samo w sobie przetnie większość specyfikacji na pół — a połowa, którą odcina, to ta połowa, która miała Cię spóźnić.

Znajdź jedno zadanie, które wykonuje Twój produkt

Zanim zdecydujesz, co budować, musisz być brutalnie jasny co do jednego zadania, które Twój produkt wykonuje dla kogoś. Nie wizja. Nie roadmapa. Jedno powtarzalne działanie, które, jeśli zadziała, poprawia komuś dzień i sprawia, że jest gotów zapłacić. Większość kuleją­cych specyfikacji jest niejasna właśnie tutaj — opisują platformę, a nie zadanie.

Spróbuj dokończyć to zdanie na głos: „Użytkownik przychodzi do mojego produktu, żeby ______, i odchodzi, mając ______." Narzędzie do grafików: kierownik przychodzi opublikować grafik na przyszły tydzień, a odchodzi z każdą zmianą obsadzoną i zespołem powiadomionym. Aplikacja do fakturowania: freelancer przychodzi wystawić rachunek klientowi, a odchodzi z wysłaną, śledzoną fakturą. Jeśli nie potrafisz wypełnić tego zdania czysto, nie jesteś jeszcze gotów określać zakresu — jesteś gotów myśleć.

Czego naprawdę potrzebuje każde SaaS-owe MVP

Niektóre rzeczy nie podlegają negocjacji, nawet w najszczuplejszej pierwszej wersji — nie dlatego, że są ekscytujące, ale dlatego, że bez nich produkt albo nie da się używać, albo niczego Cię nie nauczy. Traktuj je jak podłogę, nie sufit. Buduj je prosto, ale buduj porządnie.

• Sposób logowania. Wystarczy nawet jeden login z e-mailem i hasłem — ale prawdziwy, bezpieczny, bo wszystko inne zależy od wiedzy, kim jest użytkownik.
• Główny przepływ pracy, od początku do końca. Jedno zadanie, od pierwszego kliknięcia użytkownika do chwili, gdy uzyska wartościowy rezultat — żadnych ślepych zaułków, żadnych przycisków „wkrótce" na krytycznej ścieżce.
• Miejsce, gdzie dane faktycznie żyją. Prawdziwa pamięć, nie jednorazowy prototyp, żeby praca użytkownika przetrwała odświeżenie i mógł wrócić jutro.
• Sposób, byś widział, co się dzieje. Podstawowe logowanie lub prosty widok administratora, żebyś gdy coś się zepsuje — a zepsuje się — mógł dowiedzieć się dlaczego, bez zgadywania.
• Sposób, by użytkownicy mogli się z Tobą skontaktować. Nawet sam link e-mail. Pierwsi użytkownicy natrafią na krawędzie, których nie przewidziałeś; chcesz, żeby Ci o tym mówili, a nie po cichu odchodzili.
• Absolutne minimum zaufania: nota o prywatności, rozsądne obchodzenie się z danymi i nierobienie niczego lekkomyślnego z informacjami ludzi.

Zwróć uwagę na to, czego nie ma na tej liście: rozliczeń, wymyślnego onboardingu, stron ustawień, aplikacji mobilnych, integracji. Za chwilę dojdziemy do tego, dlaczego. Sens podłogi jest taki, że jest dość mała, by ją skończyć, i dość solidna, by się od niej uczyć. Logowanie, które działa, jeden przepływ, który dostarcza, prawdziwe dane i sposób na obserwowanie i rozmowę z użytkownikami. To jest produkt zdolny do życia.

Co świadomie pominąć w v1

To sekcja, której założyciele się opierają, więc będę szczery: większość rzeczy, które wydają się niezbędne dla Twojego pierwszego startu, taka nie jest. Wydają się niezbędne, bo „prawdziwy produkt" je ma — ale Ty nie budujesz jeszcze prawdziwego produktu, budujesz pytanie. Pominięcie ich to nie pójście na skróty. To cała dyscyplina MVP.

Automatyczne rozliczenia i złożony cennik

Niemal na pewno nie potrzebujesz w wersji pierwszej samoobsługowego silnika rozliczeń, planów warstwowych, proporcjonalnego naliczania i logiki upomnień. Jeśli pierwsi użytkownicy chcą zapłacić, możesz przyjąć ich pieniądze ręcznie — faktura, link do płatności, krótki telefon. Ręczne rozliczanie pierwszych dziesięciu klientów mówi Ci coś, czego automatyczne rozliczanie nie potrafi: czy ktokolwiek w ogóle zapłaci. Buduj maszynę, gdy udowodnisz, że jest co inkasować.

Rozbudowane role i uprawnienia

Systemy uprawnień z wieloma rolami — administratorzy, kierownicy, obserwatorzy, drobiazgowe reguły dostępu — to prawdziwe inżynierskie bagno i ogromnie mnożą powierzchnię testowania. Dla pierwszego wydania jeden rodzaj użytkownika prawie zawsze wystarczy. Prawdziwych potrzeb co do uprawnień nauczysz się, obserwując, jak prawdziwe zespoły używają tej rzeczy, a te potrzeby rzadko są tym, co zgadłbyś na papierze.

Integracje, natywne aplikacje mobilne i panel

„Musi się integrować ze wszystkim" to zdanie, które po cichu podwaja harmonogramy. Wybierz najwyżej jedną integrację, i tylko jeśli jest częścią głównego zadania. Natywne aplikacje iOS i Android prawie zawsze mogą poczekać — responsywna aplikacja webowa działa dziś na telefonie. A ten panel analityczny, którego wszyscy chcą? Użytkownicy nie mogą analizować danych, których jeszcze nie utworzyli. Najpierw wypuść rzecz, która tworzy dane; wizualizuj je, gdy będzie co pokazać.

Prosta metoda na wyznaczenie granicy

Znajomość zasady to jedno; zastosowanie jej do własnej specyfikacji, gdzie każda funkcja wydaje się Twoim dzieckiem, jest trudniejsze. Oto metoda, która działa, bo wymusza decyzję dla każdej pozycji, zamiast pozwalać wszystkiemu dryfować w „niezbędne".

1. 1
   Wypisz każdą funkcję, jaką sobie wyobraziłeś

   Wyrzuć to wszystko — jeszcze bez filtrowania. Połóż pełną listę życzeń na stole, żeby nic nie czaiło się niewypowiedziane i nie pojawiło się w połowie budowy jako niespodzianka.
2. 2
   Oznacz każdą względem głównego zadania

   Dla każdej funkcji zapytaj: czy użytkownik potrzebuje tego, by dokończyć jedno główne zadanie od początku do końca? Oznacz ją „rdzeń", „pomocne" lub „kiedyś". Bądź szczery — większość ląduje w dwóch ostatnich.
3. 3
   Zostaw tylko „rdzeń" na v1

   Twoje MVP to stos „rdzenia" i nic więcej. Stosy „pomocne" i „kiedyś" nie są odrzucone — to Twoja roadmapa, zaparkowana tam, gdzie należy.
4. 4
   Sprawdź cięcie zdrowym rozsądkiem

   Spójrz na to, co zostało, i zapytaj: czy prawdziwy użytkownik może uzyskać prawdziwą wartość tylko z tego? Jeśli tak, określiłeś zakres MVP. Jeśli coś naprawdę psuje główny przepływ, wciągnij z powrotem dokładnie tę jedną pozycję — i nic więcej.

Dyscyplina tkwi w kroku czwartym. Zawsze jest pokusa, by „wciągnąć z powrotem jeszcze tylko jedną rzecz", a potem kolejną, aż po cichu odbudujesz pełny produkt. Pozwól sobie ratować tylko pozycje, które naprawdę psują główny przepływ — nie te, które jedynie uczyniłyby go ładniejszym. Ładniejszy jest od tego, żeby zająć się nim w wersji drugiej.

Zdolny do życia wciąż znaczy, że musi sprawiać wrażenie prawdziwego

Po drugiej stronie granicy jest tryb porażki i warto go nazwać. W pośpiechu, by wypuścić coś małego, niektórzy założyciele wypuszczają coś tandetnego — i nazywają to MVP. Główny przepływ, który gubi Twoją pracę, rejestracja zwracająca 404, treść pełna tekstu zastępczego. To nie testuje Twojego pomysłu uczciwie; testuje, czy użytkownicy tolerują zepsute doświadczenie, a odpowiedź zawsze brzmi nie. Uznasz, że pomysł zawiódł, podczas gdy naprawdę zawiodło wykonanie.

„Minimum" odnosi się do zakresu, nigdy do jakości części, którą zachowujesz. Mniej funkcji, każda solidna. Jeden przepływ pracy, który wypuszczasz, powinien sprawiać wrażenie skończonego — szybkiego, jasnego i godnego zaufania — nawet jeśli to jedyna rzecz, jaką produkt robi. Wąski produkt zrobiony dobrze za każdym razem bije szeroki produkt zrobiony źle, zwłaszcza gdy prosisz obcych ludzi, by powierzyli Ci swoją pracę.

MVP to nie meta — to pierwszy odczyt

Oto część, która przestawia wszystko: start nie jest celem. Celem jest to, czego nauczysz się w tygodniach po nim. MVP, które wychodzi i mówi Ci „użytkownicy kochają rdzeń, ale wciąż proszą o X", to oszałamiający sukces — nawet jeśli X oznacza miesiąc więcej pracy. MVP, które wychodzi w ciszę, gdzie nikt nie wraca, też wykonało swoje zadanie: uchroniło Cię przed budowaniem pozostałych trzydziestu funkcji na fundamencie, którego nikt nie chciał.

Zaplanuj więc pierwsze tygodnie tak świadomie jak budowę. Obserwuj, co ludzie faktycznie robią, a nie co mówią w ankietach. Rozmawiaj z tymi, którzy wrócili, i z tymi, którzy nie. Pozwól, by prawdziwe użycie — a nie Twoja pierwotna specyfikacja — decydowało, co trafi do wersji drugiej. Roadmapa, którą wcześniej zaparkowałeś, nie jest obietnicą; to hipoteza, a Twoi użytkownicy zaraz ją ocenią.

Częste pytania