Od ideje do SaaS MVP: vodnik za ustanovitelje korak za korakom

Skoraj vsak članek o gradnji SaaS je na skrivaj napisan za nekoga, ki je denar že zbral. Predpostavlja ekipo, finančno rezervo, načrt razvoja in mir ob zavedanju, da si lahko privoščite leto dni motiti se. Če ste ustanovitelj s pravo idejo, redno službo in prihranki, ki jih zares potrebujete, je tak nasvet tiho nevaren. Pravi vam, naj gradite veliko in hitro — in prav tako večina prvih izdelkov umre, preden kdor koli plača en sam cent.

Več kot desetletje pomagam ljudem spreminjati ideje v delujočo programsko opremo in ustanovitelji, ki se jih najbolj spominjam, niso tisti z najdrznejšimi načrti. So tisti, ki so začeli majhno in ostali iskreni. Fizioterapevtka, ki je za svojo kliniko zgradila orodje za naročanje terminov in ga na koncu prodala še štiridesetim drugim. Logistični disponent, ki je avtomatiziral lastno papirologijo in ugotovil, da ima polovica panoge isto težavo. Nihče med njimi ni začel z veličastno platformo. Začeli so z eno bolečo nalogo in pripravljenostjo zaračunati za njeno rešitev.

To je torej vodnik, za katerega bi si želel, da bi ga nekdo tem ljudem izročil že prvi dan. Brez gledališča zbiranja kapitala, brez modne arhitekture, brez pretvarjanja, da mora biti prva različica vtisljiva. Le mirna pot od slutnje v vaši glavi do prve plačujoče stranke — in razsodnost, da veste, kaj med potjo izpustiti.

Kaj MVP v resnici je (in kaj ni)

Izraz minimalni sposobni izdelek je raztegnjen tako daleč, da skoraj nič več ne pomeni. Nekateri ustanovitelji slišijo »minimalni« in objavijo nekaj nerodnega, česar nihče ne more uporabljati. Drugi slišijo »izdelek« in osem mesecev gradijo izpiljeno platformo s cenovnimi razredi, skrbniško ploščo in temnim načinom, preden je en sam človek potrdil, da bi za to plačal. Oboje je napaka in to ista napaka v drugačni preobleki: graditi, preden ste se česar koli naučili.

Uporaben MVP je najmanjša stvar, ki jo lahko postavite pred resnično uporabnico in ki dokaže, da je vašo osrednjo idejo vredno plačati. Ne najmanjša stvar, ki jo lahko zgradite — najmanjša stvar, ki vas nauči nekaj resničnega. Če je vaša ideja »orodje, ki zobozdravnikom omogoča samodejno pošiljanje opomnikov za pregled«, je MVP sistem opomnikov in nič drugega. Brez portala za paciente, brez analitične nadzorne plošče, brez skupinskih računov. To so odgovori na vprašanja, ki si jih še niste prislužili.

Razlog, zakaj je to tako pomembno, so stroški. Vsaka funkcija, ki jo zgradite pred preverjanjem, je stava na slepo. Obrežite MVP na njegovo jedro in postavili ste eno majhno, povratno stavo. Zgradite celotno vizijo in vstavili ste prihranke — na ugibanje. Disciplina »minimalnega« ni v tem, da bi bili skopi. Gre za to, da ostanete pri življenju dovolj dolgo, da imate prav.

Preverite idejo, preden napišete eno samo vrstico kode

Tu je neprijetna resnica, ki je nihče, ki vam prodaja razvoj, noče izreči: večina idej za SaaS je v nečem pomembnem napačnih, vi pa to lahko ugotovite skoraj zastonj. Nagon je najprej graditi in šele nato vprašati. Obrnite to. Najcenejša različica vašega izdelka je pogovor, druga najcenejša pa pristajalna stran.

Preden se kar koli zgradi, želite dokaz za dvoje. Prvič, da je težava resnična in dovolj boleča, da ljudje zanjo že porabljajo čas ali denar — okorno, s preglednicami, lepljivimi listki in orodjem, ki ga sovražijo. Drugič, da bi zares plačali, da izgine. »To je lepa ideja« ni dokaz. »To bi uporabljal« ni dokaz. »Koliko stane in ali lahko začnem v ponedeljek?« je dokaz.

Pristajalna stran z jasno obljubo in gumbom »prijavite se na čakalni seznam« ali »rezervirajte predstavitev« je naslednji korak. Če ne morete prepričati peščice neznancev, da pustijo e-pošto za to, kar opisujete, to ni trženjska težava, ki jo boste rešili pozneje — je signal zdaj, dokler ga je še poceni slišati. Preverjanje ni faza, skozi katero hitite, da bi prišli do zabavnega dela. Za ustanovitelja, ki troši lasten denar, je zabavni del: tu se izognete dragi napaki.

