9 SaaS-utvecklingsmisstag som i tysthet sänker tidiga startups

Nästan ingen bygger en SaaS-produkt fel med flit. Misstagen som sänker tidiga startups är tysta, förnuftigt klingande beslut fattade av smarta människor under press — och de känns alla rätt i stunden. Vi har sett samma nio utspela sig i dussintals produkter, lika gärna i grundarnas garage som i välfinansierade team. Den goda nyheten är att de är förutsägbara, vilket betyder att de går att undvika. Det här är listan vi önskar att varje grundare hade tejpat på sin skärm innan de skrev den första raden kod.

Vi bygger mjukvara för små och medelstora företag, vilket innebär att vi blir inkallade vid två väldigt olika tillfällen. Ibland är det dag ett, när det inte finns något annat än en skiss och en idé. Oftare, tyvärr, är det månad nio — när en grundare har gjort av med sitt sparkapital, produkten tekniskt sett fungerar, och ändå betalar ingen för den. Det andra samtalet är det som lärde oss den här listan. Varenda gång avslöjar obduktionen samma lilla uppsättning sår, tillfogade tidigt och lämnade att bölda.

Inget av dessa misstag handlar om talang. Människorna som gör dem är oftast kompetenta och hårt arbetande. Problemet är att att bygga SaaS belönar en väldigt specifik sorts återhållsamhet som inte kommer naturligt när man är entusiastisk över sin egen idé. Så låt oss gå igenom de nio, ungefär i den ordning de brukar bita ifrån, och vara ärliga om varför var och en är så frestande.

1. Bygga i sex månader innan du pratar med en enda kund

Detta är arvsynden, och det är det dyraste. En grundare är övertygad om att idén är bra — och det kan den vara — så hen blir tyst, bygger med huvudet nedböjt i ett halvår och dyker upp med en putsad produkt som ingen bad om. Marknaden belönar inte ansträngning. Den belönar att lösa ett problem som någon vill betala för att bli av med.

Lösningen är inte komplicerad, den är bara obekväm: visa något grovt för riktiga potentiella kunder innan det är klart. En klickbar mockup, en landningssida, till och med en manuell version av tjänsten gjord för hand via e-post. Varje vecka av byggande innan du har bekräftat att folk vill ha det är en vecka du kanske ägnar åt att inreda ett hus på fel gata.

2. Bygga för en miljon användare du inte har

Det andra misstaget bär professionalismens dräkt. Grundaren, eller en ambitiös tidig ingenjör, designar systemet för att klara enorm skala från dag ett — mikrotjänster, Kubernetes, databaser i flera regioner, invecklade cachelager. Det känns ansvarsfullt. Det är i själva verket en fälla. Du gör av med din knappaste resurs — tid — på att försvara dig mot ett problem du skulle ha tur att ha.

En tråkig monolit med en enda databas bär dig bekvämt till dina första par tusen användare och långt förbi dina första intäkter. Arkitekturbesluten som spelar roll i stor skala är nästan aldrig de du kan förutse i början, och förtidig komplexitet gör produkten långsammare att ändra — vilket, i de tidiga dagarna, är det enda som faktiskt dödar dig. Bygg för de nästa tio kunderna, inte för den inbillade miljonte.

3. En MVP som varken är minimal, livskraftig eller en produkt

Alla är överens om att bygga en MVP. Nästan ingen gör det faktiskt. Det som lanseras istället är en utbredd ”version ett” fullproppad med varje funktion grundaren kunde tänka sig, eftersom att skära bort funktioner känns som att skära bort ambition. Resultatet tar tre gånger så lång tid, kostar tre gånger så mycket och är svårare att lära sig av — för när en uppblåst produkt misslyckas kan du inte säga vilken del som var fel.

En riktig MVP gör en sak tillräckligt bra för att någon ska betala för den. Det är allt. Disciplinen handlar inte om att bestämma vad som ska ingå; den handlar om att bestämma vad som ska lämnas utanför, i vetskap om att varje ”självklar” funktion du skjuter upp är en vecka du får tillbaka och en fråga du får svara på med riktiga användare istället för gissningar.

