Co by vaše SaaS MVP mělo — a nemělo — při spuštění obsahovat

Slovo „minimální“ v minimálním životaschopném produktu je ta část, kterou všichni ignorují. Zakladatelé souhlasně přikyvují myšlence začít v malém a pak vám předají zadání se čtyřiceti obrazovkami, třemi uživatelskými rolemi, fakturačním systémem, analytickým přehledem a „á, a mělo by se to integrovat se vším“. To není MVP. To je hotový produkt s optimismem vytočeným na maximum. A je to zdaleka nejčastější důvod, proč první spuštění přicházejí pozdě, nad rozpočet a nějak stále bez té jediné věci, kterou zákazníci skutečně chtěli.

Pomohl jsem slušnému počtu malých firem a samostatných zakladatelů dostat na trh jejich první softwarový produkt. Technická část lidi zřídka zaskočí. Tou těžkou částí — pokaždé, bez výjimky — je rozhodnout, co zatím nestavět. MVP není menší verze vašeho vysněného produktu s náhodně obroušenými funkcemi. Je to záměrná sázka: nejmenší věc, kterou můžete postavit před skutečné uživatele a která dokáže, že základní myšlenka stojí za víc vašich peněz a času.

Tak tohle je průvodce, který bych si přál, aby si víc zakladatelů přečetlo, než napíší své zadání. Žádný žargon, žádné divadlo „pohybuj se rychle a rozbíjej věci“. Jen praktický způsob, jak vést čáru mezi tím, co patří do prvního vydání, a tím, co může — a mělo by — počkat.

Co MVP ve skutečnosti je (a co není)

Ujasněme si definici, protože většina zmatku začíná právě tady. MVP je nejmenší a nejjednodušší verze vašeho produktu, která umožní skutečnému člověku udělat tu jednu cennou věc, kterou váš produkt slibuje — a umožní vám zjistit, jestli se vrátí, aby ji udělal znovu. To je celé. Je to nástroj k učení, který je shodou okolností vyroben z fungujícího softwaru, ne osekané spuštění hotové věci.

Klíčové slovo je životaschopný. Častou chybou je přečíst „minimální“ a vydat něco tak holého, že to uživatele uvede do rozpaků — poloviční proces, který spadne, registrace, jež vede na prázdnou obrazovku. To není minimálně-životaschopné, to je minimálně-rozbité. Druhým selháním je opak: produkt tak „úplný“, že trvalo rok ho postavit, a v tu chvíli jste utratili své rezervy dokazováním domněnky, kterou jste mohli otestovat za osm týdnů.

Tady je myšlenkový test, který používám. U každé funkce na seznamu se zeptejte: kdybychom ji odebrali, mohl by uživatel pořád dosáhnout toho jednoho základního výsledku, kvůli kterému produkt existuje? Pokud zní odpověď ano, téměř jistě to není MVP. Už jen tahle otázka osekne většinu zadání na polovinu — a osekne tu polovinu, která vás měla zdržet.

Najděte tu jednu práci, kterou váš produkt dělá

Než se rozhodnete, co postavit, musíte mít brutálně jasno v té jediné práci, kterou váš produkt pro někoho dělá. Ne vize. Ne plán rozvoje. Ta jedna opakovatelná akce, která — pokud funguje — udělá někomu den lepším a přiměje ho ochotně zaplatit. Většina pochybných zadání je vágní právě tady — popisují platformu, ne práci.

Zkuste nahlas dokončit tuhle větu: „Uživatel přichází k mému produktu, aby ______, a odchází s tím, že ______.“ Plánovací nástroj: manažer přichází zveřejnit rozpis na příští týden a odchází s každou směnou obsazenou a týmem informovaným. Fakturační aplikace: živnostník přichází vyúčtovat klientovi a odchází s odeslanou, sledovatelnou fakturou. Pokud tu větu nedokážete čistě doplnit, nejste připraveni vymezovat rozsah — jste teprve připraveni přemýšlet.

