← Blog

AI & edtech

Når kunden bliver konkurrenten: Kunden fandt en genvej til softwarefabrikken

Sahra-Josephine Hjorth seated on a mosaic bench at Park Güell in Barcelona, wearing sunglasses, a black cap and an embroidered white dress

Denne tekst er maskinoversat fra engelsk. Nuancer kan gå tabt undervejs, så vi anbefaler at læse originalen. Læs den engelske original

Del fire i serien om, hvordan 90 % af edtech forsvinder. Softwarevirksomheder brugte tyve år på at overbevise kunderne om ikke selv at bygge. Kunstig intelligens ændrer afstanden mellem at ønske sig software og at lave den.

Jeg tilbragte en del af min sommerferie med at gå rundt i en af de smukkeste kommercielle fiaskoer, der nogensinde er bygget. Park Güell er i dag det bedste, Barcelona har at byde på: Gaudí, mosaikker, en helt særlig udsigt og en stabil strøm af turister, der fotograferer sig selv ved siden af en keramisk øgle. Men parken var aldrig tænkt som offentlig. Eusebi Güell og Antoni Gaudí planlagde den som et eksklusivt boligkvarter for velhavende familier med tres huse placeret oven over byen. Kun to blev nogensinde bygget.

Vores guide forklarede, at et af problemerne overraskende nok var praktisk. De mennesker, der var rige nok til at bo der, skulle stadig nå frem til deres fabrikker og havnen, og det betød en tur i hestevogn ad en besværlig rute, hvor turen afhang af vejr og vejforhold. Kvarteret bød måske på renere luft og smukke udsigter, men det var ganske enkelt for besværligt at komme fra huset til det sted, hvor pengene blev tjent.

Der var andre forhindringer. Grundene kom med restriktive betingelser, den offentlige transport var utilstrækkelig, og den samme eksklusivitet, der gjorde kvarteret attraktivt, gjorde det også kommercielt uholdbart. Byggeriet gik i stå i 1914. Güells arvinger solgte til sidst grunden til byen, og den åbnede som offentlig park i 1926.

I dag føles stedet slet ikke afsides. Barcelona voksede omkring det, mens veje, busser, taxaer og metroen ændrede, hvad afstand betød i praksis. Park Güell blev ikke nødvendigvis bygget det forkerte sted. Den blev bygget, før vejen kom.

Jeg har brugt elleve år i SaaS-branchen inden for edtech på at fortælle kunder, at de ikke skulle bygge software, de kunne købe. I nioghalvfems ud af hundrede tilfælde var det oprigtigt fremragende råd. At bygge sin egen læringsplatform betød udviklere, designere, produktchefer, infrastruktur, integrationer, sikkerhed, vedligeholdelse og budget nok til at overleve den dag atten måneder senere, hvor nogen opdagede, at det interne system, alle havde slidt så hårdt med, var ringere end det produkt, de kunne have købt fra starten.

Softwarefabrikken fandtes, men for de fleste virksomheder var vejen derhen langsom, besværlig og uhyre dyr. Så lærte vi virksomhederne at leje i stedet. Byg ikke dit eget learning management system, køb et. Byg ikke et forfatterværktøj, abonnér på et. Byg ikke en medarbejderakademi- eller assessmentplatform, find en specialistvirksomhed, der allerede har løst problemet. Jeg byggede en succesfuld, venturefinansieret edtech-virksomhed på netop den logik.

I dag ejer jeg desuden et AI-studie, og jeg giver i stigende grad kunderne et råd, der lyder som det modsatte: Find ud af, hvad det ville koste at bygge den funktionalitet, du faktisk har brug for, før du køber endnu et softwareprodukt. Det betyder ikke nødvendigvis, at man skal bygge det selv internt. En virksomhed kan spørge en af sine egne udviklere, en AI-assisteret konsulent eller et studie som mit. Den behøver ikke blive en softwarevirksomhed eller eje fabrikken. Den skal blot have overkommelig adgang til en.