En snabb förnuftskontroll av omfattningen

Innan någon funktion läggs in i den första versionen får vi grundare att svara på en fråga högt: ”Om vi lanserade utan det här, skulle en enda betalande kund vägra använda produkten?” Om det ärliga svaret är nej får den vänta. Du kommer att bli förvånad över hur mycket av din lista över ”väsentliga” funktioner som förångas under den enda meningen.

• Om en funktion finns för att imponera på investerare, inte för att tjäna en användare, får den vänta.
• Om en funktion hanterar ett gränsfall som färre än 1 av 20 användare kommer att stöta på, får den vänta.
• Om du bygger inställningar för att konfigurera ett beteende som ingen har bett om att få ändra ännu, får den vänta.
• Om ”konkurrenten har det” är den enda anledningen till att den står på listan, får den vänta.
• Om att ta bort den inte skulle stoppa en enda försäljning, får den vänta.

4. Att behandla fakturering och introduktion som en eftertanke

Grundare öser kärlek över kärnfunktionen och kommer sedan, två veckor före lansering, ihåg att kunder behöver ett sätt att registrera sig, betala och faktiskt börja använda saken. Faktureringen skruvas på i panik. Introduktionen är en inloggningsskärm och en axelryckning. Men vägen från ”intresserad besökare” till ”betalande, aktiverad användare” är ditt företag — och det är där merparten av dina intäkter i tysthet läcker bort.

Vi har sett produkter med en genuint utmärkt kärnfunktion förlora majoriteten av registreringarna under de första fem minuterna eftersom ingen kunde lista ut vad de skulle göra efter registreringen. Prenumerationer, provperioder, proportionering, misslyckade betalningar, uppsägningar, tomtillståndsupplevelsen för ett splitter nytt konto — det här är inte pappersarbete. Det är den faktiska produkten, för kunden, i det ögonblick hen bestämmer sig för om hen ska stanna.

5. Att få multitenans fel (eller hoppa över det)

Det här är den som ser bra ut ända tills den är en katastrof. SaaS innebär att många kunder delar ett system, och hur du skiljer deras data åt — multitenans — är ett grundläggande beslut. Gör du fel bygger du antingen något som inte kan isolera kunder ordentligt, eller värre, du lanserar en bugg där ett företag kan se ett annat företags data. Det finns inget snabbare sätt att förlora alla kunder på en gång än ett dataläckage mellan tenanter.

Du behöver ingen exotisk lösning. För de flesta produkter i tidigt skede räcker en enda delad databas med ett strikt påtvingat tenant-ID på varje tabell och varje fråga gott och väl — förutsatt att isoleringen är inbyggd i grunden och testad, inte påströdd i efterhand. Misstaget är inte att välja den enkla metoden. Misstaget är att inte bestämma medvetet och upptäcka luckan när den redan är i produktion.

6. Att lansera i mörker utan något sätt att se vad användarna gör

Du lanserar. Folk registrerar sig. Och sedan... tystnad. Du har ingen aning om vilka funktioner de rör, var de fastnar eller varför de lämnar. Så du gissar. Du bygger nästa funktion baserat på en aning, det högljuddaste kundmejlet eller din egen intuition — som, efter månader inuti din egen produkt, är det minst pålitliga instrument du äger.

Grundläggande produktanalys och ett enkelt sätt att samla in feedback är ingen lyx för tillväxtskedet. De är hur du styr. Utan dem driver du inte ett företag, du driver en dyr åsikt. Att veta något så enkelt som att ”80 % av användarna öppnar aldrig funktionen jag ägnade två månader åt att bygga” är värt mer än ytterligare två månaders blint byggande.

7. Att lämna säkerhet och säkerhetskopior till ”senare”

Hastighet är religionen i tidigt skede, och oftast är det rätt. Men det finns en liten uppsättning saker som är katastrofalt dyra att eftermontera, och säkerhet står överst på listan. Att lagra lösenord ordentligt, låsa ner vem som har åtkomst till vad och — snälla — ha fungerande, testade säkerhetskopior är inga valfria funktioner du lägger till när du har tid. De är golvet du bygger på.