Co každé SaaS MVP skutečně potřebuje

Některé věci jsou nediskutovatelné i v té nejštíhlejší první verzi — ne proto, že jsou vzrušující, ale proto, že bez nich produkt buď nelze používat, nebo vás nemůže nic naučit. Berte to jako podlahu, ne strop. Postavte je jednoduše, ale postavte je pořádně.

• Způsob přihlášení. Stačí i jediné přihlášení e-mailem a heslem — ale skutečné a bezpečné, protože všechno ostatní závisí na tom, vědět, kdo je uživatel.
• Základní pracovní postup, od začátku do konce. Ta jedna práce, od prvního kliknutí uživatele po okamžik, kdy získá cenný výsledek — žádné slepé uličky, žádná tlačítka „již brzy“ v kritické cestě.
• Místo, kde data skutečně žijí. Skutečné úložiště, ne jednorázový prototyp, aby uživatelova práce přežila obnovení stránky a mohl se zítra vrátit.
• Způsob, jak vidět, co se děje. Základní logování nebo jednoduchý pohled správce, abyste — když se něco rozbije, a ono se rozbije — zjistili proč, aniž byste hádali.
• Způsob, jak vás uživatelé můžou kontaktovat. Stačí i jen e-mailový odkaz. První uživatelé narazí na hrany, které jste nepředvídali; chcete, aby vám to řekli, ne aby mlčky odešli.
• Naprosté minimum důvěry: poznámka o ochraně soukromí, rozumné zacházení s daty a nedělat nic neuváženého s informacemi lidí.

Všimněte si, co na tom seznamu není: fakturace, parádní uvedení do produktu, stránky nastavení, mobilní aplikace, integrace. K tomu, proč, se za chvíli dostaneme. Smysl podlahy je v tom, že je dost malá na dokončení a dost pevná, abyste se z ní poučili. Fungující přihlášení, jeden postup, který doručí, skutečná data a způsob, jak uživatele sledovat a mluvit s nimi. To je životaschopný produkt.

Co záměrně vynechat z verze 1

Tohle je sekce, které se zakladatelé brání, tak budu přímý: většina věcí, které vám u prvního spuštění připadají nezbytné, nezbytné nejsou. Připadají nezbytné, protože je „skutečný produkt“ má — jenže vy zatím nestavíte skutečný produkt, stavíte otázku. Jejich vynechání není šizení. Je to samotná disciplína MVP.

Automatická fakturace a složité cenotvorby

Téměř jistě nepotřebujete v první verzi samoobslužný fakturační systém, vrstvené tarify, poměrné účtování a logiku upomínek. Pokud chtějí první uživatelé platit, můžete jejich peníze vzít ručně — faktura, platební odkaz, rychlý telefonát. Ruční fakturace pro vašich prvních deset zákazníků vám řekne něco, co automatická fakturace nedokáže: jestli vůbec někdo zaplatí. Stroj postavte, až dokážete, že je co vybírat.

Propracované role a oprávnění

Systémy oprávnění s více rolemi — správci, manažeři, prohlížející, jemně členěná přístupová pravidla — jsou opravdový inženýrský bahňák a obrovsky znásobují plochu testování. Pro první vydání téměř vždy stačí jediný druh uživatele. Skutečné potřeby oprávnění poznáte z pozorování opravdových týmů, jak to používají, a tyto potřeby jsou zřídka tím, co byste odhadli na papíře.

Integrace, nativní mobilní aplikace a přehled

„Musí se to integrovat se vším“ je fráze, která potichu zdvojnásobuje harmonogramy. Vyberte nanejvýš jednu integraci, a to jen pokud je součástí základní práce. Nativní aplikace pro iOS a Android téměř vždy mohou počkat — responzivní webová aplikace dnes funguje na telefonu. A ten analytický přehled, který chtějí všichni? Uživatelé nemůžou analyzovat data, která ještě nevytvořili. Vydejte nejdřív to, co data vytváří; vizualizujte je, až bude co ukazovat.

