9 SaaS-utviklingsfeil som stille senker tidlige oppstartsbedrifter

Nesten ingen bygger et SaaS-produkt feil med vilje. Feilene som senker tidlige oppstartsbedrifter er stille, fornuftig klingende beslutninger tatt av smarte mennesker under press — og de føles alle riktige der og da. Vi har sett de samme ni utspille seg på tvers av dusinvis av produkter, like gjerne i grunnleggeres garasjer som i velfinansierte team. Den gode nyheten er at de er forutsigbare, noe som betyr at de kan unngås. Dette er listen vi skulle ønske enhver grunnlegger hadde teipet fast på skjermen før de skrev den første linjen kode.

Vi bygger programvare for små og mellomstore bedrifter, noe som betyr at vi blir tilkalt på to svært ulike tidspunkter. Noen ganger er det dag én, når det ikke finnes annet enn en skisse og en idé. Oftere, dessverre, er det måned ni — når en grunnlegger har brukt opp sparepengene sine, produktet teknisk sett fungerer, og likevel betaler ingen for det. Den andre samtalen er den som lærte oss denne listen. Hver eneste gang avslører obduksjonen den samme lille samlingen av sår, påført tidlig og latt verke.

Ingen av disse feilene handler om talent. Folkene som gjør dem er som regel dyktige og hardtarbeidende. Problemet er at å bygge SaaS belønner en helt bestemt slags tilbakeholdenhet som ikke kommer naturlig når man er begeistret for sin egen idé. Så la oss gå gjennom de ni, omtrent i den rekkefølgen de pleier å bite fra seg, og være ærlige om hvorfor hver enkelt er så fristende.

1. Bygge i seks måneder før du snakker med en eneste kunde

Dette er arvesynden, og det er den dyreste. En grunnlegger er overbevist om at idéen er god — og det kan den være — så vedkommende blir taus, bygger med hodet bøyd i et halvt år og dukker opp med et polert produkt ingen ba om. Markedet belønner ikke innsats. Det belønner å løse et problem noen vil betale for å bli kvitt.

Løsningen er ikke komplisert, den er bare ubehagelig: vis noe grovt til ekte potensielle kunder før det er ferdig. En klikkbar mockup, en landingsside, til og med en manuell versjon av tjenesten gjort for hånd via e-post. Hver uke med bygging før du har bekreftet at folk vil ha det, er en uke du kanskje bruker på å innrede et hus i feil gate.

2. Bygge for en million brukere du ikke har

Den andre feilen bærer profesjonalitetens drakt. Grunnleggeren, eller en ambisiøs tidlig ingeniør, designer systemet for å takle enorm skala fra dag én — mikrotjenester, Kubernetes, databaser i flere regioner, innfløkte hurtigbufferlag. Det føles ansvarlig. Det er i virkeligheten en felle. Du bruker din knappeste ressurs — tid — på å forsvare deg mot et problem du ville vært heldig å ha.

En kjedelig monolitt med én enkelt database bærer deg komfortabelt til dine første par tusen brukere og langt forbi din første omsetning. Arkitekturbeslutningene som betyr noe ved skala er nesten aldri de du kan forutse i starten, og for tidlig kompleksitet gjør produktet tregere å endre — noe som i de tidlige dagene er det eneste som faktisk tar livet av deg. Bygg for de neste ti kundene, ikke for den innbilte millionte.

3. En MVP som verken er minimal, levedyktig eller et produkt

Alle er enige om å bygge en MVP. Nesten ingen gjør det faktisk. Det som lanseres i stedet er en utflytende «versjon én» proppfull av enhver funksjon grunnleggeren kunne forestille seg, fordi å kutte funksjoner føles som å kutte ambisjon. Resultatet tar tre ganger så lang tid, koster tre ganger så mye og er vanskeligere å lære av — for når et oppblåst produkt feiler, kan du ikke si hvilken del som var feil.

En ekte MVP gjør én ting godt nok til at noen vil betale for det. Det er alt. Disiplinen handler ikke om å bestemme hva som skal med; den handler om å bestemme hva som skal utelates, vel vitende om at hver «opplagte» funksjon du utsetter er en uke du får igjen og et spørsmål du får svare på med ekte brukere i stedet for gjetninger.

