9 SaaS-udviklingsfejl, der i stilhed sænker tidlige startups

Næsten ingen bygger et SaaS-produkt forkert med vilje. Fejlene, der sænker tidlige startups, er stille, fornuftigt klingende beslutninger truffet af kloge mennesker under pres — og de føles alle rigtige i øjeblikket. Vi har set de samme ni udspille sig på tværs af snesevis af produkter, lige så vel i stifteres garager som i velfinansierede teams. Den gode nyhed er, at de er forudsigelige, hvilket betyder, at de kan undgås. Dette er listen, vi ville ønske, enhver stifter havde tapet fast på skærmen, før de skrev den første linje kode.

Vi bygger software til små og mellemstore virksomheder, hvilket betyder, at vi bliver tilkaldt på to vidt forskellige tidspunkter. Nogle gange er det dag et, hvor der ikke er andet end en skitse og en idé. Oftere, desværre, er det måned ni — når en stifter har brugt sin opsparing, produktet teknisk set virker, og ingen alligevel betaler for det. Det andet opkald er det, der lærte os denne liste. Hver eneste gang afslører obduktionen den samme lille samling sår, påført tidligt og efterladt til at bulne.

Ingen af disse fejl handler om talent. Folk, der begår dem, er som regel dygtige og hårdtarbejdende. Problemet er, at det at bygge SaaS belønner en helt bestemt slags tilbageholdenhed, som ikke kommer naturligt, når man er begejstret for sin egen idé. Så lad os gennemgå de ni, nogenlunde i den rækkefølge, de plejer at bide fra sig, og være ærlige om, hvorfor hver enkelt er så fristende.

1. Byg i seks måneder, før du taler med en eneste kunde

Dette er arvesynden, og det er den dyreste. En stifter er overbevist om, at idéen er god — og det kan den være — så vedkommende bliver tavs, bygger med hovedet bøjet i et halvt år og dukker op med et poleret produkt, ingen bad om. Markedet belønner ikke indsats. Det belønner at løse et problem, som nogen vil betale for at slippe af med.

Løsningen er ikke kompliceret, den er bare ubehagelig: vis noget råt til rigtige potentielle kunder, før det er færdigt. En klikbar mockup, en landingsside, endda en manuel version af tjenesten lavet i hånden via e-mail. Hver uges byggeri, før du har bekræftet, at folk vil have det, er en uge, du måske bruger på at indrette et hus på den forkerte gade.

2. Byg til en million brugere, du ikke har

Den anden fejl bærer professionalismens dragt. Stifteren eller en ambitiøs tidlig ingeniør designer systemet til at klare massiv skala fra dag et — mikrotjenester, Kubernetes, databaser i flere regioner, indviklede cachelag. Det føles ansvarligt. Det er faktisk en fælde. Du bruger din knappeste ressource — tid — på at forsvare dig mod et problem, du ville være heldig at have.

En kedelig monolit med én enkelt database bærer dig komfortabelt til dine første par tusind brugere og langt forbi din første omsætning. Arkitekturbeslutningerne, der betyder noget ved skala, er næsten aldrig dem, du kan forudse i starten, og for tidlig kompleksitet gør produktet langsommere at ændre — hvilket i de tidlige dage er det eneste, der faktisk slår dig ihjel. Byg til de næste ti kunder, ikke til den indbildte millionte.

3. En MVP, der hverken er minimal, levedygtig eller et produkt

Alle er enige om at bygge en MVP. Næsten ingen gør det faktisk. Det, der lanceres i stedet, er en udflydende „version et“ proppet med enhver funktion, stifteren kunne forestille sig, fordi at skære funktioner væk føles som at skære ambition væk. Resultatet tager tre gange så lang tid, koster tre gange så meget og er sværere at lære af — for når et oppustet produkt fejler, kan du ikke sige, hvilken del der var forkert.

En rigtig MVP gør én ting godt nok til, at nogen vil betale for det. Det er det. Disciplinen handler ikke om at beslutte, hvad der skal med; den handler om at beslutte, hvad der skal udelades, velvidende at hver „indlysende“ funktion, du udskyder, er en uge, du får igen, og et spørgsmål, du får lov at besvare med rigtige brugere i stedet for gæt.

