Under 2024 och 2025 byggde många organisationer sina AI-satsningar som om de vore ERP-införanden. En central plattformsgrupp, en styrgrupp, en modellstrategi och en färdplan på arton månader. Det var ett rimligt sätt att tänka när ingen visste vad tekniken klarade. Nu vet vi det, och den insikten har flyttat flaskhalsen någon annanstans.
Det som avgör i dag är inte vilken modell du valde. Det är hur många gånger i veckan du kan låta en riktig användare möta något du byggt och sedan ändra det. Den takten är svår att hålla i en stor organisation och närmast gratis i en liten. Därför ser vi gång på gång att fem personer med mandat levererar mer verklig nytta på ett kvartal än trettio personer med en plan.
Flaskhalsen är inte längre modellen
För tre år sedan var modellvalet ett tekniskt vägval med stora konsekvenser. Skillnaden mellan en bra och en dålig modell var skillnaden mellan en produkt som fungerade och en som inte gjorde det. I dag är avståndet mellan de ledande modellerna litet för de allra flesta uppgifter ett företag vill lösa, och det krymper varje halvår.
Det betyder inte att modellvalet är oviktigt. Det betyder att det har blivit ett beslut man kan ändra. Ett team som byggt sin lösning med ett tydligt lager mellan applikationen och leverantören byter modell på en eftermiddag. Ett team som inte gjort det har skrivit in en leverantör i sin arkitektur och betalar för det i åratal.
När modellen slutade vara det svåra flyttade svårigheten till tre andra ställen: att veta vilket problem som faktiskt är värt att lösa, att få tag på data som beskriver det, och att våga släppa något innan det är perfekt. Alla tre är organisatoriska frågor, inte tekniska.
Vad ett litet team faktiskt gör annorlunda
Det första är att avståndet till användaren är kort nog att gå. Ett team som sitter i samma rum som de som ska använda lösningen upptäcker på en förmiddag vad en kravinsamling missar på en månad. Vi har sett fall där hela hypotesen om vad som skulle automatiseras föll efter två dagars observation, och där det som verkligen tog tid var något ingen hade skrivit ner för att alla tyckte att det var självklart.
Det andra är att ett litet team kan ha fel utan att det kostar. När fem personer har byggt något i tre veckor och det visar sig vara fel väg är förlusten tre veckor. När trettio personer har byggt i ett år är förlusten inte bara året, utan också allas ovilja att erkänna det. Storleken på investeringen bestämmer hur svårt det är att överge den, och AI-arbete kräver att man överger saker ofta.
Det tredje är att beslut fattas av någon som förstår detaljerna. Ett litet team har ingen som översätter mellan de som vet och de som bestämmer. Den översättningen är där de flesta AI-projekt tappar sin precision: en nyans om att modellen är bra på det ena men opålitlig på det andra överlever sällan tre möten uppåt.
Måttet som skiljer team åt
Om vi bara fick mäta en sak på ett AI-team skulle vi mäta hur lång tid det tar från att någon får en idé till att en riktig användare har prövat den. Inte tiden till produktionssättning, inte tiden till godkänd modell. Tiden till första kontakt med verkligheten.
Team där det tar en vecka lär sig ungefär femtio gånger om året. Team där det tar ett kvartal lär sig fyra gånger. Efter två år är skillnaden inte att det ena teamet är dubbelt så bra, utan att de arbetar med helt olika frågor. Det snabba teamet har passerat de misstag det långsamma teamet fortfarande har framför sig.
Det här är också varför utvärdering är viktigare än det låter. Ett team som har ett automatiskt sätt att mäta om en ändring gjorde lösningen bättre eller sämre kan gå fort utan att gå sönder. Ett team som förlitar sig på att någon tittar på tjugo exempel och tycker till kommer att sakta ner precis när det börjar bli allvar.
När stort ändå är rätt
Det finns arbete som kräver skala, och att låtsas annat vore ohederligt. Att bygga en gemensam datagrund. Att förhandla och förvalta avtal. Att ta fram spelregler för vad som får skickas till vilken leverantör, och att se till att de går att följa i praktiken. Att driva den underliggande plattformen med den tillgänglighet som verksamheten faktiskt kräver.
Skillnaden är att den sortens arbete möjliggör snarare än levererar. Det ska bedömas på hur mycket snabbare det gör alla andra, inte på hur många funktioner det själv producerar. En plattformsgrupp som mäts på sina egna leveranser börjar bygga saker ingen bad om. En plattformsgrupp som mäts på hur snabbt det tredje teamet i ordningen kom igång bygger något annat, och något bättre.
Den vanligaste organisatoriska missen vi ser är att blanda ihop de två. En central grupp får både ansvar för grunden och för de första lösningarna, och eftersom lösningarna är synliga och grunden inte är det vinner lösningarna varje gång resurserna ska fördelas. Två år senare finns fyra halvfärdiga produkter och ingen grund.
Så här skulle vi börja
Välj ett problem som någon faktiskt klagar på i dag, inte det mest strategiska du kan formulera. Sätt fyra till sex personer på det, med minst en som gör arbetet i dag och minst en som får ändra i produktionskoden. Ge dem sex veckor och ett tydligt sätt att mäta om det blev bättre.
Bygg lagret mellan din applikation och modelleverantören redan från början, även när det känns onödigt. Det är billigt i vecka ett och dyrt i månad arton.
Bestäm i förväg vad som ska hända om det inte fungerar. Ett team som vet att det är tillåtet att lägga ner efter sex veckor arbetar öppnare än ett team som anar att nedläggning betyder att någon får skulden.
Och räkna med att det första du bygger inte är det som blir kvar. Det är inte ett misslyckande, det är hela poängen med att gå fort. Värdet ligger i vad ni vet i vecka sju som ni inte visste i vecka ett.