9 chyb ve vývoji SaaS, které tiše potápějí začínající startupy

Skoro nikdo nestaví SaaS produkt špatně schválně. Chyby, které potápějí začínající startupy, jsou tichá, rozumně znějící rozhodnutí chytrých lidí pod tlakem — a v danou chvíli všechna působí správně. Stejných devět chyb jsme sledovali u desítek produktů, v garážích zakladatelů i v dobře financovaných týmech. Dobrá zpráva je, že jsou předvídatelné, což znamená, že se jim dá vyhnout. Tohle je seznam, který bychom přáli každému zakladateli mít přilepený na monitoru dřív, než napíše první řádek kódu.

Stavíme software pro malé a střední firmy, což znamená, že nás volají ve dvou velmi odlišných okamžicích. Někdy je to první den, kdy není nic než náčrt a nápad. Častěji je to bohužel devátý měsíc — kdy zakladatel utratil úspory, produkt technicky funguje, a přesto za něj nikdo neplatí. Právě druhý typ hovoru nás tento seznam naučil. Pokaždé pitva odhalí stejnou malou sadu ran, způsobených brzy a ponechaných hnisat.

Žádná z těchto chyb není o talentu. Lidé, kteří je dělají, jsou obvykle schopní a pracovití. Problém je, že stavba SaaS odměňuje velmi specifický druh zdrženlivosti, který nepřichází přirozeně, když jste nadšení z vlastního nápadu. Pojďme tedy projít všech devět, zhruba v pořadí, v jakém mívají tendenci kousat, a buďme upřímní, proč je každá z nich tak lákavá.

1. Půl roku vývoje dřív, než promluvíte s jediným zákazníkem

Tohle je prvotní hřích a ten nejdražší. Zakladatel je přesvědčen, že nápad je dobrý — a možná je — tak se odmlčí, půl roku staví se sklopenou hlavou a vynoří se s vyleštěným produktem, o který nikdo nepožádal. Trh neodměňuje úsilí. Odměňuje vyřešení problému, za jehož odstranění je někdo ochoten zaplatit.

Řešení není složité, jen nepříjemné: ukažte něco surového skutečným potenciálním zákazníkům dřív, než to bude hotové. Proklikatelný mockup, vstupní stránku, dokonce i ruční verzi služby udělanou ručně přes e-mail. Každý týden vývoje předtím, než si potvrdíte, že to lidé chtějí, je týden, který možná strávíte zařizováním domu ve špatné ulici.

2. Stavba pro milion uživatelů, které nemáte

Druhá chyba na sebe bere kostým profesionality. Zakladatel nebo ambiciózní raný inženýr navrhne systém tak, aby od prvního dne zvládl obrovský rozsah — mikroslužby, Kubernetes, multiregionální databáze, propracované vrstvy cachování. Působí to zodpovědně. Ve skutečnosti je to past. Utrácíte svůj nejvzácnější zdroj — čas — na obranu proti problému, který byste měli štěstí mít.

Nudný monolit s jedinou databází vás pohodlně donese k prvním pár tisícům uživatelů a daleko za první tržby. Architektonická rozhodnutí, na kterých záleží při škálování, skoro nikdy nejsou ta, která dokážete předvídat na začátku, a předčasná složitost dělá produkt pomalejším na změny — což je v raných dnech jediná věc, která vás opravdu zabíjí. Stavte pro dalších deset zákazníků, ne pro pomyslného miliontého.

3. MVP, které není ani minimální, ani životaschopné, ani produkt

Všichni se shodnou na tom, že se má postavit MVP. Skoro nikdo to ale doopravdy neudělá. Místo toho se vydá rozbujelá „verze jedna“ nacpaná každou funkcí, kterou si zakladatel dokázal představit, protože škrtání funkcí připadá jako škrtání ambicí. Výsledek trvá třikrát déle, stojí třikrát víc a hůř se z něj učí — protože když nabobtnalý produkt selže, nepoznáte, která část byla špatně.

Skutečné MVP dělá jednu věc dost dobře na to, aby za ni byl někdo ochoten zaplatit. To je vše. Disciplína není v rozhodování, co zahrnout; je v rozhodování, co vynechat, s vědomím, že každá „samozřejmá“ funkce, kterou odložíte, je týden, který získáte zpět, a otázka, kterou zodpovíte se skutečnými uživateli místo dohadů.