Jeg ved, hvor omvæltende det råd er, for jeg har selv fulgt det. Jeg har tidligere skrevet om, at mit personlige nyhedsbrev kostede cirka 10.000 kroner om måneden at sende til omkring 36.000 mennesker gennem Mailchimp. Jeg brugte Lovable til at bygge mit eget afsendelsesværktøj og koblede det til SendGrid. Det kostede under 30 dollar at bygge, det koster cirka 25-30 dollar om måneden at drive, og det, jeg ikke nævnte dengang, er, at det tog under en dag.

Værktøjet er stadig ikke lige så godt som Mailchimp og mangler nogle af dets integrationer, skabeloner og specialtilfælde. Men det har jeg ikke brug for. Det klarer den del af Mailchimps funktioner, jeg faktisk bruger, og erstatter et abonnement til cirka 10.000 kroner (1.520 dollar) om måneden, svarende til omkring 18.000 dollar om året, med en infrastruktur, der koster cirka 25-30 dollar om måneden, eller 300-360 dollar om året. Mailchimp tabte mig ikke til en anden e-mail-platform. Det tabte mig til mig selv.

AI er ved at bygge vejen mellem virksomhedens kontor og softwarefabrikken, og derfor tager jeg i stigende grad mig selv i at spørge kunder om noget, jeg tidligere ville have kaldt et forfærdeligt råd: Hvorfor køber du overhovedet det her?

Købet fandtes, før konkurrencen begyndte

De fleste softwarevirksomheder tænker først på konkurrence, efter at kunden har besluttet sig for at købe. Kunden har brug for en læringsplatform, så den sammenligner læringsplatforme. Den har brug for et CRM, så den sammenligner CRM-systemer. Den har brug for et nyhedsbrevssystem, så Mailchimp konkurrerer med HubSpot, Klaviyo og alt andet, der havner på kortlisten. Kategorien har allerede vundet, det eneste tilbageværende spørgsmål er, hvilken leverandør der får pengene.

Den antagelse ligger til grund for en enorm del af SaaS-strategien. Marketing skaber efterspørgsel efter kategorien, salg omsætter efterspørgslen til en navngiven konto, produktafdelingen tilføjer nok funktioner til at slå den nærmeste konkurrent, og kundesucces-teamet passer på fornyelsen. Selv kundeafgang forudsætter, at der først var en kunde.

Tag en virksomhed med 10.000 medarbejdere og en elendig læringsopsætning. For ti år siden ville HR måske have inviteret fem LMS-leverandører til at demonstrere deres produkter og valgt en af dem. Spørg nu i stedet, hvad organisationen egentlig har brug for. Den har allerede et identitetssystem, politikker, videoer og intern viden. AI kan omdanne det materiale til øvelser. Det, der er tilbage, er at gemme gennemførelser, rapportere til ledere, dokumentere overholdelse og binde delene sammen.

Historisk krævede selv den smalle arbejdsgang så meget ingeniørarbejde, at det stadig var rationelt at købe platformen. Nu kan virksomheden beskrive arbejdsgangen, koble den til sine eksisterende systemer og lade en intern produktperson, en AI-assisteret udvikler eller et eksternt studie bygge den del, den mangler. Den kan stadig vælge at købe, hvis det kommercielle produkt er bedre, men købet er ikke længere det automatiske udgangspunkt. Virksomheden behøver ikke genskabe LMS'et. Den skal genskabe grunden til, at den i sin tid købte LMS'et.

Det farligste scenarie er derfor ikke kunden, der forsvinder ved fornyelsen. Den kunde nåede trods alt ind i CRM'et, underskrev en kontrakt og skabte en grund til at forlade, som nogen kan analysere bagefter. Det mere foruroligende scenarie er virksomheden, der aldrig bliver en prospect: Den besøger aldrig prissiden, dukker aldrig op i pipelinen, beder aldrig om en demonstration og giver aldrig indkøb en kortliste. Nogen spørger, om det her overhovedet behøver at være endnu et abonnement, opdager, at det ikke gør, og tager i stedet den nye vej til softwarefabrikken. Set fra SaaS-leverandørens side blev ingen handel tabt, for der fandtes aldrig nogen handel.

