9 SaaS-fejlesztési hiba, amely csendben elsüllyeszti a kezdő startupokat

Szinte senki sem épít szándékosan rosszul SaaS-terméket. A kezdő startupokat elsüllyesztő hibák csendes, ésszerűen hangzó döntések, amelyeket okos emberek hoznak nyomás alatt — és abban a pillanatban mind helyesnek tűnnek. Ugyanezt a kilenc hibát figyeltük meg tucatnyi terméknél, alapítók garázsaiban és jól finanszírozott csapatoknál egyaránt. A jó hír, hogy kiszámíthatók, ami azt jelenti, hogy elkerülhetők. Ez az a lista, amelyet azt kívánnánk, minden alapító a monitorára ragasztva tartson, mielőtt az első kódsort megírná.

Kis- és középvállalkozásoknak fejlesztünk szoftvert, ami azt jelenti, hogy két nagyon eltérő pillanatban hívnak minket. Néha az első napon, amikor csak egy vázlat és egy ötlet van. Sajnos gyakrabban a kilencedik hónapban — amikor egy alapító már elköltötte a megtakarításait, a termék technikailag működik, mégsem fizet érte senki. Ez a második típusú hívás tanította meg nekünk ezt a listát. Minden alkalommal a boncolás ugyanazt a kis sebcsoportot tárja fel: korán okozott, és elgennyedni hagyott sebeket.

E hibák egyike sem a tehetségről szól. Akik elkövetik őket, általában rátermettek és szorgalmasak. A baj az, hogy a SaaS építése egy nagyon sajátos önmérsékletet jutalmaz, amely nem jön természetesen, amikor lelkesedik a saját ötletéért. Vegyük hát végig mind a kilencet, nagyjából abban a sorrendben, ahogy harapni szoktak, és legyünk őszinték, miért olyan csábító mindegyik.

1. Hat hónapig fejleszteni, mielőtt egyetlen ügyféllel is beszélne

Ez az eredendő bűn, és a legdrágább is. Az alapító meg van győződve róla, hogy az ötlet jó — és lehet, hogy az is — ezért elnémul, fél éven át lehajtott fejjel fejleszt, majd egy kifényesített termékkel bukkan elő, amelyet senki sem kért. A piac nem az erőfeszítést jutalmazza. Azt jutalmazza, ha megoldanak egy problémát, amelynek megszüntetéséért valaki hajlandó fizetni.

A megoldás nem bonyolult, csak kényelmetlen: mutasson valami nyerset valódi potenciális ügyfeleknek, mielőtt elkészülne. Egy kattintható makett, egy landoló oldal, vagy akár a szolgáltatás kézzel, e-mailen át végzett manuális változata. Minden hét, amelyet azelőtt fejleszt, hogy megbizonyosodna róla, az emberek akarják, egy olyan hét, amelyet talán egy rossz utcában álló ház berendezésével tölt.

2. Egymillió felhasználóra építeni, akik nincsenek meg

A második hiba a szakszerűség jelmezét ölti. Az alapító, vagy egy nagyratörő korai mérnök úgy tervezi meg a rendszert, hogy az első naptól óriási léptéket bírjon el — mikroszolgáltatások, Kubernetes, több régiós adatbázisok, kidolgozott gyorsítótárrétegek. Felelősségteljesnek tűnik. Valójában csapda. A legritkább erőforrását — az időt — egy olyan probléma elleni védekezésre költi, amelynek megléte szerencse lenne.

Egy unalmas, egyetlen adatbázisú monolit kényelmesen elviszi az első néhány ezer felhasználóig és jóval az első bevétele után is. A léptéknél fontos architekturális döntések szinte sosem azok, amelyeket az elején előre lát, és a korai bonyolultság lassabbá teszi a termék változtatását — ami a kezdeti napokban az egyetlen dolog, ami valóban megöli. A következő tíz ügyfélre építsen, ne a képzeletbeli milliomodikra.

3. Egy MVP, amely sem nem minimális, sem nem életképes, sem nem termék

Mindenki egyetért abban, hogy MVP-t kell építeni. Szinte senki nem teszi meg valójában. Helyette egy szétterülő „első verzió” kerül kiadásra, megtömve minden funkcióval, amit az alapító el tudott képzelni, mert a funkciók kihúzása olyan, mintha az ambíciót húznák ki. Az eredmény háromszor annyi ideig tart, háromszor annyiba kerül, és nehezebb tanulni belőle — mert amikor egy felfújt termék elbukik, nem lehet megmondani, melyik rész volt rossz.

Egy valódi MVP egyetlen dolgot csinál elég jól ahhoz, hogy valaki fizessen érte. Ennyi. A fegyelem nem abban áll, hogy eldöntse, mit vegyen bele; abban áll, hogy eldöntse, mit hagyjon ki, tudva, hogy minden elhalasztott „magától értetődő” funkció egy visszanyert hét és egy kérdés, amelyet valódi felhasználókkal válaszol meg, nem találgatással.

