Rob Collie, VD och grundare av P3 Adaptive samt författare till Fair Game – Intervjuserie

Rob Collie är grundare och VD för P3 Adaptive, en Microsoft Solutions Partner för Data och AI som betjänar hundratals medelstora företag och Fortune 1000‑kunder. En tidigare ingenjörsledare på Microsoft i Excel‑, Bing‑ och Power BI‑teamet, Rob ledde Power BI‑vågen efter att ha lämnat Microsoft och har författat tre tidigare affärs‑teknologiböcker (över 92 000 sålda exemplar). Han är också programledare för podden Raw Data with Rob Collie. Hans fjärde bok, Fair Game: Customizing AI to Your Business Is Easier Than You Think (augusti 2026), sätter den praktiska trovärdigheten i centrum av AI‑ögonblicket.

Du tillbringade mer än ett decennium på Microsoft med att hjälpa till att utveckla business‑intelligence‑funktioner i Excel och Power BI innan du grundade P3 Adaptive 2013. Hur påverkade övergången från att bygga programvara inom Microsoft till att lösa dataproblem för kunder din nuvarande syn på företags‑AI?

När jag ledde produktteam på Microsoft byggde vi programvara som skulle fungera för hela världen och som inte kunde anpassas till någon specifik kunds behov. Vi kallade det ibland för att “beställa en pizza vars pålägg var acceptabla för 300 miljoner människor.” Det finns oundvikligen en känsla av lägsta gemensamma nämnare i ett sådant arbete, liksom ett visst avstånd till enskilda kunder.

Det fanns en tydlig prestige i att arbeta på den stora scenen, men det var inte lika känslomässigt tillfredsställande som att hjälpa specifika kunder att förverkliga sina unika ambitioner. När man arbetar nära en kund får man möjlighet att bli investerad i deras framgång och att utforska kreativa lösningar som aldrig skulle passa in i den en‑storlek‑passar‑alla‑modellen för Stora Programvaror. Det är på många sätt mer intellektuellt stimulerande, och den direkta kopplingen till våra kunder gör vinsterna mycket mer givande.

Men ansvaret är också större. På Microsoft var en enda missnöjd kund bara en statistik, och jag ryckte på axlarna inför klagomål varje dag som en del av mitt jobb. På P3 Adaptive betyder en enda missnöjd kund att vi har misslyckats. Det finns inga statistik. Vi har ett ansvar gentemot varje enskild relation.

Jag lärde mig många värdefulla saker på Microsoft och skulle inte byta bort den erfarenheten för något, men jag kallar mig ofta för en “återhämtande mjukvaruingenjör”, eftersom framgång nu innebär att arbeta på ett helt annat sätt.

Och det är exakt den linsen jag tar med mig in i företags‑AI. AI i hyllan är den ultimata 300‑miljondriven pizzan – ett verkligt underverk, konstruerat för att vara individuellt värdefullt för alla men utan anpassning till någon. Men organisatorisk AI‑framgång kommer från anpassningen – från att komma nära ett specifikt företag och skräddarsy AI:n till dess data, dess processer, dess definitioner. Jag har tillbringat min karriär på båda sidor av den klyftan, och det har lämnat mig utan minsta tvivel om vilken sida företags‑AI kommer att vinna på.

I Fair Game hävdar du att många företag har närmat sig artificiell intelligens baklänges genom att distribuera generella chatbot‑licenser istället för att bygga system som förstår deras verksamhet. Var når AI‑assistenter i hyllan sina gränser, och vilka signaler visar att ett företag behöver något skräddarsytt?

AI i hyllan har en doktorsexamen i allt förutom ditt företag. Den har läst hela internet, men internet saknar ditt företags definition av “aktiv kund”, din prismodell, dina operativa processer och vilken av dina två system som ska litas på när de motsäger varandra. Den kunskapen blir aldrig offentlig. Så den generiska AI:n som är en världsledare för personligt bruk räcker inte till för verklig affärsanvändning, och klyftan mellan de två upplevelserna är både avskräckande och förvirrande.

