Tworzenie MVP
Tworzenie MVP dla produktów dwustronnych
MVP to nie tańsza wersja docelowego produktu. To najmniejsza rzecz, która odpowiada na pytanie, co do którego naprawdę nie masz pewności – a w produktach dwustronnych tym pytaniem prawie nigdy nie jest lista funkcji.
- produktów wdrożonych
- 20+produktów wdrożonych
- niszy branżowych
- 4niszy branżowych
- lat budowania
- 4lat budowania
Większość MVP sprawdza niewłaściwą rzecz.
Zespoły budują cienką wersję każdej funkcji i to wypuszczają. Wraca mglisty sygnał: trochę rejestracji, mało użycia, zero jasności dlaczego. Zakres powstał z tego, co łatwo było wyciąć, a nie z tego, co było naprawdę niepewne.
W produkcie dwustronnym niepewność prawie zawsze siedzi po jednej stronie. Czy zdobędziemy podaż bez popytu. Czy ktokolwiek przejdzie weryfikację, zanim będzie co kupić. Czy druga strona wróci po tygodniu. Dobre MVP jest ukształtowane wokół tego pytania i bezwzględne wobec całej reszty.
Dość często zajmujemy też przeciwne stanowisko: czasem pierwsza wersja nie powinna być oprogramowaniem. Arkusz, grupa na czacie i człowiek dopasowujący ręcznie odpowiedzą szybciej i taniej – i powiemy, kiedy tak właśnie jest.
Co rozumiemy przez MVP
Wąskie w zakresie, nie niechlujne w wykonaniu.
Jedno pytanie, ustalone na starcie
Spisujemy, co ta wersja ma udowodnić i jaki wynik oznacza „nie”. Późniejsze spory o zakres rozstrzygamy względem tego jednego zdania.
Jedna strona zrobiona porządnie
Zwykle trudniejsza strona dostaje pełne doświadczenie, a druga minimum pozwalające na transakcję. Równy podział wysiłku kończy się tym, że żadna strona nie jest używalna.
Realne mechanizmy zaufania, w wersji minimalnej
Najsłabsza weryfikacja, jaką twoja kategoria toleruje, z ręcznym procesem za nią tam, gdzie automatyzacja nie jest jeszcze warta budowania.
Ręcznie tam, gdzie ręcznie jest taniej
Dopasowywanie, zatwierdzenia i wypłaty mogą przez pierwsze miesiące iść przez panel i człowieka. Budujemy panel, nie automatyzację.
Instrumentacja od pierwszego dnia
Zdarzenia, które odpowiadają na pytanie, a nie dashboard metryk próżności. Jeśli MVP nie potrafi powiedzieć, dlaczego się nie udało, nie udało się podwójnie.
Architektura, którą da się zostawić
Czysty, testowany, udokumentowany kod w twoich repozytoriach. Wąski zakres to decyzja produktowa, a nie wymówka dla kodu, który następny programista będzie chciał skasować.
Jak przebiega budowa
Osiem do dwunastu tygodni od pierwszej rozmowy do realnych użytkowników, jeśli zakres się trzyma.
- 01
Zdefiniowanie pytania
Dziewięćdziesiąt minut na ustalenie, co ta wersja ma udowodnić i która strona niesie ryzyko. Zwykle połowa briefu odpada na tym etapie.
Tydzień 0 - 02
Najpierw przepływy, potem piksele
Tylko ścieżki służące temu pytaniu, rozrysowane od początku do końca, razem ze stanami pustymi, które dominują w pierwszych tygodniach.
1-2 tygodnie - 03
Budowa w tygodniowych sprintach
Działające oprogramowanie od pierwszego sprintu, demo co tydzień i zakres wymieniany na termin jawnie, a nie po cichu kosztem jakości.
6-10 tygodni - 04
Start i odczytanie odpowiedzi
Oprzyrządowany start, a potem sesja o tym, co mówią dane: kontynuujemy, zmieniamy kształt albo kończymy. Zakończenie jest pełnoprawnym wynikiem i powiemy to wprost.
Na bieżąco
Pierwsze wersje, które stały się produktami
Każda zaczynała wąsko i zachowała swój kod.
Na czym to budujemy
Ten sam stack co w pełnych wdrożeniach – MVP nie jest powodem, żeby sięgać po narzędzia na wyrzucenie.
Produkt
- Next.js
- React
- TypeScript
- React Native
Backend
- Node.js
- NestJS
- PostgreSQL
- MongoDB
Operacje
- AWS
- CI/CD
- Analityka
- Monitoring błędów
Pytania, które dostajemy przed budową MVP
Osiem do dwunastu tygodni dla produktu dwustronnego, jeśli zakres się trzyma. Zmienną nie jest nasze tempo, tylko to, jak szybko zostanie zdefiniowane pytanie i jak twardo zakres pozostanie zamknięty.
Przede wszystkim dyscyplina zakresu. Dalej: ile weryfikacji i przepływu pieniędzy pierwsza wersja naprawdę potrzebuje, czy pełnego doświadczenia wymaga jedna strona czy obie i czy aplikacja natywna jest konieczna na starcie. Zakres i wyłączenia spisujemy przed podpisaniem umowy.
Przy prototypach i narzędziach wewnętrznych często tak. Przy produkcie, który obraca cudzymi pieniędzmi i tożsamością, audyty budów wspieranych przez AI pokazują u nas zwykle te same luki: brak modelu uprawnień, brak narzędzi administracyjnych i model danych, który nie uniesie drugiej funkcji. Opisaliśmy, ile naprawdę kosztuje taka przebudowa.
Nie, jeśli jest zbudowane porządnie. Wąski zakres to decyzja produktowa, a nie przyzwolenie na kod, którego nikt nie rozwinie. Kilka naszych MVP po dwóch latach działa na tym samym kodzie.
To znaczy, że zrobiło swoje za ułamek kosztu dowiedzenia się tego później. Wolimy być studiem, które powiedziało to w dziesiątym tygodniu, niż takim, które fakturowało do dwudziestego miesiąca.
Czasem, w ramach partnerstwa, a nie standardowej umowy. Jest o tym osobna strona.
Powiedz nam, czego nie jesteś pewien. Trzydzieści minut, bez sprzedaży. Jeśli najszybszą drogą do odpowiedzi nie jest oprogramowanie, powiemy to w pierwszej kolejności.
Umów rozmowę