Skip to main content
Key Takeaways

AI-påverkan: AI gör produktteamen sämre genom att ta bort skydd mot dåligt beslutsfattande.

Systemfokus: Effektivt produktledarskap fokuserar på system snarare än AI-modeller eller funktioner.

Evidensbaserat: Att prioritera evidensbaserade system förbättrar genomförandet och minskar risken för att felaktiga idéer snabbt skalas upp.

Arbetsflöden: Integrerade, AI-drivna arbetsflöden förbättrar produktutvecklingen från datainsamling till validering av beslut.

Förtroendeproblem: AI:s skenbara träffsäkerhet medför risker; verkligt ansvar kräver mänsklig tillsyn i beslutsfattandet.

Adam Root har haft roller som produktchef på olika teknikföretag. Han är för närvarande grundare av Root Ventures, där han bygger SaaS-produkter som drivs av arbetsflöden.

Vi satte oss ner med Adam för att förstå hur AI förändrar produktlivscykeln — och hur det faktiskt gör vissa team sämre på vägen. Här är vad han berättade för oss.

AI gör produktteam sämre

AI gör de flesta produktteam sämre, inte bättre — eftersom det tar bort den friktion som tidigare skyddade team från dåliga beslut.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Under de senaste 17+ åren har jag skalat SaaS-plattformar, lett AI-drivna initiativ och skapat mätbara resultat, bland annat genom att öka intäkterna från $20k till $400k MRR och leverera påverkan på företagsnivå. Tidigare i min karriär trodde jag att den svåraste delen var att bygga, lansera funktioner, skala team och genomföra en plan enligt en färdplan. Det jag har lärt mig, särskilt under de senaste åren, är att den verkliga utmaningen är att omvandla tvetydighet till övertygelse. AI har gjort den skillnaden omöjlig att ignorera. 

I dag kan vem som helst skapa en prototyp eller lansera snabbt med hjälp av AI-verktyg, men de flesta team har fortfarande svårt att omvandla det till verkligt genomslag. Jag ser konsekvent starka tekniska team bygga snabbare, men utan en tydlig produktgrund. De lägger AI ovanpå arbetsflöden som aldrig var utformade för att lyckas. Resultatet är mer produktion, men inte större påverkan.

Den insikten förändrade i grunden hur jag ser på produktledning. Jag betraktar nu varje produkt som ett system av sanning snarare än som en uppsättning funktioner. Det börjar med att verkligen förstå problemet, validera det med bevis och sekvensera beslut på ett sätt som skapar hävstång. Först då blir AI en verklig förstärkare. Utan den grunden accelererar AI bara bruset.

Så i dag ligger mitt fokus mindre på verktyg och mer på att skapa tydlighet, få team att samlas kring vad som är viktigt, varför det är viktigt och hur det driver resultat. För när systemet är rätt förstärker genomförandet sig självt.

Att bygga en AI-baserad produktportfölj

Just nu bygger jag en liten portfölj med AI-baserade och arbetsflödesdrivna SaaS-produkter inom olika områden. Var och en är utformad för att befinna sig i centrum av verkligt användarbeteende, inte bara för att lägga till funktioner ovanpå.

Sotia är ett intelligenssystem som bygger på beteendedata, med Slack som utgångspunkt, och som hjälper ledningen att förstå genomförandets hälsa i realtid. Det omvandlar kommunikationsmönster till signaler om samsyn, beslutstempo och risk, och skapar effektivt ett nytt lager mellan rå aktivitet och insikter för ledningen.

Parallellt bygger jag VowVista, en marknadsplattform inom bröllopslokaler med fokus på att lösa beslutsosäkerheten hos köpare i Gen Z. Den hanterar ett fragmenterat köp med starka känslor genom att kombinera transparens, strukturerade data och vägledda arbetsflöden för att hjälpa användare att gå från utforskning till beslut.

Parallellt med detta fortsätter jag att utveckla AI-baserade plattformar inom bygg och fältverksamhet, där vi samlar in multimodala indata som röst, foto och video från fältet och omvandlar dem till strukturerad, handlingsbar intelligens för operativa roller och ledningsgrupper.

Den gemensamma nämnaren i allt detta är att bygga produkter som fungerar som informationssystem och intelligenssystem, utformade för verkliga arbetsflöden, med en leveransmodell som kombinerar snabba iterationer med tillförlitlighet på produktionsnivå.

