Čo má — a nemá — váš SaaS MVP obsahovať pri spustení

Slovo „minimálny“ v minimálne životaschopnom produkte je tá časť, ktorú všetci ignorujú. Zakladatelia prikyvujú myšlienke začať v malom a potom odovzdajú špecifikáciu so štyridsiatimi obrazovkami, tromi používateľskými rolami, fakturačným systémom, analytickým prehľadom a „aha, a malo by sa to integrovať so všetkým“. To nie je MVP. To je plnohodnotný produkt s optimizmom nastaveným na maximum. A je to najčastejší dôvod, prečo prvé spustenia prichádzajú neskoro, nad rozpočet a akosi v nich stále chýba tá jedna vec, ktorú zákazníci naozaj chceli.

Pomohol som slušnému počtu malých firiem a samostatných zakladateľov dostať von ich prvý softvérový produkt. Technická časť býva málokedy to, na čom ľudia zakopnú. Tá ťažká časť — vždy znova — je rozhodnúť, čo ešte nestaviť. MVP nie je menšia verzia vášho vysnívaného produktu s náhodne odbrúsenými funkciami. Je to premyslená stávka: najmenšia vec, ktorú môžete postaviť pred skutočných používateľov a ktorá dokáže, že jadrová myšlienka stojí za viac vašich peňazí a času.

Toto je teda návod, ktorý by si podľa mňa malo prečítať viac zakladateľov ešte pred napísaním špecifikácie. Žiadny žargón, žiadne divadlo „pohybuj sa rýchlo a rozbíjaj veci“. Len praktický spôsob, ako načrtnúť hranicu medzi tým, čo patrí do vášho prvého vydania, a tým, čo môže — a má — počkať.

Čo MVP v skutočnosti je (a čo nie je)

Ujasnime si definíciu, lebo práve tu začína väčšina zmätku. MVP je najmenšia, najjednoduchšia verzia vášho produktu, ktorá skutočnému človeku umožní urobiť tú jednu hodnotnú vec, ktorú váš produkt sľubuje — a vám umožní zistiť, či sa vráti, aby ju urobil znova. To je všetko. Je to nástroj na učenie, ktorý je zhodou okolností postavený z fungujúceho softvéru, nie osekané spustenie hotovej veci.

Kľúčové slovo je životaschopný. Bežnou chybou je prečítať „minimálny“ a vydať niečo také holé, že to používateľa zahanbí — polovičný tok, ktorý spadne, registrácia, ktorá vedie na prázdnu obrazovku. To nie je minimálne-životaschopné, to je minimálne-pokazené. Druhým zlyhaním je opak: produkt taký „kompletný“, že trvalo rok ho postaviť, pričom dovtedy ste minuli svoju finančnú rezervu na dokazovanie domnienky, ktorú ste mohli otestovať za osem týždňov.

Tu je myšlienkový test, ktorý používam. Pri každej funkcii na zozname sa spýtajte: keby sme ju odstránili, mohol by používateľ aj tak dosiahnuť ten jeden jadrový výsledok, kvôli ktorému produkt existuje? Ak je odpoveď áno, takmer určite to nie je MVP. Už táto jediná otázka zoškrtá väčšinu špecifikácií na polovicu — a tá polovica, ktorú odreže, je tá, ktorá by vás zdržala.

Nájdite tú jednu úlohu, ktorú váš produkt robí

Skôr než sa rozhodnete, čo stavať, musíte mať brutálne jasno v tej jednej úlohe, ktorú váš produkt pre niekoho robí. Nie vízia. Nie cestovná mapa. Tá jedna opakovateľná činnosť, ktorá, ak funguje, robí niečí deň lepším a robí ho ochotným zaplatiť. Väčšina problematických špecifikácií je vágna práve tu — opisujú platformu, nie úlohu.

Skúste nahlas dokončiť túto vetu: „Používateľ prichádza k môjmu produktu, aby ______, a odchádza s tým, že ______.“ Plánovací nástroj: manažér prichádza zverejniť rozpis na budúci týždeň a odchádza s každou zmenou obsadenou a tímom upozorneným. Fakturačná aplikácia: živnostník prichádza vyúčtovať klientovi a odchádza s odoslanou, sledovateľnou faktúrou. Ak túto vetu nedokážete čisto vyplniť, nie ste pripravení vymedziť rozsah — ste ešte stále pripravení premýšľať.

