Minimum Worthy Product

Podczas przebudowy publicznych powierzchni ResumeGeni wciąż natrafiam na tę samą niewygodną granicę. Wersja, która technicznie działa, nie zawsze jest wersją, którą postawię przed osobą szukającą pracy. Parser działa. Wynik się ładuje. Przepływ się kończy. A jednak coś w tym doświadczeniu raczej wydaje zaufanie, niż je zdobywa. Siedzę z tym przez godzinę, przebudowuję powierzchnię i uczucie znika, ale zegar nie.

Napięcie jest istotą tego eseju. Dwie siły ciągną się nawzajem w przeciwne strony: wypuścić wystarczająco szybko, by wprowadzić produkt w świat, oraz odmówić wypuszczenia produktu, który wydaje wiarę użytkownika. Większość budujących rozwiązuje to napięcie, wybierając jedną stronę i jej broniąc. Kultura MVP wybiera szybkość. Perfekcjonizm wybiera dopracowanie. Obie odpowiedzi zawodzą, ponieważ napięcie jest właśnie sednem sprawy.

Minimum Worthy Product to inny standard — wypuścić najmniejszy produkt, który zdobywa wiarę, a nie najmniejszy produkt, którego można bronić jako funkcjonalnego. Worthy to podłoga, nie sufit. Minimum to ograniczenie zakresu, nie zniżka jakościowa. Twórca MWP tnie funkcje, dopóki produkt nie nadaje się do wypuszczenia, i trzyma każdą pozostałą powierzchnię na poziomie, który użytkownik jest w stanie wyczuć. Twórca MVP zbyt często robi odwrotnie: tnie jakość, by chronić zakres. To właśnie tę zamianę użytkownicy odczuwają w danych.

TL;DR

MVP miało być narzędziem uczenia: najmniejszym artefaktem, który testuje realną hipotezę z prawdziwymi użytkownikami. Zdegenerowana wersja stała się przyzwoleniem na wypuszczanie słabej pracy. Minimum Worthy Product przywraca brakujące ograniczenie. Walidować tanio, a potem zbudować najmniejszy produkt, który zdobywa wiarę. Minimum tnie zakres. Worthy trzyma pozostałą powierzchnię na standardzie, który użytkownik jest w stanie wyczuć.

---

Co MVP dobrze ujmowało

Pierwotny pomysł MVP nie dawał przyzwolenia na wypuszczanie słabej pracy. Dawał założycielom sposób, by przestać spędzać miesiące, budując niewłaściwą rzecz.¹

Eric Ries napisał The Lean Startup, aby zaadresować konkretny tryb porażki: inżynierów budujących rozbudowane produkty dla rynków, które nie istniały. MVP było instrumentem uczenia. Budowało się najmniejszy artefakt, który mógł przetestować konkretną hipotezę z realnymi użytkownikami, przeprowadzało się eksperyment, mierzyło, co się wydarzyło, i aktualizowało swoje rozumienie tego, czy hipoteza przetrwała kontakt z rzeczywistością. „Minimum” w MVP oznaczało zwężenie zakresu w służbie uczeniu, a nie obniżenie jakości w służbie wypuszczeniu.

Pierwotne ujęcie wciąż się sprawdza. Używam go. Moja sekwencja walidacji startupu (problem, rozwiązanie, kanał, przychód, skala) jest pochodną pracy Riesa. Argument za testowaniem tanich w walidacji założeń, zanim zainwestuje się w kod, jest tym samym argumentem za MWP po walidacji: instrument każdego etapu powinien pasować do tego etapu. Landing page’e i wywiady to MVP dla pożądalności. Prototypy i spike’i to MVP dla wykonalności. MWP to standard, który stosuje się, gdy dowody z walidacji są już w ręku i buduje się pierwszą prawdziwą rzecz, której prawdziwi użytkownicy zaufają.

Nie argumentuję więc przeciwko MVP. Argumentuję przeciwko temu, czym MVP stało się w praktyce.

Gdzie kultura MVP zmiękła

Gdzieś po drodze „ucz się szybko” stało się „wypuszczaj cokolwiek” i ta zamiana wyrządziła realną szkodę.

Trzy przekłady zepsuły pierwotną ideę:

1. „Jeśli nie jesteś zażenowany pierwszą wersją swojego produktu, wypuściłeś zbyt późno” (linijka Reida Hoffmana⁴) stała się przyzwoleniem na zażenowanie rzemiosłem, a nie zakresem. Pierwotne twierdzenie dotyczy liczby funkcji: wypuścić tak mało funkcji, że twoje przyszłe ja zawstydzi, jak niewiele produkt robił. Zdegenerowana wersja dotyczy wykonania: wypuścić tak surowo, że twoje przyszłe ja zawstydzi, jak produkt wyglądał i jak się go odbierało. To nie są te same zdania.

2. „Wypuszczaj szybko” zastąpiło „ucz się szybko” jako mierzalny wynik. Uczenie się to powolny, irytujący proces, który wytwarza jakościowy wgląd. Wypuszczanie to szybki, czytelny proces, który wytwarza datowany artefakt. Kiedy nie odróżnia się tych dwóch, artefakt wygrywa z automatu. Zespoły wypuszczają co tydzień i całkowicie przestają się uczyć, ponieważ nikt nie mierzy, czego zespół się nauczył.

3. Wzorzec venture (pozyskaj kapitał, rośnij, wyjdź) nagradza wypuszczenie czegokolwiek ponad wypuszczeniem słusznie. Jeśli twoim zadaniem jest demonstrowanie pędu na rzecz kolejnej transzy, rozwodniony produkt co najmniej pokonuje poprzeczkę „wypuściliśmy”. Opóźniony produkt godny wypuszczenia wygląda z zewnątrz identycznie jak utknięty zespół. Gradient zachęt wskazuje w dół.

Żadna z tych degradacji nie jest winą MVP w oryginalnym zapisie. To jest to, czym MVP stało się w ustach ludzi, którzy potrzebowali obrony dla wypuszczania słabo.

Użytkownicy odczuwają wynik. Widać to w danych. Onboarding się kończy, ale druga sesja nigdy się nie wydarza. Użytkownicy otwierają e-mail rejestracyjny i nigdy nie klikają w link. Zgłoszenia do wsparcia grupują się wokół zadań, które produkt podobno obsługuje. Krzywa churn opada ku zeru zamiast wypłaszczać się w rdzeń. Te wyniki nie są skrajnymi przypadkami. Są centralnym kosztem budowania do standardu, w który użytkownik nie jest w stanie uwierzyć.

Minimum nie oznacza niedokończone

Minimum to ograniczenie zakresu, nie zniżka jakościowa.

Operacyjnie: zdefiniować użytkownika. Zdefiniować jeden rezultat, który produkt obiecuje dostarczyć. Usunąć każdą funkcję niewymaganą dla tego rezultatu. A następnie trzymać pozostałą powierzchnię na pełnym poziomie jakości. Minimum tnie zakres, aż produkt nadaje się do wypuszczenia. Minimum nie tnie standardu, by produkt mógł zostać wypuszczony wcześniej.

Przykład z życia. Obietnica ResumeGeni to CV gotowe na ATS, które daje osobie szukającej pracy realną szansę przejścia przez systemy śledzenia aplikacji. Minimalna wersja tej obietnicy może wykluczyć:

• Niestandardowe szablony
• Współpracę zespołową
• Dashboardy analityczne
• Integracje z LinkedInem, Indeed czy portalami pracy
• Historię wersji
• Formaty eksportu poza jednym

Czego minimalna wersja wykluczyć nie może: dokładnego parsowania źródłowego CV, uczciwej oceny luk, konkretnych przepisań, które faktycznie pasują do opisu stanowiska, eksportu, który otwiera się czysto w Wordzie, oraz przepływu, który sprawia, że osoba szukająca pracy czuje się bezpiecznie. Można wypuścić bez szablonów. Nie można wypuścić z mglistymi radami, zepsutym eksportem czy treścią, która sprawia, że narażony użytkownik czuje, że produkt traktuje go jak naiwniaka.

Minimum to nóż przyłożony do backlogu produktu. Worthy to nóż przyłożony do powierzchni, która pozostaje.

Worthy to podłoga

