Proč většina MVP selhává ještě před spuštěním

Přes 100 dodaných produktů v kariérách obou zakladatelů. A způsob selhání je téměř vždy stejný. Nikoli špatný technologický stack. Nikoli špatný vývojový tým. Plánovací schůzka šest týdnů před termínem, kde někdo řekl „a při té příležitosti přidejme také…" a nikdo se neozval.

Problém definice

MVP znamená Minimální životaschopný produkt. Nikoli Minimální životaschopná sada funkcí. Nikoli „vše, co si myslíme, že potřebujeme, minus dvě věci." Minimální. Nejmenší věc, která ověří základní předpoklad byznysu.

Většina týmů definuje MVP tak, že začne vším, co chce, a odstraní věci, které se zdají zjevně nepodstatné. To je zpětně. Skončíte s produktem, který trvalo čtyři měsíce postavit, představuje 70 % toho, co jste si představovali, a přesto ještě netestoval tu jednu věc, která určuje, zda byznys funguje.

Skutečný důvod, proč se přidávají funkce

Nikdo nepřidává funkci z lehkovážnosti. Přidávají ji, protože se cítí nezodpovědné ji nepřidat. „Nemůžeme spustit bez notifikací — uživatelé se nevrátí." „Potřebujeme reportovací dashboard, jinak nám enterprise klienti nebudou věřit." „Konkurent to má — musíme to odpovídat."

Každé z těchto tvrzení je věrohodné. Žádné z nich není otestováno. Jsou to předpoklady maskované jako požadavky. A každé z nich prodlužuje harmonogram o týden, který se prodlouží o dva, vezmeme-li v úvahu složitost, kterou přináší do sousedních funkcí.

Funkce, kterou přidáte „pro jistotu", je ta, která zpozdí spuštění o tři týdny a stejně bude odstraněna při přepisu v2.

Test, kterým by každá funkce měla projít

Před přidáním jakékoli funkce do rozsahu MVP by měla odpovědět na tuto otázku: „Pokud toto nezahrneme, stále můžeme otestovat, zda je základní hodnotová nabídka skutečná?"

Pokud je odpověď ano, funkce do MVP nepatří. Patří do v2. Cílem MVP není udělat dojem. Jde o to naučit se — co nejrychleji a nejlevněji — zda věc, kterou stavíte, řeší problém, za jehož řešení lidé zaplatí.

Funkce, které do MVP téměř nikdy nepatří:

• Pokročilé filtrování a vyhledávání (pět uživatelů nepotřebuje Elasticsearch)
• Systém e-mailových notifikací (manuální e-maily fungují do 50 uživatelů)
• Adminické reportovací dashboardy (export do tabulky přežije první tři měsíce)
• Onboarding prohlídky a tipy (místo toho mluvte přímo s uživateli)
• Mobilní aplikace (responzivní webová aplikace se staví v polovičním čase)
• Integrace s třetími nástroji (pokud základní produkt nefunguje, integrace na tom nic nezmění)

Harmonogram lže a vy mu věříte

Druhý způsob selhání je přijetí harmonogramu, který nepřežije kontakt s realitou. Vývojář říká, že funkce trvá dva dny. Trvá čtyři. Vynásobte to přes 12týdenní vývoj a ztratili jste tři týdny dříve, než byl napsán první řádek CSS.

Opravou není odhadovat přesněji. Odhady budou vždy špatné. Opravou je stavět ve fázích s pevnými branami rozsahu. Ve čtvrtém týdnu demujete, co existuje. Pokud tam není, je to odříznuto — ne odloženo. Harmonogram je pevný. Rozsah se pohybuje.

Jak vypadá funkční MVP proces

Dodali jsme produkty za osm týdnů, které byly na trhu, generovaly příjmy, dříve než by „funkčně kompletní" verze, kterou klient původně popsal, byla napůl hotová. Zde je vzor, který funguje:

• Začněte s jednou uživatelskou cestou — tou, která testuje základní předpoklad. Vše ostatní je šum.
• Stavte jen to, co tato cesta vyžaduje. Nakreslete čáru před začátkem stavby a držte ji.
• Vydejte pěti skutečným uživatelům ještě před přidáním čehokoli. Jejich zpětná vazba má větší hodnotu než jakákoli funkce, kterou jste plánovali.
• Považujte v1 za výzkumný nástroj, nikoli za produkt. Kupujete informace, nestavíte software.
• Rozhodněte, jak vypadá v2, na základě toho, co jste se naučili v v1 — ne na základě plánu, který jste napsali před spuštěním.

Tvrdší pravda

Nejtěžší část budování MVP není stavba. Je to disciplína nestavět. Je to zakladatel, který musí říkat ne vlastním nápadům. Product manager, který musí zklamat stakeholdera. Vývojář, který musí odmítnout požadavek, který zní rozumně, ale přidává tři týdny.

Tato disciplína je tím, co odlišuje týmy, které dodají a naučí se, od týmů, které stráví šest měsíců budováním něčeho, co nikdo nechtěl, přesně tak, jak si to představovaly.

MVP, které se spustí za osm týdnů a selže, vás něco naučí. MVP, které se spustí za šest měsíců a selže, vás stojí jen šest měsíců.