Hur AI får produktchefer att gå bortom sin roll

Resan till produktledning

Jag har varit produktchef i över 15 år nu. Tidigare i karriären gjorde jag allt annat jag kunde, inklusive design, försäljning, konsultarbete, marknadsföring och till och med programmering på PHP-tiden – usch.

Jag började arbeta med produktledning eftersom jag verkligen tyckte om att växla mellan olika ämnen och ha kontakt med användare, utvecklare, chefer och så vidare. Jag hade också ett ganska gott öga för design och en god känsla för produktkvalitet. Efter mycket efterforskning upptäckte jag att det fanns en roll som passade det väldigt bra – produktledning. Så jag sökte min första PM-roll, och det var så jag hamnade här.

Jag har arbetat inom alla möjliga områden: B2B, B2B2C, detaljhandel och konsumentprogramvara. Jag började undervisa i produktledning på General Assembly för över ett decennium sedan, och därefter lanserade jag självständigt mina egna kurser online via Udemy och senare LinkedIn Learning. I dag har jag sammanlagt över 1,6 miljoner studenter på båda plattformarna. Jag har också talat på många konferenser om produkt- och projektledning, bland annat tillsammans med Google, där jag undervisade i en produktkurs i Kyiv, Ukraina.

För närvarande arbetar jag med Probably.dev, en deterministisk dataagentapp finansierad av a16z. Vi är ett litet team, så jag är inte bara produktchef utan också ingenjör, säljare, designer och så vidare.

Vår app är en inbyggd skrivbordsapp som utför deterministisk datavetenskap på doktorsnivå med stödjande visualiseringar för att direkt besvara alla typer av frågor på naturligt språk, utan att känsliga data lämnar din dator. Du kan tänka på den som en "datapilot". Vi arbetar direkt ovanpå datalagermodeller, till exempel BigQuery, Snowflake och Clickhouse, samt med lokala filer som CSV, JSON och Parquet. Alla svar som vår agent ger kan spåras och återskapas av en människa, så typiska hallucinationer från LLM är inget problem. Det är inte bara ännu en agent som genererar SQL, och vi kan hantera miljarder rader och kolumner samt komplexa scheman med tiotusentals tabeller.

You should also read

• Eisenhower-matrisen: Så prioriterar du uppgifter på ett smart sätt

• Tips för att bygga din Slack-profil

• Så bemästrar du resurshantering i projektledning

Så hjälper AI team att få mer gjort per person

AI har haft stor inverkan på mitt arbete. Tidigare var jag "bara en PM". Det låter kanske dumt eftersom PM:er gör så mycket, men nu kan jag bidra med nästan allt annat också, till exempel inom utveckling och försäljning. Och det hjälper teamet att arbeta snabbare. När AI förändrar projektledningen blir de traditionella rollgränserna mer flytande.

Tidskrävande uppgifter som efterforskning och analys går mycket snabbare, och tidsbesparingarna gör det möjligt att ha betydligt mer direktkontakt och kommunikation med intressenter. Det möjliggör också snabbare beslutsfattande.

En stor del av en PM:s arbete är att se till att alla andra kan utföra sina arbetsuppgifter effektivt, så när jag själv kan göra ännu mer får vi mycket mer gjort per person. Det här människa–AI-hybrida arbetssättet blir allt viktigare för moderna leveransteam.

Varför en djup förståelse av AI gör att produktchefer kan göra nästan vad som helst

Ju mer jag sätter mig in i det, desto mer inser jag hur brant inlärningskurvan faktiskt är för att använda AI/LLM effektivt och ändamålsenligt, samt för den delkompetens som krävs för att få det att passa in i de arbetsflöden som människor omkring dig eller i dina team föredrar. Detta stärker ytterligare min övertygelse om att alla på ett företag måste vara väl insatta inte bara i LLM i allmänhet och i de modeller som finns tillgängliga, utan också i mängden ekosystemverktyg runt dem, som MCP:er, modaliteter som CLI och GUI och, viktigast av allt, transformatorarkitekturen. För den som vill fördjupa sin förståelse kan en genomgång av böcker om AI inom projektledning ge värdefulla insikter i hur man implementerar dessa tekniker effektivt.