Rychlá kontrola zdravého rozumu rozsahu

Než se jakákoli funkce dostane do první verze, necháváme zakladatele nahlas odpovědět na jednu otázku: „Kdybychom to vydali bez tohohle, odmítl by jediný platící zákazník produkt používat?“ Pokud je upřímná odpověď ne, počká to. Budete žasnout, kolik z vašeho seznamu „nezbytných“ funkcí se pod touhle jedinou větou vypaří.

• Pokud funkce existuje, aby zapůsobila na investory, ne aby posloužila uživateli, počká to.
• Pokud funkce řeší hraniční případ, na který narazí méně než 1 z 20 uživatelů, počká to.
• Pokud stavíte nastavení pro konfiguraci chování, jehož změnu zatím nikdo nepožadoval, počká to.
• Pokud je jediným důvodem na seznamu „má to konkurence“, počká to.
• Pokud by jeho odebrání nezastavilo jediný prodej, počká to.

4. Fakturace a onboarding jako věc na poslední chvíli

Zakladatelé vloží lásku do hlavní funkce a pak si dva týdny před spuštěním vzpomenou, že zákazníci potřebují způsob, jak se zaregistrovat, zaplatit a tu věc skutečně začít používat. Fakturace se v panice přilepí dodatečně. Onboarding je přihlašovací obrazovka a pokrčení rameny. Ale cesta od „zaujatého návštěvníka“ k „platícímu, aktivovanému uživateli“ je váš byznys — a je to místo, kudy většina vašich tržeb tiše uniká.

Viděli jsme produkty se skutečně vynikající hlavní funkcí ztratit většinu registrací v prvních pěti minutách, protože nikdo nedokázal přijít na to, co dělat po registraci. Předplatná, zkušební verze, poměrné vyúčtování, neúspěšné platby, zrušení, prázdný stav úplně nového účtu — to není papírování. To je skutečný produkt, pro zákazníka, v okamžiku, kdy se rozhoduje, jestli zůstane.

5. Špatná multi-tenancy (nebo její vynechání)

Tohle je ta chyba, která vypadá v pořádku přesně do chvíle, než je z ní katastrofa. SaaS znamená mnoho zákazníků sdílejících jeden systém a to, jak oddělíte jejich data — multi-tenancy — je zásadní rozhodnutí. Když to uděláte špatně, buď postavíte něco, co nedokáže zákazníky správně izolovat, nebo, ještě hůř, vydáte chybu, kdy jedna firma vidí data jiné firmy. Není rychlejší způsob, jak ztratit všechny zákazníky najednou, než únik dat mezi nájemníky.

Nepotřebujete exotické nastavení. Pro většinu produktů v rané fázi dokonale stačí jediná sdílená databáze se striktně vynucovaným ID nájemníka v každé tabulce a každém dotazu — za předpokladu, že izolace je zabudovaná do základů a otestovaná, ne posypaná navrch později. Chyba není ve volbě jednoduchého přístupu. Chyba je nerozhodnout se vědomě a objevit tu díru, až když už je v produkci.

6. Vydání do tmy bez možnosti vidět, co uživatelé dělají

Spustíte. Lidé se registrují. A pak... ticho. Nemáte tušení, kterých funkcí se dotýkají, kde uvíznou nebo proč odcházejí. Tak hádáte. Stavíte další funkci na základě tušení, nejhlasitějšího zákaznického e-mailu nebo vlastní intuice — která je po měsících uvnitř vlastního produktu tím nejméně spolehlivým nástrojem, který máte.

Základní produktová analytika a jednoduchý způsob sběru zpětné vazby nejsou luxus fáze růstu. Jsou tím, jak kormidlujete. Bez nich neřídíte byznys, řídíte drahý názor. I vědět něco tak prostého jako „80 % uživatelů nikdy neotevře funkci, na které jsem strávil dva měsíce“ má větší cenu než další dva měsíce slepého vývoje.

7. Odkládání bezpečnosti a záloh na „později“

Rychlost je náboženstvím rané fáze a většinou je to správně. Ale existuje malá množina věcí, které je katastrofálně drahé dodělávat dodatečně, a bezpečnost je na vrcholu seznamu. Správné ukládání hesel, uzamčení toho, kdo má k čemu přístup, a — prosím — mít funkční, otestované zálohy nejsou volitelné funkce, které přidáte, až budete mít čas. Jsou podlahou, na které stavíte.

