CB Insights co roku publikuje zestawienie przyczyn upadania startupów. Od lat na pierwszym miejscu widnieje ten sam powód: „brak potrzeby rynkowej". Nie złe wykonanie. Nie brak pieniędzy. Nie słaby zespół. Produkt po prostu nie rozwiązywał problemu, na który ludzie byli gotowi zmienić swoje zachowanie.
Ta statystyka jest zadziwiająca, biorąc pod uwagę, ile wysiłku wkłada się w budowanie produktów. Zespoły spędzają miesiące — czasem lata — projektując systemy, pisząc kod, kłócąc się o architekturę i doskonaląc przepływy. A najczęstszą przyczyną porażki jest to, że nikt nie zapytał, czy w ogóle rozwiązuje to realny problem.
Budowanie produktów, których ludzie naprawdę chcą, to nie talent. To dyscyplina. Ma swoją metodę, a tej metody można się nauczyć.
Najczęstszy błąd produktowy polega na zakochaniu się w rozwiązaniu, zanim dogłębnie zrozumie się problem. To niemal powszechne wśród pierwszych założycieli i zaskakująco częste wśród doświadczonych. Schemat jest zawsze ten sam: ktoś ma pomysł, uważa go za przekonujący i zaczyna budować. Klient jest wtórny — kimś do przekonania, a nie do zrozumienia.
Antidotum jest proste, choć wymaga dyscypliny: spędź więcej czasu na problemie, niż uważasz za uzasadnione, zanim w ogóle pomyślisz o rozwiązaniach. Rozmawiaj z ludźmi, którzy mają ten problem. Obserwuj, jak pracują. Zrozum obejścia, których dziś używają, i dlaczego są niedoskonałe. Dopiero wtedy masz wystarczający kontekst, by zaprojektować coś, co naprawdę pasuje.
Dobry rozwój produktu to nie linia prosta — to pętla. Każda iteracja wokół pętli to okazja do zastąpienia założeń dowodami. Zespoły, które budują produkty, których ludzie chcą, to te, które przechodzą tę pętlę szybko i często.
Pętla nie jest formalnością. Każdy etap ma konkretny wynik, który staje się wejściem do następnego. Pomijanie etapów — najczęściej przeskakiwanie wprost od Problemu do Budowania — to właśnie produkuje produkty, które chybiają.
Nie wszystkie problemy warte są rozwiązania. Dobry problem produktowy ma trzy cechy: jest częsty (dotyczy ludzi często, nie rzadko), intensywny (ludzie czują go na tyle mocno, że chcą ulgi) i istniejące rozwiązania są naprawdę niewystarczające (nie tylko nieco inne od tego, co byś zbudował).
Błąd polega na optymalizowaniu pod kątem pierwszej cechy i ignorowaniu pozostałych dwóch. „Ludzie marnują czas na spotkaniach" to problem częsty. Ale jeśli ból jest niski — jeśli ludzie znaleźli wystarczająco dobre obejścia — problem może nie być wart komercyjnego rozwiązania. A jeśli istnieje już dwanaście narzędzi robiących to, co chcesz zrobić, potrzebujesz bardzo konkretnego powodu, dlaczego Twoje byłoby wybierane.
Badania mają złą reputację w kręgach produktowych — kojarzą się z powolnymi konsultingami, grubymi raportami i wynikami, których nikt nie czyta. To porażka wykonania, nie samej praktyki. Dobre badania produktowe są szybkie, konkretne i zmieniają to, co budujesz.
Celem badań nie jest potwierdzenie, że problem jest realny. Powinieneś w to wierzyć zanim poważnie zainwestujesz w badania. Celem jest zrozumienie problemu wystarczająco głęboko, by wiedzieć, jak wygląda dobre rozwiązanie: kto konkretnie ma ten problem, w jakim kontekście, co już próbował, jakich słów używa do jego opisania i jak dla niego wygląda „rozwiązany".
Hipoteza to konkretna, falsyfikowalna prognoza dotycząca tego, w co wierzysz. Wymusza jasność. Jeśli nie możesz zapisać jasnej hipotezy, nie rozumiesz jeszcze problemu wystarczająco dobrze, by budować rozwiązanie.
Użyteczna hipoteza produktowa ma trzy części:
Sygnał jest najważniejszą częścią — i najczęściej pomijaną. Bez wcześniej ustalonego sygnału każdy eksperyment „jakoś zadziałał". Zespoły znajdują sposoby na interpretowanie niejednoznacznych danych na swoją korzyść. Hipoteza bez warunku falsyfikacji to tylko życzenie.
Faza budowania to ta, w której większość zespołów spędza zbyt dużo czasu. Celem nie jest zbudowanie produktu — lecz zbudowanie minimalnej rzeczy, która da sygnał dotyczący hipotezy. To różne cele i produkują bardzo różne wyniki.
W przypadku większości wczesnych hipotez minimum jest znacznie mniejsze, niż zespoły myślą. Czy możesz ręcznie robić to, co robiłoby oprogramowanie, dla dziesięciu osób, by sprawdzić, czy cenią wynik? Czy możesz połączyć istniejące narzędzia i przetestować przepływ pracy, zanim zbudujesz nową infrastrukturę? Czy możesz naszkicować prototyp i pokazać go pięciu użytkownikom, zanim napiszesz jakikolwiek kod?
Dyscyplina tutaj polega na pytaniu, zanim cokolwiek zbudujesz: „Czego próbuję się nauczyć?" i „Jaka jest minimalna rzecz, która pozwoli mi to odkryć?" Odpowiedź jest prawie zawsze mniejsza niż to, co zespół chce zbudować.
Po wdrożeniu — czy to prototypu, pilotu ręcznego, czy wdrożonej funkcji — faza mierzenia to ta, w której zespoły najczęściej się oszukują. Pytają użytkowników, czy im się podobało. Użytkownicy mówią tak. Zespół zalicza eksperyment jako zwalidowany.
Nastrój to nie sygnał. Jedynym wiarygodnym sygnałem jest zachowanie: czy ludzie zrobili to? Czy wrócili? Czy zapłacili? Czy powiedzieli komuś innemu?
Do pomiaru ilościowego instrumentuj przed wdrożeniem. Wiedz, które konkretne działania śledzisz. Ustal próg z góry — „uznamy to za zwalidowane, jeśli X% użytkowników ukończy Y w ciągu Z dni". Do pomiaru jakościowego przeprowadź ustrukturyzowane wywiady uzupełniające, nie otwarte ankiety satysfakcji.
Faza uczenia się polega na aktualizacji modelu mentalnego użytkownika i problemu, a nie tylko decydowaniu, co zbudować dalej. Zespoły, które pomijają ten krok, zbierają dane, ale nie kumulują zrozumienia. Wykonują szybko, ale z czasem nie poprawiają swojego osądu.
Dobra sesja uczenia się pyta: co przewidzieliśmy? Co się faktycznie stało? Co mówi nam przepaść o naszych założeniach? Co jest teraz najważniejszą rzeczą, której nie wiemy?
Wynikiem fazy uczenia się jest ostrzejsza definicja problemu, poprawiona hipoteza lub — jeśli eksperyment wyraźnie się nie powiódł — decyzja o obraniu zupełnie innego kierunku. Wszystkie te wyniki mają wartość. Najgorszy wynik to niejednoznaczność: „nauczyliśmy się trochę, ale nie wiemy, co zrobić dalej". To znak, że eksperyment nie był wystarczająco konkretny.
Rozwój produktu nigdy nie osiąga etapu, na którym przestajesz uruchamiać tę pętlę. Pytania się zmieniają — na początku walidują, czy problem jest realny; później walidują, czy konkretny element rozwiązania działa — ale struktura jest zawsze ta sama. Obserwuj, formułuj hipotezy, testuj, ucz się.
Zespoły budujące produkty, których ludzie chcą, to nie te z najinteligentniejszym początkowym pomysłem. To te, które przechodzą pętlę najszybciej i najuczciwiej. Prędkość uczenia się, nie prędkość dostarczania, jest przewagą konkurencyjną.