← Wszystkie wpisy

Minimum Worthy Product: najmniejszy produkt, który zdobywa zaufanie

Przebudowując publiczne powierzchnie produktu ResumeGeni, raz po raz natrafiam na tę samą niewygodną granicę. Wersja, która technicznie działa, nie zawsze jest tą, którą postawię przed osobą szukającą pracy. Parser się uruchamia. Wynik się ładuje. Ścieżka dobiega końca. A jednak coś w tym doświadczeniu przepala zaufanie, zamiast je budować. Siedzę nad tym godzinę, przebudowuję powierzchnię i wrażenie znika — zegar jednak tyka dalej.

To napięcie jest właśnie tematem tego eseju. Ciągną w przeciwne strony dwie siły: wydać wystarczająco szybko, by produkt trafił w świat, i nie wydać produktu, który przepala zaufanie użytkownika. Większość twórców rozwiązuje ten konflikt, wybierając jedną stronę i broniąc jej. Kultura MVP wybiera szybkość. Perfekcjonizm wybiera dopracowanie. Obie odpowiedzi zawodzą, bo w tym napięciu tkwi cały sens.

Minimum Worthy Product to inny standard — wydać najmniejszy produkt, który zdobywa zaufanie, a nie najmniejszy, który da się obronić jako działający. „Godny” to podłoga, nie sufit. „Minimum” to ograniczenie zakresu, a nie zniżka na jakość. Twórca pracujący w duchu MWP tnie funkcje, dopóki produkt nie będzie gotowy do wydania, i utrzymuje każdą pozostałą powierzchnię na poziomie, który użytkownik czuje. Twórca pracujący w duchu MVP zbyt często robi odwrotnie: tnie jakość, żeby ocalić zakres. To właśnie tę podmianę użytkownicy odczuwają, a dane pokazują.

TL;DR

MVP miało być narzędziem uczenia się: najmniejszym artefaktem, który testuje prawdziwą hipotezę na prawdziwych użytkownikach. Zdegradowana wersja stała się przyzwoleniem na wypuszczanie słabej pracy. Minimum Worthy Product przywraca brakujące ograniczenie. Najpierw tania walidacja, potem najmniejszy produkt, który zdobywa zaufanie. „Minimum” tnie zakres. „Godny” utrzymuje resztę powierzchni na poziomie, który użytkownik czuje.


W czym MVP miało rację

Pierwotna idea MVP nie dawała przyzwolenia na wypuszczanie słabej pracy. Dawała założycielom sposób, by przestać marnować miesiące na budowanie nie tego, co trzeba.1

Eric Ries napisał The Lean Startup, żeby opisać konkretny tryb porażki: inżynierów budujących rozbudowane produkty dla rynków, które nie istniały. MVP było instrumentem poznawczym. Budowało się najmniejszy artefakt zdolny przetestować konkretną hipotezę na prawdziwych użytkownikach, przeprowadzało eksperyment, mierzyło wynik i aktualizowało wiedzę o tym, czy hipoteza przetrwała zderzenie z rzeczywistością. „Minimum” w MVP oznaczało zwinięcie zakresu w służbie uczenia się, a nie zwinięcie jakości w służbie wydania.

Pierwotne ujęcie broni się do dziś. Sam z niego korzystam. Moja sekwencja walidacji startupu (problem, rozwiązanie, kanał, przychód, skala) wywodzi się wprost z Riesa. Argument za tanim testowaniem założeń przed inwestycją w kod jest tym samym argumentem, który stawia MWP zaraz po walidacji: narzędzie każdego etapu powinno pasować do tego etapu. Landing page’e i wywiady to MVP dla pożądalności. Prototypy i sondy techniczne to MVP dla wykonalności. MWP to standard, który stosuje się wtedy, gdy dowody z walidacji są już w ręku i powstaje pierwsza prawdziwa rzecz, której prawdziwi użytkownicy mają zaufać.

Nie występuję więc przeciwko MVP. Występuję przeciwko temu, czym MVP stało się w praktyce.

Gdzie kultura MVP zmiękła

Gdzieś po drodze „ucz się szybko” zamieniło się w „wydaj cokolwiek”, a ta podmiana wyrządziła realne szkody.