Egy gyors hatóköri józanságteszt

Mielőtt bármely funkció bekerülne az első verzióba, az alapítóknak hangosan meg kell válaszolniuk egy kérdést: „Ha enélkül adnánk ki, akár egyetlen fizető ügyfél is megtagadná a termék használatát?” Ha az őszinte válasz nem, akkor vár. El fog csodálkozni, hogy a „nélkülözhetetlen” funkciólistájából mennyi párolog el e mondat alatt.

• Ha egy funkció azért létezik, hogy a befektetőket lenyűgözze, nem hogy a felhasználót szolgálja, akkor vár.
• Ha egy funkció olyan szélső esetet kezel, amellyel 20 felhasználóból kevesebb mint 1 találkozik, akkor vár.
• Ha olyan viselkedés beállítására épít beállításokat, amelynek megváltoztatását még senki sem kérte, akkor vár.
• Ha az egyetlen ok, amiért a listán van, hogy „a versenytársnak megvan”, akkor vár.
• Ha az eltávolítása egyetlen eladást sem állítana meg, akkor vár.

4. A számlázás és a beléptetés utólagos gondolatként kezelése

Az alapítók szeretetet öntenek az alapfunkcióba, majd két héttel az indulás előtt eszükbe jut, hogy az ügyfeleknek szükségük van egy módra a regisztrációra, fizetésre és arra, hogy ténylegesen használni kezdjék a dolgot. A számlázást pánikban toldják hozzá. A beléptetés egy bejelentkezési képernyő és egy vállrándítás. De az „érdeklődő látogatótól” a „fizető, aktivált felhasználóig” vezető út maga az üzlete — és itt szivárog el a bevételének nagy része csendben.

Láttunk valóban kiváló alapfunkcióval rendelkező termékeket, amelyek a regisztrációk többségét elvesztették az első öt percben, mert senki sem tudta kitalálni, mit kezdjen a regisztráció után. Előfizetések, próbaidőszakok, arányosítás, sikertelen fizetések, lemondások, egy vadonatúj fiók üres állapotú élménye — ezek nem papírmunka. Ezek maga a valódi termék, az ügyfél számára, abban a pillanatban, amikor eldönti, hogy marad-e.

5. A multi-tenancy elrontása (vagy kihagyása)

Ez az, amely pontosan addig tűnik rendben lévőnek, amíg katasztrófává nem válik. A SaaS azt jelenti, hogy sok ügyfél osztozik egyetlen rendszeren, és az, hogy hogyan választja szét az adataikat — multi-tenancy — alapvető döntés. Ha elrontja, vagy olyat épít, amely nem tudja megfelelően elszigetelni az ügyfeleket, vagy ami rosszabb, kiad egy hibát, amelyben az egyik cég látja egy másik cég adatait. Nincs gyorsabb módja minden ügyfél egyszerre történő elvesztésének, mint egy adatszivárgás a bérlők között.

Nincs szüksége egzotikus felállásra. A legtöbb korai szakaszú termékhez tökéletesen elegendő egyetlen megosztott adatbázis, minden táblán és minden lekérdezésen szigorúan kikényszerített bérlőazonosítóval — feltéve, hogy az elszigetelés az alapokba van beépítve és tesztelve, nem utólag rászórva. A hiba nem az egyszerű megközelítés választása. A hiba az, ha nem tudatosan dönt, és a rést akkor fedezi fel, amikor már éles üzemben van.

6. Sötétbe való kiadás, anélkül hogy látná, mit csinálnak a felhasználók

Elindítja. Az emberek regisztrálnak. Aztán... csend. Fogalma sincs, mely funkciókat érintik, hol akadnak el, vagy miért távoznak. Így találgat. A következő funkciót megérzés alapján építi, vagy a leghangosabb ügyfél-e-mail, vagy a saját intuíciója alapján — amely a saját termékében töltött hónapok után a legkevésbé megbízható eszköze.

Az alapvető termékanalitika és egy egyszerű mód a visszajelzések gyűjtésére nem a növekedési szakasz luxusa. Ez az, ahogyan kormányoz. Nélkülük nem üzletet vezet, hanem egy drága véleményt. Még olyan egyszerű dolgot tudni is, mint hogy „a felhasználók 80%-a soha nem nyitja meg a funkciót, amelyre két hónapot fordítottam”, többet ér, mint újabb két hónapnyi vakon való fejlesztés.

7. A biztonság és a mentések „későbbre” hagyása

