Kaj naj vaš SaaS MVP ob lansiranju vsebuje — in česa ne

Beseda »minimalen« v minimalno sposobnem izdelku je tisti del, ki ga vsi spregledajo. Ustanovitelji prikimavajo zamisli, da bi začeli z malim, nato pa izročijo specifikacijo s štiridesetimi zasloni, tremi uporabniškimi vlogami, sistemom za zaračunavanje, analitično nadzorno ploščo in »aha, in povezovati se mora z vsem«. To ni MVP. To je celovit izdelek z optimizmom, navitim do konca. In to je najpogostejši razlog, da prva lansiranja prispejo prepozno, čez proračun in nekako še vedno brez tiste ene stvari, ki so jo stranke v resnici želele.

Pomagal sem precejšnjemu številu majhnih podjetij in samostojnih ustanoviteljev, da so spravili na trg svoj prvi programski izdelek. Tehnični del le redko spotakne ljudi. Težki del — vsakič znova — je odločiti, česa še ne graditi. MVP ni manjša različica vašega sanjskega izdelka z naključno odbrušenimi funkcijami. Je premišljena stava: najmanjša stvar, ki jo lahko postavite pred resnične uporabnike in ki dokaže, da je osrednja zamisel vredna več vašega denarja in časa.

To je torej vodnik, ki bi ga, kot si želim, prebralo več ustanoviteljev, preden napišejo svojo specifikacijo. Brez žargona, brez gledališča »premikaj se hitro in razbijaj stvari«. Le praktičen način, kako potegniti mejo med tem, kar sodi v vašo prvo izdajo, in tem, kar lahko — in mora — počakati.

Kaj MVP pravzaprav je (in kaj ni)

Razčistimo definicijo, saj se tu začne večina zmede. MVP je najmanjša, najpreprostejša različica vašega izdelka, ki resnični osebi omogoči, da naredi tisto eno dragoceno stvar, ki jo vaš izdelek obljublja — in vam omogoči, da izveste, ali se bo vrnila, da jo naredi znova. To je to. Je orodje za učenje, ki je po naključju narejeno iz delujoče programske opreme, ne pa okrnjeno lansiranje dokončane stvari.

Ključna beseda je sposoben. Pogosta napaka je prebrati »minimalen« in izdati nekaj tako golega, da uporabnika spravi v zadrego — polovična pot, ki se sesuje, registracija, ki vodi na prazen zaslon. To ni minimalno-sposobno, to je minimalno-pokvarjeno. Drugi neuspeh je nasproten: izdelek tako »dokončan«, da ga je trajalo leto dni zgraditi, do tedaj pa ste porabili svojo finančno rezervo za dokazovanje domneve, ki bi jo lahko preizkusili v osmih tednih.

Tu je miselni test, ki ga uporabljam. Za vsako funkcijo na seznamu se vprašajte: če bi jo odstranili, bi uporabnik še vedno dosegel tisti en osrednji izid, zaradi katerega izdelek obstaja? Če je odgovor da, skoraj zagotovo ne gre za MVP. Že to eno vprašanje bo večino specifikacij prepolovilo — in tista polovica, ki jo odreže, je tista, ki bi vas zakasnila.

Najdite tisto eno opravilo, ki ga vaš izdelek opravlja

Preden se lahko odločite, kaj graditi, morate imeti brutalno jasno predstavo o tistem enem opravilu, ki ga vaš izdelek opravlja za nekoga. Ne vizija. Ne časovni načrt. Tisto eno ponovljivo dejanje, ki, če deluje, izboljša nekomu dan in ga pripravi do tega, da je pripravljen plačati. Večina problematičnih specifikacij je nejasna prav tu — opisujejo platformo, ne opravila.

Poskusite naglas dokončati ta stavek: »Uporabnik pride k mojemu izdelku, da ______, in odide, potem ko je ______.« Orodje za razporejanje: vodja pride objavit razpored za prihodnji teden in odide z vsako izmeno zapolnjeno in obveščeno ekipo. Aplikacija za izstavljanje računov: samostojni podjetnik pride zaračunat stranki in odide s poslanim, sledljivim računom. Če tega stavka ne morete čisto dokončati, niste pripravljeni določiti obsega — še vedno ste pripravljeni razmišljati.