Det grymma med den här kategorin är att du kommer undan med det ända tills du inte gör det. Allt är bra i ett år, och sedan raderar ett intrång, en oavsiktlig massradering, en utpressningstrojan-morgon förtroendet och datan du byggde det året. Vi ber inte om en säkerhetsavdelning. Vi ber om att grunderna ska finnas på plats från början, eftersom kostnaden för att lägga till dem efter en incident mäts i döda företag.

8. Att anlita fel byggare för fel skede

Icke-tekniska grundare står inför ett brutalt val: vem bygger faktiskt det här? De två klassiska misstagen speglar varandra. Det ena är att anlita den billigaste möjliga frilansaren som levererar något som ser rätt ut men hålls ihop med tejp, och faller samman i samma stund du behöver ändra det. Det andra är överanställning — ett fullt seniorteam med fulla löner för att bygga en produkt som inte har förtjänat en enda kund ännu.

Det ärliga svaret beror helt på var du befinner dig. För att validera en idé vill du ha ett litet, senior, pragmatiskt team som har byggt produkter i tidigt skede förut och vet exakt vad som ska lämnas utanför. För att skala en bevisad produkt vill du ha andra människor med andra instinkter. Att matcha byggaren till skedet är i sig en färdighet — och att göra det fel slösar bort mer pengar än något tekniskt beslut på den här listan.

9. Att behandla lanseringen som mållinjen

Det sista misstaget är det sorgligaste, eftersom det kommer efter så mycket hårt arbete. Teamet behandlar lanseringsdagen som målet, kastar allt på att ta sig dit och anländer utmattat utan plan, utan budget och utan energi för det som kommer härnäst. Men lanseringen är inte mållinjen. Den är början på den enda fas som spelar roll: att lära sig av riktiga användare och förbättra, vecka efter vecka.

En SaaS-produkt är aldrig ”klar”. Den första versionen är en hypotes, och månaderna efter lanseringen är när du får reda på hur fel den var — på det goda sättet. Grundare som planerar för det, som håller lite startbana och mycket nyfikenhet i reserv, är de som förvandlar en skakig lansering till ett riktigt företag. De som gjorde av med allt på att nå startlinjen brukar inte ta sig mycket längre.

Hur du faktiskt undviker alla nio

Att läsa en lista över misstag är lätt. Att undvika dem under deadlinepress, med dina egna pengar på spel och din egen idé i hjärtat, är genuint svårt. Så här är kortversionen av hur grundarna som får det rätt brukar arbeta — inte som regler, utan som vanor värda att stjäla.

1. 1
   Validera innan du bygger

   Få något grovt framför riktiga potentiella kunder och bekräfta att de betalar, innan du skriver seriös kod. Billigt att göra, brutalt att hoppa över.
2. 2
   Välj den minsta riktiga produkten

   Definiera den enda sak din produkt måste göra och skjut hänsynslöst upp allt annat. Skriv ner vad ”version ett” medvetet inte inkluderar.
3. 3
   Bygg tråkigt och isolera tenanter

   Använd den enklaste arkitektur som fungerar, men gör dataseparation mellan kunder till ett grundläggande, testat beslut från dag ett.
4. 4
   Designa pengavägen tidigt

   Behandla registrering, introduktion och fakturering som kärnprodukt, inte pappersarbete. De första fem minuterna avgör om resten ens blir sett.
5. 5
   Mät den, lansera sedan för att lära

   Lansera med grundläggande analys och feedback på plats, behåll startbana för fasen efter lanseringen och behandla den första versionen som en fråga, inte ett svar.

Lägg märke till att nästan inget av detta handlar om kodningsskicklighet. Det handlar om omdöme — att veta vad man ska bygga, vad man ska hoppa över och när. Det är precis därför så många tekniskt kompetenta team ändå producerar produkter som misslyckas: den svåra delen av SaaS var aldrig ingenjörskonsten. Den var återhållsamheten.

Vanliga frågor