9 SaaS-kehityksen virhettä, jotka hiljaa upottavat varhaiset startupit

Lähes kukaan ei rakenna SaaS-tuotetta väärin tarkoituksella. Virheet, jotka upottavat varhaiset startupit, ovat hiljaisia, järkeviltä kuulostavia päätöksiä, joita fiksut ihmiset tekevät paineen alla — ja ne kaikki tuntuvat oikeilta sillä hetkellä. Olemme nähneet samat yhdeksän toistuvan kymmenissä tuotteissa, niin perustajien autotalleissa kuin hyvin rahoitetuissa tiimeissäkin. Hyvä uutinen on, että ne ovat ennustettavissa, mikä tarkoittaa, että ne ovat vältettävissä. Tämä on lista, jonka toivoisimme jokaisen perustajan teipanneen näyttönsä reunaan ennen ensimmäisen koodirivin kirjoittamista.

Rakennamme ohjelmistoja pienille ja keskisuurille yrityksille, mikä tarkoittaa, että meidät kutsutaan apuun kahdessa hyvin erilaisessa hetkessä. Joskus se on päivä yksi, jolloin on vain luonnos ja idea. Useammin, valitettavasti, se on yhdeksäs kuukausi — kun perustaja on käyttänyt säästönsä, tuote teknisesti toimii, eikä silti kukaan maksa siitä. Jälkimmäinen puhelu opetti meille tämän listan. Joka ikinen kerta ruumiinavaus paljastaa saman pienen joukon haavoja, jotka on aiheutettu varhain ja jätetty märkimään.

Mikään näistä virheistä ei liity lahjakkuuteen. Niitä tekevät ihmiset ovat yleensä kyvykkäitä ja ahkeria. Ongelma on, että SaaS:n rakentaminen palkitsee hyvin tietynlaisesta pidättyvyydestä, joka ei tule luonnostaan, kun olet innoissasi omasta ideastasi. Käydään siis läpi nuo yhdeksän, suunnilleen siinä järjestyksessä, jossa ne yleensä purevat, ja ollaan rehellisiä siitä, miksi jokainen niistä on niin houkutteleva.

1. Puoli vuotta rakentamista ennen kuin puhut yhdellekään asiakkaalle

Tämä on perisynti, ja se on kaikkein kallein. Perustaja on vakuuttunut, että idea on hyvä — ja se saattaa olla — joten hän vaikenee, rakentaa pää painuksissa puoli vuotta ja ilmestyy esiin hiotulla tuotteella, jota kukaan ei pyytänyt. Markkina ei palkitse vaivannäöstä. Se palkitsee sellaisen ongelman ratkaisemisesta, jonka poistamisesta joku on valmis maksamaan.

Korjaus ei ole monimutkainen, se on vain epämukava: näytä jotain raakaa oikeille mahdollisille asiakkaille ennen kuin se on valmis. Klikattava mallikuva, laskeutumissivu, jopa palvelun manuaalinen versio, jonka teet käsin sähköpostitse. Jokainen rakentamisviikko ennen kuin olet vahvistanut ihmisten haluavan sitä, on viikko, jonka saatat käyttää väärän kadun talon sisustamiseen.

2. Miljoonan käyttäjän rakentaminen, joita sinulla ei ole

Toinen virhe pukeutuu ammattimaisuuden asuun. Perustaja tai kunnianhimoinen varhainen insinööri suunnittelee järjestelmän kestämään valtavaa skaalaa ensimmäisestä päivästä lähtien — mikropalvelut, Kubernetes, monialueiset tietokannat, monimutkaiset välimuistikerrokset. Se tuntuu vastuulliselta. Se on itse asiassa ansa. Käytät niukinta resurssiasi — aikaa — puolustautuaksesi ongelmaa vastaan, jonka saaminen olisi onnenkantamoinen.