En rask fornufts-sjekk av omfanget

Før noen funksjon går inn i den første versjonen, ber vi grunnleggere svare på ett spørsmål høyt: «Hvis vi lanserte uten dette, ville en eneste betalende kunde nekte å bruke produktet?» Hvis det ærlige svaret er nei, venter den. Du vil bli overrasket over hvor mye av listen din over «essensielle» funksjoner som fordamper under den ene setningen.

• Hvis en funksjon finnes for å imponere investorer, ikke for å tjene en bruker, venter den.
• Hvis en funksjon håndterer et grensetilfelle som færre enn 1 av 20 brukere vil treffe, venter den.
• Hvis du bygger innstillinger for å konfigurere en oppførsel ingen har bedt om å endre ennå, venter den.
• Hvis «konkurrenten har den» er den eneste grunnen til at den står på listen, venter den.
• Hvis det ikke ville stoppe et eneste salg å fjerne den, venter den.

4. Å behandle fakturering og onboarding som en ettertanke

Grunnleggere øser kjærlighet i kjernefunksjonen og husker så, to uker før lansering, at kundene trenger en måte å registrere seg, betale og faktisk begynne å bruke greia på. Faktureringen skrus på i panikk. Onboardingen er en innloggingsskjerm og et skuldertrekk. Men veien fra «interessert besøkende» til «betalende, aktivert bruker» er forretningen din — og det er der mesteparten av omsetningen din stille lekker bort.

Vi har sett produkter med en genuint utmerket kjernefunksjon miste flertallet av registreringene i de første fem minuttene fordi ingen klarte å skjønne hva de skulle gjøre etter registreringen. Abonnementer, prøveperioder, forholdsmessig beregning, mislykkede betalinger, oppsigelser, tomtilstand-opplevelsen for en splitter ny konto — dette er ikke papirarbeid. Det er det faktiske produktet, for kunden, i øyeblikket vedkommende bestemmer seg for om de blir.

5. Å få multitenancy feil (eller hoppe over det)

Dette er den som ser fin ut helt til den er en katastrofe. SaaS betyr at mange kunder deler ett system, og hvordan du skiller dataene deres — multitenancy — er en grunnleggende beslutning. Gjør du det feil, bygger du enten noe som ikke kan isolere kunder skikkelig, eller verre, du lanserer en feil der ett selskap kan se et annet selskaps data. Det finnes ingen raskere måte å miste alle kundene på én gang enn en datalekkasje mellom tenants.

Du trenger ikke et eksotisk oppsett. For de fleste produkter i tidlig fase er én delt database med en strengt håndhevet tenant-ID på hver tabell og hvert spørring fullt ut tilstrekkelig — forutsatt at isolasjonen er bygget inn i fundamentet og testet, ikke drysset på senere. Feilen er ikke å velge den enkle tilnærmingen. Feilen er å ikke bestemme bevisst og oppdage hullet når det allerede er i produksjon.

6. Å lansere ut i mørket uten noen måte å se hva brukerne gjør

Du lanserer. Folk registrerer seg. Og så... stillhet. Du aner ikke hvilke funksjoner de tar i, hvor de står fast, eller hvorfor de forsvinner. Så du gjetter. Du bygger den neste funksjonen basert på en magefølelse, den mest høylytte kunde-e-posten eller din egen intuisjon — som etter måneder inne i ditt eget produkt er det minst pålitelige instrumentet du eier.

Grunnleggende produktanalyse og en enkel måte å samle tilbakemeldinger på er ingen luksus for vekstfasen. De er måten du styrer på. Uten dem driver du ikke en bedrift, du driver en dyr mening. Bare det å vite noe så enkelt som «80 % av brukerne åpner aldri funksjonen jeg brukte to måneder på å bygge» er verdt mer enn ytterligere to måneder med blind bygging.

7. Å la sikkerhet og sikkerhetskopier vente til «senere»

Fart er den tidlige fasens religion, og for det meste er det riktig. Men det finnes en liten gruppe ting som er katastrofalt dyre å ettermontere, og sikkerhet står øverst på listen. Å lagre passord skikkelig, låse ned hvem som har tilgang til hva og — vær så snill — ha fungerende, testede sikkerhetskopier er ikke valgfrie funksjoner du legger til når du har tid. De er gulvet du bygger på.