Du skal bare slå fakturaen

I størstedelen af SaaS-æraen kunne leverandørerne bundte hundredvis af funktioner sammen, fordi det var så dyrt at genskabe den delmængde, kunden brugte, at det gav mening at leje hele produktet. Den tærskel er ved at falde. Kunden behøver ikke bygge noget bedre, genskabe leverandørens samlede platform eller dække hvert eneste specialtilfælde. Den skal bare løse sit eget problem godt nok til at slå fakturaen.

Tag en bevidst enkel prismodel for en læringsplatform: 12 dollar pr. bruger om måneden, uden implementeringsgebyr, basisgebyr eller mængderabat. En virksomhed med 10.000 brugere betaler 1,44 millioner dollar om året. Ved 50.000 brugere er den årlige omkostning 7,2 millioner dollar, ved 200.000 er den 28,8 millioner. Det er ikke en påstand om, at en kompetent indkøbsafdeling ville acceptere den flade pris ved 200.000 pladser. Men selv efter en mængderabat på 75 procent ville det årlige abonnement stadig løbe op i 7,2 millioner dollar. Forudsætningerne rykker på det punkt, hvor det bliver rationelt at bygge selv, men de ophæver ikke forskellen mellem en omkostning, der stiger pr. bruger, og en, der måske ikke gør.

Selvfølgelig ville en kunde af den størrelse forhandle. Enterprise-kontrakter er sjældent så rene, og en seriøs læringsplatform gør langt mere end at hoste nogle få sider og registrere gennemførelser. Den kan tilbyde hundredvis af integrationer, avancerede rettigheder, tilgængelighed, revisionsspor, indholdsstandarder, lokalisering, support, sikkerhedsdokumentation og kontraktligt ansvar. En troværdig sammenligning må tage højde for alt det.

Men det er netop pointen: Kunden behøver ikke genskabe alt det, leverandøren har bygget. Forestil dig, rent som model, at en skræddersyet læringsplatform koster 1 million dollar at bygge og yderligere 2 dollar pr. bruger om måneden at drive, sikre og vedligeholde. Ved 10.000 brugere ville første år koste cirka 1,24 millioner dollar, allerede under det abonnement, der koster 1,44 millioner dollar. Ved 50.000 brugere ville det koste cirka 2,2 millioner i stedet for 7,2 millioner, ved 200.000 cirka 5,8 millioner i stedet for 28,8 millioner.

Det er illustrative tal, ikke en universel business case for selv at bygge. Regnestykket kan hurtigt vende, når en virksomhed har brug for global compliance, snesevis af dybe integrationer, døgnåben support, komplekse migreringer eller en leverandør, der er villig til at påtage sig reel driftsmæssig risiko. Skræddersyet software skaber risici for vedligeholdelse, sikkerhed og teknisk gæld, som et regneark kan skjule med imponerende effektivitet. Mange enterprise-platforme prissætter desuden efter aktive brugere, forbrug eller forhandlede intervaller frem for en flad, offentlig pris.

Selv efter alle disse forbehold er tendensen svær at overse. SaaS-priser pr. bruger stiger med kundens størrelse, mens omkostningen ved at bygge den relevante funktionalitet ikke nødvendigvis stiger nær så hurtigt. Større kunder giver flere pladser og mersalg, men de har måske også den stærkeste økonomiske grund til at spørge, om leverandøren overhovedet skal indgå i arbejdsgangen.

Ingen bruger seks måneder på at genskabe et produkt, der koster 200 euro om måneden. En lille skole bør nok ikke selv vedligeholde et hjemmelavet studieadministrationssystem, og en reguleret organisation bør passe på med følsomme data. En virksomhed, der betaler 250.000 euro om året, regner anderledes. Din mest attraktive kunde kan også være den, der har den stærkeste bevæggrund for aldrig at blive din kunde.