Pierwotną ideę zepsuły trzy przekłamania:

  1. „Jeśli nie wstydzisz się pierwszej wersji swojego produktu, wypuściłeś ją za późno” (zdanie Reida Hoffmana4) stało się przyzwoleniem na wstyd za rzemiosło, a nie za zakres. Pierwotna teza dotyczy liczby funkcji: wydać tak mało funkcji, że po czasie będzie wstyd, jak niewiele produkt potrafił. Wersja zdegradowana dotyczy wykonania: wydać coś tak surowego, że po czasie będzie wstyd, jak produkt wyglądał i jak się go używało. To nie jest to samo zdanie.

  2. „Wydawaj szybko” zastąpiło „ucz się szybko” jako mierzalny wynik. Uczenie się jest procesem powolnym i irytującym, a jego owocem jest wgląd jakościowy. Wydawanie jest procesem szybkim i czytelnym, a jego owocem — artefakt z datą. Gdy nie da się rozróżnić jednego od drugiego, artefakt wygrywa automatycznie. Zespoły wydają co tydzień i zupełnie przestają się uczyć, bo nikt nie mierzy tego, czego zespół się nauczył.

  3. Schemat venture (runda, wzrost, wyjście) nagradza wydanie czegokolwiek bardziej niż wydanie dobrze. Kiedy zadaniem jest pokazanie rozpędu przed kolejnym czekiem, rozwodniony produkt przynajmniej przechodzi próg „wydaliśmy”. Opóźniony, godny produkt wygląda z zewnątrz identycznie jak zespół, który utknął. Gradient bodźców prowadzi w dół.

Żadna z tych degradacji nie jest winą MVP w pierwotnym brzmieniu. To jest to, czym MVP stało się w ustach ludzi, którzy potrzebowali usprawiedliwienia dla wydawania słabizny.

Użytkownicy czują skutek. W danych widać go wyraźnie. Onboarding kończy się sukcesem, ale druga sesja nigdy nie następuje. Użytkownicy otwierają mail rejestracyjny i nigdy nie klikają w link. Zgłoszenia do wsparcia gromadzą się wokół zadań, które produkt rzekomo obsługuje. Krzywa odejść opada ku zeru, zamiast wypłaszczyć się w trzon lojalnych użytkowników. To nie są przypadki brzegowe. To główny koszt budowania do standardu, w który użytkownik nie potrafi uwierzyć.

Minimum nie znaczy niedokończone

Minimum to ograniczenie zakresu, a nie zniżka na jakość.

Operacyjnie: zdefiniować użytkownika. Zdefiniować jeden wynik, który produkt obiecuje dostarczyć. Usunąć każdą funkcję, która do tego wyniku nie jest konieczna. Potem utrzymać całą pozostałą powierzchnię na pełnym poziomie jakości. Minimum tnie zakres, dopóki produktu nie da się wydać. Minimum nie tnie standardu po to, żeby wydać wcześniej.

Oba standardy obok siebie:

Wymiar MVP (w praktyce) MWP
Cel Wydać cokolwiek, by udowodnić ruch Wydać coś, co zdobywa zaufanie użytkownika
Zakres Najmniejszy artefakt, który da się obronić jako działający Najmniejsza powierzchnia, która realizuje zwalidowaną obietnicę
Poprzeczka jakości Działa na tyle, żeby się uruchomić Poziom, który użytkownik czuje
Reguła stopu „Wydaliśmy” Oba testy zdane; po trzech nieudanych przebudowach przebudować założenia
Sygnał sukcesu Data w changelogu Pięć wskaźników zaufania: drugi sukces, stosunek D30/D1, kształt krzywej kohorty, polecenia organiczne, tarcie jakościowe
Tryb porażki Słabe pierwsze wrażenie spala zaufanie użytkownika Dopracowywanie zamienia się w chowanie się

Przykład z życia. Obietnica ResumeGeni to CV gotowe pod ATS — takie, które czysto przechodzi przez systemy śledzenia kandydatów i daje osobie szukającej pracy realną szansę dotarcia do osoby decyzyjnej. Wersja minimalna tej obietnicy może wykluczyć:

  • Własne szablony
  • Współpracę zespołową
  • Panele analityczne
  • Integracje z LinkedIn, Indeed czy portalami z ofertami pracy
  • Historię wersji
  • Formaty eksportu poza jednym