Varför produktledare bör fokusera på systemet, inte AI

AI är inte produkten. Det är systemet runt omkring som är produkten.

De flesta team börjar med att fokusera på modellen, funktionen eller förmågan. Men i praktiken är modellen den minst särskiljande och ofta den enklaste delen. Det verkliga arbetet är allt runt omkring: datan, integrationen med arbetsflödet, användarupplevelsen, förtroendemodellen och hur resultatet driver ett faktiskt beslut eller en handling.

Om du misslyckas med det kommer AI att få din produkt att se imponerande ut utan att göra den användbar. Du lanserar funktioner som fungerar bra i demonstrationer men som inte börjar användas, eftersom de inte är inbäddade i hur användarna faktiskt arbetar eller fattar beslut.

Det verkliga arbetet är allt runt omkring AI: datan, integrationen med arbetsflödet, användarupplevelsen, förtroendemodellen och hur resultatet driver ett faktiskt beslut eller en handling. Om du misslyckas med det kommer AI att få din produkt att se imponerande ut utan att göra den användbar.

Adam Root
Adam RootOpens new window

Grundare av Root Ventures

Om du gör det rätt blir AI en förstärkare. Den omvandlar rörig indata till strukturerade insikter, minskar friktionen i verkliga arbetsflöden och skapar hävstång i hela systemet.

Om jag hade vetat det tidigare skulle jag ha undvikit att överinvestera i ”intelligensen” innan jag validerade arbetsflödet. I några fall byggde vi imponerande funktioner som fungerade tekniskt men inte förändrade användarnas beteende, eftersom de inte var inbäddade i hur arbetet faktiskt utfördes. Vi var tvungna att gå tillbaka och utforma om utifrån arbetsflödet, inte modellen.

Hur evidensbaserade system kan förbättra genomförandet

Jag har gått från att bygga funktioner till att bygga evidensbaserade system innan jag skriver kod – genom att använda AI som ett lager för syntes och validering tidigt i processen.

Tidigare gick även starka team relativt snabbt från upptäckt till specifikationer. Den modellen fungerar sämre i en AI-förstärkt värld eftersom kostnaden för att bygga har sjunkit så mycket. Du kan generera och lansera lösningar snabbare än du kan validera om de borde finnas. Det skapar ett nytt slags misslyckande: team skalar upp fel idéer med otrolig hastighet.

Upptäckt behöver nu bli en kontinuerlig, systemdriven funktion, inte en fas. Det innebär att:

  • Samla in verkliga signaler i stor skala, inklusive användarbeteende, supportdata, vinst-förlust-analyser och kvalitativa indata
  • Använda AI för att syntetisera mönster mellan dessa indata, inte bara sammanfatta dem
  • Uttryckligen koppla problem till arbetsflöden och mäta om produkten faktiskt hanterar dem
  • Kontinuerligt omvalidera antaganden när nya data kommer in

Jag kör till exempel strukturerade promptar över flera datakällor för att upptäcka återkommande problem, koppla dem till arbetsflöden och uttryckligen testa om produkten faktiskt löser dem. Den processen ogiltigförklarar ofta de ursprungliga idéerna eller omformar dem betydligt innan de når design- eller utvecklingsfasen.

Resultatet blev en högre kvalitet på övertygelsen. Vi bygger färre saker, men det vi bygger är mycket bättre anpassat till verkliga problem. Det förändrar också hur team arbetar. I stället för att diskutera åsikter reagerar vi på syntetiserad evidens. För mig handlar AI därför mindre om att snabba upp genomförandet och mer om att öka träffsäkerheten i det vi väljer att genomföra.

Hur AI komprimerar hela arbetsflödet från signal till lanserad produkt

Här är ett AI-drivet arbetsflöde från början till slut som jag använder för att gå från råa användarsignaler till en lanserad och validerad produktloop.

Det börjar med signalaggregering. Jag hämtar in kvalitativa data och beteendedata, inklusive intervjuer med par, trådar på Reddit, omdömen om lokaler, avhoppspunkter i tratten och inkommande frågor. I stället för att gå igenom dessa en och en använder jag AI för att syntetisera information från alla källor och identifiera återkommande problem, hur ofta de dyker upp och var användarna fastnar i beslutsprocessen.