Et hurtigt fornufts-tjek af omfanget

Før nogen funktion ryger med i den første version, beder vi stiftere svare på ét spørgsmål højt: „Hvis vi lancerede uden det her, ville en eneste betalende kunde så nægte at bruge produktet?“ Hvis det ærlige svar er nej, venter den. Du vil blive overrasket over, hvor meget af din liste over „essentielle“ funktioner der fordamper under den ene sætning.

• Hvis en funktion findes for at imponere investorer, ikke for at tjene en bruger, venter den.
• Hvis en funktion håndterer et grænsetilfælde, som færre end 1 ud af 20 brugere vil ramme, venter den.
• Hvis du bygger indstillinger til at konfigurere en adfærd, som ingen har bedt om at ændre endnu, venter den.
• Hvis „konkurrenten har den“ er den eneste grund til, at den står på listen, venter den.
• Hvis det ikke ville stoppe et eneste salg at fjerne den, venter den.

4. At behandle fakturering og onboarding som en eftertanke

Stiftere øser kærlighed i kernefunktionen og husker så, to uger før lancering, at kunder har brug for en måde at tilmelde sig, betale og rent faktisk begynde at bruge tingen. Faktureringen skrues på i panik. Onboardingen er en login-skærm og et skuldertræk. Men vejen fra „interesseret besøgende“ til „betalende, aktiveret bruger“ er din forretning — og det er der, størstedelen af din omsætning i stilhed siver væk.

Vi har set produkter med en ægte fremragende kernefunktion miste flertallet af tilmeldingerne i de første fem minutter, fordi ingen kunne regne ud, hvad de skulle gøre efter registreringen. Abonnementer, prøveperioder, forholdsmæssig beregning, mislykkede betalinger, opsigelser, tom-tilstand-oplevelsen for en splinterny konto — det her er ikke papirarbejde. Det er det egentlige produkt, for kunden, i det øjeblik vedkommende beslutter, om de bliver.

5. At få multitenancy forkert (eller springe det over)

Dette er den, der ser fin ud lige indtil den er en katastrofe. SaaS betyder, at mange kunder deler ét system, og hvordan du adskiller deres data — multitenancy — er en grundlæggende beslutning. Gør du det forkert, bygger du enten noget, der ikke kan isolere kunder ordentligt, eller værre, du lancerer en fejl, hvor én virksomhed kan se en anden virksomheds data. Der findes ingen hurtigere måde at miste alle kunder på én gang end et datalæk mellem tenants.

Du behøver ingen eksotisk opsætning. For de fleste produkter i tidlig fase er én delt database med et strengt håndhævet tenant-id på hver tabel og hver forespørgsel fuldt ud tilstrækkeligt — forudsat at isoleringen er bygget ind i fundamentet og testet, ikke drysset på senere. Fejlen er ikke at vælge den enkle tilgang. Fejlen er ikke at beslutte bevidst og opdage hullet, når det allerede er i produktion.

6. At lancere ud i mørket uden nogen måde at se, hvad brugerne gør

Du lancerer. Folk tilmelder sig. Og så... stilhed. Du aner ikke, hvilke funktioner de rører ved, hvor de går i stå, eller hvorfor de forsvinder. Så du gætter. Du bygger den næste funktion baseret på en fornemmelse, den højlydteste kunde-e-mail eller din egen intuition — som efter måneder inde i dit eget produkt er det mindst pålidelige instrument, du ejer.

Grundlæggende produktanalyse og en enkel måde at indsamle feedback på er ingen luksus for vækstfasen. De er måden, du styrer på. Uden dem driver du ikke en forretning, du driver en dyr holdning. Bare det at vide noget så enkelt som „80 % af brugerne åbner aldrig den funktion, jeg brugte to måneder på at bygge“ er mere værd end yderligere to måneders blind byggeri.

7. At lade sikkerhed og backups vente til „senere“

Hastighed er den tidlige fases religion, og for det meste er det rigtigt. Men der er en lille gruppe ting, der er katastrofalt dyre at eftermontere, og sikkerhed står øverst på listen. At opbevare adgangskoder ordentligt, låse ned for hvem der har adgang til hvad og — please — have fungerende, testede backups er ikke valgfrie funktioner, du tilføjer, når du har tid. De er gulvet, du bygger på.