Produkt godny wypuszczenia nie musi zawierać wszystkiego, co sobie wyobrażasz. Wszystko, co zawiera, musi szanować użytkownika.

Worthy w sensie operacyjnym oznacza, że produkt rozwiązuje zwalidowany problem na tyle dobrze, że użytkownik przenosi zaufanie do następnej interakcji. Widzą, co budowałeś, i wierzą, że będzie więcej. Pierwsza sesja przestaje być próbą do przetrwania i staje się uściskiem dłoni, który otwiera drzwi do drugiej. Produkty godne wypuszczenia gromadzą wiarę. Produkty na wpół godne ją wydają.

Zaufania nie da się sfałszować. Użytkownicy przychodzą z oczekiwaniami ukształtowanymi przez produkty, które już znają.⁵ Kiedy twój produkt leży poniżej tych oczekiwań (przyciski, które nie reagują, treść, która się asekuruje, przepływy, które porzucają użytkownika w połowie), użytkownicy rejestrują tę lukę, zanim potrafią ją wyartykułować. Odchodzą, nie wracają, a żaden e-mail retencyjny nie uratuje sesji, którą już spisali na straty.

Pytanie czy to jest godne wypuszczenia? nie jest pytaniem o gust. Jest pytaniem o zaufanie. Odpowiedź użytkownika pojawia się jako zachowanie.

Walidacja najpierw, godność później

Najsilniejszy zarzut wobec MWP mówi, że użytkownicy określają godność poprzez kontakt, nie poprzez przekonanie twórcy. Zgoda. MWP nie zastępuje osądu użytkownika. MWP zapobiega temu, by przed dotarciem pierwszych prawdziwych użytkowników do oceny spalić zwalidowane zaufanie.

Kontakt z użytkownikiem należy do walidacji. Zanim zaczniesz budować, testujesz, czy problem jest realny, czy twoje proponowane rozwiązanie go adresuje, czy możesz dotrzeć do użytkowników oraz czy zapłacą. Dowody pochodzą z landing page’y, wywiadów, testów concierge, prototypów i list oczekujących. Napisałem o tej sekwencji szczegółowo. Hipoteza, która przeżywa ten bieg przeszkód, zasłużyła na prawo do zbudowania.

MWP zaczyna się po walidacji. Walidacja pyta, czy ktokolwiek chce obietnicy. MWP pyta, czy wypuszczona powierzchnia zasługuje na zaufanie, które walidacja już zdobyła. Retencja, rekomendacje i dane dotyczące tarć jakościowych decydują, czy osąd się utrzymał.

Pominięcie walidacji i nazwanie wyniku MWP wytwarza piękną odpowiedź na pytanie, którego nikt nie zadał. Pominięcie MWP i nazwanie wyniku lean wytwarza rozwodniony produkt, który kosztuje zaufanie, jakie walidacja już zdobyła.

Właściwa sekwencja: walidować tanio z prawdziwymi użytkownikami, a następnie zbudować najmniejszy godny produkt dla zwalidowanej obietnicy. Zrobić oba. Nie pomijać żadnego.

Dwa testy: Jiro i Steve

Produkt musi przejść dwa różne testy, zanim nazwę go gotowym.

Test Jiro pyta, czy praca jest poprawna. Dowody, że produkt działa. Obsłużone przypadki brzegowe. Dokończone niewidoczne detale. Twierdzenia cytują konkretne dowody. Bez asekuracji; wydaje mi się nie jest dowodem. Test Jiro oddziela rzemiosło od aspiracji. Napisałem o filozofii jakości Jiro w kontekście dyscypliny stosowanej wobec agentów AI; ta sama dyscyplina stosuje się do każdej powierzchni produktu. Evidence Gate to sposób, w jaki operacjonalizuję ten test w raportach z kodu.

Test Steve’a pyta, czy praca zasługuje na istnienie. Widoczny punkt widzenia. Spójność całości. Godność użytkownika zachowana. Mechanizm zachwytu lub jasności, który czytelnik potrafi zidentyfikować, a nie rozmyć gestem. Test Steve’a oddziela produkt od inwentarza. Wypuszczona rzecz nie jest automatycznie rzeczą godną. Pełny argument za gustem jako systemem technicznym żyje w osobnym eseju; w tym wpisie to operacyjna definicja powyżej niesie ciężar.

