9 chýb pri vývoji SaaS, ktoré ticho potápajú začínajúce startupy

Takmer nikto nestavia SaaS produkt zle úmyselne. Chyby, ktoré potápajú rané startupy, sú tiché, rozumne znejúce rozhodnutia, ktoré pod tlakom robia šikovní ľudia — a všetky sa v danej chvíli zdajú správne. Sledovali sme, ako sa tých istých deväť odohráva na desiatkach produktov, v garážach zakladateľov rovnako ako v dobre financovaných tímoch. Dobrá správa je, že sú predvídateľné, čo znamená, že sa im dá vyhnúť. Toto je zoznam, ktorý by sme si priali, aby mal každý zakladateľ nalepený na monitore skôr, než napíše prvý riadok kódu.

Staviame softvér pre malé a stredné podniky, čo znamená, že nás volajú v dvoch veľmi odlišných okamihoch. Niekedy je to prvý deň, keď neexistuje nič okrem náčrtu a nápadu. Častejšie, bohužiaľ, je to deviaty mesiac — keď zakladateľ minul svoje úspory, produkt technicky funguje, a predsa zaň nikto neplatí. Práve tento druhý typ hovoru nás naučil tento zoznam. Zakaždým pitva odhalí tú istú malú množinu rán, spôsobených skoro a ponechaných hnisať.

Žiadna z týchto chýb nie je o talente. Ľudia, ktorí ich robia, sú zvyčajne schopní a pracovití. Problém je, že stavba SaaS odmeňuje veľmi špecifický druh zdržanlivosti, ktorý neprichádza prirodzene, keď ste nadšení z vlastného nápadu. Prejdime teda tých deväť, zhruba v poradí, v akom zvyknú hrýzť, a buďme úprimní o tom, prečo je každá z nich taká lákavá.

1. Šesť mesiacov stavania predtým, než sa porozprávate čo i len s jedným zákazníkom

Toto je prvotný hriech a je najdrahší. Zakladateľ je presvedčený, že nápad je dobrý — a možno je — tak stíchne, pol roka stavia so sklonenou hlavou a vynorí sa s vylešteným produktom, ktorý nikto nechcel. Trh neodmeňuje úsilie. Odmeňuje vyriešenie problému, za ktorého zmiznutie niekto zaplatí.

Náprava nie je zložitá, je len nepríjemná: ukážte niečo hrubé skutočným potenciálnym zákazníkom skôr, než je to hotové. Klikateľný model, vstupnú stránku, dokonca aj ručnú verziu služby vybavenú e-mailom. Každý týždeň stavania predtým, než ste potvrdili, že to ľudia chcú, je týždeň, ktorý možno trávite zariaďovaním domu na nesprávnej ulici.

2. Stavanie pre milión používateľov, ktorých nemáte

Druhá chyba má na sebe kostým profesionality. Zakladateľ alebo ambiciózny raný inžinier navrhne systém tak, aby od prvého dňa zvládol obrovskú záťaž — mikroslužby, Kubernetes, databázy vo viacerých regiónoch, prepracované vrstvy vyrovnávacej pamäte. Pôsobí to zodpovedne. V skutočnosti je to pasca. Míňate svoj najvzácnejší zdroj — čas — na obranu pred problémom, ktorý by ste mali šťastie vôbec mať.

Nudný monolit s jednou databázou vás pohodlne odnesie k prvým niekoľkým tisícom používateľov a ďaleko za vaše prvé tržby. Architektonické rozhodnutia, na ktorých záleží pri veľkej záťaži, takmer nikdy nie sú tie, ktoré viete na začiatku predvídať, a predčasná zložitosť robí produkt pomalším na zmenu — a to je v ranom období jediná vec, ktorá vás naozaj zabíja. Stavajte pre ďalších desať zákazníkov, nie pre vymysleného milióntneho.

3. MVP, ktoré nie je ani minimálne, ani životaschopné, ani produkt

Všetci sa zhodnú na stavbe MVP. Takmer nikto to v skutočnosti neurobí. Namiesto toho sa vydá rozľahlá „verzia jeden“ napchatá každou funkciou, akú si zakladateľ vedel predstaviť, pretože škrtanie funkcií pôsobí ako škrtanie ambícií. Výsledok trvá trikrát dlhšie, stojí trikrát viac a ťažšie sa z neho učí — pretože keď nafúknutý produkt zlyhá, neviete povedať, ktorá časť bola nesprávna.

Skutočné MVP robí jednu vec dosť dobre na to, aby zaňu niekto zaplatil. To je všetko. Disciplína nie je v rozhodovaní, čo zahrnúť; je v rozhodovaní, čo vynechať, s vedomím, že každá „samozrejmá“ funkcia, ktorú odložíte, je týždeň, ktorý získate späť, a otázka, na ktorú smiete odpovedať so skutočnými používateľmi namiesto dohadov.