Czego wersja minimalna wykluczyć nie może: trafnego parsowania źródłowego CV, uczciwej oceny braków, konkretnych przeredagowań, które naprawdę pasują do ogłoszenia, eksportu otwierającego się bez błędów w Wordzie oraz ścieżki, przy której kandydat czuje się bezpiecznie. Można wydać produkt bez szablonów. Nie można wydać go z mglistymi radami, zepsutym eksportem czy tekstem, po którym osoba w trudnej sytuacji czuje, że produkt traktuje ją jak naiwniaka.

Minimum to nóż przyłożony do backlogu produktu. „Godny” to nóż przyłożony do powierzchni, która została.

„Godny” wyznacza podłogę

Godny produkt nie musi zawierać wszystkiego, co się wymyśli. Wszystko, co zawiera, musi szanować użytkownika.

Godny w sensie operacyjnym znaczy, że produkt rozwiązuje zwalidowany problem na tyle dobrze, że użytkownik przenosi zaufanie na kolejną interakcję. Widzi, co powstawało, i wierzy, że będzie tego więcej. Pierwsza sesja przestaje być próbą do przetrwania, a staje się uściskiem dłoni, który otwiera drzwi do drugiej. Godne produkty kumulują zaufanie. Półgodne je przepalają.

Zaufania nie da się udawać. To, co użytkownicy już znają, kształtuje ich oczekiwania wobec nowego produktu.5 Kiedy produkt wypada poniżej tych oczekiwań (przyciski, które nie reagują, teksty, które asekurancko owijają w bawełnę, ścieżki, które porzucają w połowie), użytkownicy rejestrują tę różnicę, zanim zdążą ją nazwać. Odchodzą, nie wracają i żaden mail retencyjny nie uratuje sesji, którą już spisali na straty.

Pytanie czy to jest godne? nie jest pytaniem o gust. To pytanie o zaufanie. Odpowiedź użytkownika przychodzi w postaci zachowania.

Najpierw walidacja, potem godność zaufania

Najmocniejszy zarzut wobec MWP brzmi: o tym, czy produkt jest godny, decydują użytkownicy w kontakcie z nim, a nie przekonanie twórcy. Zgadza się. MWP nie zastępuje osądu użytkownika. MWP zapobiega spaleniu zwalidowanego zaufania, zanim pierwsi prawdziwi użytkownicy zdążą wydać wyrok.

Kontakt z użytkownikiem należy do walidacji. Zanim cokolwiek powstanie, sprawdza się, czy problem jest prawdziwy, czy proponowane rozwiązanie go dotyka, czy da się dotrzeć do użytkowników i czy zapłacą. Dowody pochodzą z landing page’y, wywiadów, testów concierge, prototypów i list oczekujących. Opisałem tę sekwencję szczegółowo. Hipoteza, która przejdzie przez ten tor przeszkód, zasłużyła na to, żeby ją zbudować.

MWP zaczyna się po walidacji. Walidacja pyta, czy ktokolwiek chce tej obietnicy. MWP pyta, czy wydana powierzchnia zasługuje na zaufanie, które walidacja już zdobyła. To dane o retencji, poleceniach i tarciu jakościowym rozstrzygają, czy ocena się obroniła.

Pominięcie walidacji i nazwanie efektu „MWP” daje piękną odpowiedź na pytanie, którego nikt nie zadał. Pominięcie MWP i nazwanie efektu „lean” daje rozwodniony produkt, który kosztuje dokładnie to zaufanie, które walidacja już zdobyła.

Właściwa kolejność: tania walidacja na prawdziwych użytkownikach, a potem najmniejszy godny produkt dla zwalidowanej obietnicy. Jedno i drugie. Bez pomijania.

Dwa testy: Jiro i Steve

Produkt musi przejść dwa różne testy, zanim uznam go za skończony.

Jiro Test pyta, czy praca jest poprawna. Dowód, że produkt działa. Produkt radzi sobie z przypadkami brzegowymi. Niewidoczne detale trzymają. Twierdzenia powołują się na konkretny dowód. Żadnego asekuranctwa; wydaje mi się nie jest dowodem. Jiro Test oddziela rzemiosło od aspiracji. Pisałem o filozofii jakości Jiro w kontekście agentów AI; ta sama dyscyplina obowiązuje na każdej powierzchni produktu. Bramka dowodowa to sposób, w jaki operacjonalizuję ten test w raportach z kodu.