A sebesség a korai szakasz vallása, és többnyire ez helyes. De van egy kis halmaza dolgoknak, amelyeket katasztrofálisan drága utólag beépíteni, és a biztonság áll a lista élén. A jelszavak megfelelő tárolása, annak lezárása, ki mihez férhet hozzá, és — kérem — működő, tesztelt mentésekkel rendelkezni nem opcionális funkciók, amelyeket akkor ad hozzá, ha lesz ideje. Ezek a padló, amelyre épít.

E kategória kegyetlensége az, hogy pontosan addig megússza, amíg meg nem. Egy évig minden rendben, aztán egyetlen behatolás, egyetlen véletlen tömeges törlés, egyetlen zsarolóvírusos reggel kitörli a bizalmat és az adatokat, amelyeket abban az évben épített. Nem kérünk biztonsági részleget. Azt kérjük, hogy az alapok ott legyenek a kezdettől, mert egy incidens utáni hozzáadásuk költségét halott cégekben mérik.

8. A rossz fejlesztő felvétele a rossz szakaszhoz

A nem technikai alapítók brutális választással néznek szembe: ki építi meg valójában ezt a dolgot? A két klasszikus hiba egymás tükörképe. Az egyik a lehető legolcsóbb szabadúszó felvétele, aki valami helyesnek látszót szállít, de cellux tartja össze, majd összeomlik abban a pillanatban, amikor változtatnia kell rajta. A másik a túlzott felvétel — egy teljes szenior csapat teljes fizetésekkel egy olyan termék építésére, amely még egyetlen ügyfelet sem szerzett.

Az őszinte válasz teljes mértékben attól függ, hol tart. Egy ötlet érvényesítéséhez egy kicsi, szenior, pragmatikus csapatot akar, amely már épített korai szakaszú termékeket, és pontosan tudja, mit hagyjon ki. Egy bevált termék skálázásához más emberekre van szüksége, más ösztönökkel. A fejlesztő szakaszhoz illesztése maga is készség — és elrontása több pénzt pazarol el, mint bármely technikai döntés ezen a listán.

9. Az indulást célvonalként kezelni

Az utolsó hiba a legszomorúbb, mert annyi kemény munka után jön. A csapat az indulás napját tekinti célnak, mindent beleölel, hogy odaérjen, és kimerülten érkezik meg, terv nélkül, költségvetés nélkül és energia nélkül arra, ami ezután jön. De az indulás nem a célvonal. Az egyetlen számító szakasz kezdete: tanulni a valódi felhasználóktól, és javítani, hétről hétre.

Egy SaaS-termék soha nincs „kész”. Az első verzió egy hipotézis, és az indulás utáni hónapok azok, amikor megtudja, mennyire volt téves — jó értelemben. Azok az alapítók, akik ezzel számolnak, akik egy kis pénzügyi tartalékot és sok kíváncsiságot tartanak vissza, azok, akik egy ingatag indulást valódi üzletté alakítanak. Akik mindent elköltöttek, hogy elérjék a rajtvonalat, általában nem jutnak sokkal tovább.

Hogyan kerülje el valóban mind a kilencet

Egy hibalistát elolvasni könnyű. Elkerülni őket határidőnyomás alatt, a saját pénzével a kockán és a saját ötletével a szívében, igazán nehéz. Íme tehát a rövid változata annak, ahogyan a sikeres alapítók működni szoktak — nem szabályként, hanem ellopásra érdemes szokásként.

1. 1
   Érvényesítsen, mielőtt épít

   Tegyen valami nyerset valódi potenciális ügyfelek elé, és erősítse meg, hogy fizetni fognak, mielőtt komoly kódot írna. Olcsó megtenni, brutális kihagyni.
2. 2
   Válassza a legkisebb valódi terméket

   Határozza meg azt az egy dolgot, amit a terméknek tennie kell, és kíméletlenül halasszon el minden mást. Írja le, mit nem tartalmaz szándékosan az „első verzió”.
3. 3
   Építsen unalmasan és szigetelje el a bérlőket

   Használja a legegyszerűbb működő architektúrát, de az ügyfelek közötti adatszétválasztást tegye alapvető, tesztelt döntéssé az első naptól.
4. 4
   Tervezze meg korán a pénz útját

   Kezelje a regisztrációt, a beléptetést és a számlázást alaptermékként, nem papírmunkaként. Az első öt perc dönti el, hogy a többit egyáltalán látják-e.
5. 5
   Műszerezze fel, majd indítson, hogy tanuljon

   Adja ki alapvető analitikával és visszajelzéssel a helyén, tartson tartalékot az indulás utáni szakaszra, és kezelje az első verziót kérdésként, ne válaszként.

Vegye észre, hogy ennek szinte semmi köze a kódolási képességhez. Az ítélőképességről szól — tudni, mit építsen, mit hagyjon ki, és mikor. Pontosan ezért állítanak elő technikailag képes csapatok mégis bukásra ítélt termékeket: a SaaS nehéz része soha nem a mérnöki munka volt. Az önmérséklet volt.

Gyakori kérdések