9 grešaka u razvoju SaaS-a koje tiho potapaju startupe u ranoj fazi

Gotovo nitko ne gradi SaaS proizvod pogrešno namjerno. Greške koje potapaju rane startupe tihe su, razumno zvučeće odluke koje pametni ljudi donose pod pritiskom — i sve se u tom trenutku čine ispravnima. Promatrali smo kako se istih devet odvija na desecima proizvoda, u garažama osnivača jednako kao i u dobro financiranim timovima. Dobra je vijest da su predvidljive, što znači da ih se može izbjeći. Ovo je popis za koji bismo voljeli da ga je svaki osnivač zalijepio na svoj monitor prije nego što je napisao prvi redak koda.

Gradimo softver za mala i srednja poduzeća, što znači da nas zovu u dva vrlo različita trenutka. Ponekad je to prvi dan, kad ne postoji ništa osim skice i ideje. Češće je, nažalost, deveti mjesec — kad je osnivač potrošio svoju ušteđevinu, proizvod tehnički radi, a ipak nitko ne plaća za njega. Ta druga vrsta poziva ono je što nas je naučilo ovaj popis. Svaki put obdukcija otkriva isti mali skup rana, nanesenih rano i ostavljenih da gnoje.

Nijedna od tih grešaka nije stvar talenta. Ljudi koji ih rade obično su sposobni i marljivi. Problem je u tome što izgradnja SaaS-a nagrađuje vrlo specifičnu vrstu suzdržanosti koja ne dolazi prirodno kad ste oduševljeni vlastitom idejom. Stoga prođimo kroz tih devet, otprilike onim redom kojim obično ujedaju, i budimo iskreni o tome zašto je svaka toliko primamljiva.

1. Šest mjeseci izgradnje prije razgovora s ijednim kupcem

Ovo je istočni grijeh i najskuplji je. Osnivač je uvjeren da je ideja dobra — i možda jest — pa utihne, glavom prignut gradi pola godine i izroni s uglađenim proizvodom koji nitko nije tražio. Tržište ne nagrađuje trud. Nagrađuje rješavanje problema za koji će netko platiti da nestane.

Rješenje nije komplicirano, samo je neugodno: pokažite nešto grubo stvarnim potencijalnim kupcima prije nego što je gotovo. Klikabilni model, odredišnu stranicu, čak i ručnu inačicu usluge obavljenu rukom putem e-pošte. Svaki tjedan izgradnje prije nego što ste potvrdili da to ljudi žele tjedan je koji možda trošite uređujući kuću u pogrešnoj ulici.

2. Gradnja za milijun korisnika koje nemate

Druga greška nosi kostim profesionalnosti. Osnivač, ili ambiciozan rani inženjer, dizajnira sustav tako da od prvog dana podnosi golemu skalabilnost — mikroservisi, Kubernetes, baze podataka u više regija, razrađeni slojevi predmemorije. Čini se odgovornim. Zapravo je zamka. Trošite svoj najoskudniji resurs — vrijeme — braneći se od problema koji biste imali sreće da ga uopće imate.

Dosadan monolit s jednom bazom podataka udobno će vas ponijeti do prvih nekoliko tisuća korisnika i daleko preko vašeg prvog prihoda. Arhitektonske odluke koje su važne pri velikoj skali gotovo nikad nisu one koje možete predvidjeti na početku, a preuranjena složenost čini proizvod sporijim za promjenu — što je, u ranim danima, jedino što vas zaista ubija. Gradite za sljedećih deset kupaca, ne za zamišljenog milijuntog.

3. MVP koji nije ni minimalan, ni održiv, ni proizvod

Svi se slažu oko izgradnje MVP-a. Gotovo nitko to zapravo ne radi. Umjesto toga isporučuje se rasprostranjena "prva inačica" natrpana svakom značajkom koju je osnivač mogao zamisliti, jer rezanje značajki djeluje kao rezanje ambicije. Rezultat traje tri puta dulje, košta tri puta više i iz njega je teže učiti — jer kad napuhani proizvod propadne, ne možete reći koji je dio bio pogrešan.

Pravi MVP radi jednu stvar dovoljno dobro da netko za nju plati. To je sve. Disciplina nije u odlučivanju što uključiti; ona je u odlučivanju što izostaviti, znajući da je svaka "očita" značajka koju odgodite tjedan koji dobivate natrag i pitanje na koje smijete odgovoriti sa stvarnim korisnicima umjesto nagađanjima.