Poiščite eno funkcijo, brez katere vaš izdelek ne more živeti

Vsaka ideja za SaaS, ko jo prvič opišete, pride zavita v ducat funkcij. Tu je tisto, kar počne, in nato ozvezdje »lepo bi bilo imeti«, ki ga je vaši možgani že priključili: poročila, integracije, mobilne aplikacije, vloge in dovoljenja, javni API. Najdragocenejša spretnost pri prehodu od ideje do MVP je naučiti se vse to olupiti in najti tisto eno funkcijo, ki bi, če izgine, celotno stvar naredila nesmiselno.

Ta osrednja funkcija je vaš MVP. Vse drugo je hipoteza, ki jo boste preizkusili pozneje, ko bodo ljudje uporabljali jedro in vam povedali, kaj jim resnično manjka. Ustanovitelji to dosledno počnejo narobe — najprej zgradijo stranske vloge, ker se zdi varneje, in jim zmanjka časa in denarja, preden tista ena pomembna stvar sploh ugleda luč sveta.

Preizkus enega stavka

Poskusite opisati, kaj vaš izdelek počne, v enem samem stavku brez »in«. »Klinikam omogoča pošiljanje samodejnih opomnikov za termin.« »Fotografijo računa spremeni v knjigovodski vnos.« »Sledi, katere ponudbe je obrtnik poslal, in ga opomni, naj se oglasi.« Če za opis vrednosti potrebujete »in«, imate verjetno dva izdelka, ki se borita znotraj enega MVP — in najprej bi morali objaviti bolj bolečo polovico.

• Zapišite vse, kar si predstavljate, da izdelek počne — spravite vse ven, ne filtrirajte.
• Pri vsaki postavki se vprašajte: če tega ne bi bilo, bi kdo še vedno plačal? Prečrtajte vsak »da«.
• Kar ostane po prečrtanju, je vaše jedro. To je MVP.
• Najmočnejše prečrtane postavke vzemite in jih dajte na seznam »za pozneje« — niso izginile, le ne zdaj.
• Uprite se ponovnemu dodajanju. Seznam »za pozneje« je kraj, kjer dobre ideje čakajo, da si prislužijo mesto, in ne kraj, kamor MVP-ji hodijo umirat.

Zgraditi, kupiti ali pretvarjati: kako narediti MVP

Ko poznate svojo eno osrednjo funkcijo, imate izbiro, ki jo ustanovitelji le redko sprejmejo zavestno: koliko od tega morate v resnici zgraditi iz nič? Iskren odgovor je za prvo različico običajno »manj, kot mislite«. Obstajajo tri široke poti, pametna poteza pa je pogosto njihova kombinacija.

Pot no-code / lepljenja

Za nekatere MVP-je lahko povežete obstoječa orodja — obrazec, podatkovno zbirko, plast avtomatizacije, e-poštno storitev — in idejo preverite, ne da bi napisali eno samo vrstico namenske kode. To je odlično za preizkus, ali bodo ljudje delovni tok uporabljali in zanj plačali. Je hitro in poceni. Njegove omejitve se pokažejo pozneje: ko potrebujete resnično izkušnjo izdelka, lasten podatkovni model ali kar koli zares edinstvenega, začne lepljenje pokati po šivih. To je dobra težava — pomeni, da je čas za pravo gradnjo, s plačujočimi strankami že v rokah.

Pot razvoja po meri

Ko je vaša osrednja funkcija tisto, po čemer se razlikujete — pravi razlog, zakaj stranke izberejo prav vas — si ta del zasluži pravo, po meri narejeno programsko opremo. Napaka je gradnja po meri vsega okrog nje. Ni vam treba pisati lastnega preverjanja pristnosti, obdelave plačil ali e-poštne infrastrukture; to so rešene težave, ki bi si jih morali najeti. Zgradite del, ki je edinstveno vaš, ostalo najemite in iskreni bodo tako stroški kot časovnica.

Večina uspešnih MVP-jev, ki sem jih videl, je premišljena mešanica: najeti gradniki za dolgočasno-a-nujno napeljavo in osredotočen razvoj po meri za tisto eno stvar, zaradi katere je izdelek vreden plačila. Vedeti, kaj je kaj — kaj zgraditi in kaj kupiti — je natanko tista vrsta odločitve, za katero se splača dobiti drugo mnenje, preden kar koli porabite.

Kaj lahko v prvi različici brez skrbi izpustite

Vedeti, kaj izpustiti, je prav tako pomembno kot vedeti, kaj zgraditi, in prav tu ustanovitelji najbolj potrebujejo dovoljenje. Pa naj bo: imate dovoljenje izpustiti skoraj vse. Prva različica obstaja zato, da se učite, ne da naredite vtis, in skoraj nobena od stvari, zaradi katerih se izdelek zdi »dokončan«, vam v resnici ne pomaga pri učenju.