Det grusomme med denne kategorien er at du slipper unna med det helt til du ikke gjør det. Alt er bra i et år, og så utsletter ett innbrudd, én utilsiktet masseslettelse, én ransomware-morgen tilliten og dataene du brukte det året på å bygge. Vi ber ikke om en sikkerhetsavdeling. Vi ber om at det grunnleggende er der fra starten, for kostnaden ved å legge det til etter en hendelse måles i døde selskaper.

8. Å ansette feil bygger til feil fase

Ikke-tekniske grunnleggere står overfor et brutalt valg: hvem bygger egentlig dette? De to klassiske feilene speiler hverandre. Den ene er å ansette den billigst mulige frilanseren som leverer noe som ser riktig ut, men er holdt sammen med teip, og faller fra hverandre i det øyeblikket du må endre det. Den andre er overansettelse — et fullt seniorteam med fulle lønninger for å bygge et produkt som ennå ikke har fortjent en eneste kunde.

Det ærlige svaret avhenger fullstendig av hvor du er. For å validere en idé vil du ha et lite, senior, pragmatisk team som har bygget produkter i tidlig fase før og vet nøyaktig hva som skal utelates. For å skalere et bevist produkt vil du ha andre mennesker med andre instinkter. Å matche byggeren til fasen er i seg selv en ferdighet — og å gjøre det feil sløser bort mer penger enn noen teknisk beslutning på denne listen.

9. Å behandle lanseringen som målstreken

Den siste feilen er den tristeste, fordi den kommer etter så mye hardt arbeid. Teamet behandler lanseringsdagen som målet, kaster alt inn på å nå dit og ankommer utmattet uten plan, uten budsjett og uten energi til det som kommer etterpå. Men lanseringen er ikke målstreken. Den er begynnelsen på den eneste fasen som betyr noe: å lære av ekte brukere og forbedre, uke etter uke.

Et SaaS-produkt er aldri «ferdig». Den første versjonen er en hypotese, og månedene etter lanseringen er når du finner ut hvor feil den var — på den gode måten. Grunnleggere som planlegger for det, som holder litt rullebane og mye nysgjerrighet i reserve, er de som forvandler en vaklevoren lansering til en ekte bedrift. De som brukte alt på å nå startstreken pleier ikke å komme stort lenger.

Hvordan du faktisk unngår alle ni

Å lese en liste over feil er enkelt. Å unngå dem under tidsfristpress, med dine egne penger på spill og din egen idé i hjertet, er genuint vanskelig. Så her er kortversjonen av hvordan grunnleggerne som får det til pleier å jobbe — ikke som regler, men som vaner verdt å stjele.

1. 1
   Valider før du bygger

   Få noe grovt foran ekte potensielle kunder og bekreft at de vil betale, før du skriver seriøs kode. Billig å gjøre, brutalt å hoppe over.
2. 2
   Velg det minste ekte produktet

   Definer den ene tingen produktet ditt må gjøre, og utsett nådeløst alt annet. Skriv ned hva «versjon én» bevisst ikke inkluderer.
3. 3
   Bygg kjedelig og isoler tenants

   Bruk den enkleste arkitekturen som fungerer, men gjør dataseparasjon mellom kunder til en grunnleggende, testet beslutning fra dag én.
4. 4
   Design pengeveien tidlig

   Behandl registrering, onboarding og fakturering som kjerneprodukt, ikke papirarbeid. De første fem minuttene avgjør om resten i det hele tatt blir sett.
5. 5
   Instrumenter det, lanser så for å lære

   Lanser med grunnleggende analyse og tilbakemelding på plass, behold rullebane til fasen etter lanseringen, og behandl den første versjonen som et spørsmål, ikke et svar.

Legg merke til at nesten ingenting av dette handler om programmeringsferdigheter. Det handler om dømmekraft — å vite hva man skal bygge, hva man skal hoppe over, og når. Det er nettopp derfor så mange teknisk dyktige team likevel produserer produkter som feiler: den vanskelige delen av SaaS var aldri ingeniørarbeidet. Det var tilbakeholdenheten.

Vanlige spørsmål