Čo každý SaaS MVP naozaj potrebuje

Niektoré veci sú nespochybniteľné aj v tej najštíhlejšej prvej verzii — nie preto, že sú vzrušujúce, ale preto, že bez nich produkt buď nemožno použiť, alebo vás nemôže nič naučiť. Predstavte si ich ako podlahu, nie strop. Postavte ich jednoducho, ale postavte ich poriadne.

• Spôsob prihlásenia. Postačí aj jednoduché prihlásenie e-mailom a heslom — ale skutočné a bezpečné, lebo všetko ostatné závisí od toho, či viete, kto je používateľ.
• Jadrový pracovný tok, od začiatku do konca. Tá jedna úloha, od prvého kliknutia používateľa až po okamih, keď získa hodnotný výsledok — žiadne slepé uličky, žiadne tlačidlá „čoskoro“ na kritickej ceste.
• Niekde, kde dáta naozaj žijú. Skutočné úložisko, nie jednorazový prototyp, aby práca používateľa prežila obnovenie a aby sa mohol zajtra vrátiť.
• Spôsob, ako uvidíte, čo sa deje. Základné logovanie alebo jednoduchý administrátorský pohľad, aby ste pri poruche — a tá nastane — dokázali zistiť prečo bez hádania.
• Spôsob, ako vás používatelia môžu zastihnúť. Hoci len e-mailový odkaz. Prví používatelia narazia na okraje, ktoré ste nepredvídali; chcete, aby vám to povedali, nie aby ticho odišli.
• Holé minimum dôvery: poznámka o ochrane súkromia, rozumné zaobchádzanie s dátami a žiadne nerozvážne nakladanie s informáciami ľudí.

Všimnite si, čo na tom zozname nie je: fakturácia, parádne uvedenie do používania, stránky nastavení, mobilné aplikácie, integrácie. K tomu, prečo, sa dostaneme o chvíľu. Pointa podlahy je, že je dosť malá na dokončenie a dosť pevná na to, aby ste sa z nej poučili. Prihlásenie, ktoré funguje, jeden pracovný tok, ktorý dodáva, skutočné dáta a spôsob, ako pozorovať používateľov a hovoriť s nimi. To je životaschopný produkt.

Čo zámerne vynechať z v1

Toto je časť, ktorej sa zakladatelia bránia, tak buďem otvorený: väčšina vecí, ktoré sa pre vaše prvé spustenie zdajú nevyhnutné, nimi nie sú. Zdajú sa nevyhnutné, lebo ich „skutočný produkt“ má — lenže vy ešte nestaviate skutočný produkt, staviate otázku. Vynechať ich neznamená šetriť na nesprávnom mieste. Je to celá disciplína MVP.

Automatizovaná fakturácia a zložité cenotvorba

Takmer určite nepotrebujete vo verzii jeden samoobslužný fakturačný systém, stupňovité plány, pomernú fakturáciu a logiku upomienok. Ak prví používatelia chcú zaplatiť, ich peniaze môžete prijať ručne — faktúra, platobný odkaz, krátky telefonát. Ručná fakturácia pre vašich prvých desať zákazníkov vám povie niečo, čo automatizovaná fakturácia nedokáže: či vôbec niekto zaplatí. Stroj postavte, až keď dokážete, že je čo vyberať.

Prepracované role a oprávnenia

Systémy oprávnení s viacerými rolami — administrátori, manažéri, pozorovatelia, jemné pravidlá prístupu — sú skutočná inžinierska bažina a obrovsky znásobujú plochu na testovanie. Pre prvé vydanie takmer vždy stačí jeden druh používateľa. Skutočné potreby oprávnení sa naučíte z pozorovania, ako reálne tímy tú vec používajú, a tie potreby sú málokedy také, aké by ste tipovali na papieri.

Integrácie, natívne mobilné aplikácie a prehľadová tabuľa

„Musí sa to integrovať so všetkým“ je veta, ktorá ticho zdvojnásobuje harmonogramy. Vyberte najviac jednu integráciu, a to len ak je súčasťou jadrovej úlohy. Natívne iOS a Android aplikácie takmer vždy môžu počkať — responzívna webová aplikácia dnes funguje na telefóne. A analytická prehľadová tabuľa, ktorú chce každý? Používatelia nemôžu analyzovať dáta, ktoré ešte nevytvorili. Najprv vydajte vec, ktorá dáta vytvára; vizualizujte ich, až keď je čo ukázať.