Krutost této kategorie spočívá v tom, že vám to projde přesně do chvíle, než vám to neprojde. Celý rok je všechno v pořádku, a pak jediný průnik, jediné nechtěné hromadné smazání, jediné ransomwarové ráno vymaže důvěru a data, která jste celý ten rok budovali. Nežádáme bezpečnostní oddělení. Žádáme, aby tu základy byly od začátku, protože náklady na jejich přidání po incidentu se měří v mrtvých firmách.

8. Najmutí špatného tvůrce pro špatnou fázi

Netechničtí zakladatelé čelí brutální volbě: kdo to vlastně postaví? Dvě klasické chyby jsou si zrcadlem. Jedna je najmout co nejlevnějšího freelancera, který dodá něco, co vypadá správně, ale je slepené izolepou a rozpadne se ve chvíli, kdy potřebujete něco změnit. Druhá je přehnaný nábor — kompletní seniorní tým s plnými platy na stavbu produktu, který si zatím nezískal jediného zákazníka.

Upřímná odpověď zcela závisí na tom, kde jste. K ověření nápadu chcete malý, seniorní, pragmatický tým, který už ranofázové produkty stavěl a přesně ví, co vynechat. K škálování ověřeného produktu chcete jiné lidi s jinými instinkty. Sladit tvůrce s fází je samo o sobě dovednost — a udělat to špatně promrhá víc peněz než jakékoli technické rozhodnutí na tomto seznamu.

9. Spuštění jako cílová páska

Poslední chyba je nejsmutnější, protože přichází po tolika tvrdé práci. Tým bere den spuštění jako cíl, vrhne do něj všechno, a dorazí vyčerpaný, bez plánu, bez rozpočtu a bez energie na to, co přijde dál. Ale spuštění není cílová páska. Je to začátek jediné fáze, na které záleží: učit se od skutečných uživatelů a zlepšovat se, týden co týden.

SaaS produkt není nikdy „hotový“. První verze je hypotéza a měsíce po spuštění jsou doba, kdy zjistíte, jak moc byla špatná — v tom dobrém smyslu. Zakladatelé, kteří s tím počítají, kteří si v záloze nechají trochu finanční rezervy a spoustu zvídavosti, jsou ti, kdo promění vratké spuštění ve skutečný byznys. Ti, kdo utratili všechno na dosažení startovní čáry, obvykle nedojdou o mnoho dál.

Jak se všem devíti opravdu vyhnout

Číst seznam chyb je snadné. Vyhýbat se jim pod tlakem termínů, s vlastními penězi v sázce a vlastním nápadem v srdci, je doopravdy těžké. Tady je tedy krátká verze toho, jak mívají tendenci fungovat zakladatelé, kterým se to daří — ne jako pravidla, ale jako návyky hodné ukradení.

1. 1
   Ověřte dřív, než stavíte

   Postavte něco surového před skutečné potenciální zákazníky a potvrďte si, že zaplatí, dřív než napíšete vážný kód. Levné udělat, brutální přeskočit.
2. 2
   Vyberte nejmenší skutečný produkt

   Definujte tu jednu věc, kterou váš produkt musí dělat, a bezohledně odložte všechno ostatní. Sepište, co „verze jedna“ záměrně neobsahuje.
3. 3
   Stavte nudně a izolujte nájemníky

   Použijte nejjednodušší architekturu, která funguje, ale oddělení dat mezi zákazníky udělejte zásadním, otestovaným rozhodnutím od prvního dne.
4. 4
   Navrhněte cestu peněz brzy

   Berte registraci, onboarding a fakturaci jako hlavní produkt, ne jako papírování. Prvních pět minut rozhoduje, jestli se zbytek vůbec uvidí.
5. 5
   Vybavte to měřením, pak spusťte a učte se

   Vydejte se základní analytikou a zpětnou vazbou na svém místě, nechte si rezervu na fázi po spuštění a berte první verzi jako otázku, ne odpověď.

Všimněte si, že skoro nic z toho není o programátorské zručnosti. Je to o úsudku — vědět, co stavět, co vynechat a kdy. Přesně proto tolik technicky schopných týmů přesto vytvoří produkty, které selžou: ta těžká část SaaS nikdy nebyla inženýrství. Byla to zdrženlivost.

Časté otázky