Tylsä, yhden tietokannan monoliitti kantaa sinut mukavasti ensimmäisiin muutamaan tuhanteen käyttäjään ja hyvin ensimmäisten tulojesi ohi. Arkkitehtuuripäätökset, joilla on merkitystä mittakaavassa, eivät lähes koskaan ole niitä, jotka voit ennakoida alussa, ja ennenaikainen monimutkaisuus tekee tuotteesta hitaamman muuttaa — mikä alkuvaiheessa on ainoa asia, joka oikeasti tappaa sinut. Rakenna seuraavalle kymmenelle asiakkaalle, älä kuvitellulle miljoonannelle.

3. MVP, joka ei ole minimaalinen, elinkelpoinen eikä tuote

Kaikki ovat yhtä mieltä MVP:n rakentamisesta. Lähes kukaan ei oikeasti tee sitä. Sen sijaan julkaistaan rönsyilevä ”versio yksi”, joka on tupattu täyteen jokaista ominaisuutta, jonka perustaja saattoi kuvitella, koska ominaisuuksien karsiminen tuntuu kunnianhimon karsimiselta. Lopputulos kestää kolme kertaa kauemmin, maksaa kolme kertaa enemmän ja siitä on vaikeampi oppia — koska kun pömpöttävä tuote epäonnistuu, et voi sanoa, mikä osa oli väärin.

Todellinen MVP tekee yhden asian riittävän hyvin, jotta joku maksaa siitä. Siinä kaikki. Kuri ei ole päättää, mitä sisällyttää; se on päättää, mitä jättää pois, tietäen, että jokainen ”ilmeinen” ominaisuus, jonka lykkäät, on viikko, jonka saat takaisin, ja kysymys, johon saat vastata oikeilla käyttäjillä arvailujen sijaan.

Nopea laajuuden järkitarkistus

Ennen kuin mikään ominaisuus pääsee ensimmäiseen versioon, pyydämme perustajia vastaamaan yhteen kysymykseen ääneen: ”Jos julkaisisimme ilman tätä, kieltäytyisikö yksikään maksava asiakas käyttämästä tuotetta?” Jos rehellinen vastaus on ei, se odottaa. Yllätyt, kuinka paljon ”olennaisten” ominaisuuksiesi listasta haihtuu tuon yhden lauseen alla.

• Jos ominaisuus on olemassa tehdäkseen vaikutuksen sijoittajiin, ei palvellakseen käyttäjää, se odottaa.
• Jos ominaisuus käsittelee reunatapausta, joka koskee harvempaa kuin 1 käyttäjää 20:stä, se odottaa.
• Jos rakennat asetuksia konfiguroidaksesi käyttäytymistä, jonka muuttamista kukaan ei ole vielä pyytänyt, se odottaa.
• Jos ”kilpailijalla on se” on ainoa syy sen olemiselle listalla, se odottaa.
• Jos sen poistaminen ei estäisi yhtäkään kauppaa, se odottaa.

4. Laskutuksen ja käyttöönoton kohtelu jälkikäteisajatuksena

Perustajat kaatavat rakkautta ydinominaisuuteen ja muistavat sitten, kaksi viikkoa ennen julkaisua, että asiakkaat tarvitsevat tavan rekisteröityä, maksaa ja oikeasti aloittaa tuotteen käyttö. Laskutus pultataan kiinni paniikissa. Käyttöönotto on kirjautumisruutu ja olankohautus. Mutta polku ”kiinnostuneesta vierailijasta” ”maksavaan, aktivoituneeseen käyttäjään” on liiketoimintasi — ja juuri siellä suurin osa tuloistasi vuotaa hiljaa pois.

Olemme nähneet tuotteita, joilla on aidosti erinomainen ydinominaisuus, menettävän valtaosan rekisteröitymisistä ensimmäisten viiden minuutin aikana, koska kukaan ei tajunnut, mitä tehdä rekisteröitymisen jälkeen. Tilaukset, kokeilujaksot, suhteutus, epäonnistuneet maksut, peruutukset, aivan uuden tilin tyhjän tilan kokemus — nämä eivät ole paperityötä. Ne ovat varsinainen tuote asiakkaalle sillä hetkellä, kun hän päättää, jääkö hän.

5. Monikäyttäjyyden tekeminen väärin (tai sen ohittaminen)