Det grusomme ved denne kategori er, at du slipper afsted med det lige indtil du ikke gør. Alt er fint i et år, og så udsletter ét brud, én utilsigtet masseslettelse, én ransomware-morgen den tillid og de data, du brugte det år på at bygge. Vi beder ikke om en sikkerhedsafdeling. Vi beder om, at det basale er der fra starten, for prisen for at tilføje det efter en hændelse måles i døde virksomheder.

8. At ansætte den forkerte bygger til den forkerte fase

Ikke-tekniske stiftere står over for et brutalt valg: hvem bygger egentlig det her? De to klassiske fejl spejler hinanden. Den ene er at ansætte den billigst mulige freelancer, der leverer noget, der ser rigtigt ud, men er holdt sammen med tape, og falder fra hinanden i det øjeblik, du skal ændre det. Den anden er overansættelse — et fuldt seniorteam med fulde lønninger til at bygge et produkt, der endnu ikke har fortjent en eneste kunde.

Det ærlige svar afhænger fuldstændig af, hvor du er. For at validere en idé vil du have et lille, senior, pragmatisk team, der har bygget produkter i tidlig fase før og ved præcis, hvad der skal udelades. For at skalere et bevist produkt vil du have andre mennesker med andre instinkter. At matche byggeren til fasen er i sig selv en færdighed — og at gøre det forkert spilder flere penge end nogen teknisk beslutning på denne liste.

9. At behandle lanceringen som målstregen

Den sidste fejl er den tristeste, fordi den kommer efter så meget hårdt arbejde. Teamet behandler lanceringsdagen som målet, kaster alt efter at nå derhen og ankommer udmattet uden plan, uden budget og uden energi til det, der kommer bagefter. Men lanceringen er ikke målstregen. Den er begyndelsen på den eneste fase, der betyder noget: at lære af rigtige brugere og forbedre, uge efter uge.

Et SaaS-produkt er aldrig „færdigt“. Den første version er en hypotese, og månederne efter lanceringen er, når du finder ud af, hvor forkert den var — på den gode måde. Stiftere, der planlægger efter det, der holder lidt landingsbane og masser af nysgerrighed i reserve, er dem, der forvandler en vakkelvorn lancering til en rigtig forretning. De, der brugte alt på at nå startlinjen, plejer ikke at komme meget længere.

Sådan undgår du faktisk alle ni

At læse en liste over fejl er nemt. At undgå dem under deadlinepres, med dine egne penge på spil og din egen idé i hjertet, er ægte svært. Så her er kortversionen af, hvordan de stiftere, der får det rigtigt, plejer at arbejde — ikke som regler, men som vaner, der er værd at stjæle.

1. 1
   Validér før du bygger

   Få noget råt foran rigtige potentielle kunder og bekræft, at de vil betale, før du skriver seriøs kode. Billigt at gøre, brutalt at springe over.
2. 2
   Vælg det mindste rigtige produkt

   Definér den ene ting, dit produkt skal gøre, og udskyd hensynsløst alt andet. Skriv ned, hvad „version et“ bevidst ikke inkluderer.
3. 3
   Byg kedeligt og isolér tenants

   Brug den enkleste arkitektur, der virker, men gør dataadskillelse mellem kunder til en grundlæggende, testet beslutning fra dag et.
4. 4
   Design pengevejen tidligt

   Behandl tilmelding, onboarding og fakturering som kerneprodukt, ikke papirarbejde. De første fem minutter afgør, om resten overhovedet bliver set.
5. 5
   Instrumentér det, lancér så for at lære

   Lancér med grundlæggende analyse og feedback på plads, behold landingsbane til fasen efter lanceringen, og behandl den første version som et spørgsmål, ikke et svar.

Læg mærke til, at næsten intet af dette handler om programmeringsevner. Det handler om dømmekraft — at vide, hvad man skal bygge, hvad man skal springe over, og hvornår. Det er præcis derfor, så mange teknisk dygtige teams alligevel producerer produkter, der fejler: den svære del af SaaS var aldrig ingeniørarbejdet. Det var tilbageholdenheden.

Almindelige spørgsmål