Kaj vsak SaaS MVP zares potrebuje

Nekatere stvari so neizpogajljive tudi v najvitkejši prvi različici — ne zato, ker bi bile razburljive, ampak zato, ker brez njih izdelka bodisi ni mogoče uporabljati bodisi vas ne more ničesar naučiti. Predstavljajte si jih kot tla, ne strop. Zgradite jih preprosto, a zgradite jih kot je treba.

• Način prijave. Tudi preprosta prijava z e-pošto in geslom je v redu — a resnična in varna, saj je vse drugo odvisno od tega, da veste, kdo je uporabnik.
• Osrednji potek dela, od začetka do konca. Tisto eno opravilo, od prvega uporabnikovega klika do trenutka, ko prejme dragoceni izid — brez slepih ulic, brez gumbov »kmalu na voljo« na kritični poti.
• Nekje, kjer podatki resnično živijo. Resnično shranjevanje, ne enkratni prototip, da uporabnikovo delo preživi osvežitev in se lahko vrne jutri.
• Način, da vidite, kaj se dogaja. Osnovno beleženje ali preprost skrbniški pogled, da lahko, kadar se kaj pokvari — in se bo — ugotovite zakaj brez ugibanja.
• Način, da vas uporabniki dosežejo. Pa čeprav le povezava do e-pošte. Zgodnji uporabniki bodo naleteli na robove, ki jih niste predvideli; želite, da vam to povedo, ne da tiho odidejo.
• Goli minimum zaupanja: obvestilo o zasebnosti, razumno ravnanje s podatki in nikakršno nepremišljeno ravnanje s podatki ljudi.

Opazite, česa na tem seznamu ni: zaračunavanja, imenitnega uvajanja, strani z nastavitvami, mobilnih aplikacij, integracij. Do tega, zakaj, pridemo čez trenutek. Bistvo tal je, da so dovolj majhna, da jih dokončate, in dovolj trdna, da se iz njih naučite. Prijava, ki deluje, en potek dela, ki obrodi, resnični podatki in način, da opazujete uporabnike in se z njimi pogovarjate. To je sposoben izdelek.

Kaj namerno izpustiti iz v1

To je razdelek, ki se mu ustanovitelji upirajo, zato naj bom odkrit: večina stvari, ki se zdijo bistvene za vaše prvo lansiranje, to niso. Zdijo se bistvene, ker jih »pravi izdelek« ima — a vi še ne gradite pravega izdelka, gradite vprašanje. Izpustiti jih ne pomeni varčevati na napačnem mestu. To je celotna disciplina MVP.

Samodejno zaračunavanje in zapletene cene

Skoraj zagotovo v prvi različici ne potrebujete samopostrežnega sistema za zaračunavanje, stopenjskih paketov, sorazmernega obračunavanja in logike opominov. Če zgodnji uporabniki želijo plačati, lahko njihov denar prevzamete ročno — račun, povezava za plačilo, kratek telefonski klic. Ročno zaračunavanje za vaših prvih deset strank vam pove nekaj, česar samodejno zaračunavanje ne more: ali bo sploh kdo plačal. Stroj zgradite, ko dokažete, da je kaj pobrati.

Dovršene vloge in dovoljenja

Sistemi dovoljenj z več vlogami — skrbniki, vodje, opazovalci, drobna pravila dostopa — so pravo inženirsko močvirje in ogromno pomnožijo površino za testiranje. Za prvo izdajo skoraj vedno zadostuje ena vrsta uporabnika. Resnične potrebe po dovoljenjih se boste naučili z opazovanjem, kako resnične ekipe uporabljajo stvar, in te potrebe so redko takšne, kot bi jih uganili na papirju.

Integracije, domorodne mobilne aplikacije in nadzorna plošča

»Povezovati se mora z vsem« je stavek, ki tiho podvoji časovnice. Izberite največ eno integracijo, in to le, če je del osrednjega opravila. Domorodne aplikacije za iOS in Android lahko skoraj vedno počakajo — odzivna spletna aplikacija danes deluje na telefonu. In analitična nadzorna plošča, ki si jo želijo vsi? Uporabniki ne morejo analizirati podatkov, ki jih še niso ustvarili. Najprej izdajte stvar, ki podatke ustvari; vizualizirajte jih, ko je kaj pokazati.

