9 napak pri razvoju SaaS, ki tiho potapljajo zagonska podjetja v zgodnji fazi

Skoraj nihče ne gradi SaaS izdelka napačno namerno. Napake, ki potapljajo zgodnje startupe, so tihe, razumno zveneče odločitve, ki jih pod pritiskom sprejemajo pametni ljudje — in vse se v tistem trenutku zdijo pravilne. Opazovali smo, kako se istih devet odvije pri desetinah izdelkov, tako v garažah ustanoviteljev kot v dobro financiranih ekipah. Dobra novica je, da so predvidljive, kar pomeni, da se jim je mogoče izogniti. To je seznam, za katerega bi si želeli, da bi ga imel vsak ustanovitelj prilepljenega na monitor, preden je napisal prvo vrstico kode.

Gradimo programsko opremo za mala in srednje velika podjetja, kar pomeni, da nas pokličejo v dveh zelo različnih trenutkih. Včasih je to prvi dan, ko ni ničesar razen skice in ideje. Pogosteje, žal, je deveti mesec — ko je ustanovitelj porabil prihranke, izdelek tehnično deluje, pa vendar zanj nihče ne plačuje. Prav ta druga vrsta klica nas je naučila tega seznama. Vsakič znova obdukcija razkrije isti majhen nabor ran, povzročenih zgodaj in puščenih, da gnojijo.

Nobena od teh napak ni stvar talenta. Ljudje, ki jih delajo, so običajno sposobni in marljivi. Težava je v tem, da gradnja SaaS nagrajuje zelo posebno vrsto zadržanosti, ki ne pride sama od sebe, ko ste navdušeni nad lastno idejo. Pojdimo torej skozi teh devet, približno po vrstnem redu, po katerem običajno grizejo, in bodimo iskreni o tem, zakaj je vsaka tako mamljiva.

1. Šest mesecev gradnje, preden spregovorite z eno samo stranko

To je izvirni greh in je najdražji. Ustanovitelj je prepričan, da je ideja dobra — in morda je — zato utihne, pol leta gradi s sklonjeno glavo in se prikaže z dovršenim izdelkom, ki ga nihče ni želel. Trg ne nagrajuje truda. Nagrajuje reševanje težave, za izginotje katere bo nekdo plačal.

Rešitev ni zapletena, le neprijetna je: pokažite nekaj surovega resničnim potencialnim strankam, preden je dokončano. Klikljiv model, pristajalno stran, celo ročno različico storitve, opravljeno po e-pošti. Vsak teden gradnje, preden ste potrdili, da to ljudje želijo, je teden, ki ga morda porabite za urejanje hiše na napačni ulici.

2. Gradnja za milijon uporabnikov, ki jih nimate

Druga napaka nosi kostum profesionalnosti. Ustanovitelj ali ambiciozen zgodnji inženir zasnuje sistem tako, da že prvi dan prenese ogromen obseg — mikrostoritve, Kubernetes, večregijske podatkovne baze, dovršene plasti predpomnjenja. Zdi se odgovorno. Pravzaprav je past. Trošite svoj najredkejši vir — čas — za obrambo pred težavo, ki bi jo bili srečni sploh imeti.

Dolgočasen monolit z eno samo podatkovno bazo vas bo udobno ponesel do prvih nekaj tisoč uporabnikov in daleč prek vaših prvih prihodkov. Arhitekturne odločitve, ki so pomembne pri velikem obsegu, skoraj nikoli niso tiste, ki jih lahko predvidite na začetku, prezgodnja zapletenost pa naredi izdelek počasnejši za spreminjanje — kar je v zgodnjih dneh edina stvar, ki vas zares ubije. Gradite za naslednjih deset strank, ne za izmišljenega milijontega.

3. MVP, ki ni niti minimalen, niti vzdržen, niti izdelek

Vsi se strinjajo z gradnjo MVP-ja. Skoraj nihče tega dejansko ne stori. Namesto tega se izda razvejana »različica ena«, natlačena z vsako funkcijo, ki si jo je ustanovitelj lahko zamislil, ker se krčenje funkcij zdi kot krčenje ambicij. Rezultat traja trikrat dlje, stane trikrat več in je iz njega težje učiti — saj ko napihnjen izdelek propade, ne morete ugotoviti, kateri del je bil napačen.

Pravi MVP počne eno stvar dovolj dobro, da bo nekdo zanjo plačal. To je vse. Disciplina ni v odločanju, kaj vključiti; je v odločanju, kaj izpustiti, vedoč, da je vsaka »očitna« funkcija, ki jo odložite, teden, ki ga dobite nazaj, in vprašanje, na katero smete odgovoriti z resničnimi uporabniki namesto z ugibanji.