Oba testy muszą przejść. Jeśli Jiro zawodzi, zatrzymać się i naprawić. Jeśli Steve zawodzi, przebudować. Jeśli oba zawodzą, problem żyje wyżej w brief.

Operacyjne pytanie, gdy osąd jest niepewny, jest najprostsze w zestawie: czy podpisałbym się pod tym bez drgnięcia? Jeśli odpowiedź brzmi nie, praca jeszcze nie jest godna.

Dowód pod twoimi stopami: blakecrosley.com

Strona, którą czytasz, zaczęła się jako mały eksperyment w mojej ścieżce bez ścieżki. Jest także częścią argumentu.

Nie ma React. Nie ma Tailwinda. Nie ma webpacka, Vite, bundlera, kroku buildu. Cała strona działa na FastAPI, HTMX, Alpine.js, Jinja2 oraz zwykłym CSS, serwowanym bezpośrednio. Na bieżącym buildzie pierwsze renderowanie ląduje przy 45 do 60KB, a Lighthouse raportuje 100 na 100 w kategoriach wydajności, dostępności, dobrych praktyk i SEO.³ Strona działa w dziewięciu językach, wypuszcza nową zawartość przewodników i bloga od początku do końca w jednym pushu git, i nie niesie żadnego node_modules/ w całym repozytorium.

Wersja MVP tej strony poszłaby za domyślną radą roku 2026 — Next.js, Tailwind, Vercel. Zostałaby wypuszczona w weekend. Byłaby w porządku. Wylądowałbyś tutaj, strona załadowałaby się w szanownym czasie. Różnica nie leżałaby w zdolnościach. Różnica leżałaby w guście. Napisałem o tym, jak faktycznie buduje się idealny wynik Lighthouse; w skrócie każda kilobajt payloadu, którego czytelnik nie pobiera, jest formą szacunku.

Wersja MWP zajęła dłużej. Wersja MWP wymagała napisania wzorców HTMX od podstaw, strojenia typografii ręcznie, samodzielnego hostowania fontów, przeprowadzenia potoku i18n przez Cloudflare D1 oraz traktowania braku narzędzia buildu jako funkcji. Wersja MWP nie jest technicznie bardziej wydajna niż domyślny stos. Wersja MWP jest bardziej intencjonalna. Intencja ujawnia się jako mniej szwów, które czytelnik mógłby zauważyć.

Niewidoczne rzemiosło. Czytelnik nie widzi decyzji. Czytelnik czuje brak tarcia. Brak tarcia jest mechanizmem.

Dowód skierowany do klienta: ResumeGeni

ResumeGeni podnosi poprzeczkę, ponieważ użytkownik nie przegląda. Użytkownik próbuje ulepszyć dokument, który może zdecydować, czy dostanie rozmowę kwalifikacyjną.

Walidacja ResumeGeni wróciła czysta: landing page, lista oczekujących, ukierunkowane posty na Reddicie i LinkedInie, 340 rejestracji e-mailowych w dwa tygodnie oraz tuzin odpowiedzi pytających, kiedy produkt zostanie otwarty.⁷ Sekwencja walidacji mówiła: zbuduj to. Build był łatwą decyzją. Jak ten build miałby wyglądać, było trudną decyzją i tam właśnie MWP wykonywał faktyczną pracę.

Dwie kategorie cięć. Pierwsza kategoria to funkcje: szablony, współpraca, analityka, dziesiątki wariantów eksportu, integracje z portalami pracy. Wszystko wycięte. Żadne z nich nie jest częścią obietnicy.

Druga kategoria to standard, który byłem gotów utrzymać dla tego, co pozostało. Standard nie zostaje wycięty. Parser nie może być słaby. Porada nie może być mglista. Eksport nie może być zepsuty. Treść nie może traktować narażonego użytkownika jako metryki konwersji. Przepływ nie może porzucić kogoś w połowie procesu, dlatego że miałem czas tylko na ścieżkę szczęśliwą.