Steve Test pyta, czy praca zasługuje na istnienie. Widoczny punkt widzenia. Spójność całości. Powierzchnia, która chroni godność użytkownika. Mechanizm zachwytu albo klarowności, który da się wskazać palcem, a nie tylko zbyć machnięciem ręki. Steve Test oddziela produkt od asortymentu. Rzecz wydana nie jest automatycznie rzeczą godną. Pełny wywód o guście jako systemie technicznym znajduje się w osobnym eseju; w tym tekście ciężar niosą powyższe definicje operacyjne.

Oba testy muszą wypaść pozytywnie. Jeśli zawodzi Jiro — zatrzymać się i naprawić. Jeśli zawodzi Steve — przebudować. Jeśli zawodzą oba, problem leży wyżej, w samych założeniach.

Kiedy osąd się waha, obowiązuje najprostsze pytanie z całego zestawu: czy podpisałbym się pod tym bez wahania? Jeśli odpowiedź brzmi „nie”, praca nie jest jeszcze godna.

Dowód pod stopami: blakecrosley.com

Ta strona zaczęła się jako niewielki eksperyment w ramach mojego przejścia poza utartą ścieżkę. Jest też częścią tego wywodu.

Nie ma tu Reacta. Nie ma Tailwinda. Nie ma webpacka, Vite, bundlera ani kroku budowania. FastAPI serwuje całą witrynę bezpośrednio: HTMX, Alpine.js, Jinja2 i zwykły CSS — nic pomiędzy. W wersji z 17 kwietnia 2026 roku początkowy transfer strony mieści się w przedziale od 45 do 60 KB, a Lighthouse raportuje 100 na 100 punktów w wydajności, dostępności, dobrych praktykach i SEO.3 Witryna działa w dziesięciu językach, wydaje nowe treści przewodników i bloga od początku do końca jednym pushem do Gita i nie ma nigdzie w repozytorium ani jednego katalogu node_modules/.

Wersja tej witryny w duchu MVP poszłaby za domyślną radą roku 2026 — Next.js, Tailwind, Vercel. Powstałaby w weekend. Byłaby w porządku. Wejście tutaj skończyłoby się tym, że strona załadowałaby się w przyzwoitym czasie. Różnica nie leżałaby w możliwościach. Różnica leżałaby w guście. Pisałem o tym, jak naprawdę powstaje idealny wynik w Lighthouse; w skrócie: każdy kilobajt, którego czytelnik nie musi pobrać, jest formą szacunku.

Wersja MWP wymagała więcej pracy. Wymagała napisania wzorców HTMX od zera, ręcznego dostrojenia typografii, hostowania fontów u siebie, przepuszczenia potoku i18n przez Cloudflare D1 i potraktowania braku narzędzi budujących jako funkcji. Wersja MWP nie jest technicznie bardziej wydolna niż domyślny stos. Jest bardziej świadoma. Ta świadomość objawia się mniejszą liczbą szwów, które czytelnik mógłby zauważyć.

Niewidoczne rzemiosło. Czytelnik nie widzi decyzji. Czytelnik czuje brak tarcia. I to właśnie brak tarcia jest mechanizmem.

Dowód od strony klienta: ResumeGeni

ResumeGeni podnosi poprzeczkę, bo użytkownik tu nie przegląda. Użytkownik próbuje poprawić dokument, od którego może zależeć, czy w ogóle dostanie rozmowę kwalifikacyjną.

Walidacja ResumeGeni wypadła czysto: landing page, lista oczekujących, celowane posty na Reddicie i LinkedInie, 340 zapisów mailowych w dwa tygodnie, 12 bezpośrednich zapytań o to, kiedy produkt ruszy, i 3 niezamówione propozycje zapłaty za wczesny dostęp.7 Sekwencja walidacji powiedziała: budować. Sama decyzja o budowie była łatwa. Trudna była decyzja, jak ta budowa ma wyglądać — i to właśnie tam MWP odwaliło całą robotę.

Cięcia w dwóch kategoriach. Pierwsza to funkcje: szablony, współpraca, analityka, dziesiątki wariantów eksportu, integracje z portalami pracy. Wszystko wycięte. Nic z tego nie jest częścią obietnicy.

Druga kategoria to standard, na jakim byłem gotów utrzymać to, co zostało. Standardu się nie tnie. Parser nie może być słaby. Rady nie mogą być mgliste. Eksport nie może się psuć. Tekst nie może traktować osoby w trudnej sytuacji jak wskaźnika konwersji. Ścieżka nie może porzucić kogoś w połowie procesu, dlatego że starczyło mi tylko na happy path.