Hitra preverba zdravega obsega

Preden katera koli funkcija pride v prvo različico, ustanoviteljem naročimo, naj na glas odgovorijo na eno vprašanje: »Če bi izdali brez tega, bi katera koli plačujoča stranka zavrnila uporabo izdelka?« Če je iskren odgovor ne, čaka. Presenečeni boste, koliko vašega seznama »nujnih« funkcij izhlapi pod tem enim stavkom.

• Če funkcija obstaja zato, da naredi vtis na vlagatelje, in ne zato, da služi uporabniku, čaka.
• Če funkcija obravnava robni primer, na katerega bo naletelo manj kot 1 od 20 uporabnikov, čaka.
• Če gradite nastavitve za konfiguracijo vedenja, ki ga še nihče ni prosil spremeniti, čaka.
• Če je »konkurent to ima« edini razlog, da je na seznamu, čaka.
• Če njena odstranitev ne bi ustavila niti ene prodaje, čaka.

4. Obravnavanje obračunavanja in uvajanja kot naknadne misli

Ustanovitelji vlijejo ljubezen v osrednjo funkcijo, nato pa se dva tedna pred zagonom spomnijo, da stranke potrebujejo način, da se registrirajo, plačajo in to stvar dejansko začnejo uporabljati. Obračunavanje se v paniki prilepi. Uvajanje je prijavni zaslon in skomig z rameni. Toda pot od »zainteresiranega obiskovalca« do »plačujočega, aktiviranega uporabnika« je vaše podjetje — in prav tu vam večina prihodkov tiho odteka.

Videli smo izdelke z resnično odlično osrednjo funkcijo, ki so izgubili večino registracij v prvih petih minutah, ker nihče ni mogel ugotoviti, kaj storiti po registraciji. Naročnine, preizkusna obdobja, sorazmerno obračunavanje, neuspela plačila, preklici, izkušnja praznega stanja za povsem nov račun — to ni papirologija. To je resnični izdelek, za stranko, v trenutku, ko se odloča, ali bo ostala.

5. Napačno izvedena večnajemnost (ali njeno preskakanje)

To je tista, ki je videti povsem v redu vse do trenutka, ko postane katastrofa. SaaS pomeni veliko strank, ki si delijo en sistem, in to, kako ločite njihove podatke — večnajemnost — je temeljna odločitev. Če jo zavozite, ali zgradite nekaj, kar strank ne more pravilno izolirati, ali še huje, izdate napako, pri kateri eno podjetje vidi podatke drugega podjetja. Ni hitrejšega načina, da naenkrat izgubite vse stranke, kot je uhajanje podatkov med najemniki.

Ne potrebujete eksotične postavitve. Za večino izdelkov v zgodnji fazi povsem zadošča ena sama skupna podatkovna baza s strogo uveljavljenim ID-jem najemnika v vsaki tabeli in vsaki poizvedbi — pod pogojem, da je ta izolacija vgrajena v temelje in preizkušena, ne pa pozneje potresena nanjo. Napaka ni izbira preprostega pristopa. Napaka je, da se ne odločite zavestno in odkrijete vrzel, ko je že v produkciji.

6. Izdajanje v temo brez možnosti videti, kaj uporabniki počnejo

Zaženete. Ljudje se registrirajo. In nato ... tišina. Nimate pojma, katerih funkcij se dotaknejo, kje obtičijo ali zakaj odidejo. Zato ugibate. Naslednjo funkcijo gradite na podlagi slutnje ali najglasnejšega e-poštnega sporočila stranke ali lastne intuicije — ki je po mesecih znotraj lastnega izdelka najmanj zanesljiv inštrument, ki ga imate.

Osnovna analitika izdelka in preprost način zbiranja povratnih informacij nista razkošje faze rasti. Sta način, kako krmarite. Brez njiju ne vodite podjetja, vodite drago mnenje. Že vedeti nekaj tako preprostega kot »80 % uporabnikov nikoli ne odpre funkcije, ki sem jo gradil dva meseca«, je vredno več kot nadaljnja dva meseca slepe gradnje.

7. Puščanje varnosti in varnostnih kopij za »pozneje«

Hitrost je vera zgodnje faze in večinoma je to pravilno. Vendar obstaja majhen nabor stvari, ki jih je katastrofalno drago naknadno vgraditi, in varnost je na vrhu seznama. Pravilno shranjevanje gesel, omejevanje, kdo lahko do česa dostopa, in — prosim — imeti delujoče, preizkušene varnostne kopije niso izbirne funkcije, ki jih dodate, ko imate čas. So tla, na katerih gradite.