Idag är i princip allas svar på “vad man ska göra med AI” ”köp prenumerationer och se vad som händer”. Jag anser att det är ett naturligt första steg, så jag kritiserar inte dem som gjort det. Istället är jag sympatiskt – ingen tar egentligen tid att förklara att prenumerationerna i hyllan inte räcker till, eller varför. Så jag tror att företag är precis där vi bör förvänta oss att de är – de provar det som finns tillgängligt och börjar inse att det är otillräckligt.

Lösningen är inte att röra AI‑modellen själv – du behöver inte bli en LLM‑forskare. Det handlar om allt du omger modellen med: dina data, dina instruktioner skrivna på klar engelska och vanlig mjukvara. När du märker att du skriver in samma kontext i en chatbot för femte gången den här veckan, är det en signal. Allt du fortsätter att förklara om och om igen är exakt vad ett skräddarsytt system redan bör veta – varje gång det vaknar.

Du använder termen “Crafters” för att beskriva datakunniga affärsproffs som kan bygga värdefulla skräddarsydda AI‑system utan att vara traditionella mjukvaruutvecklare. Vilka egenskaper särskiljer en Crafter, och hur kan ledare identifiera dessa personer i sin befintliga arbetsstyrka?

En Crafter är någon som föddes med ett behov av att lösa problem med verktyg. Ungefär en av 16 kunskapsarbetare har detta, enligt min erfarenhet. De var Excel‑power‑användarna, sedan Power BI‑generationen, sedan de personer IT kallade “shadow IT”. De är dina analytiker, dina finansmodellörer, dina driftledare – personer som växte upp i verksamheten och upptäckte en talang för verktyg.

Två egenskaper gör dem idealiska för AI‑arbete. Först, systemtänkande: de bryter instinktivt ner en rörig process i indata, regler och utdata, likt professionella mjukvaruutvecklare. För det andra, förankring i verksamheten: de vet vilka siffror CFO:n faktiskt följer och vad personen som ställer en fråga egentligen menar. Ingen av dessa kan läras ut på en bootcamp.

Hur du hittar dina: följ kalkylbladen. Just nu finns det i ditt företag kalkylblad, instrumentpaneler och automatiseringar i hjärtat av kritiska arbetsflöden. Ingen av dem byggdes av IT, och varje har en författare. Börja där. Och börja sedan bedöma hur de kan rikta sina talanger mot skräddarsydda AI‑lösningar.

Varför tror du att Crafters, snarare än enbart utvecklare, är bäst lämpade att leda många interna AI‑projekt, och hur bör ansvaret fördelas mellan affärsexperter, datateam, mjukvaruingenjörer, IT‑avdelningar och säkerhetsteam?

För att den svåra delen av skräddarsydd AI inte är kod – det är kontext. Den enskilt mest avkastningsgivande aktiviteten i ett AI‑projekt är att bestämma vad systemet behöver veta om ditt företag, och Crafters har den kunskapen inbyggd. En briljant ingenjör som hoppar in från tre led i organisationsschemat måste genomföra månader av intervjuer för att lära sig vad din driftledare redan vet av reflex.

Men detta är tydligt inte en berättelse om att utvecklare är föråldrade. Den arbetsfördelning jag rekommenderar har tre faktorer, och ingen av dem är senioritet eller personlighet: arbete dras mot professionella utvecklare när återanvändbarhet, komplexitet och känslighet ökar. Allt som är kundinriktat, allt som berör känslig data, allt som fattar autonoma beslut – det är utvecklarterritorium, och när agenterna multipliceras blir dessa knappa ingenjörsfärdigheter mer värdefulla, inte mindre. Arbete dras mot Crafters där nyanser i affärsprocesser dominerar.