Wersja MVP wypuściłaby kreatora w dziesięciu krokach, generyczny wynik, ścianę subskrypcji w najlepszym momencie i stronę roadmapy obiecującą wszystko, co zostało wycięte. Byłaby funkcjonalna. Może raz nawet skonwertowałaby część użytkowników. Nauczyłaby też pierwszą kohortę, żeby produktowi nie ufać — a taka lekcja to fatalny fundament pod tak wrażliwe zastosowanie.

Wersja MWP jest mniejsza, niż bym chciał. Każdą wyciętą funkcję będę jeszcze chciał z powrotem. Poprzeczka jest jedna: produkt, na który trafiają użytkownicy, ma ich szanować. To jedyny fundament, na jakim potrafię budować.

Co użytkownicy naprawdę mówią

Użytkownicy rzadko mówią wprost: teraz wierzę w ten produkt. Ale ich zachowanie zostawia ślady.6

Pięć sygnałów, które śledzę, skalibrowanych pod odbiorcę, który sam buduje produkty:

  1. Wskaźnik drugiego sukcesu. Odsetek aktywowanych użytkowników, którzy wracają i po raz drugi doprowadzają do kluczowego wyniku w naturalnym oknie użycia. Zaufanie buduje się przy drugim sukcesie, nie przy pierwszym. W produktach o użyciu cyklicznym wynik poniżej 30% traktuję jako sygnał do przebudowy. W produktach epizodycznych należy mierzyć kolejny naturalny cykl użycia, zamiast na siłę narzucać okno 30-dniowe.

  2. Retencja 30. dnia w stosunku do aktywacji 1. dnia. Maile reaktywacyjne potrafią podrasować surową retencję. Stosunku już nie. W produktach używanych tygodniowo lub miesięcznie pokazuje on, czy aktywacja była zaufaniem, czy jednorazową ciekawością. Wartość poniżej 0,25 traktuję jako ostrzeżenie, a poniżej 0,15 — jako wyrok.

  3. Kształt krzywej retencji kohorty. Godne produkty wypłaszczają się po początkowym spadku. Słabe osypują się dalej. Warto wykreślić te krzywe — kształt opowiada historię, którą średnie ukrywają. Jeśli krzywa nigdy się nie wypłaszcza, nie ma trzonu użytkowników, którzy naprawdę ufają produktowi.

  4. Udział organicznych poleceń bez zachęt. Odsetek nowych aktywowanych użytkowników, którzy przychodzą z bezpośredniego polecenia, udostępnionego wyniku albo poczty pantoflowej — nie z kanałów płatnych i nie z łapówek w programie poleceń. O godnych produktach użytkownicy mówią. Słabe zapominają. Jeśli kategoria ma naturalny moment dzielenia się, a organiczne polecenia wciąż odpowiadają za mniej niż 10% pozyskania nowych użytkowników, produkt nie zapracował na rekomendację.

  5. Wskaźnik tarcia jakościowego. Zwroty, wściekłe kliknięcia, zgłoszenia do wsparcia, nieudane eksporty i ręczne poprawki — liczone na 100 aktywowanych użytkowników, w podziale na kohorty. Ten wskaźnik to ból, jaki produkt zadaje użytkownikom, którym rzekomo służy. Wraz z dojrzewaniem produktu powinien spadać. Jeśli utrzymuje się na płasko albo rośnie, problemem jest produkt, a nie proces obsługi.

Żaden z tych sygnałów nie jest metryką próżności. Każdy trudno podrobić. Każdy prowadzi do realnego doświadczenia użytkownika, które albo zdobyło zaufanie, albo nie. Jeśli nie da się podać liczb konkretnej kohorty dla wszystkich pięciu, nie wiadomo jeszcze, czy produkt jest godny.

Kiedy MVP albo prototyp wciąż są właściwym ruchem

MWP nie jest właściwym standardem dla każdego artefaktu.