Wersja MVP wypuściłaby kreator z dziesięcioma krokami, generyczny wynik, blokadę subskrypcji w najlepszym momencie oraz stronę roadmapy obiecującą wszystko, co zostało wycięte. Byłaby funkcjonalna. Mogłaby skonwertować część użytkowników raz. Nauczyłaby także pierwszej kohorty, by nie ufać produktowi, a ta lekcja staje się kiepskim fundamentem dla narażonego przypadku użycia.

Wersja MWP jest mniejsza, niż bym chciał. Każdą funkcję, którą wyciąłem, będę chciał odzyskać. Poprzeczką jest to, że produkt, na którym użytkownicy lądują, ich szanuje. Fundament jest jedynym, na którym umiem budować.

Co użytkownicy naprawdę ci mówią

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

Pięć sygnałów, które obserwuję, skalibrowanych pod odbiorcę budującego:

1. Wskaźnik drugiego sukcesu. Odsetek aktywowanych użytkowników, którzy wracają i po raz drugi kończą główny rezultat w naturalnym oknie użytkowania. Zaufanie buduje się przy drugim sukcesie, nie przy pierwszym. Dla produktów cyklicznych traktuję wskaźnik drugiego sukcesu poniżej 30% jako sygnał do przebudowy. Dla produktów epizodycznych mierzy się następny naturalny cykl użytkowania zamiast wymuszać okno 30-dniowe.

2. Retencja dnia 30. względem aktywacji dnia 1. E-mail reaktywacyjny może manipulować surową retencją. Stosunek już nie. Dla produktów używanych co tydzień lub co miesiąc stosunek mówi, czy aktywacja była zaufaniem, czy jednorazową ciekawością. Używam wartości poniżej 0,25 jako ostrzeżenia, a poniżej 0,15 jako werdyktu.

3. Kształt krzywej retencji kohorty. Produkty godne wypuszczenia wypłaszczają się po wczesnym spadku. Słabe produkty nadal się dezintegrują. Wykreśl krzywe; kształt opowiada historię, którą średnie ukrywają. Jeśli krzywa nigdy się nie wypłaszcza, nie ma rdzenia użytkowników, którzy naprawdę ufają produktowi.

4. Udział niepremiowanych rekomendacji organicznych. Odsetek nowych aktywowanych użytkowników przychodzących przez bezpośrednią rekomendację, udostępniony wynik lub słowo z ust, a nie płatne kanały, nie łapówki programów poleceń. O produktach godnych wypuszczenia się rozmawia. Słabe produkty idą w zapomnienie. Jeśli kategoria ma naturalny moment dzielenia się, a organiczne polecenia wciąż stanowią poniżej 10% pozyskiwania nowych użytkowników, produkt nie zdobywa rekomendacji.

5. Wskaźnik tarcia jakościowego. Zwroty, wściekłe kliknięcia, zgłoszenia do wsparcia, nieudane eksporty, ręczne poprawki na 100 aktywowanych użytkowników, śledzone po kohortach. Wskaźnik to ból, jaki produkt zadaje użytkownikom, którym deklaruje służyć. Wskaźnik powinien trendować w dół wraz z dojrzewaniem produktu. Jeśli trenduje płasko lub w górę, problem leży w produkcie, nie w procesie wsparcia.

Żaden z tych sygnałów nie jest metryką próżności. Każdy z nich jest trudny do sfałszowania. Każdy z nich śledzi realne doświadczenie użytkownika, które albo zdobyło wiarę, albo tego nie dokonało. Jeśli nie potrafisz nazwać konkretnych liczb określonej kohorty dla wszystkich pięciu, jeszcze nie wiesz, czy twój produkt jest godny wypuszczenia.

Kiedy MVP lub prototyp wciąż jest właściwym ruchem

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

Trzy przypadki, w których logika MVP lub prototypu pozostaje poprawna:

• Przed walidacją. Landing page’e, wywiady, testy concierge, klikalne prototypy. Celem jest uczenie, nie rzemiosło. Wypuścić brzydką wersję, która testuje hipotezę. Wypuścić dzisiaj. Sekwencja walidacji jest właściwą taktyką tutaj, nie MWP.