• Več cenovnih razredov — izberite eno ceno ali na začetku celo zaračunavajte ročno prek računa.
• Samopostrežni postopek registracije — ročna uvedba prvih desetih strank vas nauči več kot kateri koli samodejni lijak.
• Skrbniško nadzorno ploščo z grafi — dokler imate deset uporabnikov, lahko podatkovno zbirko berete neposredno.
• Mobilne aplikacije, če splet zaenkrat dobro deluje na telefonu.
• Vloge, dovoljenja in skupinske račune — dokler brez njih ni blokirana resnična stranka.
• Izpiljene nastavitve, teme in vsak robni primer — najprej obravnavajte običajno pot, ostalo, ko kdo nanj naleti.

Realistična pot od ideje do prve stranke

Tu je zaporedje, skozi katero bi popeljal skoraj vsakega ustanovitelja. Namenoma je počasno na začetku in hitro, ko enkrat gradite, saj drage napake vse živijo v zgodnjih korakih — tistih, ki jih ustanovitelji najbolj mika preskočiti.

1. 1
   Težavo zapišite v enem stavku

   Ne rešitve — težavo. »Klinike izgubljajo denar zaradi neprihodov, ker so opomniki ročni.« Če težave ne znate jasno ubesediti, je niste pripravljeni rešiti.
2. 2
   Opravite deset resničnih pogovorov

   Pogovarjajte se z ljudmi, ki imajo težavo. Prisluhnite bolečini in denarju, ki se že troši. Idejo prilagodite ali opustite glede na to, kar slišite, in ne glede na to, kar ste upali.
3. 3
   Postavite pristajalno stran in ceno

   Obljubo opišite preprosto, navedite ceno in prosite za e-pošto ali rezervacijo predstavitve. Glejte, ali se neznanci nagnejo bliže. To je preverjanje, ki mu lahko zaupate.
4. 4
   Določite eno osrednjo funkcijo

   Idejo olupite na tisto eno stvar, ki jo brez sebe naredi nesmiselno. Napišite enostavčni opis brez »in«. To je obseg vaše gradnje.
5. 5
   Za vsak del se odločite zgraditi ali kupiti

   Po meri gradite le tisto, po čemer se razlikujete. Najemite prijavo, plačila, e-pošto in gostovanje. To zemljevid pravilno nastavite, preden kdo napiše kodo — določa celoten proračun.
6. 6
   Zgradite najmanjšo delujočo različico

   Ciljajte na tedne, ne na mesece. Če sama osrednja funkcija traja dlje kot nekaj mesecev, je obseg še vedno prevelik — znova obrežite.
7. 7
   Prve stranke uvedite ročno

   Vodite jih osebno. Opazujte, kje se spotaknejo. Prvih deset uporabnikov je vaša najboljša ekipa za izdelek — in vaš prvi prihodek.
8. 8
   Izboljšujte na podlagi uporabe, ne mnenja

   Spreminjajte, kar vam resnična uporaba pove, naj spremenite. Šele zdaj začnete jemati postavke s seznama »za pozneje« — prislužene s povpraševanjem, ne dodane z ugibanjem.

Koliko to v resnici stane — v denarju in v času

Ustanovitelji vedno najprej vprašajo o stroških, iskren odgovor pa je »odvisno, večino tega pa nadzirate vi«. Največje gonilo stroškov je obseg — koliko ste se odločili zgraditi, preden ste se odločili učiti. Strnjen MVP z eno osrednjo funkcijo, ki si napeljavo najema, je skromen, jasno opredeljen projekt. Ista ideja, zgrajena kot polna platforma z vsem vklopljenim, je povsem drugo vesolje stroškov in veliko večja možnost neuspeha še pred zagonom.

Strošek, na katerega večina ljudi pozabi, je čas — vaš. Vsak mesec, ki ga porabite za gradnjo nečesa, za kar nihče ni potrdil, da bo kupil, je mesec vašega življenja in vaših prihrankov, porabljen za ugibanje. To je pravi argument, da začnete majhno: ne da je majhno poceni, ampak da je majhno hitro, hitro pa pomeni, da se naučite, ali imate prav, dokler je stava še povratna. Ustanovitelj, ki v treh mesecih z ozkim orodjem doseže plačujočo stranko, je v veliko močnejšem položaju kot tisti, ki leto pozneje še vedno lošči veličastno platformo.

Obstaja še tišji strošek: vsaka funkcija, ki jo objavite, je nekaj, kar morate zdaj vzdrževati, podpirati in pojasnjevati. Majhen izdelek, ki eno stvar počne zanesljivo, je cenejši za delovanje, lažji za prodajo in enostavnejši za izboljševanje kot razvejan, ki deset stvari počne na pol. Zadržanost ni le to, kako preživite gradnjo — je tudi to, kako posel po njej ohranite znosen.

Pogosta vprašanja