Brza provjera zdravorazumskog opsega

Prije nego što ijedna značajka uđe u prvu inačicu, navedemo osnivače da naglas odgovore na jedno pitanje: "Da smo isporučili bez ovoga, bi li ijedan kupac koji plaća odbio koristiti proizvod?" Ako je iskren odgovor ne, čeka. Iznenadit ćete se koliko se vašeg popisa "nužnih" značajki ispari pod tom jednom rečenicom.

• Ako značajka postoji da impresionira ulagače, a ne da služi korisniku, čeka.
• Ako značajka rješava rubni slučaj na koji će naići manje od 1 od 20 korisnika, čeka.
• Ako gradite postavke kako biste konfigurirali ponašanje koje nitko još nije tražio da se promijeni, čeka.
• Ako je 'konkurent to ima' jedini razlog zašto je na popisu, čeka.
• Ako njezino uklanjanje ne bi zaustavilo ijednu prodaju, čeka.

4. Tretiranje naplate i uvođenja korisnika kao naknadne misli

Osnivači ulažu ljubav u temeljnu značajku, a onda se, dva tjedna prije lansiranja, sjete da kupcima treba način da se registriraju, plate i zaista počnu koristiti tu stvar. Naplata se u panici nakalemi. Uvođenje je zaslon za prijavu i slijeganje ramenima. No put od "zainteresiranog posjetitelja" do "korisnika koji plaća i aktivan je" jest vaš posao — i to je mjesto na kojem vam većina prihoda tiho otječe.

Vidjeli smo proizvode sa zaista izvrsnom temeljnom značajkom koji izgube većinu registracija u prvih pet minuta jer nitko nije mogao shvatiti što učiniti nakon registracije. Pretplate, probna razdoblja, razmjerni obračun, neuspjela plaćanja, otkazivanja, doživljaj praznog stanja za potpuno nov račun — to nije papirologija. To je stvarni proizvod, za kupca, u trenutku kad odlučuje hoće li ostati.

5. Pogrešno postavljena višenajamnost (ili njezino preskakanje)

Ovo je ona koja izgleda u redu sve dok ne postane katastrofa. SaaS znači mnogo kupaca koji dijele jedan sustav, a način na koji razdvajate njihove podatke — višenajamnost — temeljna je odluka. Pogriješite li, ili izgradite nešto što ne može pravilno izolirati kupce, ili još gore, isporučite grešku u kojoj jedna tvrtka može vidjeti podatke druge tvrtke. Nema bržeg načina da izgubite sve kupce odjednom od curenja podataka između najmoprimaca.

Ne treba vam egzotičan postav. Za većinu proizvoda u ranoj fazi, jedna zajednička baza podataka sa strogo provođenim ID-jem najmoprimca u svakoj tablici i svakom upitu sasvim je dovoljna — pod uvjetom da je ta izolacija ugrađena u temelje i testirana, a ne posuta naknadno. Greška nije u odabiru jednostavnog pristupa. Greška je ne odlučiti svjesno i otkriti rupu kad je već u produkciji.

6. Isporuka u mrak bez načina da vidite što korisnici rade

Lansirate. Ljudi se registriraju. A onda... tišina. Nemate pojma koje značajke dodiruju, gdje zapnu ili zašto odlaze. Pa nagađate. Gradite sljedeću značajku na temelju slutnje, ili najglasnijeg kupčevog e-maila, ili vlastite intuicije — koja je, nakon mjeseci unutar vlastitog proizvoda, najnepouzdaniji instrument koji posjedujete.

Osnovna analitika proizvoda i jednostavan način prikupljanja povratnih informacija nisu luksuz faze rasta. Oni su način na koji upravljate kormilom. Bez njih ne vodite posao, vodite skupo mišljenje. Čak i znati nešto tako jednostavno kao "80 % korisnika nikad ne otvori značajku koju sam gradio dva mjeseca" vrijedi više od još dva mjeseca slijepe izgradnje.

7. Ostavljanje sigurnosti i sigurnosnih kopija za 'kasnije'

Brzina je religija rane faze i to je uglavnom ispravno. No postoji mali skup stvari koje je katastrofalno skupo naknadno ugraditi, a sigurnost je na vrhu popisa. Ispravno pohranjivanje lozinki, ograničavanje tko čemu može pristupiti i — molimo vas — posjedovanje radnih, testiranih sigurnosnih kopija nisu neobavezne značajke koje dodajete kad imate vremena. To je pod na kojem gradite.