Rýchla kontrola zdravého rozsahu

Skôr než akákoľvek funkcia vojde do prvej verzie, necháme zakladateľov nahlas odpovedať na jednu otázku: „Keby sme to vydali bez toho, odmietol by čo i len jeden platiaci zákazník produkt používať?“ Ak je úprimná odpoveď nie, čaká. Budete prekvapení, koľko z vášho zoznamu „nevyhnutných“ funkcií sa pod touto jednou vetou vyparí.

• Ak funkcia existuje preto, aby zapôsobila na investorov, a nie aby slúžila používateľovi, čaká.
• Ak funkcia rieši hraničný prípad, na ktorý narazí menej než 1 z 20 používateľov, čaká.
• Ak staviate nastavenia na konfiguráciu správania, ktoré zatiaľ nikto nepožiadal zmeniť, čaká.
• Ak je „konkurent to má“ jediný dôvod, prečo je na zozname, čaká.
• Ak by jej odstránenie nezastavilo ani jeden predaj, čaká.

4. Branie fakturácie a uvedenia používateľa ako dodatočnej myšlienky

Zakladatelia vlejú lásku do hlavnej funkcie a potom si dva týždne pred spustením spomenú, že zákazníci potrebujú spôsob, ako sa zaregistrovať, zaplatiť a skutočne začať tú vec používať. Fakturácia sa v panike priskrutkuje. Uvedenie je prihlasovacia obrazovka a pokrčenie ramen. No cesta od „zaujatého návštevníka“ k „platiacemu, aktivovanému používateľovi“ je vaším biznisom — a práve tam vám väčšina tržieb ticho uniká.

Videli sme produkty so skutočne vynikajúcou hlavnou funkciou stratiť väčšinu registrácií v prvých piatich minútach, pretože nikto neprišiel na to, čo robiť po registrácii. Predplatné, skúšobné obdobia, pomerné účtovanie, neúspešné platby, zrušenia, zážitok z prázdneho stavu pre úplne nový účet — to nie je papierovačka. To je skutočný produkt, pre zákazníka, v okamihu, keď sa rozhoduje, či zostane.

5. Zle urobená viacnájomnosť (alebo jej vynechanie)

Toto je tá, ktorá vyzerá v poriadku presne až do chvíle, keď je z nej katastrofa. SaaS znamená, že mnoho zákazníkov zdieľa jeden systém, a to, ako oddelíte ich údaje — viacnájomnosť — je základné rozhodnutie. Pokazte to a buď postavíte niečo, čo nedokáže zákazníkov poriadne izolovať, alebo, čo je horšie, vydáte chybu, pri ktorej jedna firma vidí údaje inej firmy. Niet rýchlejšieho spôsobu, ako naraz stratiť všetkých zákazníkov, než únik údajov medzi nájomcami.

Nepotrebujete exotické nastavenie. Pre väčšinu produktov v ranej fáze úplne postačí jedna zdieľaná databáza s prísne vynucovaným ID nájomcu v každej tabuľke a každom dopyte — za predpokladu, že je tá izolácia zabudovaná do základov a otestovaná, nie posypaná naň neskôr. Chybou nie je voľba jednoduchého prístupu. Chybou je nerozhodnúť sa vedome a objaviť tú medzeru, keď je už v produkcii.

6. Vydávanie do tmy bez možnosti vidieť, čo používatelia robia

Spustíte to. Ľudia sa registrujú. A potom... ticho. Netušíte, ktorých funkcií sa dotýkajú, kde uviaznu alebo prečo odídu. Tak hádate. Ďalšiu funkciu staviate na základe tušenia, alebo najhlasnejšieho e-mailu zákazníka, alebo vlastnej intuície — ktorá je po mesiacoch vnútri vlastného produktu najmenej spoľahlivým nástrojom, aký vlastníte.

Základná produktová analytika a jednoduchý spôsob zberu spätnej väzby nie sú luxus fázy rastu. Sú spôsobom, akým kormidlujete. Bez nich neriadite biznis, riadite drahý názor. Aj vedieť niečo také jednoduché ako „80 % používateľov nikdy neotvorí funkciu, ktorú som dva mesiace staval“ má väčšiu cenu než ďalšie dva mesiace slepého stavania.

7. Odkladanie bezpečnosti a záloh na „neskôr“

Rýchlosť je náboženstvom ranej fázy a väčšinou je to správne. No existuje malá množina vecí, ktoré je katastrofálne drahé dodatočne dorábať, a bezpečnosť je na vrchole zoznamu. Správne ukladanie hesiel, uzamknutie toho, kto má k čomu prístup, a — prosím — mať funkčné, otestované zálohy nie sú voliteľné funkcie, ktoré pridáte, keď máte čas. Sú podlahou, na ktorej staviate.

