Od nápadu k MVP

Většina nápadů na appku, které k nám dorazí, nezemře proto, že byly špatné. Zemřou proto, že chtěly udělat všechno najednou. Seznam funkcí se nafoukne, rozpočet se vyčerpá ještě před prvním vydáním a po roce práce není ve store nic. Tahle lekce je o opaku: jak nápad osekat na první verzi, kterou má smysl pustit ven, a teprve pak ji nechat růst podle toho, co lidé skutečně dělají.

Co je MVP a proč ne „všechno hned“

MVP je nejmenší verze appky, která doručí tu jednu hlavní hodnotu a kterou už dává smysl vydat. Ne polotovar, ne „skoro hotovo“. Něco, co reálný uživatel otevře a dostane to, kvůli čemu si appku stáhl.

Pokušení postavit nejdřív všechno je obrovské, protože na papíře vypadá každá funkce důležitě. Jenže každá funkce je práce, kterou musíte navrhnout, naprogramovat, otestovat a pak donekonečna udržovat. Když chcete mít hotové všechno před prvním vydáním, dostanete se do bodu, kdy utratíte celý rozpočet na věci, o kterých vůbec nevíte, jestli je někdo bude chtít.

MVP bolí. Budete vydávat něco, za co se trochu stydíte, a budete muset odmítat funkce, které se vám líbí. Ale jen tak zjistíte, co stavět dál, dřív než utratíte všechno.

A hlavně: dokud appku nikdo nepoužívá, jsou všechny vaše představy o tom, co lidé chtějí, jen dohady. MVP ty dohady promění v data.

Must-have vs nice-to-have: jak roztřídit funkce

Vraťte se k té jedné hlavní práci, kterou má appka odvádět (řešili jsme ji v první lekci). Každou funkci pak proženete jednou otázkou: pomáhá tahle věc uživateli odvést tu jednu hlavní práci, nebo bez ní hlavní práci zvládne taky?

• Must-have. Bez téhle funkce appka nedoručí svoji hodnotu. Když ji vyškrtnete, ztratí appka smysl. Tohle jde do v1.
• Nice-to-have. Hezké, užitečné, ale hlavní práce funguje i bez toho. Tohle počká na v2, v3, nebo nikdy.

Vezměte si appku na rezervaci stolu v restauraci. Vybrat termín a odeslat rezervaci je must-have. Filtr podle typu kuchyně, věrnostní body, sdílení rezervace s kamarády a tmavý režim jsou nice-to-have. Krásné nápady, ale ani jeden není důvod, proč si appku člověk stáhl.

Pozor na „a“. Když popisujete appku a říkáte „je to na rezervace a ještě objednávání jídla a taky recenze“, každé „a“ je příznak, že do v1 cpete víc projektů najednou. Jedna appka, jedna hlavní práce. Zbytek je seznam přání.

Klíčová cesta uživatele: postavte ji jako první a pořádně

Než začnete cokoliv stavět, nakreslete jednu jedinou cestu: krok za krokem to, co udělá uživatel od otevření appky až po okamžik, kdy dostal svou hodnotu. U té rezervace třeba: otevře appku → vybere restauraci → zvolí datum a počet lidí → potvrdí → vidí potvrzení rezervace. Pět kroků. To je vaše klíčová cesta.

Tahle cesta musí v MVP fungovat skvěle. Ne „nějak“. Skvěle. Rychle, srozumitelně, bez zádrhelů. Je to ta část, podle které vás lidé budou soudit a kvůli které se vrátí, nebo appku smažou.

Všechno ostatní v první verzi může být klidně strohé. Nastavení účtu nemusí mít deset přepínačů, stačí jeden. Profil nemusí být vyšperkovaný. Ale ta jedna cesta, kvůli které appka existuje, musí být vyleštěná do lesku. Když si nejste jistí, kam dát energii, dejte ji sem.

Klikací prototyp před první řádkou kódu

Tady se dá ušetřit nejvíc peněz a skoro nikdo to nedělá. Než někdo začne programovat, postavte klikací prototyp: obrazovky naklikané ve Figmě nebo podobném nástroji, propojené tak, že si jimi můžete reálně proklikat klíčovou cestu na telefonu.

Důvod je jednoduchý a hodně praktický: změnit obrazovku v prototypu trvá pět minut. Změnit ji v naprogramované appce trvá dny a stojí peníze. Čím dřív zjistíte, že jste tlačítko dali na blbé místo nebo že krok navíc lidi mate, tím levněji to opravíte.

• Dejte prototyp pěti lidem. Ideálně takovým, kteří appku neznají. Mlčte a dívejte se, kde zaváhají. Kde se ptají „a co teď?“, tam máte problém.
• Neřešte barvy a ikony. V prototypu jde o to, jestli cesta dává smysl, ne jestli je modrá ta správná modrá.
• Teprve když cesta sedí, jde se kódit. Prototyp, který prošel pěti lidmi bez zaváhání, je nejlevnější pojistka, jakou si můžete koupit.

Časté pasti, do kterých spadne skoro každý

Nápad na appku má pár klasických způsobů, jak se sám zabít. Tyhle potkáváme pořád dokola:

• Feature creep. Seznam funkcí roste rychleji, než stíháte stavět. Každý týden přibyde „ještě by to chtělo“. Lék je ta jedna věta o hlavní práci: když nová funkce té větě nepomáhá, jde na seznam pro později, ne do v1.
• Kopírování velkých appek. Instagram, Uber nebo Booking mají za sebou stovky lidí a roky práce. To, co u nich vidíte, je výsledek deseti let, ne jejich MVP. Kopírovat dnešní Instagram jako svoji první verzi je jako chtít postavit dálnici, než víte, jestli tudy někdo pojede.
• Leštění věcí, které nikdo nepoužívá. Tři dny strávené nad obrazovkou nastavení, do které se za celý život podívají dvě procenta lidí. Nebo deset variant motivu, když většina uživatelů nechá výchozí. Energii dejte do klíčové cesty, ne do koutů, kam nikdo nechodí.

Doplňte si jednu větu a schovejte ji: „První verze naší appky musí umět (co) pro (koho), a nic víc.“ Při každém dalším nápadu na funkci se k ní vraťte. Když jí ta věc nepomáhá, do v1 nepatří.

MVP není o tom dělat málo. Je o tom dělat to správné jako první a pořádně. Až tu jednu věc lidé budou skutečně používat, řeknou vám sami, co stavět dál. A to je mnohem lepší zadání než jakýkoliv seznam, který vymyslíte u stolu předem.