Okrutno je u ovoj kategoriji to što vam prolazi sve dok ne prestane prolaziti. Sve je u redu godinu dana, a onda jedan proboj, jedno slučajno masovno brisanje, jedno jutro s ucjenjivačkim softverom izbriše povjerenje i podatke koje ste tu godinu gradili. Ne tražimo sigurnosni odjel. Tražimo da osnove budu tu od početka, jer se trošak njihova dodavanja nakon incidenta mjeri u mrtvim tvrtkama.

8. Zapošljavanje pogrešnog graditelja za pogrešnu fazu

Netehnički osnivači suočavaju se s okrutnim izborom: tko zapravo gradi ovu stvar? Dvije klasične greške zrcale jedna drugu. Jedna je zaposliti najjeftinijeg mogućeg slobodnjaka koji isporuči nešto što izgleda ispravno, ali je zalijepljeno selotejpom, a onda se raspadne čim ga trebate promijeniti. Druga je prekomjerno zapošljavanje — cijeli seniorski tim s punim plaćama da gradi proizvod koji još nije zaradio ni jednog kupca.

Iskren odgovor u potpunosti ovisi o tome gdje se nalazite. Za potvrdu ideje želite mali, seniorski, pragmatičan tim koji je već gradio proizvode u ranoj fazi i točno zna što izostaviti. Za skaliranje dokazanog proizvoda želite drukčije ljude s drukčijim instinktima. Uparivanje graditelja s fazom samo je po sebi vještina — a pogriješiti u tome troši više novca od bilo koje tehničke odluke na ovom popisu.

9. Tretiranje lansiranja kao ciljne crte

Posljednja je greška najtužnija jer dolazi nakon toliko teškog rada. Tim tretira dan lansiranja kao cilj, baca sve u to da stigne onamo i stiže iscrpljen, bez plana, bez proračuna i bez energije za ono što slijedi. No lansiranje nije ciljna crta. Ono je početak jedine faze koja je važna: učenja od stvarnih korisnika i poboljšavanja, tjedan za tjednom.

SaaS proizvod nikad nije "gotov". Prva je inačica hipoteza, a mjeseci nakon lansiranja vrijeme su kad otkrivate koliko je bila pogrešna — na dobar način. Osnivači koji to planiraju, koji čuvaju malo financijskog zaleta i mnogo znatiželje u rezervi, oni su koji nestabilno lansiranje pretvore u stvaran posao. Oni koji su sve potrošili da bi dosegnuli startnu crtu obično ne stignu mnogo dalje.

Kako zaista izbjeći svih devet

Čitati popis grešaka lako je. Izbjegavati ih pod pritiskom roka, s vlastitim novcem na kocki i vlastitom idejom u srcu, doista je teško. Stoga evo kratke inačice toga kako obično rade osnivači koji to izvedu kako treba — ne kao pravila, nego kao navike koje vrijedi ukrasti.

1. 1
   Potvrdite prije nego što gradite

   Stavite nešto grubo pred stvarne potencijalne kupce i potvrdite da će platiti, prije nego što napišete ozbiljan kod. Jeftino za napraviti, okrutno za preskočiti.
2. 2
   Odaberite najmanji stvarni proizvod

   Definirajte onu jednu stvar koju vaš proizvod mora raditi i nemilosrdno odgodite sve ostalo. Zapišite što 'prva inačica' namjerno ne uključuje.
3. 3
   Gradite dosadno i izolirajte najmoprimce

   Koristite najjednostavniju arhitekturu koja radi, ali učinite razdvajanje podataka među kupcima temeljnom, testiranom odlukom od prvog dana.
4. 4
   Rano dizajnirajte put novca

   Tretirajte registraciju, uvođenje i naplatu kao temeljni proizvod, ne kao papirologiju. Prvih pet minuta odlučuje hoće li se ostatak uopće vidjeti.
5. 5
   Instrumentirajte ga, pa lansirajte da biste učili

   Isporučite s postavljenom osnovnom analitikom i povratnim informacijama, čuvajte financijski zalet za fazu nakon lansiranja i tretirajte prvu inačicu kao pitanje, ne kao odgovor.

Primijetite da gotovo ništa od ovoga nije stvar vještine kodiranja. Stvar je u prosudbi — znati što graditi, što preskočiti i kada. Upravo zato toliko tehnički sposobnih timova i dalje proizvodi proizvode koji propadaju: teški dio SaaS-a nikad nije bio inženjerstvo. Bila je to suzdržanost.

Česta pitanja