Kruté na tejto kategórii je, že vám to prejde presne až do chvíle, keď neprejde. Celý rok je všetko v poriadku a potom jeden únik, jedno náhodné hromadné zmazanie, jedno ráno s vydieračským softvérom vymaže dôveru a údaje, ktoré ste ten rok budovali. Nežiadame bezpečnostné oddelenie. Žiadame, aby tam základy boli od začiatku, pretože cena ich pridania po incidente sa meria v mŕtvych firmách.

8. Najatie nesprávneho staviteľa pre nesprávnu fázu

Netechnickí zakladatelia čelia krutej voľbe: kto to vlastne postaví? Dve klasické chyby sú si vzájomným zrkadlom. Jednou je najať najlacnejšieho možného freelancera, ktorý dodá niečo, čo vyzerá správne, ale drží pohromade na lepiacej páske, a potom sa rozpadne vo chvíli, keď to potrebujete zmeniť. Druhou je prehnané najímanie — celý senior tím s plnými platmi na stavbu produktu, ktorý si ešte nezarobil ani jedného zákazníka.

Úprimná odpoveď úplne závisí od toho, kde sa nachádzate. Na overenie nápadu chcete malý, senior, pragmatický tím, ktorý už staval produkty v ranej fáze a presne vie, čo vynechať. Na škálovanie overeného produktu chcete iných ľudí s inými inštinktmi. Spárovanie staviteľa s fázou je samo o sebe zručnosť — a pokaziť to vás stojí viac peňazí než ktorékoľvek technické rozhodnutie na tomto zozname.

9. Branie spustenia ako cieľovej čiary

Posledná chyba je najsmutnejšia, pretože prichádza po toľkej tvrdej práci. Tím berie deň spustenia ako cieľ, hodí doň všetko, aby sa tam dostal, a dorazí vyčerpaný bez plánu, bez rozpočtu a bez energie na to, čo nasleduje. No spustenie nie je cieľová čiara. Je začiatkom jedinej fázy, na ktorej záleží: učenia sa od skutočných používateľov a zlepšovania, týždeň za týždňom.

SaaS produkt nie je nikdy „hotový“. Prvá verzia je hypotéza a mesiace po spustení sú časom, keď zistíte, ako veľmi bola nesprávna — v tom dobrom zmysle. Zakladatelia, ktorí s tým počítajú, ktorí si v rezerve nechajú trochu finančnej rezervy a veľa zvedavosti, sú tí, ktorí zmenia vratké spustenie na skutočný biznis. Tí, čo minuli všetko na dosiahnutie štartovej čiary, zvyčajne nedôjdu oveľa ďalej.

Ako sa naozaj vyhnúť všetkým deviatim

Čítať zoznam chýb je ľahké. Vyhýbať sa im pod tlakom termínu, s vlastnými peniazmi v hre a vlastným nápadom v srdci, je naozaj ťažké. Tak tu je krátka verzia toho, ako zvyknú fungovať zakladatelia, ktorí to robia správne — nie ako pravidlá, ale ako návyky, ktoré stojí za to ukradnúť.

1. 1
   Overte skôr, než staviate

   Postavte niečo hrubé pred skutočných potenciálnych zákazníkov a potvrďte, že zaplatia, skôr než napíšete vážny kód. Lacné na urobenie, kruté na vynechanie.
2. 2
   Vyberte najmenší skutočný produkt

   Definujte tú jednu vec, ktorú váš produkt musí robiť, a nemilosrdne odložte všetko ostatné. Zapíšte, čo „verzia jeden“ zámerne nezahŕňa.
3. 3
   Stavajte nudne a izolujte nájomcov

   Použite najjednoduchšiu architektúru, ktorá funguje, ale oddelenie údajov medzi zákazníkmi urobte základným, otestovaným rozhodnutím od prvého dňa.
4. 4
   Cestu peňazí navrhnite skoro

   Berte registráciu, uvedenie a fakturáciu ako základný produkt, nie papierovačku. Prvých päť minút rozhodne, či sa zvyšok vôbec uvidí.
5. 5
   Vybavte to meraním, potom spustite, aby ste sa učili

   Vydajte s nasadenou základnou analytikou a spätnou väzbou, nechajte si finančnú rezervu na fázu po spustení a berte prvú verziu ako otázku, nie odpoveď.

Všimnite si, že takmer nič z toho nie je o programátorskej zručnosti. Je to o úsudku — vedieť, čo postaviť, čo vynechať a kedy. Práve preto toľko technicky schopných tímov stále vyrába produkty, ktoré zlyhávajú: ťažkou časťou SaaS nikdy nebolo inžinierstvo. Bola to zdržanlivosť.

Časté otázky