Tämä on se, joka näyttää hyvältä aivan siihen asti, kunnes se on katastrofi. SaaS tarkoittaa, että monet asiakkaat jakavat yhden järjestelmän, ja se, kuinka erotat heidän tietonsa — monikäyttäjyys — on perustavanlaatuinen päätös. Tee se väärin ja joko rakennat jotain, joka ei pysty eristämään asiakkaita kunnolla, tai mikä pahempaa, julkaiset bugin, jossa yksi yritys voi nähdä toisen yrityksen tiedot. Ei ole nopeampaa tapaa menettää kaikki asiakkaat kerralla kuin tietovuoto asiakkaiden välillä.

Et tarvitse eksoottista kokoonpanoa. Useimmille varhaisen vaiheen tuotteille yksi jaettu tietokanta, jossa on tiukasti valvottu asiakastunniste jokaisessa taulussa ja jokaisessa kyselyssä, on täysin riittävä — edellyttäen, että eristys on rakennettu perustaan ja testattu, ei ripoteltu päälle myöhemmin. Virhe ei ole yksinkertaisen lähestymistavan valitseminen. Virhe on jättää päättämättä tietoisesti ja löytää aukko, kun se on jo tuotannossa.

6. Julkaisu pimeään ilman keinoa nähdä, mitä käyttäjät tekevät

Julkaiset. Ihmiset rekisteröityvät. Ja sitten... hiljaisuus. Sinulla ei ole aavistustakaan, mihin ominaisuuksiin he koskevat, missä he juuttuvat tai miksi he lähtevät. Joten arvailet. Rakennat seuraavan ominaisuuden aavistuksen, äänekkäimmän asiakassähköpostin tai oman intuitiosi pohjalta — joka kuukausien jälkeen oman tuotteesi sisällä on epäluotettavin instrumentti, joka sinulla on.

Perustason tuoteanalytiikka ja yksinkertainen tapa kerätä palautetta eivät ole kasvuvaiheen ylellisyyttä. Ne ovat tapa, jolla ohjaat. Ilman niitä et pyöritä liiketoimintaa, vaan pyörität kallista mielipidettä. Jo niinkin yksinkertaisen asian tietäminen kuin ”80 % käyttäjistä ei koskaan avaa ominaisuutta, jonka rakentamiseen käytin kaksi kuukautta” on arvokkaampaa kuin toiset kaksi kuukautta sokeaa rakentamista.

7. Tietoturvan ja varmuuskopioiden jättäminen ”myöhemmäksi”

Nopeus on varhaisen vaiheen uskonto, ja enimmäkseen se on oikein. Mutta on pieni joukko asioita, jotka ovat katastrofaalisen kalliita jälkiasentaa, ja tietoturva on listan kärjessä. Salasanojen kunnollinen tallentaminen, sen lukitseminen, kuka pääsee mihinkin käsiksi, ja — ole hyvä — toimivien, testattujen varmuuskopioiden olemassaolo eivät ole valinnaisia ominaisuuksia, jotka lisäät, kun sinulla on aikaa. Ne ovat lattia, jonka päälle rakennat.

Tämän kategorian julmuus on, että pääset siitä kuin koira veräjästä aina siihen asti, kunnes et pääse. Kaikki on hyvin vuoden, ja sitten yksi tietomurto, yksi vahingossa tehty massapoisto, yksi kiristyshaittaohjelma-aamu pyyhkii pois luottamuksen ja tiedot, joita rakensit sen vuoden. Emme pyydä tietoturvaosastoa. Pyydämme, että perusasiat ovat paikallaan alusta alkaen, koska niiden lisäämisen hinta tapahtuman jälkeen mitataan kuolleissa yrityksissä.

8. Väärän rakentajan palkkaaminen väärään vaiheeseen

Ei-tekniset perustajat kohtaavat raa'an valinnan: kuka oikeasti rakentaa tämän? Kaksi klassista virhettä peilaavat toisiaan. Toinen on halvimman mahdollisen freelancerin palkkaaminen, joka toimittaa jotain, joka näyttää oikealta mutta on kasassa teipillä, ja luhistuu sillä hetkellä, kun sitä pitää muuttaa. Toinen on ylipalkkaaminen — täysi senioritiimi täysillä palkoilla rakentamaan tuotetta, joka ei ole ansainnut yhtäkään asiakasta vielä.