Därefter går jag över till problemstrukturering. AI hjälper till att gruppera dessa signaler i tydliga problemformuleringar kopplade till specifika delar av arbetsflödet. Sedan stresstestar jag problemen genom att fråga: ”Är detta vanligt, smärtsamt och möjligt att lösa med produkten?”

Nästa steg är att utforma lösningen. Jag använder AI för att snabbt utforska olika sätt att lösa problemet – inte bara funktioner, utan även förändringar av arbetsflödet. Det viktiga är att snabbt generera flera angreppssätt och sedan begränsa urvalet utifrån vad som bäst passar användarnas beteende.

Sedan går vi vidare till utveckling och instrumentering. Med AI-assisterade utvecklingsverktyg går vi snabbt från koncept till en fungerande version, men med instrumentering inbyggd från början. Vi följer upp om användarna interagerar med det nya arbetsflödet, var de hoppar av och om det förbättrar säkerheten i besluten eller framstegen.

Därefter blir det en lärloop. AI analyserar användningsmönster, kvalitativ feedback och kantfall för att identifiera vad som fungerar och vad som inte gör det. Vi undersöker om förändringen faktiskt ändrade beteendet, inte bara om användarna interagerade med den.

Slutligen leder det tillbaka till iteration eller borttagning. Om arbetsflödet förbättrar resultaten bygger vi ut det. Om det inte gör det förfinar eller tar vi snabbt bort det.

Claude, som är ansluten till mina produktdata och användarsignaler, hanterar större delen av detta arbetsflöde.

Hur AI kan skapa falsk säkerhet

Det bästa resultatet av AI som jag ser är en kraftig ökning av hastigheten till klarhet. AI har komprimerat arbete som tidigare tog dagar till timmar, särskilt inom upptäckt, syntes och tidig produktdefinition. Jag kan gå igenom betydligt fler indata, upptäcka mönster snabbare och stresstesta idéer innan teamet avsätter resurser. Kvalitativt har det lett till bättre inledande inramning, färre svaga idéer som tar sig in i diskussioner om produktplanen och bättre samsyn mellan produkt, design och utveckling.

Det har också förbättrat genomströmningen i själva produktskapandet. Under det senaste året har jag använt AI-assisterade arbetsflöden för att gå från koncept till fungerande produkt dramatiskt snabbare än vad traditionella cykler skulle tillåta. Det omfattar att gå från problemformulering till arkitektur, PRD:er och användbar programvara på en bråkdel av den vanliga tiden. Fördelen är inte bara hastigheten. Det är möjligheten att testa verkliga arbetsflöden tidigare, vilket förbättrar inlärningshastigheten.

Det är dock inte bara bra. AI kan skapa falsk trygghet. Team kan förväxla polerade resultat med produktkvalitet. En prototyp ser övertygande ut, specifikationen låter komplett och alla känner att framsteg görs, även när det underliggande arbetsflödet, förtroendemodellen eller användarbehovet fortfarande är olöst. Jag har också sett AI öka bruset när det används utan en stark produktvision. Det kan generera fler idéer, mer text, fler ärenden och fler artefakter än ett team realistiskt kan utvärdera, vilket faktiskt kan göra prioriteringen sämre.

Adam Root

Adam delar med sig

Det bästa resultatet av AI som jag ser är en kraftigt ökad snabbhet till klarhet. AI har komprimerat arbete som tidigare tog dagar till timmar, särskilt inom upptäckt, syntes och tidig produktdefinition.

Där AI inte räcker till inom produktutveckling

AI har tydligast inte levererat där jag förväntade mig att det skulle skapa språngvisa förbättringar i produktomdöme och varaktig produkteffekt.

Jag trodde först att AI påtagligt skulle förbättra prioritering och kvaliteten på färdplaner genom att göra mönster uppenbara. Det hjälper till att synliggöra mönster, men det löser inte vad som faktiskt är viktigt. Det svåra är fortfarande att tolka avvägningar, förstå andrahandskonsekvenser och fatta beslut om en riktning under osäkerhet. AI ger underlag till den processen, men ersätter den inte. Jag har inte sett det konsekvent leda till bättre produktbeslut på egen hand.