Jednoduchá metoda, jak vést čáru

Znát princip je jedna věc; uplatnit ho na vlastní zadání, kde vám každá funkce připadá jako vlastní dítě, je těžší. Tady je metoda, která funguje, protože vynucuje rozhodnutí u každé položky, místo aby nechala všechno splývat do „nezbytného“.

1. 1
   Sepište každou funkci, kterou jste si představovali

   Vysypte to všechno ven — zatím bez filtrování. Dejte celý seznam přání na stůl, ať nic nečíhá nevyřčené a nevynoří se uprostřed stavění jako překvapení.
2. 2
   Posuďte každou vůči základní práci

   U každé funkce se zeptejte: potřebuje ji uživatel, aby dokončil tu jednu základní práci od začátku do konce? Označte ji „základní“, „užitečná“ nebo „někdy“. Buďte upřímní — většina spadne do posledních dvou.
3. 3
   Pro v1 si nechte jen „základní“

   Vaše MVP je hromádka „základní“ a nic jiného. Hromádky „užitečná“ a „někdy“ nejsou zamítnuté — jsou to váš plán rozvoje, zaparkovaný tam, kam patří.
4. 4
   Prověřte řez zdravým rozumem

   Podívejte se na to, co zbylo, a zeptejte se: získá skutečný uživatel skutečnou hodnotu jen z tohohle? Pokud ano, vymezili jste rozsah MVP. Pokud něco opravdu rozbíjí základní postup, vtáhněte zpět jen tu jednu položku — a nic jiného.

Disciplína je ve čtvrtém kroku. Vždycky je tu pokušení „vtáhnout zpět jenom ještě jednu věc“, a pak další, až jste potichu znovu postavili celý produkt. Dovolte si zachránit jen položky, které skutečně rozbíjejí základní postup — ne položky, které by ho jen udělaly hezčím. Hezčí je úkol pro druhou verzi.

Životaschopný pořád znamená, že to musí působit opravdově

Na druhé straně čáry existuje způsob selhání a stojí za to ho pojmenovat. Ve spěchu vydat něco malého někteří zakladatelé vydají něco odbytého — a říkají tomu MVP. Základní postup, který ztratí vaši práci, registrace, jež hodí chybu 404, texty plné zástupných slov. To vaši myšlenku spravedlivě netestuje; testuje to, jestli uživatelé strpí rozbitý zážitek, a odpověď je vždycky ne. Usoudíte, že selhal nápad, zatímco ve skutečnosti selhalo provedení.

„Minimální“ se vztahuje na rozsah, nikdy na kvalitu té části, kterou si necháte. Méně funkcí, každá pevná. Ten jediný postup, který vydáte, by měl působit dohotoveně — rychle, jasně a důvěryhodně — i kdyby to bylo to jediné, co produkt dělá. Úzký produkt udělaný dobře pokaždé porazí široký produkt udělaný špatně, zvlášť když po cizích lidech chcete, aby vám svěřili svou práci.

MVP není cílová čára — je to první odečet

Tady je ta část, která vše přerámuje: spuštění není cíl. Cílem je to, co se naučíte v týdnech po něm. MVP, které se spustí a řekne vám „uživatelé základ milují, ale pořád žádají X“, je obrovský úspěch — i když X znamená měsíc práce navíc. MVP, které se spustí do ticha a nikdo se nevrátí, také splnilo svou práci: ušetřilo vás od stavění dalších třiceti funkcí na základech, které nikdo nechtěl.

Tak plánujte první týdny stejně promyšleně jako stavbu. Sledujte, co lidé skutečně dělají, ne co říkají v dotaznících. Mluvte s těmi, kdo se vrátili, i s těmi, kdo ne. Nechte skutečné používání — ne vaše původní zadání — rozhodnout, co půjde do druhé verze. Plán rozvoje, který jste dříve zaparkovali, není slib; je to hypotéza, a vaši uživatelé ji za chvíli oznámkují.

Časté otázky