Att arbeta bra med AI i dagens enorma hav av AI-sörja, oavsett om det gäller innehåll eller verktyg, är en färdighet som du måste utveckla, och det kan bara göras genom erfarenhet. Du måste kunna förstå hur LLM fungerar och vad de kan eller inte kan göra bra för att få ut det bästa av dem och arbeta optimalt.

Många "banbrytande" SaaS-produkter och verktyg där ute verkar vara bra lösningar – att skapa PRD:er till exempel – men jag har upptäckt att 99 % av allt du behöver göra kan göras själv, billigare, snabbare, mer anpassat och avsevärt bättre. Det vill säga, så länge du förstår ovanstående koncept och har färdigheterna att använda LLM effektivt.

Det är som i de där TV-reklamerna där en person gör något enkelt, och sedan visar de hur "svårt" det är och försöker sälja en hel apparat för att lösa just det där lilla användningsområdet. I stället för att skära en banan i bitar med en kniv som en vanlig människa vill de till exempel sälja en bananformad skärare som skär alla bitar på en gång …

Kniven är en LLM och bananskäraren är en skräpapp för en smal nisch. Lär dig använda den förbaskade kniven. Köp en av god kvalitet, använd den, lär dig den och sluta köpa dumma saker bara för att teknik-Twitter säger att någon slumpmässig SaaS-app precis "gjorde designers överflödiga" eller "dödade programmering".

Det finns i princip ingenting du inte kan göra med en LLM i ett CLI, en webbläsare och då och då ett öppet, uppgiftsoberoende automatiseringsverktyg som n8n.

Spara dina pengar och lär dig bygga saker som återspeglar visdomen från dina samlade erfarenheter i stället för att acceptera resultatet från ett över natten uppdykande SaaS-verktyg.

Den enda gången detta inte skulle gälla är för verktyg med ett enda syfte, som specifikt fokuserar på att lösa problem där transformerbaserad LLM-arkitektur i vanliga frontier-modeller (dvs. inte finjusterade modeller) har inneboende brister. Till exempel storskalig datavetenskap eller matematik.

Så kommer du igång med att lära dig om AI som produktchef

Det bästa med LLM:er är att du kan fråga dem hur du ska lära dig om dem. Om du är en visuell inlärare som jag är YouTube pricken över i:et; där finns massor av bra resurser om AI och LLM:er.

Om jag skulle börja om skulle jag närma mig lärandet så här: Säg till en LLM att du vill lära dig allt inom AI/LLM-området, anpassat efter din nivå av teknisk förståelse. Du kan till och med instruera den att ställa gradvis mer tekniska frågor för att förstå din nuvarande kunskapsnivå inom AI/LLM-området, med början i grunderna. Och när du når en punkt där du inte längre hänger med kan du be den rekommendera ämnen att lära dig, från grunderna i transformerarkitekturen ända till hur en app som ChatGPT fungerar.

Tanken är att få en lista över ämnen att lära sig och sedan söka efter vart och ett av dem på YouTube för att hitta en video som förklarar ämnet.

Här är ett exempel på en prompt:

Agera som min bedömare av min ”startpunkt” inom AI/LLM.

Ställ upp till 12 frågor (en blandning av enkla och tekniska) för att bedöma:

• min allmänna tekniska trygghet (programmering, data, API:er)
• min förståelse för hur LLM:er fungerar (modellmodaliteter som CLI och grafiska användargränssnitt samt token, kontext, hallucinationer osv.)
• min kännedom om moderna mönster för LLM-appar (RAG/inbäddningar, agenter/verktygsanvändning)
• min förmåga att bedöma kvalitet (utvärderingar, verifiering)
• min medvetenhet om risker (integritet, promptinjektion osv.)
• min medvetenhet om AI:s begränsningar (bra respektive dåliga användningsområden för LLM:er, noggrannhet, LLM-resultatens okontrollerbara natur osv.)

När jag har svarat ska du ENDAST skriva ut:

• 5–10 punkter med de YouTube-ämnen som ger störst hävstång och som jag bör lära mig härnäst, ordnade efter prioritet. Varje punkt måste vara en YouTube-sökfras (inte en mening) + en förklaring på 5–10 ord av varför det spelar roll.