Det finns också en underskattad mellanställning: Crafter bygger, utvecklaren granskar. IT och säkerhet bör inte vara grindvakter som godkänner projekt för att de ska existera – de bör äga den bana som redan är lagd. Tillhandahåll de godkända plattformarna, dataåtkomstreglerna, granskningspunkterna, och låt de personer som är närmast problemen göra själva bygget. Behandla hela processen som en mognadsmodell, inte ett stängsel.

Skräddarsydd AI behöver tillgång till företagsspecifik terminologi, mått, processer och institutionell kunskap. Vilken roll spelar semantiska modeller och befintlig business‑intelligence‑infrastruktur för att ge AI en korrekt förståelse av ett företag?

De är avkodningsringen. Just nu lever ditt företags definitioner – vad som räknas som en aktiv kund, vilka kostnader som hör till bruttovinst – i människors huvud och i tusen något inkonsekventa kalkylblad. En AI‑agent kan inte på ett pålitligt sätt resonera kring dina data förrän dessa definitioner är nedskrivna i ett format som en maskin kan lita på. Branschen har börjat kalla denna disciplin för “context engineering”, och jag skulle översätta termen så här: det är arbetet med att strukturera vad ditt företag vet så att en AI faktiskt kan använda det. Analytikerna fick det att låta nytt. BI‑praktiker har gjort en version av detta i femton år.

Det är den goda nyheten som gömmer sig i klar sikt: om du investerade i BI‑eran (och särskilt om du investerade i Power BI), kan du redan ha ett försprång. En välbyggd semantisk modell är exakt den maskinläsbara fångsten av affärsmening som agenterna behöver. Företag som behandlade sitt semantiska lager som en eftertanke upptäcker nu att det “tråkiga” definitionsarbetet de hoppade över är nu tullstationen på vägen till AI. Och kritiskt är detta arbete djupt specifikt för ditt företag – vilket är precis varför det är den hållbara fördelen. Varje leverantör kan sälja dig samma modell. Ingen kan sälja dig dina egna definitioner.

Du byggde en skräddarsydd AI‑redigerare, känd som Eddie, för att hjälpa till att utveckla Fair Game. Vad gjorde systemet egentligen under skrivprocessen, och vad lärde dess framgångar och misslyckanden dig om att designa AI kring ett starkt personligt arbetsflöde?

För att vara tydlig skrev jag varje stycke i boken från grunden, medan Eddie mest satt och väntade. Ibland tillbringade jag timmar med att slipa fram ett helt avsnitt av ett kapitel innan jag bad “honom” läsa det. Andra gånger kastade jag idéer på honom varannan minut. Men avgörande var att Eddie var i beredskap dygnet runt. Jag kunde få feedback lika lätt klockan tre på morgonen som klockan ett på eftermiddagen, och han levererade den inom en minut eller mindre. Sammanlagt tror jag att Eddie läste manuskriptet minst trettio gånger. Ingen människa skulle kunna göra det här jobbet, för ingen människa skulle vilja det.

Han följde upp löften jag gjort i Kapitel Tre och påpekade när Kapitel Tolv glömde dem. Han lärde sig min skrivstil och sedan verkställde den – han höll mig till den bästa versionen av min egen röst istället för att låta mig glida in i Humorless Business Author‑läget. Han sa till mig när jag var lat och när jag slogs på en död häst. Vi hade riktiga meningsskiljaktigheter, och ibland vann han.

Den största designlärdomen: Eddies “hjärna” är skriven på engelska och ligger i en mapp. Varje gång han gav feedback som missade – för generell, fel register, glömde en regel jag redan sagt – var lösningen att skriva ner korrigeringen och göra den till en del av hans permanenta kontext. Misslyckandena var inte AI‑misslyckanden; de var luckor i vad jag hade tagit mig tid att lära honom. Den slingan – märk av misstaget, koda in lektionen, se den fastna – är hela hantverket av skräddarsydd AI i miniatyr. Och det är därför jag slutade med att bygga specialiserade Eddie‑versioner för publicitet, konkurrensforskning och webbplatsmeddelanden. Samma LLM under ytan. Men olika specialister.