Det har också inte räckt till när det gäller att driva verklig användning. AI-funktioner gör ofta ett mycket starkt intryck i demonstrationer, men det leder inte till återkommande användning om de inte är djupt integrerade i faktiska arbetsflöden. Jag har sett team lansera imponerande AI-funktioner som användare provar en gång men inte återkommer till, eftersom produkten inte förändrade beteendet eller blev en del av hur arbetet utförs.

En annan brist gäller att minska komplexiteten. Jag förväntade mig att AI skulle förenkla hur produkter byggs och drivs, men i många fall introducerar det nya lager, bland annat promptlogik, specialfall, utmaningar med utvärdering och överväganden kring förtroende. I stället för att ta bort arbete flyttar det det till nya områden som fortfarande kräver stark produkt- och ingenjörsdisciplin.

Varför ansvaret måste förbli mänskligt

Jag använder AI flitigt överallt där skala och mönsterigenkänning är viktiga, och jag ser till att människor är involverade överallt där omdöme, risk eller känsla avgör resultatet.

På AI-sidan förlitar jag mig mest på det inom upptäckt och syntes. Jag matar in utskrifter, supportärenden, vinstförlustdata och beteendesignaler för att identifiera återkommande problem, kvantifiera frekvensen och koppla problemen till arbetsflöden. Det är också användbart i tidig prioritering, inte för att fatta beslut utan för att stresstesta antaganden genom att visa avvägningar, andrahandskonsekvenser och alternativa sätt att formulera saker som jag kanske inte hade övervägt. I experiment hjälper AI till att generera hypoteser, ta fram varianter och snabbt analysera resultat, särskilt när man hanterar stora mängder kvalitativ feedback.

På AI-sidan förlitar jag mig mest på det inom upptäckt och syntes. Det är också användbart i tidig prioritering, inte för att fatta beslut utan för att stresstesta antaganden genom att visa avvägningar, andrahandskonsekvenser och alternativa sätt att formulera saker som jag kanske inte hade övervägt.

Adam Root
Adam RootOpens new window

Grundare av Root Ventures

Där jag uttryckligen låter människor ha ansvaret är när det gäller övertygelse och åtagande. Slutliga prioriteringsbeslut, ordningen i färdplanen och vad vi väljer att inte bygga ligger fortfarande hos ledningsgruppen och mig. Detsamma gäller UX-beslut som kräver känsla, förtroende och emotionell kontext. Tekniska avvägningar leds också av människor, eftersom de innefattar långsiktigt systemtänkande, riskbenägenhet och organisatoriska begränsningar som AI inte fullt ut kan internalisera.

Anledningen är enkel: AI är utmärkt på att komprimera information och utvidga lösningsutrymmet, men det bär inte konsekvenserna. Produktledarskap handlar i grunden om att fatta oåterkalleliga eller kostsamma beslut under osäkerhet. Det ansvaret måste förbli mänskligt.

Varför produktledare måste vara uppmärksamma på falskt förtroende i stor skala

Produktledare underskattar ofta risken för falskt förtroende i stor skala.

AI-system är mycket bra på att skapa resultat som känns korrekta, även när de inte är det. Faran är inte ett uppenbart misslyckande. Det är plausibel träffsäkerhet. Något som ser rätt ut, låter självsäkert och är fel på sätt som inte omedelbart går att upptäcka.

I liten skala kanske en användare upptäcker det. I produktskala upprepas samma fel i tusentals interaktioner och formar i det tysta beslut, arbetsflöden och resultat.

Jag har sett detta dyka upp inom områden som dokumenttolkning, rekommendationer och arbetsflödesautomatisering. Systemet fungerar tillräckligt bra för det mesta för att användarna ska börja förlita sig på det, men det är i gränsfallen den verkliga risken finns. Och dessa gränsfall får ofta de allvarligaste konsekvenserna.

Det som gör detta särskilt farligt är att traditionell produktintuition inte fångar upp det. Du ser inte ett tapp eller en krasch. Du ser engagemang. Produkten ”fungerar”. Tills den inte gör det.

Åtgärden är inte bara bättre modeller. Det handlar om att utforma för förtroende och verifiering:

Adam Root

Adam delar med sig

Produktledare underskattar ofta risken med falskt förtroende i stor skala…Det som gör detta särskilt farligt är att traditionell produktintuition inte fångar upp det. Du ser inte ett tapp eller en krasch. Du ser engagemang. Produkten ”fungerar.” Tills den inte gör det.

  • Visa belägg, inte bara svar
  • Synliggöra säkerhet och osäkerhet
  • Skapa tydliga kontrollpunkter där människor deltar i processen
  • Instrumentera för när systemet har fel, inte bara när det används