Börja med dina frågor nu.

Vilka AI-kunskaper produktchefer bör lära sig först

Enligt min åsikt är det viktigt att förstå var och hur du kan använda LLM:er. Med det menar jag att förstå att de kan finnas i en app, i datorns terminal eller i kod som körs i en automatisering via MCP:er eller API:er.

I andra hand måste du förstå att de är:

1. icke-deterministiska, okontrollerbara och benägna att göra misstag
2. aldrig något man bör förlita sig på för korrekt information, särskilt inte vid kritiska beslut
3. möjliga att automatisera på kreativa sätt för att minska effekterna av de två föregående punkterna, beroende på ditt användningsfall

Det klassiska exemplet jag brukar ge är att aldrig använda en LLM för att skriva en hel uppsats åt dig, men det är helt okej att be den lista några idéer på möjliga riktningar om du har fastnat och inte vet vad du ska skriva härnäst. Med andra ord är LLM:er utmärkta komplement till det mänskliga sinnet, men det är en mörk väg att slå in på när du försöker få dem att göra allt tänkande i stället för det mänskliga sinnet.

Det sista jag vill nämna här är att du, medan du lär dig ovanstående begrepp, måste försöka göra sådant själv. Om du till exempel lär dig hur promptteknik fungerar bör du ställa samma fråga till en LLM på två olika sätt för att se skillnaden i resultatet. Lär dig aldrig utan att samtidigt öva på det du lär dig.

Varför du inte bör automatisera kundinteraktioner med högt värde med AI

När du har lärt dig det du behöver veta kan du göra i stort sett vad som helst. Men det betyder inte att du bör göra det.

För ett företag i ett tidigt skede med en premiumprodukt verkar kundinteraktion och försäljning vara det som är mest lämpat för AI och automatisering. Men i praktiken har jag upptäckt att en mänsklig kontakt är helt nödvändig. Personligen tycker jag att interaktionen med användare eller potentiella kunder är ett stort mervärde för båda sidor, och jag vill inte ens försöka automatisera den.

Som PM skulle du göra dig själv en otjänst om du på något sätt alls tog avstånd från att prata med användare. Ju mer du själv pratar med dem med din egen röst, desto mer information får du och desto mer förtroende skapar du.

Varför det är svårt — men möjligt — för produktchefer att bidra till kod

Så jag är försiktig med vad jag använder AI till, men jag använder det mycket.

Precis före en produktionssättning uppstår till exempel alltid en intensiv period av buggfixar. På ett större företag skulle ingenjörerna och QA-teamet vanligtvis arbeta med den här typen av finjusteringar. Den seniora produktansvariga skulle naturligtvis vara insatt, men skulle också planera nästa steg och strategier för att övervaka lanseringen, samla in användarfeedback, förbereda flera utvecklingscykler i förväg eller samla in mätvärden när funktionen eller produkten har lanserats.

Eftersom jag för närvarande arbetar på ett mindre företag har möjligheten att hjälpa ingenjörerna att få bukt med buggar varit en riktig spelväxlare för mig, och jag har bara kunnat åstadkomma det genom att använda AI/LLM:er.

Jag har alltid varit involverad i QA för produkter och funktioner under min karriär, men jag har sällan kunnat gå ner på djupet och åtgärda en bugg som innebär kodändringar genom hela teknikstacken.

Erfarna personer inom teknik förstår att ingenjörer är mycket noggranna med sina kodbaser och kodstandarder. Så även om du tekniskt sett vet hur du ska åtgärda en viss bugg behöver du också ha sammanhanget kring kodstandarderna och personligheterna i ingenjörsteamet, samt förstå vilka ingenjörer som har arbetat med varje del av koden. Därför är det flera steg från enkelt att åtgärda vissa buggar, även om du vet hur man gör, och de flesta ingenjörer skulle avfärda din pull request för åtgärden.

Tack vare AI har jag dock kunnat bidra till koden genom att skicka ändringar direkt till main och samtidigt hantera de sekundära kulturella faktorerna som är involverade.

Så bygger du en AI-agent som säkert kan bidra till din kodbas