Många organisationer tror att de måste rensa och centralisera sina data helt innan de försöker med skräddarsydd AI. Hur mycket dataklarhet krävs egentligen för att börja, och hur kan företag börja skapa värde utan att vänta på en perfekt grund?

Dataperfektion är inte ett förutsättningskrav, och det är goda nyheter eftersom perfektion aldrig kommer. Om du först försöker bygga en perfekt data‑egendom, som många konsultfirmor skulle råda, bygger du vad jag kallar “rördragning för sakens skull” – dyra rör överallt, men när du äntligen installerar en kran upptäcker du att det inte finns något rör där du behöver det.

Vårt företag förespråkar istället ett “kranar först”-tillvägagångssätt. Välj ett specifikt användningsfall och arbeta baklänges från affärspåverkan snarare än framåt från infrastruktur. Bygg en MVP från det fallet, och gör det med minimal ny infrastruktur. Iterera på MVP:n tills den är produktionsklar, och gå sedan tillbaka och utvärdera hur du kan stärka din infrastruktur för att stödja den. Det levererar affärspåverkan snabbare, minimerar kostnader och informerar framtida projekt – både på kran‑ och rörnivå.

En skräddarsydd AI‑prototype kan verka imponerande under en demonstration men bli opålitlig när den utsätts för riktiga anställda, förändrade data och kantfall. Vilken utvärdering, övervakning och mänsklig tillsyn bör etableras innan ett internt AI‑system blir operativt?

Med några få anmärkningsvärda undantag tror jag att demo‑presentationer är mindre värdefulla i AI‑eran än de var i mjukvareran. Mjukvarademon överlöpte alltid och vi alla visste det. Men AI‑demoer kommer att vara ännu längre bort från din verklighet.

AI handlar om arbetsflöden. Och det finns inget mer skräddarsytt än de tusentals arbetsflöden som driver en specifik organisations verksamhet. Gå tillbaka till metaforen “nyanställd med en doktorsexamen i allt”. Hur mycket utbildning – och praktisk erfarenhet av att arbeta i ditt företag – krävs för att en nyanställd ska vara effektiv i ditt företag? Hur kan en demo möjligen ta hänsyn till allt detta?

Så vi använder demoer för att få folk att tänka. För att visa dem vad som är möjligt. Inte för att sälja en produkt. Den verkliga demon börjar med prototypen av den skräddarsydda lösningen. MVP:n. Och sedan itererar och förbättrar vi. Snabbt.

Efter en tid är den redo för en mjuk lansering eller pilotprogram. Och återigen lär vi oss – tillsammans – och förbättrar snabbt baserat på den lärdomen. Detta är ofta fasen där övervakning, utvärdering och tillsyn blir tydligt i fokus. De saker du slutligen behöver är ofta mycket annorlunda än vad du skulle ha gissat från början.

Hur kan företag ge Crafters möjlighet att experimentera utan att skapa en ny generation av shadow‑AI‑system, duplicerade arbetsflöden, säkerhetsbrister och verktyg som ingen tar ansvar för att underhålla?

Kom ihåg var shadow‑IT kom ifrån: det var inte illvilja, det var ett nödvändigt svar på ouppfylld efterfrågan. Crafters bygger eftersom problem stör dem – det är genen. Om den godkända vägen innebär ett års väntan kommer shadow‑AI att fylla gapet – och fylla det under radarn, där det är mest farligt.

Så gör den godkända vägen till den enkla vägen. Ge Crafters en godkänd plattform med säkerhetsriktlinjer redan inbyggda – identitet, dataåtkomst, loggning – så att det efterlevnadsgodkända valet också är det bekväma. Behåll ett lättviktigt register: allt som går från personligt experiment till något en annan person är beroende av skrivs ner, med en namngiven ägare. Den enda regeln eliminerar de flesta problem med föräldralösa verktyg, eftersom verktyg med namn kopplade till sig inte överges tyst.