• Spike’i wykonalności. Kiedy niewiadomą jest kwestia techniczna (czy model odpowie na ten rodzaj zapytań przy wymaganym opóźnieniu? czy API udźwignie obciążenie? czy parser zadziała na długim ogonie realnych danych wejściowych?), zbuduj najmniejszy jednorazowy instrument, który odpowiada na pytanie. Nie próbuj uczynić go godnym. Uczyń go prawdziwym.

• Powierzchnie beta o efektach sieciowych. Marketplace’y, produkty społecznościowe i narzędzia z efektami sieciowymi potrzebują realnej bazy użytkowników, zanim ktokolwiek może je ocenić, więc właściwym artefaktem jest wyraźnie oznaczona beta z oprzyrządowaniem kohortowym. Wypuszczenie bety nie jest substytutem wersji godnej wypuszczenia; wypuszczenie bety jest jedynym sposobem odkrycia, co oznacza godność. Oznaczyć powierzchnię uczciwie jako betę. Nie stroić jej jako v1.

MWP jest dla pierwszej prawdziwej powierzchni produktowej. Jeśli wciąż jesteś powyżej tej powierzchni (uczenie, testowanie, odkrywanie), właściwe narzędzia żyją dalej w sekwencji.

Limit przebudów

Wysoki standard bez reguły zatrzymania staje się unikaniem.

Doktryna, którą stosuję do każdej nietrywialnej pracy, ma limit przebudów wynoszący trzy uczciwe próby.² Uczciwa próba oznacza, że zidentyfikowałeś oś porażki, nazwałeś konkretny ruch naprawczy, zmieniłeś podejście materialnie i ponownie ocieniłeś pracę wobec obu testów. Trzy powtórzenia tego samego przebiegu polerującego nie liczą się jako trzy próby. Powtórzenia liczą się jako jedna nieudana próba powtórzona trzy razy.

Po trzech uczciwych przebudowach, które nie zaowocowały godnym produktem, problem nie leży w rzemiośle. Problem żyje wyżej, w ujęciu, zakresie, briefie lub zespole. Przestać przebudowywać powierzchnię i spojrzeć na przesłankę. Czasem obietnica była za duża na zakres, który realistycznie potrafisz utrzymać na poziomie standardu. Czasem walidacja była słabsza, niż sądziłeś. Czasem problem w ogóle nie jest problemem produktowym.

Limit przebudów rozwiązuje dwie przeciwne porażki. Odmawia błogosławienia słabej pracy i powstrzymuje dopracowanie przed staniem się ukrywaniem. Celem nie jest doskonałość. Celem jest godne i wypuszczone. Nie czyste i zawieszone na zawsze.

Perfekcjonizm to rzemiosło bez odwagi. Jeśli jesteś na czwartej przebudowie tej samej powierzchni, przestałeś tworzyć produkt i zacząłeś używać projektu jako miejsca, w którym się chowasz.

Kluczowe wnioski

Dla założycieli i samodzielnych twórców: - Walidować tanio przed jakimkolwiek kodem. MWP stosuje się po potwierdzeniu dopasowania do rynku przez walidację. - Agresywnie ciąć funkcje. Trzymać pozostałą powierzchnię na pełnym poziomie jakości. - Wypuszczać przy godności. Ograniczyć przebudowy do trzech. Eskalować brief po tym.

Dla liderów produktu i PM-ów: - Mierzyć proxy zaufania bezpośrednio: wskaźnik drugiego sukcesu, stosunek retencji dnia 30 do dnia 1, kształt krzywej kohorty, udział rekomendacji organicznych, wskaźnik tarcia jakościowego na 100 użytkowników. - Oddzielić rozmowy o zakresie od rozmów o jakości. Cięcia zakresu są negocjowalne. Cięcia jakości nie są. - Chronić doświadczenie pierwszej kohorty. Zdegenerowane pierwsze wrażenie na narażonych użytkownikach kosztuje lata odzyskiwania.

Dla liderów inżynierii: - Nazwać bramkę Jiro i bramkę Steve’a dla każdej powierzchni, którą wypuszczasz. Obie muszą przejść. - Zabudżetować na niewidoczne rzemiosło. Różnica między „działa” a „godne” zwykle żyje w detalach, na które nikt nie wskazuje. - Wbudować limit przebudów w proces, by perfekcjonizm przestał chować się pod postacią dopracowania.