Trzy sytuacje, w których logika MVP albo prototypu pozostaje słuszna:

  • Przed walidacją. Landing page’e, wywiady, testy concierge, klikalne prototypy. Celem jest nauka, nie rzemiosło. Wypuścić brzydką wersję, która testuje hipotezę. Wypuścić ją dzisiaj. Właściwym podręcznikiem jest tu sekwencja walidacji, a nie MWP.

  • Sondy wykonalności. Kiedy niewiadoma jest techniczna (czy model odpowie na tego typu zapytanie z potrzebnym opóźnieniem? czy API wytrzyma obciążenie? czy parser poradzi sobie z długim ogonem realnych danych wejściowych?), należy zbudować najmniejszy jednorazowy instrument, który odpowie na to pytanie. Nie ma sensu robić go godnym. Ma być prawdomówny.

  • Powierzchnie beta z efektem sieciowym. Marketplace’y, produkty społecznościowe i narzędzia oparte na efekcie sieciowym potrzebują realnej bazy użytkowników, zanim ktokolwiek zdoła je ocenić, więc właściwym artefaktem jest wyraźnie oznaczona beta z pomiarem kohortowym. Wydanie bety nie zastępuje wersji godnej; wydanie bety jest jedynym sposobem, by odkryć, co „godny” tutaj znaczy. Powierzchnię trzeba uczciwie oznaczyć jako betę. Nie stroić jej w kostium wersji 1.0.

MWP dotyczy pierwszej prawdziwej powierzchni produktu. Kto jest jeszcze przed nią (uczy się, testuje, odkrywa), ten znajdzie właściwe narzędzia wcześniej w tej sekwencji.

Limit przebudów

Wysoki standard bez reguły stopu zamienia się w unikanie.

Doktryna, którą stosuję do każdej nietrywialnej pracy, przewiduje limit trzech uczciwych przebudów.2 Uczciwa próba oznacza, że wskazano oś, na której praca zawiodła, nazwano konkretny ruch naprawczy, istotnie zmieniono podejście i ponownie oceniono efekt względem obu testów. Trzy powtórzenia tego samego szlifu nie liczą się jako trzy próby. Liczą się jako jedna nieudana próba powtórzona trzykrotnie.

Jeśli po trzech uczciwych przebudowach wciąż nie powstaje godny produkt, problemem nie jest rzemiosło. Problem leży wyżej: w ujęciu tematu, w zakresie, w założeniach albo w zespole. Trzeba przestać przebudowywać powierzchnię i przyjrzeć się przesłance. Czasem obietnica była za duża jak na zakres, który realnie da się utrzymać na poziomie. Czasem walidacja była słabsza, niż się wydawało. A czasem problem w ogóle nie jest problemem produktowym.

Limit przebudów rozwiązuje dwie przeciwstawne porażki. Nie pozwala pobłogosławić słabej pracy i nie pozwala, by dopracowywanie stało się chowaniem się. Celem nie jest doskonałość. Celem jest godne i wydane. Nie czyste i wiecznie odkładane.

Perfekcjonizm to rzemiosło bez odwagi. Czwarta przebudowa tej samej powierzchni oznacza, że praca nad produktem się skończyła, a projekt stał się kryjówką.

Najważniejsze wnioski

Dla założycieli i twórców solo: - Tania walidacja przed jakimkolwiek kodem. MWP obowiązuje po tym, jak walidacja potwierdzi dopasowanie do rynku. - Ciąć funkcje agresywnie. Resztę powierzchni utrzymać na pełnym poziomie jakości. - Wydawać wtedy, gdy produkt jest godny. Limit trzech przebudów. Potem eskalować do założeń.

Dla liderów produktu i PM-ów: - Mierzyć wskaźniki zaufania wprost: wskaźnik drugiego sukcesu, stosunek retencji 30. dnia do 1. dnia, kształt krzywej kohorty, udział organicznych poleceń, tarcie jakościowe na 100 użytkowników. - Oddzielać rozmowy o zakresie od rozmów o jakości. Cięcia zakresu są negocjowalne. Cięcia jakości nie. - Chronić doświadczenie pierwszej kohorty. Zepsute pierwsze wrażenie u wrażliwych użytkowników odrabia się latami.

Dla liderów inżynierii: - Dla każdej wydawanej powierzchni wyznaczyć bramkę Jiro i bramkę Steve’a. Obie muszą przepuścić. - Zarezerwować budżet na niewidoczne rzemiosło. Różnica między „działa” a „godne” siedzi zwykle w detalach, których nikt nie wskazuje palcem. - Wbudować limit przebudów w proces, żeby perfekcjonizm przestał się chować pod płaszczykiem dopracowywania.