Applicera sedan eskaleringsmodellen: experiment kör fritt, men när något blir kritiskt för verksamheten – fler användare, högre känslighet, mer autonomi – får det successivt mer ingenjörsgranskning. Crafter behåller ägandet av affärslogiken; en utvecklare förstärker det som behöver förstärkas. Målet är en mognadspipeline, inte en tillståndsprocess. Företag har redan spelat upp exakt den här filmen med kalkylblad, och vinnarna var inte de som förbjöd Excel.

För ett företag som påbörjar sitt första skräddarsydda AI‑initiativ, hur bör det välja det första användningsfallet, mäta om projektet levererar meningsfullt affärsvärde, och besluta om det ska skalas upp, omdesignas eller överges?

Vi har två typer av startpunkter som vi använder med våra kunder.

Alternativ ett, leta efter de uppgifter som ingen utför – inte de uppgifter du vill eliminera. Det finns en fråga jag älskar att ställa till chefer: när har du tänkt, “om jag hade en person som ständigt övervakade detta och tänkte på det, skulle saker bli meningsfullt bättre – men jag skulle aldrig kunna motivera en hel anställning för det”? Det är ofta dina bästa startpunkter. De är säkra, bygger förtroende, ingen känner sig som ett mål, och kontrafaktum är ärligt: alternativet var inte en människa som gjorde det bra, det var ingen som gjorde det alls (som min redaktörsvän Eddie).

Alternativ två, överväg att ersätta instrumentpaneler med data‑agenter. Så enkla som instrumentpaneler verkade, föll de långt ifrån att leverera på sitt löfte i praktiken. När någon har en affärsfråga är det mycket arbete för dem att översätta den frågan till instrumentpanelslandskapet. Var är instrumentpanelen som svarar på denna fråga? Vad heter den namnmässigt? Finns en sådan instrumentpanel ens existerar? Och om du lyckas hitta den “rätta”, är den tydlig och bekväm att använda? Måste du upprepade gånger manipulera den, skriva ner eller ta skärmdumpar av flera versioner för att sammanställa den övergripande bilden du behöver?

I AI‑eran tar du bara din affärsfråga – i dina egna ord – och skriver in den (eller dikterar den!) till en data‑agent som sedan hanterar allt åt dig, och returnerar ett certifierat, välundersökt svar – visuella element inkluderade – på en minut eller två. När du har en uppföljningsfråga svarar den gärna snabbt på den också – under mötet medan beslut fortfarande kan fattas.

Den gemensamma tråden bakom båda dessa startalternativ? De adresserar båda smärtpunkter som anställda kommer att omfamna snarare än motstå. Du vill inte att dina tidiga AI‑initiativ så frön av misstro. Du vill att de istället tar med anställda till bordet. Du vill att anställda föreslår förbättringar och nya projektidéer. För återigen består ditt företag av tusentals arbetsflöden, och dina anställda känner dem bättre än du.

När det gäller att skala upp, omdesigna eller överge – var snäll mot dig själv, för forskningen på detta är verkligen tröstande: de flesta framgångsrika AI‑implementeringar hade misslyckanden innan dem. Ett första projekt som ger en läxa istället för en avkastning är en utbildning, inte bevis på att AI inte fungerar. Min tumregel: om folk använder det, skala upp det. Om folk inte använder det, måste du veta varför, och svaret kan variera från ”för att det inte fungerar bra” till ”för att jag inte förstår det” till ”det skrämmer mig”. Svaret avgör om du förbättrar, omdesignar eller överger. Du behöver inte förutsäga var allt detta hamnar. Du måste bara börja någonstans ärligt.

Tack för det fantastiska intervjun, läsarna bör också läsa Fair Game: Customizing AI to Your Business Is Easier Than You Think.