Dla projektantów: - Punkt widzenia nie jest dekoracją; to mechanizm, który sprawia, że produkt staje się rozpoznawalny. - Godna powierzchnia widocznie odmawia rzeczom. Jeśli zespół niczemu nie odmówił, zakres jest nie ten. - Operacyjny test w dwuznaczności: czy podpisałbyś się pod tą decyzją bez drgnięcia?

Zamknięcie: wypuścić, kiedy zdobywa wiarę

Rządzącym pytaniem w produkcie nie jest czy jest gotowe? Rządzącym pytaniem jest czy zasługuje na istnienie?

Jeśli odpowiedź brzmi tak, wypuścić. Jeśli odpowiedź brzmi „jeszcze nie, ale tak będzie w ciągu trzech uczciwych przebudów”, pracować dalej. Jeśli odpowiedź brzmi nie i pozostaje na nie po trzech próbach, przebudować brief, nie powierzchnię.

To podejście, w jakim buduję każdy produkt, pod którym stawiam swoje imię. Mentalność MVP optymalizuje pod cykle. Mentalność MWP składa się w dzieło.

Wypuścić najmniejszy produkt, który można szanować. Nie wypuszczać przed tym. Nie czekać poza to. Minimum i worthy to ta sama instrukcja, trzymana równocześnie.

---

FAQ

Czym jest Minimum Worthy Product?

Minimum Worthy Product to najmniejsza publiczna wersja zwalidowanego produktu, która zdobywa wiarę użytkownika, a nie ją wydaje. Minimum oznacza, że zakres jest przycięty do podstawowej obietnicy. Worthy oznacza, że pozostała powierzchnia spełnia poprzeczkę jakości, którą użytkownik jest w stanie wyczuć. Pierwsza prawdziwa rzecz, którą widzą prawdziwi użytkownicy, musi zasługiwać na ich zaufanie, a nie tylko funkcjonować.

Czym MWP różni się od MVP?

Minimum Viable Product w pierwotnym zapisie było instrumentem uczenia: najmniejszym artefaktem, który testuje konkretną hipotezę. W praktyce MVP zdegenerowało się do przyzwolenia na wypuszczanie słabej pracy. Minimum Worthy Product przywraca brakujące ograniczenie. Walidacja pokrywa, czy ktokolwiek chce tej rzeczy (zadanie dla MVP, landing page’y i wywiadów). MWP pokrywa standard, który utrzymujesz, budując pierwszą prawdziwą wersję tego, co walidacja potwierdziła.

Kiedy zespoły powinny użyć MVP zamiast MWP?

Trzy przypadki, w których logika Minimum Viable Product lub prototypu wciąż obowiązuje: przed walidacją (landing page’e, wywiady, testy concierge, klikalne prototypy), podczas spike’ów wykonalności (kod jednorazowy, który testuje opóźnienie lub jakość) oraz dla produktów o efektach sieciowych, które potrzebują oznaczonej bety z prawdziwymi użytkownikami, zanim zespół może zdefiniować, co jest godne. MWP stosuje się do pierwszej prawdziwej powierzchni produktowej, nie do każdego artefaktu wyżej w sekwencji.

Jak mierzyć, czy produkt jest godny wypuszczenia?

Przez pięć behawioralnych proxy zaufania, nie metryki próżności: wskaźnik drugiego sukcesu (odsetek aktywowanych użytkowników, którzy kończą główny rezultat po raz drugi), retencję dnia 30 względem aktywacji dnia 1 (stosunek, nie wartość bezwzględna), kształt krzywej retencji kohorty (płaski versus zanikający), udział niepremiowanych rekomendacji organicznych oraz wskaźnik tarcia jakościowego (zwroty, nieudane eksporty, zgłoszenia do wsparcia na 100 aktywowanych użytkowników). Godny produkt pokazuje siłę we wszystkich pięciu; słaby pokaże to w co najmniej jednym, a często we wszystkich.

---

The Worthy Gate

Narzędzie decyzyjne do zastosowania tych ram do własnej pracy. Przejdź przez pięć wejść, a następnie przez trzy szyny doktryny. Brak punktacji, brak zgeimifikowanego miernika. Werdykt, który nazywa oś i następny ruch.

---

References