Min första metod var att skapa ett Markdown-dokument med kodstandarder genom att låta en agent-svärm i Claude Code utforska hela kodförvaret under de föregående sex månaderna och ta till sig kodstilen, filen Claude.md i kodförvaret och, framför allt, alla kommentarer i GitHub-differenser, konfliktlösningar, commits och redigeringar av pull requests.

Därefter hade jag ett ganska stabilt dokument med kodstandarder, som jag kompletterade genom att omvandla det till en uppsättning färdigheter och kommandon i Claude Code. Dessa skulle ta all kod som jag genererade för en buggfix och korrigera den enligt de kodstandarder som teamet redan hade implementerat i kodbasen. Sedan skapade jag ytterligare en underagent som använde krokar med GitHub, vilka jag också kunde utlösa manuellt för att granska koden jag hade skrivit samt kommentarerna eller korrigeringarna och sedan införliva allt detta som ett tillägg i dokumentet med kodstandarder.

Så småningom, efter bara några pull requests, kunde koden som jag genererade för en viss korrigering mycket enkelt översättas till den typ av kod vi vill se i kodbasen via ett enkelt Markdown-dokument som i praktiken var en kontinuerligt förbättrad och självlärande stilguide för kod, som utlöstes genom flera cron-jobb och automatiseringar med Claude Code.

Agenten är så bra nu att jag kan slå samman ändringar direkt till main.

Så kan små produktteam öka sin smidighet

Det är ett bra exempel på hur jag går utanför den traditionella PM-rollen. Men att gå utanför traditionella roller kräver bra processer.

Vi har en välunderhållen och taggad backlogg i Linear, och vi har obligatoriska möten på måndags-, onsdags- och fredagsmorgnar. De dagar vi inte har ett synkmöte håller vi oss uppdaterade genom en avstämning i Slack. All annan prioritering och diskussion sker i realtid via Slack.

Det här kanske inte är den bästa lösningen för större företag, men du skulle bli förvånad över hur väl den fungerar för det här användningsområdet och hur smidiga den håller oss. Tidigare använde jag Google Drive, kalkylblad, dokument, presentationer och en miljon andra appar. Nu klarar vi oss som ett litet team med GSuite, Slack, Linear och GitHub.

Lättviktiga PM-metoder är viktiga i det här ständigt föränderliga AI/LLM-området. Något kan hända vilken dag som helst, antingen i form av användarfeedback eller lanseringar från potentiella konkurrenter, och då måste vi snabbt hålla oss uppdaterade och prioritera därefter.

Så tvingar AI produktteam att tänka om kring rutiner

När det gäller rutiner är den största förändringen att det nu verkligen är en cirkulär, aldrig upphörande rutin, snarare än något med stillastående dokument som du hela tiden måste skapa och hänvisa till.

Omfattningen börjar som en väl avgränsad Linear-uppgift med varierande detaljnivå. Sedan använder jag AI för att stresstesta den med avseende på tvetydigheter, gränsfall och olika alternativ för ordningsföljd, och jag förfinar den tills den går att leverera i minsta möjliga del.

För oss i ett litet distansteam sker samordningen främst asynkront — en kort Slack-tråd som avslutas med ett tydligt beslut och nästa åtgärder, medan lättviktiga avstämningar hanteras av Geekbot. Det finns dock fortfarande ett enormt värde i tre eller fyra teammöten i veckan där vi kan spåna tillsammans och bygga laganda.

Valideringen är det område där jag har blivit striktare, inte mindre strikt. LLM:er genererar vanligtvis övertygande skräp om du inte vet hur du ska använda dem korrekt, så varje funktions- eller appändring får ett litet utvärderingsramverk — realistiska indata, förväntade utdata och antagonistiska fall — som AI kan hjälpa till att utforma, men som jag själv granskar och testar.

Genomförandet består sedan helt enkelt av Linear + Claude Code + egen drift av Posthog-analys. Leverera, observera, justera och håll loopen snabb, eftersom teknikmarknaden förändras i en takt som numera verkar vara timvis.

Varför en minimalistisk, AI-fokuserad verktygsstack är bäst

Så här ser min grundläggande PM-stack ut:

• GSuite
• Slack
• Slack-roboten Geekbot (för dagliga avstämningar)
• Linear
• VSCode
• LLM-baserat CLI (Claude Code i vårt fall)