Jednoduchá metóda, ako načrtnúť hranicu

Poznať princíp je jedna vec; uplatniť ho na vlastnú špecifikáciu, kde sa každá funkcia javí ako vaše dieťa, je ťažšie. Tu je metóda, ktorá funguje, lebo si vynucuje rozhodnutie o každej položke namiesto toho, aby nechala všetko odplávať do „nevyhnutné“.

1. 1
   Spíšte každú funkciu, ktorú ste si predstavili

   Vysypte všetko von — zatiaľ bez filtrovania. Položte celý zoznam želaní na stôl, aby nič nevyčkávalo nevyrieknuté a nevynorilo sa uprostred stavania ako prekvapenie.
2. 2
   Označte každú voči jadrovej úlohe

   Pri každej funkcii sa spýtajte: potrebuje ju používateľ na dokončenie tej jednej jadrovej úlohy, od začiatku do konca? Označte ju „jadrová“, „užitočná“ alebo „raz“. Buďte úprimní — väčšina pristane v posledných dvoch.
3. 3
   Pre v1 si nechajte len „jadrové“

   Vaše MVP je kopa „jadrových“ a nič iné. Kopy „užitočné“ a „raz“ nie sú zamietnuté — sú to vaša cestovná mapa, zaparkovaná tam, kam patrí.
4. 4
   Overte ten rez zdravým rozumom

   Pozrite sa na to, čo zostalo, a spýtajte sa: dokáže skutočný používateľ získať skutočnú hodnotu len z tohto? Ak áno, vymedzili ste rozsah MVP. Ak niečo naozaj lámе jadrový tok, vytiahnite späť len tú jednu položku — a nič iné.

Disciplína je vo štvrtom kroku. Vždy existuje pokušenie „vytiahnuť späť ešte jednu vec“, a potom ďalšiu, až kým ticho nepostavíte celý produkt nanovo. Dovoľte si zachrániť len položky, ktoré naozaj lámu jadrový tok — nie položky, ktoré by ho len urobili krajším. Krajšie je to, na čo slúži druhá verzia.

Životaschopný stále znamená, že to musí pôsobiť skutočne

Na druhej strane hranice je režim zlyhania a stojí za to ho pomenovať. V zhone vydať niečo malé niektorí zakladatelia vydajú niečo odfláknuté — a nazvú to MVP. Jadrový tok, ktorý stratí vašu prácu, registrácia, čo vráti 404, text plný zástupných slov. To vašu myšlienku neotestuje férovo; otestuje, či používatelia budú tolerovať pokazený zážitok, a odpoveď je vždy nie. Usúdite, že myšlienka zlyhala, hoci v skutočnosti zlyhalo prevedenie.

„Minimálny“ sa vzťahuje na rozsah, nikdy na kvalitu časti, ktorú si nechávate. Menej funkcií, každá pevná. Ten jeden pracovný tok, ktorý vydáte, by mal pôsobiť dokončene — rýchlo, jasne a dôveryhodne — aj keby to bolo jediné, čo produkt robí. Úzky produkt urobený dobre vždy poráža široký produkt urobený zle, najmä keď žiadate cudzích ľudí, aby vám zverili svoju prácu.

MVP nie je cieľová čiara — je to prvé odčítanie

Tu je časť, ktorá všetko stavia do nového svetla: spustenie nie je cieľom. Cieľom je to, čo sa naučíte v týždňoch po ňom. MVP, ktoré sa vydá a povie vám „používatelia milujú jadro, ale stále žiadajú X“, je obrovský úspech — aj keď X znamená mesiac práce navyše. MVP, ktoré sa vydá do ticha, bez nikoho, kto by sa vrátil, tiež splnilo svoju úlohu: zachránilo vás pred stavaním tých ďalších tridsiatich funkcií na základe, ktorý nikto nechcel.

Naplánujte teda prvé týždne rovnako zámerne ako samotnú stavbu. Sledujte, čo ľudia naozaj robia, nie čo hovoria v dotazníkoch. Hovorte s tými, čo sa vrátili, aj s tými, čo nie. Nechajte skutočné používanie — nie vašu pôvodnú špecifikáciu — rozhodnúť, čo pôjde do druhej verzie. Cestovná mapa, ktorú ste skôr zaparkovali, nie je sľub; je to hypotéza a vaši používatelia ju práve idú oznámkovať.

Časté otázky