AI kommer inte ersätta Product Managers, men det förändrar hur vi jobbar
Under hösten har jag lagt mer tid än jag hade tänkt på att utforska MCP, RAG-bots och AI-agenter. Inte för att bli expert, utan för att jag är nyfiken på hur de här teknikerna kan hjälpa oss i vardagen som Product Managers. Jag kommer inte att beskriva hur ni använder AI i era produkter utan snarare hur de här teknikerna påverkar sättet vi bygger produkter på och hur vi kan bli snabbare och fatta bättre beslut.
Jag ser mig inte som ett proffs inom området. Men jag har byggt några experiment, läst mig igenom många exempel och presenterat mina tankar för mina kollegor på Seventyone Consulting. I den här artikeln vill jag helt enkelt dela det som hjälpt mig att förstå vad allt detta betyder i praktiken. Förhoppningen är att du ska ta med dig några lärdomar och börja testa själv, det har varit det bästa sättet för mig att lära mig.
För mig har det blivit tydligt att AI inte handlar om att ersätta rollen som Product Manager. Det handlar om hur arbetet runt omkring oss förändras. MCP, RAG och agenter är inte målet i sig utan exempel på vad som blir möjligt när AI flyttar in i vårt dagliga produktarbete.
RAG-bot
Vad är en RAG-bot?
RAG står för Retrieval Augmented Generation och är ett sätt att kombinera sök och AI.
Retrieval – boten hittar relevant information i dina egna källor.
Augmentation – tar den hämtade informationen och lägger den i en ‘prompt’ som AI:n kan använda
Generation – Skapar ett svar baserat på den hämtade informationen, i kombination med modellens resonemang
Enkelt uttryckt är en RAG-boten en smart assistent som försöker svara med stöd i den information du har gett den, i stället för att gissa fritt.
Varför behövs RAG?
I de organisationer jag har varit i så finns det väldigt mycket data för en PM att ta till sig och använda för att lyckas i sitt jobb. Det är inte ovanligt att kundinsikter är utspridda och svårt att få en helhetsbild. De ligger ofta isolerade i olika produktteam, eller i andra delar av organisationen som customer service, sälj osv. Mycket tid går åt till att leta i dessa olika källor för att hitta det man söker, och om man kombinerar datan behöver man lyfta ut den till ett ytterligare ställe för att bearbeta innehållet. Här kommer RAG-boten in som en hjälp för att få något som liknar en egen smart bibliotekarie, där du kan ställa frågor och få svar baserade på sammanhang, inte bara nyckelord.
RAG-bot kan:
Samla ihop tidigare kunskap
Ge konsekventa svar
Hitta rätt dokument, trådar och kommentarer
Sammanfatta med stöd i källor och minska risken att den hittar på
För er i teamet eller produkttriaden så får ni ytterligare ett verktyg som hjälper er att fatta kloka beslut.
MCP (Model Context Protocol)
Vad är MCP?
När jag först hörde talas om MCP tänkte jag att det var ännu en teknisk standard som mest angår utvecklare. Men ganska snabbt insåg jag att det är något som vi PMs måste relatera till och ta med oss in i vårt arbete. MCP är ett gemensamt sätt för AI-appar och agenter att koppla upp sig mot system utanför sin egen träningsdata. Det är ett protokoll som gör att AI kan förstå var information finns, hur den ska hämtas och vad den får göra med den.
Varför behövs MCP?
En AI-modell i sig är ganska begränsad, eftersom den normalt inte har tillgång till data utanför sin träningsdata. Med MCP får vi data från våra interna system, databaser och interna API:er, eller arbeta med realtidsdata som skapas i organisationen.
Det här blir snabbt ett problem när vi vill använda AI i vårt dagliga produktarbete, där information och beslut lever i andra system som Jira, Figma, Slack, Confluence och Miro. När vi vill nyttja AI i vår produktutveckling för att skapa agenter eller AI chatbotar, så behöver vi tillgång till både aktuell data och möjligheten att agera i våra system. Utan MCP behöver varje sådan koppling byggas som en specialintegration, ofta hårdkodad, svår att återanvända och dyr att underhålla.
Vad möjliggör MCP?
Det är här MCP blir riktigt intressant.
Med MCP kan AI:
läsa och skriva i system
utföra riktiga handlingar, inte bara föreslå dem
jobba med samma verktyg som människor gör
agera konsekvent över flera system i samma arbetsflöde
Det gör att AI går från att vara en passiv assistent till att bli en aktiv deltagare i våra arbetsflöden.För mig är det här ett av de största skiftena i hur vi kan använda AI i produktarbete. Precis som RAG-bot ger AI tillgång till rätt information, ger MCP AI tillgång till rätt verktyg.
Vad är då skillnaden mellan MCP och RAG?
Ett sätt som hjälpt mig att tänka är detta:
RAG svarar på frågan, “Vad vet vi?”
MCP svarar på frågan, “Vad kan vi göra?”
RAG handlar om att hämta och använda kunskap medan MCP handlar om att agera på den kunskapen.
Hur kan det se ut i praktiken?
För att ge ett exempel på hur ni i ett team, en area eller vertikal kan jobba med AI i produktutvecklingsprocessen har jag för enkelhetens skull använt mig av Double Diamond och visar hur olika agenter skulle kunna användas i processen.
Agent Problem
Hämtar automatiskt all kundfeedback, adoption-data och insikter om ett flöde från olika system sådant som annars kräver manuella sökningar i Slack, dashboards, researchmappar och tickets.
Agent Ideation
Här kan man tänka sig att det redan finns en mängd befintliga insikter kring problemet man försöker lösa insikter som kan finnas i en annan del av organisationen, eller i ett annat produktområde. Gör man ett nytt insiktsarbete kan man enkelt kombinera det med de gamla insikterna. Agenten sammanställer och generera lösningsidéer eller koncept.
Agent Solution
Kopplar upp sig mot till exempel designsystemet, Figma och datakällor via MCP för att skapa en första version av en komponent eller funktion. Byggd på riktiga komponenter och riktig data.
Agent Measure & Learn
Sammanfattar resultat från tester, experiment eller mätningar och dokumenterar automatiskt lärdomar i rätt system.
Konceptuellt AI-agenter i Double Diamond
Det fina med flödet är inte att det automatiserar hela processen, utan att varje agent kan stötta i ett tydligt avgränsat steg, medan människor fortfarande sätter riktning, prioriterar och fattar beslut. Så avfärda inte AI som något som bara hör hemma i utvecklingsfasen, utan fundera istället på hur kan jag få in detta i mitt arbetet?
Vad betyder det för oss inom produkt?
Här är några lärdomar och insikter som fastnat hos mig:
AI blir ett fjärde perspektiv i produkttriaden (Product–Design–Tech–AI).
Inte så att det blir en ny medlem utan snarare hjälper till att sudda ut gränserna. Designers kan enklare ta steg in i koden och utvecklare kan ta steg in i designen. PM kan stötta över båda kompetenserna. Alla kan hjälpa till att lösa problem.
Produktutvecklingsprocessen
Produktbeslut kan fattas snabbare och med bättre data om du har en RAG-bot som hämtar datan från olika källor.
Discovery kan gå snabbare med hjälp av RAG-bot som sammanfattar stora mängder av data.
Designsystem och komponentbibliotek kan få hjälp av agenter som bygger komponenter baserat på Figma-skisser.
Få en bättre kunskap om hela kunden. Med hjälp av dessa verktyg kan man enklare få en mer heltäckande bild av kunden. Det är vanligt att man som PM har bra koll på sin kund och det problem man ansvarar för inom sitt område. Tänk en AI som kan ge dig insikter om kunden i andra silos, så att du får en mer komplett bild.
När nya teammedlemmar tillkommer tappas ofta information, och det blir svårt att hitta tidigare beslut och insikter. En AI som har tillgång till information över tid skulle vara magisk som ett sätt att enkelt hitta historisk data och förstå varför beslut fattades.
Produkter - Hur kan vi bygga produkter på ett annat sätt?
Produktupplevelser kan bli mer dynamiska och anpassa sig efter användarens beteende. Hur kommer våra digitala produkter att se ut med AI? Jag tänker att vi kan personalisera våra gränssnitt efter kundens behov, där kunden får tillgång till den information som den själv önskar och på vilket sätt den vill.
Kundmötet kan flytta utanför våra egna produkter. Med gemensamma gränssnitt kan publika AI-agenter, som kunden själv väljer, få tillgång till relevant data med kundens godkännande. Det gör det möjligt att möta kunden där den redan är, till exempel genom att be en agent om hjälp med “flytta mitt bolån från bank X till bank Y”.
Produkter som inte bara visar information, utan hjälper användaren att agera. I stället för att visa en lista med data kan en agent föreslå nästa steg, förklara konsekvenser och hjälpa användaren att ta beslut i stunden.
Mindre behov av att förstå hela systemet. En agent kan bli ett lager ovanpå produkten som gör att användaren inte behöver veta var saker finns eller hur processer hänger ihop – utan kan fokusera på sitt jobb.
Verktyg kan prata med varandra via gemensamma gränssnitt i stället för specialintegrationer. Det gör det enklare att bygga produkter som hänger ihop bättre och som kan utvecklas över tid, utan att varje ny koppling blir ett eget projekt.
Mindre statiska flöden, mer dialog. Vissa delar av produkten kanske inte längre är hårdkodade flöden, utan samtal där användaren kan resonera sig fram till rätt handling tillsammans med produkten.
