Zakres MVP: ważniejsze jest to, czego NIE budować

Termin MVP — minimum viable product — został wprowadzony przez Franka Robinsona i spopularyzowany przez książkę Erica Riesa „The Lean Startup” (2011). Kluczowe słowo to minimum. To także słowo, które początkujący najgorzej rozumieją: po „nikt tego nie potrzebuje”, największym zabójcą startów jest „nigdy nie zostało wysłane” — produkt rozrósł się o funkcje i nigdy nie ujrzał światła dziennego. Ta lekcja jest o nożu, którym tniesz zakres.

Kluczowa pętla użytkownika

Opisz JEDNĄ ścieżkę, za którą ludzie płacą: przybywa → robi główną rzecz → otrzymuje wartość → wraca. Przykład (usługa podsumowująca rozmowy): przesyłasz nagranie → dostajesz notatki z zadaniami → wysyłasz je do zespołu. Cokolwiek, co nie jest na tej pętli, nie jest MVP.

Klasyczny przykład: pierwsza wersja Instagrama nazywała się Burbn i oferowała meldowanie się, plany spotkań, punkty i zdjęcia. Użytkownicy korzystali tylko ze zdjęć. Kevin Systrom odciął całą resztę i zachował jedną pętlę: zrób zdjęcie → nałóż filtr → opublikuj. Dwa lata później Facebook kupił go za miliard dolarów. Pętla napędza produkt; dodatki go zatapiają.

Nóż zakresu: trzy listy

1. Teraz (pętla + logowanie + płatność): bez tego nie ma produktu.
2. Później (gdy masz prawdziwych użytkowników): motywy, integracje, zespoły, ustawienia.
3. Nie teraz (pokusy): aplikacja mobilna, API, marketplace. Zapisz to, a potem zapomnij, dopóki nie będziesz mieć stu klientów.

Test dla każdej funkcji: „Czy użytkownik zrezygnowałby w pierwszym miesiącu, gdyby tego brakowało?” Nie — trafia na listę drugą. To jedno pytanie oszczędza tygodnie.

Sokratejska pauza

Masz zamiar dodać „ustawienia powiadomień” do MVP. Zatrzymaj się i zapytaj: czy choć jedna osoba zrezygnowałaby w pierwszym miesiącu, gdyby powiadomienia działały po prostu na rozsądnych domyślnych ustawieniach, bez żadnych opcji? Odpowiedź prawie zawsze brzmi nie. Co oznacza: lista „na później”.

Mity początkujących

• „MVP to zły produkt.” Nie. To wąski, ale dobry produkt: jedna rzecz zrobiona dobrze, a nie dziesięć źle.
• „Nie zadziała bez social login / dark mode / aplikacji mobilnej.” Rzeczy działają na samej pętli. Dopracowanie dodaje się na podstawie prawdziwych użytkowników.
• „Dodam to na wszelki wypadek.” „Na wszelki wypadek” to najdroższe zdanie w oprogramowaniu. Każda funkcja to kod, błędy i utrzymanie — na zawsze.

Brief produktowy dla AI

Bierzemy brief z kursu vibe coding i rozwijamy go w brief produktowy:

Produkt: [nazwa] — [dla kogo] — [kluczowa wartość].
Loop: [kroki użytkownika].
Strony: landing, logowanie, aplikacja (jeden działający ekran!), minimalne ustawienia.
Dane: [encje i pola — jak uczono na lekcji o bazach danych].
Nie w MVP: [lista „na później” — umieść ją bezpośrednio w briefie, aby AI nie budowało dodatków].
Styl: [referencja + paleta].

Ta linia „nie w MVP” to tajny składnik. Asystent AI (model, który pisze kod na podstawie twojego opisu) uwielbia być pomocny i wypełniać luki: poproś o formularz logowania, a dostaniesz odzyskiwanie hasła, uwierzytelnianie dwuskładnikowe i stronę ustawień profilu w pakiecie. Wyraźny zakaz trzyma zakres na smyczy.

Tempo i diagnoza

MVP zbudowane na podstawie tego briefu w Lovable/Replit zajmuje 2–4 tygodnie wieczorami. Jeśli twój szacunek jest dłuższy, zakres jest nadal zbyt duży: ogranicz pętlę do jednego scenariusza. Zasada jest prosta — pytanie nie brzmi „co jeszcze mógłbym dodać”, ale „co jeszcze mogę wyrzucić, zachowując nienaruszoną pętlę”. Każda odrzucona rzecz to dzień, którego nie zmarnowałeś.

Gdzie to idzie źle: „Nie mogę niczego wyciąć, wszystko jest ważne”

Najczęstszy sprzeciw w tej lekcji brzmi: „ale wszystko w moim produkcie jest połączone, nic nie może zniknąć”. To prawie zawsze iluzja wynikająca ze zbyt bliskiego patrzenia na własny pomysł. Przetestuj to uczciwie: weź funkcję, której „nie możesz usunąć” i wyobraź sobie użytkownika, który nigdy jej nie otwiera w pierwszym miesiącu. Czy nadal otrzymuje wartość? Jeśli tak, ta funkcja nie jest na pętli — może i powinna poczekać.

Tnie się zakres nie dlatego, że funkcje są złe, ale dlatego, że w tej chwili uniemożliwiają one wysłanie produktu. Odłożone nie oznacza odrzucone; czeka na swoją kolej na liście „na później”.

Jak to łączy się z innymi kursami

Dane i encje do briefu (co i jak przechowywać) mają swoją własną lekcję o kontach i danych później w tym kursie, a podstawowa technika budowania na podstawie briefu znajduje się w kursie vibe coding. Tutaj brief zmienia się z technicznego w produktowy — z tą wyraźną linią „nie w MVP”.

Zrób to teraz (5 minut)

Weź swój pomysł z ostatniej lekcji i zapisz pętlę jako jedną linię strzałek. Następnie wypisz wszystko, co chcesz umieścić w produkcie, i uczciwie posortuj to na trzy listy. Jeśli lista „Teraz” ma więcej niż 5 pozycji, tnij dalej.