Kruto pri tej kategoriji je, da vam uspe točno do trenutka, ko vam ne. Leto dni je vse v redu, nato pa en vdor, en pomotoma izveden množičen izbris, eno jutro z izsiljevalsko programsko opremo izbriše zaupanje in podatke, ki ste jih to leto gradili. Ne prosimo za varnostni oddelek. Prosimo, da so osnove tam že od začetka, kajti strošek njihovega dodajanja po incidentu se meri v mrtvih podjetjih.

8. Najem napačnega graditelja za napačno fazo

Netehnični ustanovitelji se soočajo z brutalno izbiro: kdo to stvar pravzaprav zgradi? Klasični napaki sta zrcalni druga drugi. Ena je najem najcenejšega možnega samostojnega izvajalca, ki dostavi nekaj, kar je videti pravilno, a drži skupaj z lepilnim trakom, in se nato razsuje v trenutku, ko ga morate spremeniti. Druga je pretiran najem — celotna senior ekipa s polnimi plačami, da zgradi izdelek, ki si še ni prislužil niti ene stranke.

Iskren odgovor je popolnoma odvisen od tega, kje ste. Za potrditev ideje želite majhno, senior, pragmatično ekipo, ki je že gradila izdelke v zgodnji fazi in natanko ve, kaj izpustiti. Za skaliranje dokazanega izdelka želite drugačne ljudi z drugačnimi instinkti. Uskladitev graditelja s fazo je sama po sebi veščina — in zavoziti to vas stane več denarja kot katera koli tehnična odločitev na tem seznamu.

9. Obravnavanje zagona kot ciljne črte

Zadnja napaka je najbolj žalostna, ker pride po toliko trdega dela. Ekipa obravnava dan zagona kot cilj, vrže vse v to, da pride tja, in prispe izčrpana, brez načrta, brez proračuna in brez energije za to, kar sledi. Toda zagon ni ciljna črta. Je začetek edine faze, ki je pomembna: učenja od resničnih uporabnikov in izboljševanja, teden za tednom.

SaaS izdelek ni nikoli »dokončan«. Prva različica je hipoteza, meseci po zagonu pa so čas, ko ugotovite, kako zelo je bila napačna — v dobrem smislu. Ustanovitelji, ki to načrtujejo, ki si v rezervi ohranijo malo finančne vzdržljivosti in veliko radovednosti, so tisti, ki majav zagon spremenijo v resnično podjetje. Tisti, ki so porabili vse, da so dosegli štartno črto, običajno ne pridejo dosti dlje.

Kako se dejansko izogniti vsem devetim

Brati seznam napak je lahko. Izogibati se jim pod pritiskom roka, z lastnim denarjem na kocki in lastno idejo v srcu, je resnično težko. Tukaj je torej kratka različica tega, kako običajno delujejo ustanovitelji, ki to izpeljejo prav — ne kot pravila, ampak kot navade, ki jih je vredno ukrasti.

1. 1
   Potrdite, preden gradite

   Postavite nekaj surovega pred resnične potencialne stranke in potrdite, da bodo plačale, preden napišete resno kodo. Poceni za izvedbo, brutalno za preskočiti.
2. 2
   Izberite najmanjši resnični izdelek

   Opredelite tisto eno stvar, ki jo mora vaš izdelek početi, in neusmiljeno odložite vse ostalo. Zapišite, česa »različica ena« namerno ne vključuje.
3. 3
   Gradite dolgočasno in izolirajte najemnike

   Uporabite najpreprostejšo arhitekturo, ki deluje, a ločevanje podatkov med strankami naredite za temeljno, preizkušeno odločitev že od prvega dne.
4. 4
   Zgodaj zasnujte pot denarja

   Registracijo, uvajanje in obračunavanje obravnavajte kot osrednji izdelek, ne kot papirologijo. Prvih pet minut odloči, ali bo preostanek sploh viden.
5. 5
   Opremite ga z meritvami, nato zaženite, da se učite

   Izdajte z vzpostavljeno osnovno analitiko in povratnimi informacijami, ohranite finančno vzdržljivost za fazo po zagonu in prvo različico obravnavajte kot vprašanje, ne kot odgovor.

Opazite, da skoraj nič od tega ni stvar programerske veščine. Gre za presojo — vedeti, kaj zgraditi, kaj izpustiti in kdaj. Prav zato toliko tehnično sposobnih ekip še vedno ustvari izdelke, ki propadejo: težki del SaaS nikoli ni bil inženiring. Bila je zadržanost.

Pogosta vprašanja