Preprosta metoda za potegovanje meje

Poznati načelo je eno; uporabiti ga na lastni specifikaciji, kjer se vsaka funkcija zdi kot vaš otrok, je težje. Tu je metoda, ki deluje, ker prisili k odločitvi o vsaki postavki, namesto da pusti, da vse odplava v »bistveno«.

1. 1
   Naštejte vsako funkcijo, ki ste si jo zamislili

   Stresite vse ven — še brez filtriranja. Položite celoten seznam želja na mizo, da nič ne preži neizrečeno in se sredi gradnje ne pojavi kot presenečenje.
2. 2
   Označite vsako glede na osrednje opravilo

   Za vsako funkcijo se vprašajte: ali jo uporabnik potrebuje, da dokonča tisto eno osrednje opravilo, od začetka do konca? Označite jo »osrednja«, »koristna« ali »nekoč«. Bodite iskreni — večina pristane v zadnjih dveh.
3. 3
   Za v1 obdržite le »osrednje«

   Vaš MVP je kup »osrednjih« in nič drugega. Kupa »koristno« in »nekoč« nista zavrnjena — to je vaš časovni načrt, parkiran tam, kamor sodi.
4. 4
   Preverite rez z zdravo pametjo

   Poglejte, kaj je ostalo, in se vprašajte: ali lahko resnični uporabnik dobi resnično vrednost samo iz tega? Če da, ste določili obseg MVP. Če nekaj resnično prelomi osrednji tok, povlecite nazaj le tisto eno postavko — in nič drugega.

Disciplina je v četrtem koraku. Vedno obstaja skušnjava, da bi »povlekli nazaj še eno stvar«, in potem še eno, dokler tiho ne zgradite celotnega izdelka znova. Dovolite si rešiti le postavke, ki resnično prelomijo osrednji tok — ne postavke, ki bi ga le polepšale. Lepše je tisto, čemur je namenjena druga različica.

Sposoben še vedno pomeni, da mora delovati resnično

Na drugi strani meje obstaja način odpovedi in vredno ga je poimenovati. V naglici, da bi izdali nekaj majhnega, nekateri ustanovitelji izdajo nekaj zanikrnega — in temu rečejo MVP. Osrednji tok, ki izgubi vaše delo, registracija, ki vrne 404, besedilo, polno nadomestnih besed. To vaše zamisli ne preizkusi pošteno; preizkusi, ali bodo uporabniki prenašali pokvarjeno izkušnjo, in odgovor je vedno ne. Sklenili boste, da je zamisel propadla, čeprav je v resnici propadla izvedba.

»Minimalen« se nanaša na obseg, nikoli na kakovost dela, ki ga obdržite. Manj funkcij, vsaka trdna. Tisti en potek dela, ki ga izdate, bi moral delovati dokončan — hiter, jasen in vreden zaupanja — tudi če je to edino, kar izdelek počne. Ozek izdelek, dobro narejen, vsakič premaga širok izdelek, slabo narejen, še posebej, ko od neznancev zahtevate, da vam zaupajo svoje delo.

MVP ni ciljna črta — je prvo odčitavanje

Tu je del, ki vse postavi v novo luč: lansiranje ni cilj. Cilj je tisto, kar se naučite v tednih po njem. MVP, ki se izda in vam pove »uporabniki obožujejo jedro, a stalno prosijo za X«, je velikanski uspeh — tudi če X pomeni mesec dni dela več. MVP, ki se izda v tišino, ne da bi se kdo vrnil, je prav tako opravil svoje: rešil vas je pred gradnjo tistih ostalih tridesetih funkcij na temelju, ki ga nihče ni želel.

Zato načrtujte prve tedne enako premišljeno kot samo gradnjo. Opazujte, kaj ljudje v resnici počnejo, ne kaj pravijo v anketah. Pogovorite se s tistimi, ki so se vrnili, in s tistimi, ki se niso. Pustite, da resnična uporaba — ne vaša prvotna specifikacija — odloči, kaj gre v drugo različico. Časovni načrt, ki ste ga prej parkirali, ni obljuba; je hipoteza, in vaši uporabniki jo bodo pravkar ocenili.

Pogosta vprašanja