Det gamle spørgsmål var, om en skræddersyet løsning kunne måle sig med produktet. Det nye spørgsmål er, om den kan slå fakturaen, hvilket er en langt lavere overligger.

Lejen rykker ned i stakken

Det er ikke enden på at leje, det er en forandring af, hvad kunden lejer. Min Mailchimp-erstatning bruger stadig SendGrid til at levere mails. Jeg byggede ikke global mailinfrastruktur, forhandlede ikke direkte med hver eneste internetudbyder og skabte ikke mit eget system til at beskytte afsenderreputationen. Jeg erstattede et applikationsabonnement med en tyndere samling af infrastruktur og et lille stykke software, jeg selv styrer.

En virksomhed, der bygger sit eget læringsmiljø, vil sandsynligvis gøre det samme. Den kan betale OpenAI, Anthropic eller Google for modeladgang, bruge AWS eller Azure til infrastruktur og holde et eksternt team til at vedligeholde systemet. Softwarefabrikken er ikke blevet gratis. Den kræver stadig strøm, maskiner, råvarer og nogen, der forstår, hvad der bliver produceret, men lejen flytter sig ned i stakken.

I stedet for at betale et stort løbende gebyr for en færdig applikation med 400 funktioner kan kunden betale mindre løbende gebyrer for infrastruktur og selv eje de syv funktioner, den rent faktisk bruger. Den kan bestille et engangsprojekt uden at oprette en intern softwareafdeling, ligesom et modefirma kan bestille produktion uden at eje hver eneste maskine, der syr tøjet. Valget står ikke længere blot mellem at bygge eller købe. Det står mellem at købe, bygge, samle eller bestille, og AI gør de sidste tre billigere.

SaaS vandt oprindeligt, fordi én specialistvirksomhed kunne bygge et produkt én gang og distribuere det billigt til tusindvis af kunder. Den fordel forsvinder ikke, men leverandøren skal fordele omkostningen ved et generelt produkt, sit salgsapparat, sit kundesucces-team, sine investorer og sin funktionsplan ud over hele kundebasen. Et skræddersyet system skal kun betjene én virksomhed. I årevis var det også dets svaghed, for én kunde kunne ikke retfærdiggøre turen til fabrikken. Nu er vejen kortere.

Edtech er særligt udsat, fordi to omkostninger falder samtidig. Generativ AI reducerer omkostningen ved at producere og koordinere læring: En leder kan bede en assistent om at forklare en politik, generere en øvelse, tilpasse materialet til en rolle, oversætte det og teste forståelsen uden overhovedet at åbne et kursuskatalog. Samtidig reducerer AI-assisteret udvikling omkostningen ved at bygge det system, der tildeler, sporer og dokumenterer den læring. Den ene kraft angriber brugen, den anden angriber selve købet.

En edtech-virksomhed kan derfor blive klemt, selv mens efterspørgslen efter læring vokser. Organisationer vil stadig uddanne medarbejdere, dele viden, dokumentere compliance og udvikle kompetencer, og måske gøre mere af det hele. Men stigende efterspørgsel efter resultatet garanterer ikke stigende efterspørgsel efter den eksisterende produktkategori. Folk holdt ikke op med at se film, da DVD-udlejningen kollapsede, og de holdt ikke op med at lytte til musik, da det blev absurd at købe cd'er. Aktiviteten overlevede, men produktet, distributionen og betalingsmodellen omkring den ændrede sig.

Læring forsvinder ikke. Men antagelsen om, at den skal pakkes ind i en separat, købt læringsplatform, bliver mindre sikker.

Måske var din voldgrav afstanden