Dla projektantów: - Punkt widzenia nie jest dekoracją; to mechanizm, dzięki któremu produkt staje się rozpoznawalny. - Godna powierzchnia czegoś odmawia, i to widocznie. Jeśli zespół niczego nie odrzucił, zakres jest zły. - Test rozstrzygający w chwili niepewności: czy dałoby się podpisać pod tą decyzją bez wahania?

Zamknięcie: wydawać wtedy, gdy produkt zdobywa zaufanie

Nadrzędne pytanie w produkcie nie brzmi czy to jest skończone? Nadrzędne pytanie brzmi czy to zasługuje na istnienie?

Jeśli odpowiedź brzmi „tak” — wydawać. Jeśli brzmi „jeszcze nie, ale będzie w ciągu trzech uczciwych przebudów” — pracować dalej. Jeśli brzmi „nie” i po trzech próbach nadal brzmi „nie” — przebudować założenia, a nie powierzchnię.

Tak buduję każdy produkt, pod którym się podpisuję. Mentalność MVP optymalizuje pod cykle. Mentalność MWP kumuluje się w dorobek.

Wydawać najmniejszy produkt, który da się szanować. Ani chwili wcześniej. Ani chwili później. „Minimum” i „godny” to jedna instrukcja, trzymana jednocześnie.


FAQ

Czym jest Minimum Worthy Product?

Minimum Worthy Product to najmniejsza publiczna wersja zwalidowanego produktu, która zdobywa zaufanie użytkownika, zamiast je przepalać. „Minimum” znaczy, że zakres jest ścięty do rdzenia obietnicy. „Godny” znaczy, że reszta powierzchni spełnia poziom jakości, który użytkownik czuje. Pierwsza prawdziwa rzecz, jaką widzą prawdziwi użytkownicy, musi zasługiwać na ich zaufanie, a nie tylko działać.

Czym MWP różni się od MVP?

Minimum Viable Product w pierwotnym ujęciu to instrument poznawczy: najmniejszy artefakt do przetestowania konkretnej hipotezy. W praktyce MVP zdegradowało się do przyzwolenia na wypuszczanie słabej pracy. Minimum Worthy Product przywraca brakujące ograniczenie. Walidacja odpowiada na pytanie, czy ktokolwiek tego chce (to zadanie dla MVP, landing page’y i wywiadów). MWP odpowiada za standard, jaki się trzyma, budując pierwszą prawdziwą wersję tego, co walidacja potwierdziła.

Kiedy zespoły powinny sięgnąć po MVP zamiast MWP?

Trzy sytuacje, w których logika Minimum Viable Product albo prototypu wciąż obowiązuje: przed walidacją (landing page’e, wywiady, testy concierge, klikalne prototypy), przy sondach wykonalności (jednorazowy kod testujący opóźnienie albo jakość) oraz w produktach opartych na efekcie sieciowym, które potrzebują oznaczonej bety z prawdziwymi użytkownikami, zanim zespół zdoła zdefiniować, co znaczy „godny”. MWP dotyczy pierwszej prawdziwej powierzchni produktu, a nie każdego artefaktu, który ją poprzedza.

Jak zmierzyć, czy produkt jest godny?

Za pomocą pięciu behawioralnych wskaźników zaufania, a nie metryk próżności: wskaźnika drugiego sukcesu (odsetek aktywowanych użytkowników, którzy po raz drugi doprowadzają do kluczowego wyniku), retencji 30. dnia względem aktywacji 1. dnia (stosunek, nie wartość bezwzględna), kształtu krzywej retencji kohorty (płaska kontra osypująca się), udziału organicznych poleceń bez zachęt oraz tarcia jakościowego (zwroty, nieudane eksporty, zgłoszenia do wsparcia na 100 aktywowanych użytkowników). Godny produkt wypada mocno we wszystkich pięciu; słaby zdradzi się przynajmniej w jednym, a często we wszystkich.


Bramka godnego produktu

Narzędzie decyzyjne pozwalające zastosować te ramy do własnej pracy. Najpierw pięć danych wejściowych, potem trzy szyny doktryny. Bez punktacji, bez zgrywalizowanego wskaźnika. Werdykt, który nazywa oś i kolejny ruch.