Varför Linear? Det innehåller det allra nödvändigaste. Det är tillräckligt kraftfullt för att uppfylla nästan alla krav som ett projektteam kan ha, men tillräckligt enkelt för att vara lättillgängligt. Det är motsatsen till JIRA. Och framför allt har det enkel integration med GitHub och Slack, där ingenjörer ändå arbetar. Det är enkelt, lättviktigt och innebär minimalt med extra friktion för ingenjörer när de ska hålla reda på uppgifter eller uppdatera dem. Det är också extremt utbyggbart, så du kan göra häftiga saker som att låta din LLM i ditt CLI automatiskt försöka åtgärda ett fel när det rapporteras i en preliminär pull request – innan en människa ens börjar titta på det.

Inget annat behövs. Allt slags arbete som behöver göras utanför detta kan utföras med verktyg med öppen källkod i terminalen.

Coles favoritverktyg med AI för personlig produktivitet

På ett personligt plan, utanför teamet, är jag fullständigt besatt av Raycast för produktivitet. Det är den ultimata snabbåtkomstappen – helt anpassningsbar, extremt lättviktig och en ersättning för den usla appen ”Spotlight” på Mac eller Windows-tangenten i Windows. Du kommer att minska användningen av musen med 75 % för de flesta saker. Du kan integrera nästan vilken app som helst med deras befintliga integrationer eller enkelt skapa egna — be bara Claude Code att skapa ett tillägg åt dig!

Om jag vill få texten från en bild som jag ser till urklippet trycker jag på Raycasts genvägsknappar, skriver ”OCR” och trycker på Enter. Det aktiverar skärmbildsverktyget cleanshotX OCR, och jag har texten från vilken bild som helst på mindre än fem sekunder. På samma sätt kan jag trycka på genvägen, skriva ”Ask spotify” och sedan skriva en mening på naturligt språk, som ”ge mig lite bra kodningsmusik med högt tempo”, vilket tolkar min mening genom en LLM, söker igenom musiktaggar och egenskaper i Spotify API och sedan omedelbart startar en spellista med den typ av musik jag just bad om i Spotify.

Användningsområdena är oändliga. Ladda bara ner det, aktivera AI antingen med dina egna API-nycklar eller via deras prenumeration och gå igenom topptilläggen på deras webbplats för att hitta sådant som du tror skulle vara användbart för dig. En riktig förändring.

Varför produktledning och ingenjörsarbete börjar överlappa

Snart kommer de flesta ingenjörer som arbetar med funktioner att tvingas börja tänka och fatta beslut som produktchefer, och produktchefer kommer att behöva lära sig tillräckligt om maskininlärning, neurala nätverk, LLM:er och olika arkitekturer för att komma så nära de kan att vara ingenjörer som använder LLM:er utan att faktiskt vara ingenjörer. Denna omvandling speglar djärva metoder för AI-integration som omformar traditionella roller.

Det finns uppenbarligen många förbehåll och områden där detta inte gäller, men generellt kommer Venn-diagrammet för alla tidigare roller i ett företag, från försäljning till marknadsföring, produkt och ingenjörsarbete, oundvikligen att närma sig varandra, och mycket få färdigheter kommer att vara exklusiva för en viss roll.

Så undviker du den oundvikliga existentiella krisen när AI omformar produktarbetet

Här är mitt råd: Försök undvika den oundvikliga existentiella kris som du kommer att frestas att hamna i medan denna teknikeran fortsätter att utvecklas.

Fokusera i stället på de färdigheter du har utvecklat genom erfarenhet. LLM:er kan generera innehåll, men de är verkligen usla på att ha gott omdöme.

Svar finns det numera tretton på dussinet, så att ställa unika, erfarenhetsspecifika frågor till AI är numera en färdighet. Dessutom är det verkliga intellektuella arbetet att upptäcka vilken fråga man ska ställa i sitt eget sinne.

Följ med

Du kan följa Cole på X och på hans personliga webbplats, medan han fortsätter att utmana vad som är möjligt för produktchefer. Och kolla in Probably.dev!

Fler expertintervjuer kommer på The Digital Project Manager!