Den indlysende indvending er, at vibe-kodet software er upålidelig, usikker og let at demonstrere, men svær at drive. Ofte er det sandt. Der er en enorm afstand mellem at lave en fungerende prototype og at drive et forretningskritisk system, som kræver arkitektur, tests, rettigheder, overvågning, backup, datastyring, tilgængelighed, sikkerhedsgennemgang og nogen, der står til ansvar, når det bryder sammen. AI kan producere dårlig kode meget hurtigt og lade en virksomhed skabe en skrøbelig intern afhængighed, som ingen forstår seks måneder senere.

Men svag eksekvering redder ikke en svag forretningsmodel, den betyder blot, at kunderne har brug for en kompetent vej ind i det at bygge. Det tidlige internet var fuldt af elendige hjemmesider, og det reddede hverken avisernes rubrikannoncer, rejsebureauerne eller detailhandlen. Dårlige første forsøg kan sagtens sameksistere med en strukturel forandring i omkostning og adgang.

Det mere brugbare spørgsmål er, hvilken del af en SaaS-virksomheds forsvar der kom fra oprigtigt vanskeligt arbejde, og hvilken del der blot kom af, at kunden var for langt fra fabrikken. Dybe integrationer, proprietære data, myndighedsgodkendelse, kontraktligt ansvar, betroede adgangsnøgler, distribution, fællesskab og påviste resultater kan være formidable. En leverandør, der forstår et kompliceret domæne og påtager sig ansvaret for at drive det, kan være langt mere værd end sine funktioner alene.

Mange funktioner er ikke nødvendigvis en voldgrav. En smuk brugerflade holder mindre, når brugerflader kan genereres, et årtis ophobede kode betyder mindre, når kunden kun har brug for en smal arbejdsgang, og skifteomkostninger beskytter kun i begrænset omfang mod en virksomhed, der endnu ikke har købt noget som helst. Mange SaaS-virksomheder var trygge, dels fordi selv en ringere version krævede et team, kunden ikke havde, og et budget, den ikke kunne forsvare.

AI gør ikke ethvert produkt let, sikkert eller fornuftigt at genbygge. Den gør blot nok produkter billige nok til, at man med rette kan sætte spørgsmålstegn ved dem. Deraf følger en hårdere definition af forsvarsevne: En voldgrav er ikke det, der gør dit produkt svært at genskabe. Det er det, der gør det svært for kunden at slippe af med sit køb.

I tyve år handlede softwarepositionering mest om at svare på spørgsmålet: Hvorfor os frem for dem? Kunden havde allerede accepteret, at den skulle købe noget, og leverandørens opgave var at vinde sammenligningen. I stigende grad bliver softwarevirksomheder nødt til at svare på et langt farligere spørgsmål: Hvorfor overhovedet købe?

Det er et meget sværere argument at føre, for virksomheden gør ikke indsigelse mod din pris, beder ikke om endnu en funktion og truer ikke med at vælge din konkurrent. Den kommer måske aldrig ind på dit marked overhovedet. Ingen mulighed dukker op i CRM'et, ingen indkøbsproces går i gang, og ingen analyse af en tabt handel forklarer, hvad der skete. Behovet bliver simpelthen løst gennem software, virksomheden ejer, frem for software, den lejer.

Funktionaliteten består. Medarbejderne lærer stadig, lederne har stadig brug for information, og compliance har stadig brug for dokumentation. Det, der forsvinder, er transaktionen i midten.

Park Güell blev ikke bygget det forkerte sted. Den blev bygget, før infrastrukturen ændrede, hvad det sted betød. SaaS blev bygget til en verden, hvor vejen til softwarefabrikken var for lang og dyr for de fleste virksomheder at tilbagelægge, så SaaS gjorde fabrikkens output til noget, de kunne leje i stedet. Det var oprigtigt godt råd, indtil vejen ændrede sig.

Softwarefabrikken er ikke forsvundet, og det er behovet for det, den laver, heller ikke. Men virksomheder kan i stigende grad nå den uden om den SaaS-leverandør, der regnede med at sælge dem et abonnement, og det betyder, at din konkurrent ikke er endnu et produkt. Det er selve forsvindingen af købet.