Źródła


  1. Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011. Źródło pierwotne dla ujęcia MVP jako instrumentu poznawczego. Degradacja pierwotnej koncepcji do „wypuszczania słabej pracy” ma charakter kulturowy, a nie tekstowy; sama książka pozostaje ostrożna w tym, co rozumie przez minimum. 

  2. Limit przebudów i arbitraż dwóch testów (Jiro Test + Steve Test) pochodzą z doktryny produktowej, którą stosuję w każdym projekcie. Stronę Jiro opisuje Dlaczego mój agent AI ma filozofię jakości. Stronę gustu jako osądu opisuje Gust jest systemem technicznym. Osobny esej poświęcony wyłącznie Steve’owi (integralność całości, odmowa wydania kompromisu, pytanie nadrzędne) jest w przygotowaniu. W tym tekście ciężar dowodowy niosą powyższe testy operacyjne. 

  3. Wynik Lighthouse można zweryfikować przez PageSpeed Insights; liczba 100/100 odnosi się do wersji z dnia publikacji tego wpisu. Wartość 45–60 KB początkowego transferu zmierzyłem lokalnie w Chrome DevTools (panel Network, cache wyłączony); każdy może ją odtworzyć na żywej stronie, otwierając devtools i przeładowując widok. 

  4. Hoffman, Reid. “If There Aren’t Any Typos In This Essay, We Launched Too Late!”, LinkedIn, 29 marca 2017. Hoffman pisze, że sam ukuł to zdanie, i osadza je wokół szybkości, uczenia się, błędnych założeń oraz niekompletnych, ale akceptowalnych pierwszych doświadczeń. Blitzscaling Hoffmana i Yeha (2018) daje użyteczny kontekst, ale esej z LinkedIna jest czystszym źródłem pierwotnym dla tego cytatu. 

  5. Nielsen, Jakob. “Jakob’s Law of Internet User Experience”, Nielsen Norman Group. Prawo Jakoba: użytkownicy spędzają większość czasu w produktach innych niż nasz, więc oczekują, że nasz będzie zachowywał się tak jak te, które już znają. Norman, Don. The Design of Everyday Things (Basic Books, 2013), rozdział 3, opisuje, jak powstają modele mentalne użytkowników i dlaczego rozjazd między modelem projektanta a modelem użytkownika odpowiada za większość porażek produktowych. 

  6. Pięć wskaźników zaufania odzwierciedla moją własną praktykę pomiarową w ResumeGeni, Ace Citizenship i tuzinie projektów opisanych we wpisie Stos walidacji startupu. Literatura kierunkowa, na której się opieram: Andrew Chen o zastojach wzrostu i punktach odniesienia dla retencji oraz złudzeniu kolejnej funkcji; Lenny Rachitsky i Casey Winters o tym, co uchodzi za dobrą retencję w poszczególnych kategoriach; benchmark dopasowania produktu do rynku Seana Ellisa (40% odpowiedzi „must-have”), który Rahul Vohra operacjonalizuje w How Superhuman Built an Engine to Find Product/Market Fit; oraz Amplitude o kształtach krzywych retencji, w tym płaskich, opadających i reaktywacyjnych. Progi podane w tym wpisie to moja własna kalibracja na własnych produktach; publiczna literatura potwierdza kierunek każdej z tez, a nie konkretne punkty odcięcia. 

  7. Zapisy z listy oczekujących ResumeGeni i odpowiedzi zebrane przez autora, kwiecień 2026. Liczby 340 zapisów, 12 zapytań i 3 propozycji zapłaty za wczesny dostęp pojawiają się także we wpisie Stos walidacji startupu i pochodzą z tych samych danych źródłowych. 

Powiązane artykuły

Test Steve’a: czy ta praca zasługuje na istnienie?

Test Steve’a i test Jiro: ramy do rozstrzygania, czy praca zasługuje na istnienie, utrzymuje zaufanie użytkownika i pasu…

19 min czytania

Stos walidacji startupowej: czego 12 projektów nauczyło mnie o dowodach

Zwalidowałem 12 projektów w 9 miesięcy. Jedne trzymały się frameworku, inne pomijały kroki. Różnica pokazała, które dowo…

7 min czytania

Ścieżka bez mapy: jak odszedłem z roli wiceprezesa po 12 latach, by zbudować 12 projektów

Odszedłem ze stanowiska VP of Product Design w ZipRecruiter po 12 latach, by tworzyć niezależnie. Bez planu, bez celu — …

5 min czytania