Rehellinen vastaus riippuu täysin siitä, missä olet. Idean validoimiseksi haluat pienen, seniori, käytännönläheisen tiimin, joka on rakentanut varhaisen vaiheen tuotteita ennenkin ja tietää tarkalleen, mitä jättää pois. Todistetun tuotteen skaalaamiseksi haluat eri ihmisiä eri vaistoilla. Rakentajan sovittaminen vaiheeseen on itsessään taito — ja sen tekeminen väärin haaskaa enemmän rahaa kuin mikään tekninen päätös tällä listalla.

9. Julkaisun kohtelu maaliviivana

Viimeinen virhe on surullisin, koska se tulee niin suuren kovan työn jälkeen. Tiimi kohtelee julkaisupäivää tavoitteena, heittää kaiken sinne pääsemiseen ja saapuu uupuneena ilman suunnitelmaa, ilman budjettia ja ilman energiaa siihen, mitä tulee seuraavaksi. Mutta julkaisu ei ole maaliviiva. Se on ainoan merkityksellisen vaiheen alku: oppiminen oikeilta käyttäjiltä ja parantaminen, viikko viikolta.

SaaS-tuote ei ole koskaan ”valmis”. Ensimmäinen versio on hypoteesi, ja julkaisua seuraavat kuukaudet ovat se aika, jolloin saat selville, kuinka väärässä se oli — hyvällä tavalla. Perustajat, jotka suunnittelevat tätä varten, jotka pitävät hieman pelivaraa ja paljon uteliaisuutta varalla, ovat niitä, jotka kääntävät epävarman julkaisun todelliseksi liiketoiminnaksi. Ne, jotka käyttivät kaiken lähtöviivalle pääsemiseen, eivät yleensä pääse paljon pidemmälle.

Kuinka oikeasti välttää kaikki yhdeksän

Virhelistan lukeminen on helppoa. Niiden välttäminen määräaikapaineen alla, omat rahasi pelissä ja oma ideasi sydämessäsi, on aidosti vaikeaa. Tässä siis lyhyt versio siitä, kuinka oikein tekevät perustajat yleensä toimivat — ei sääntöinä, vaan varastamisen arvoisina tapoina.

1. 1
   Validoi ennen kuin rakennat

   Vie jotain raakaa oikeiden mahdollisten asiakkaiden eteen ja vahvista, että he maksavat, ennen kuin kirjoitat vakavaa koodia. Halpaa tehdä, raakaa ohittaa.
2. 2
   Valitse pienin todellinen tuote

   Määritä se yksi asia, jonka tuotteesi täytyy tehdä, ja lykkää armottomasti kaikkea muuta. Kirjoita ylös, mitä ”versio yksi” tarkoituksella ei sisällä.
3. 3
   Rakenna tylsästi ja eristä asiakkaat

   Käytä yksinkertaisinta toimivaa arkkitehtuuria, mutta tee asiakkaiden välisestä tietojen erottelusta perustavanlaatuinen, testattu päätös ensimmäisestä päivästä lähtien.
4. 4
   Suunnittele rahapolku varhain

   Kohtele rekisteröitymistä, käyttöönottoa ja laskutusta ydintuotteena, ei paperityönä. Ensimmäiset viisi minuuttia ratkaisevat, näkeekö loppua kukaan.
5. 5
   Mittaroi se, julkaise sitten oppiaksesi

   Julkaise perustason analytiikka ja palaute paikallaan, säilytä pelivaraa julkaisun jälkeiseen vaiheeseen ja kohtele ensimmäistä versiota kysymyksenä, ei vastauksena.

Huomaa, että lähes mikään tästä ei liity koodaustaitoon. Se liittyy harkintaan — siihen, että tietää, mitä rakentaa, mitä ohittaa ja milloin. Juuri siksi niin monet teknisesti kyvykkäät tiimit silti tuottavat tuotteita, jotka epäonnistuvat: SaaS:n vaikea osa ei koskaan ollut insinöörityö. Se oli pidättyvyys.

Yleisiä kysymyksiä