Risken är att anta att noggrannheten ökar linjärt med användningen. I verkligheten växer risken snabbare än noggrannheten.

Hur AI:s omdöme kan bli svagt

AI har haft störst svårigheter där produkten behöver förstå mänskliga insatser, tvetydighet och kostnaden för att ha fel – inte bara generera ett plausibelt svar.

Ett bra exempel finns inom efterlevnadsinriktade arbetsflöden eller arbetsflöden med högt förtroendekrav. Jag har arbetat med produktkoncept där AI kan extrahera information från dokument, flagga problem och rekommendera nästa steg. På pappret ser det ut som ett perfekt användningsområde för AI. I praktiken är svårigheten att modellen kan ge ett svar som låter mycket säkert samtidigt som den missar viktig kontext, feltolkar en klausul eller inte förstår varför ett undantag är viktigare än ett annat.

Det skapar omedelbart ett förtroendeproblem. Användaren frågar inte: ”Var det här resultatet imponerande?” Hen frågar: ”Kan jag förlita mig på detta utan att skapa risker längre fram?”

Det jag har lärt mig är att AI ofta har svagt omdöme när:

  • Kontexten är ofullständig
  • Konsekvenserna av ett fel är asymmetriska
  • Användaren behöver en förklaring, inte bara ett resultat

Hur AI omstrukturerar team

AI har förändrat formen på mina produktteam från rollbaserade stuprör till mindre, mer integrerade och systemorienterade team.

Tidigare strukturerades team kring tydliga överlämningar: produkt definierar, design formger, utveckling bygger och data analyserar. Den modellen bryter samman när AI komprimerar genomförandet och introducerar sannolikhetsbaserade system som kräver täta återkopplingsloopar.

Nu lutar jag åt färre personer som kan arbeta över olika gränser. Produktchefer förväntas gå djupare in i data, promptdesign och arbetsflödeslogik. Utvecklare står närmare problemet och användarkontexten, inte bara implementeringen. Design handlar mindre om statiska skärmar och mer om interaktionsmönster, förtroende och hur systemet beter sig när det är osäkert eller har fel.

Jag har också sett nya ansvarsområden växa fram snarare än helt nya roller. Till exempel:

  • Ansvara för ”systembeteendet” i alla gränsfall, inte bara den förväntade vägen
  • Definiera trösklar för säkerhet och tillfällen då en människa ska delta i processen
  • Hantera datakvalitet och återkopplingsloopar som centrala produktfrågor

Hur produktledare bör använda AI

Mitt råd är enkelt: Använd inte AI för att gå snabbare. Använd det för att få fler saker rätt.

Just nu fokuserar de flesta team på snabbhet, fler funktioner, snabbare cykler och snabbare resultat. Det är den uppenbara fördelen. Men snabbhet utan tydlighet skalar bara upp misstagen.

Adam Root

Adams råd

Mitt råd är enkelt: Använd inte AI för att gå snabbare. Använd det för att få fler saker rätt…Den verkliga förändringen är denna: att bygga är inte längre begränsningen. Det är omdömet som är det.

Den verkliga förändringen är denna: att bygga är inte längre begränsningen. Det är omdömet som är det.

Så som produktledare handlar din roll mindre om att driva genomförandet och mer om att:

  • Definiera rätt problem
  • Prioritera beslutens ordningsföljd
  • Säkerställa att det som byggs faktiskt förändrar användarnas beteende

Använd AI för att bredda ditt tänkande, syntetisera signaler och stresstesta idéer. Men lägg inte ut de svåra besluten på entreprenad. Det är där värdet finns.

Gör också om hur ditt team arbetar:

  • Se upptäcktsarbetet som kontinuerligt, inte som en fas.
  • Utforma för förtroende, inte bara funktionalitet.
  • Bygg system, inte funktioner.

Och framför allt, stå emot frestelsen att hoppa över det svåra tänkandet.

Följ med

Du kan följa Adam Root på LinkedIn medan han fortsätter att bygga Sotia, VowVista och de andra SaaS-produkterna i sin portfölj.

Fler expertintervjuer kommer på The CPO Club!

Andrew Lumby
By Andrew Lumby