Hur det skiljer sig att bygga AI-produkter – och varför produktteamen måste utvecklas

Galen Low: Är det verkligen något som skiljer sig så mycket i processen att utveckla en produkt med inbyggd AI-funktionalitet jämfört med andra produkter som kanske bara råkar använda befintlig AI-teknik?

Jyothi Nookula: Ja. När du bygger en AI-infödd produkt hanterar du tre saker som är annorlunda. För det första är AI i grunden oförutsägbar.

Galen Low: Vad är det första du gör som ledare när du märker att ett team kanske inte ligger på samma nivå när det gäller att förstå, använda och till och med acceptera ny teknik som AI?

Jyothi Nookula: Jag delar upp problemet i två separata frågor. Den första är kompetens. Den andra är inställning. Om du behandlar ett inställningsproblem som ett kompetensproblem gör du det bara värre.

Galen Low: Vilka är dina viktigaste saker som en produktchef som är intresserad av att utveckla AI-produkter behöver ha på sitt CV eller i sin portfölj för att sticka ut?

Jyothi Nookula: Det ena är bevis på att ha byggt något med AI, inte bara pratat om det. Det andra är …

Galen Low: Välkomna till podden Digital Project Manager – programmet som hjälper leveransansvariga att arbeta smartare, leverera snabbare och leda bättre i AI-åldern. Jag heter Galen, och varje vecka går vi igenom strategier från verkligheten, nya verktyg, beprövade ramverk och ibland en krigshistoria från projektets frontlinjer. Oavsett om du leder stora omvandlingsprojekt, hanterar AI-arbetsflöden eller bara försöker hålla kaoset under kontroll har du kommit rätt. Nu sätter vi igång.

I dag pratar vi om produktchefens framtid, vad som krävs för att utveckla AI-produkter, hur AI används för att effektivisera produktutvecklings- och lanseringsprocessen och vad teamledare kan göra när deras produktteam har ojämn fördelning av färdigheter och inställningar kring ny teknik som AI.

Med mig i studion i dag är Jyothi Nookula. Jyothi har över 13 års erfarenhet av att driva innovation inom AI-produkter och plattformar på företag som Netflix, Meta, Amazon AWS och Etsy. Hon har också 12 patent inom maskininlärning och har genom utbildningsföretaget Next Gen Product Manager handlett över 1 500 produktchefer i deras övergång till AI-roller.

Jyothi, tack så mycket för att du är med mig i dag.

Jyothi Nookula: Hej allihop. Jag är så glad över att vara här i dag.

Galen Low: Jag är också väldigt glad, och jag har verkligen sett fram emot det här i flera veckor. När du och jag pratade första gången, och jag tittade på din profil, tänkte jag: wow, Jyothi är en kraft att räkna med. Det finns många varumärken och mycket teknik i din profil som man kan avundas.

Jag är dessutom alltid svag för personer som försöker hjälpa nästa generation inom ett hantverk att utvecklas i en alltmer teknisk och numera AI-orienterad värld. När vi pratade tänkte jag därför: wow, vi har så mycket gemensamt. Jag arbetar från projektsidan och du mer från produktsidan. Men jag ser verkligen fram emot att gå igenom hur saker förändras och vad du har lärt dig under din resa genom AI- och maskininlärningsprodukter.

Jag vet att vi förmodligen kommer att hamna på några sidospår som blir både väldigt intressanta och värdefulla, och jag hoppas att vi gör det. Men projektledaren i mig skapade den här färdplanen för oss i dag. Till att börja med ville jag få undan en stor brännande fråga – den obekväma men angelägna frågan som jag tror att alla vill veta svaret på.

Sedan vill jag zooma ut och prata om tre saker. För det första vill jag prata om att identifiera och täppa till kompetensluckor i produktteam. När man arbetar med produkter som använder AI- och maskininlärningsfunktioner vill jag sedan utforska exempel på hur era team har använt AI-verktyg i produktutvecklingsprocessen, oavsett om det gäller research, dataanalys, design, utveckling, användartester eller något helt annat.

Till sist vill jag utforska hur framtiden ser ut för rollen som produktchef. Vad ett CV eller en portfölj behöver innehålla för att man ens ska komma i fråga för roller hos företag som Meta, AWS, Netflix, Etsy och andra tunga, AI-orienterade varumärken.

Jyothi Nookula: Jag älskar det. Jag är intresserad. Det är det hetaste ämnet just nu. Jag älskar det.

Galen Low: Fantastiskt. Låt oss börja med den stora frågan. Min övergripande fråga är: eftersom du har stor erfarenhet av att arbeta med produktteam för att utveckla AI- och maskininlärningsbaserade lösningar för jättar som Meta, Amazon, Etsy och Netflix – är det verkligen något som skiljer sig så mycket i processen att utveckla en produkt med AI-infödd funktionalitet jämfört med andra produkter som bara råkar använda befintlig AI-teknik?

Jyothi Nookula: Det är en bra fråga, eftersom den verkligen går till kärnan av vad som förändras inom produktutveckling just nu. Det ärliga svaret är i grunden ja, men inte på det sätt som många tror. Så här menar jag. När du bygger en AI-infödd produkt hanterar du tre saker som skiljer sig från traditionell programvara eller produkter som bara integrerar AI via ett API.

För det första är AI i grunden oförutsägbar. I traditionell produktutveckling skriver du deterministisk kod: om detta händer, gör då så. Eller: om jag klickar på den här knappen går jag till nästa skärm. Varje gång jag klickar på knappen händer samma sak. Men med AI-infödda produkter arbetar du med sannolikhetsbaserade system, så AI-funktionen kan fungera på olika sätt varje gång den körs.

Det innebär att hela din kvalitetssäkringsprocess, hanteringen av specialfall och dina garantier för tillförlitlighet måste tänkas om helt. Du testar inte bara om något fungerar, utan om det fungerar tillräckligt bra och konsekvent varje gång över en fördelning av möjliga resultat.

Det första som är fundamentalt annorlunda är alltså oförutsägbarheten, skillnaden mellan deterministiskt och sannolikhetsbaserat. Det andra är att vi bygger produkter på mark i rörelse, eftersom de underliggande modellerna utvecklas på sätt som du inte kan eller inte kontrollerar. En ny modell kan till exempel förändra beteendet.

Det behöver inte vara en förändring som bryter något, men beteendet kan ändras lite, kapaciteten kan utökas eller nya typer av fel kan introduceras. Och detta sker över en natt i den takt som utvecklingen har i dag. Till skillnad från traditionella beroenden, där du kan versionshantera förändringar som bryter funktionalitet och dokumentera uppdateringar, förändras dessa modeller snabbare än vi ens hinner med.

Det tredje – och det här är stort – är att dina framgångsmått måste vara annorlunda. Du kan inte längre bara mäta om funktionen kördes framgångsrikt. Nu måste du mäta saker som: var resultatet användbart? Det handlar inte bara om att det kördes, utan om det faktiskt var användbart.

Matchade det användarens avsikt? Frågan som användaren ställde? Och hur definierar du ens vad som är bra för ditt användningsområde? Du behöver mycket tätare återkopplingsloopar med användarna och måste bygga in dessa utvärderingsmekanismer direkt i produktutvecklingen, vilket skiljer sig mycket från traditionell produktutveckling.

Det är alltså de tre sakerna som skiljer sig tydligt för produkter som bara använder befintlig AI, till exempel om jag bara lägger till en ChatGPT-integration. De kan fortfarande fungera som traditionella integrationer. Du har fortfarande framgångsmått och saker att hålla koll på, liksom utvärderingar.

Men där finns åtminstone ett avtal. När du däremot bygger produkten som en AI-infödd produkt från grunden är det helt annorlunda. Det är där dessa tre saker påverkar produktutvecklingen ännu mer.

Galen Low: Det är roligt, för när jag gick in i frågan tänkte jag: jag ska ställa den här frågan och hon kommer förmodligen att säga att det är ungefär samma sak med några mindre skillnader. Men det förändrar verkligen spelplanen.

Jag gillar verkligen det du sa om att mäta avsikt och om själva mätningen. Jag kommer från projektvärlden, där vi har vårt kravdokument. Det är binärt: ja eller nej. Gjorde det det som stod i den funktionella specifikationen? Men sedan finns all denna tvetydighet, dels eftersom det är sannolikhetsbaserat och resultatet inte blir samma varje gång, dels eftersom den underliggande arkitekturen på sätt och vis är en svart låda som utvecklas snabbare än människor kan förstå.

Det är faktiskt väldigt annorlunda jämfört med hur jag tror att de flesta digitala produkter har skapats på senare tid. Men det är logiskt. Här är vad jag tänker på.

Du har över ett decenniums erfarenhet av att arbeta med maskininlärning och AI. Många har bara börjat under de senaste två åren. ChatGPT lyfte på locket till hur AI kan användas, men tekniken har funnits i programvara och digitala produkter länge.

Och eftersom du arbetade med rekommendationer på Netflix tänker jag: det ser så enkelt ut, men det är det förmodligen inte. Algoritmen, maskininlärningen och databearbetningen i bakgrunden handlar inte bara om att allt på Netflix är märkt med en viss taxonomi. Det är inte som relaterade länkar på en webbplats.

Det handlar faktiskt om beteende och avsikt, och det är lätt att göra fel. Det är lätt att nästan aldrig upptäcka hur fel det blev förrän någon skriver ett inlägg: oj, min Netflix förstår aldrig rätt eftersom jag tittade på det här. Nu föreslår den 18 säsonger av Barney.

Jyothi Nookula: Det händer hela tiden med Instagram Reels och TikTok också. Jag kan titta på en enda video där någon åker skidor och sedan översvämmas jag av skidvideor.

Galen Low: Och jag tror att vi tar det för givet. Det vore lätt för människor, inklusive mig själv, att tänka: jag vet inte, det där verkar ganska enkelt. Samma trick, samma färdigheter. Men när man verkligen bryter ner det på det sättet är det inte alls så enkelt.

Jag undrar om vi kan zooma ut lite. Förutom din imponerande bakgrund med att leda digitala produkter för varumärken som Amazon, Meta, Netflix och Etsy är du också grundare av Next Gen Product Manager, som bland annat erbjuder en femveckorskurs för att gå från traditionell produktledning till AI-produktledning.

Att kursen ens finns säger mig att alla traditionella färdigheter inom produktledning inte riktigt räcker längre. Det krävs ett nästa generations- eller mer framåtblickande tankesätt och en ny uppsättning färdigheter. Även om du kanske har kunnat handplocka dina team under karriären är det rimligt att anta att inte alla i teamen har haft exakt samma kompetens och inställning till AI och annan ny teknik.

Vad är det första du gör som ledare när du märker att ett team kanske inte ligger på samma nivå när det gäller att förstå, använda och acceptera ny teknik som AI?

Jyothi Nookula: Det här är en mycket praktisk och verklig utmaning, och något jag har hanterat mycket och ständigt fortsätter att hantera. Jag har varit personalansvarig och lett team av olika storlek, från tre till fem, tio och tolv personer. Kompetensgapet och trygghetsgapet kring AI är det största jag har sett för någon teknik eller förändring under min karriär.

När jag ställs inför det här problemet gör jag först något som jag tycker är viktigt: jag delar upp det i två separata frågor. Den första är kompetens, där människor inte vet hur de ska arbeta effektivt med AI. Den andra är inställning, där människor är skeptiska, motvilliga eller till och med oroliga.

Du måste alltså diagnostisera vilken av dessa två situationer du hanterar. Kanske är det en kombination av båda. Men det är viktigt att känna igen vilket problem du försöker lösa, för om du behandlar ett inställningsproblem som ett kompetensproblem gör du det bara värre.

Vid kompetensluckor är mitt första steg att skapa ett gemensamt sammanhang genom att göra, inte genom att lära sig teoretiskt. Det är samma princip som jag lär ut till mina studenter i min femveckorskurs i AI-produktledning: de lär sig genom att göra, inte bara genom att titta på material.

Jag skickar alltså inte bara människor på utbildning eller ber dem titta på handledningar. I stället bäddar jag omedelbart in AI i våra faktiska arbetsflöden och gör det enkelt att ta med sig resultaten.

Det kan handla om att integrera Claude eller GPT för att skriva sammanfattningar av sprintretrospektiv, sammanställa teman, göra djupgående research eller skapa sammanfattningar av användarundersökningar. Något där människor ser verktyget utföra verkligt arbete åt dem, utan att nödvändigtvis uppleva det som att verktyget ersätter dem.

Efter ett par veckor frågar jag deltagarna på mötet: berätta om något som AI hjälpte dig att göra snabbare, eller berätta om en insikt du inte skulle ha upptäckt utan AI. Dessa gemensamma erfarenheter blir grunden för att bygga kompetens tillsammans.

När det gäller inställningsproblem, alltså motstånd eller rädsla, tycker jag att det bästa är att börja med nyfikenhet och inte evangelism. I mina individuella samtal brukar jag fråga: vad är du egentligen orolig för? Sedan håller jag faktiskt tyst och lyssnar.

Det som kommer fram brukar vara legitimt. De kan säga: jag känner att detta kommer att nedvärdera mitt hantverk. Eller: jag litar inte på resultaten eftersom jag inte kan verifiera dem helt. Eller: jag känner att jag hamnar efter och att allt blir överväldigande.

Det är verkliga farhågor. Jag har lärt mig att man inte kan resonera bort någon ur rädsla. Det man kan göra är att bekräfta den, normalisera den och sedan visa en väg framåt.

För någon som är orolig för att hantverket ska nedvärderas visar jag hur AI kan hantera grundarbetet, medan personen kan fokusera på det nyanserade arbetet som kräver gott omdöme och som det tidigare aldrig fanns tid för. För någon som är orolig för verifiering säger jag: okej, låt oss bygga utvärderingsramverket tillsammans.

Då blir personen expert på kvalitetssäkring av AI. En annan sak som fungerar mycket bra är att snabbt identifiera brobyggarna. I varje team finns människor som är naturligt nyfikna på AI. De experimenterar hela tiden och driver innovation. De är praktiska och får resultat.

Jag ger dessa personer uttryckligt tillstånd att dela med sig av vad som fungerar bra. På ett lågmält sätt kan man till exempel ha korta kunskapsdelningar under dagliga möten. Det skapar lärande mellan kollegor, eftersom människor är mer öppna för att prova när de ser en kollega använda tekniken och få resultat, jämfört med när en ledare uppifrån säger åt dem att göra det.

Den sista punkten kan vara lite kontroversiell: jag etablerar snabbt att AI-kunnighet håller på att bli ett grundläggande krav. Jag är empatisk inför inlärningskurvan och mycket tålmodig med processen, men tydlig med riktningen: det här är inte valfritt.

Precis som vi alla behövde lära oss agila arbetssätt, analys och kanske först design, är detta en del av jobbet nu. Jag har märkt att kombinationen av stort stöd och höga krav faktiskt minskar oron.

De team jag har sett kämpa mest är de där ledarna är otydliga med förväntningarna och samtidigt inte erbjuder verkligt stöd. Då uppstår bitterhet, eftersom människor känner sig hjälplösa.

Målet är inte att få alla till samma nivå omedelbart. Målet är att få alla att röra sig i samma riktning, med psykologisk trygghet och praktiska verktyg.

Galen Low: Jag älskar det. Först och främst gillar jag verkligen uppdelningen mellan kompetens och inställning. Jag är glad att du tog det dit. När du beskrev det tänkte jag att det nästan är en blandning av förändringsledning och teambyggande i realtid.

Vi tenderar att tänka på förändringsledning som något man gör när en stor förändring ska införas. Det blir nästan ett engångsinitiativ. Men det här är förändringsledning i realtid, varje dag, med ett team.

Med stöd, inte bara ett meddelande om att man ska lära sig något på egen hand eftersom man måste. Det bygger den kollektiva kompetensen och inställningen i teamet, eftersom det blir lite plattare och mer gräsrotsdrivet, med större tydlighet. Det är inte grupptryck, utan kollegialt stöd.

Vi delar kunskap och information. Jag gillar också det du sa om legitima farhågor kring AI: att känna att man hamnar efter, att det inte finns tillräckligt med tid och att hantverket nedvärderas. Det finns förmodligen inget bättre sätt att hitta en väg framåt än att se kollegor hantera det och omsätta det i praktiken i vardagen, inte bara prata teoretiskt.

Ni gör det faktiskt tillsammans. Jag älskar det. Jag är själv ett stort fan av att lära genom att göra, så jag är glad att höra att det är en del av hur du undervisar. Tydligheten du nämnde resonerar verkligen med mig. Kraven och förväntningarna är höga, men stödet finns där, och det är tydligheten som för oss framåt.

Frågan om detta bara är en övergående trend som man kan ignorera, eller om det kommer att bli lika normalt som att skriva på tangentbord, är vi redan förbi. Åtminstone organisatoriskt har många av dem du har arbetat med redan fattat beslutet. AI kan inte ignoreras. Så låt oss ta oss dit, men vi måste gå framåt tillsammans.

Jyothi Nookula: Ja.

Galen Low: Du nämnde några saker om små experiment och pilotprojekt för att ge människor praktisk erfarenhet av AI och bygga kompetens och självförtroende. Jag föreställer mig att det finns många sätt att utveckla detta och många områden där AI kan användas i utvecklingen av produkter som själva också är AI-produkter.

Kan du ge några exempel på hur era team har använt AI när de designar och utvecklar produkter?

Jyothi Nookula: Ja. Jag kan ge konkreta exempel från hela produktutvecklingens livscykel.

Galen Low: Underbart.

Jyothi Nookula: Vi kan börja med upptäckt och research. Där använder vi AI för att kraftigt komprimera tiden det tar att skapa insikter. Normalt gör vi mycket användarresearch, kanske 15–20 samtal. I stället för att ägna en vecka åt att identifiera teman matar vi in transkriptionerna i Claude och ber det identifiera mönster, motsägelser och specialfall.

Men nyckeln är att man inte bara tar resultatet rakt av. Vi granskar det fortfarande tillsammans med forskaren, som ifrågasätter och förfinar det. Människan i loopen är mycket viktig.

AI ger ett starkt första utkast på en timme i stället för en vecka. Forskaren kan i stället ägna tiden åt arbetet som kräver gott omdöme: vilka insikter spelar faktiskt roll, vilka utmanar våra antaganden och vad bör vi undersöka härnäst?

Samma sak gäller supportärenden. Om produkten redan finns på marknaden är mängden supportärenden alltid enorm. I stället för att manuellt gå igenom ärendena för att hitta mönster analyserar vi tusentals kundsupportkonversationer för att identifiera problemområden, hur stora de är och hur många de når.

AI synliggör dessa mönster på ett sätt som vi inte hade kunnat göra manuellt, helt enkelt på grund av den stora mängden information som kommer via supportkanalerna. Som produktchef ser du nu användarresearchen och mönstren i supporten, vilket ger dig ett bättre underlag för att avgöra vad som ska prioriteras och vilka funktioner som faktiskt bör prioriteras i färdplanen.

Även inom dokumentation och kommunikation eliminerar AI grovarbetet. Vi har sett människor använda AI för att skriva produktkravsdokument, sammanfatta granskningar och skapa uppdateringar till intressenter.

Det här är saker där AI kan skapa starka första utkast. En av mina produktchefer sa: jag brukade lägga 30 procent av min tid på att skriva dokumentation, och nu lägger jag 30 procent av min tid på att redigera och förfina dokumentationen. Det är mycket mer värdefullt, eftersom jag nu har en bra utgångspunkt att bygga vidare på.

Vi använder också AI för att göra dokumentationen mer tillgänglig. Någon kan fråga: vad bestämde vi om den här omarbetningen av betalningsflödet? Och få ett svar som sammanställts från tre olika Slack-trådar, möten och ett produktkravsdokument. AI hjälper alltså också till att göra dokumentationen mer åtkomlig.

Det gäller hela produktutvecklingslivscykeln: från experiment till dokumentation och även hur vi samarbetar med utvecklingsteamet. Tidigare ägde och skrev produktcheferna produktkravsdokument, och de kommer inte att försvinna. Men en ny komponent tillkommer: prototypen.

Varför bara ge en lista med användarberättelser när man faktiskt kan prova och prototypa? Man kan skapa en enkel produkt–marknadspassning och lämna över prototypen som en idé till utvecklingsteamet.

Ett nytt sätt att arbeta med produktkravsdokument är alltså att dokumentet fångar visionen, utvärderingarna, hur produkten ska fungera, när den ska fungera, vad som är bra och vad som är dåligt. Men man har också en prototyp som visar interaktionen, användbarheten och hur produkten ska föreställas. Vi ser detta över hela produktutvecklingslivscykeln.

Galen Low: Jag gillar att du tog det dit. Jag pratade med några produktpersoner häromveckan och vi diskuterade om produktkravsdokumentet är dött.

En person jag pratade med sa nej, eftersom man fortfarande måste ha tankarna och de måste vara bra. Hon hade byggt en liten app som hjälper en att formulera dessa tankar och grunden för varför produkten passar marknaden, vilka funktioner den ska ha och vad som ska prioriteras.

Sedan kopplar vi det till prototypen. Den måste fortfarande ha visionen. AI kommer inte själv att hitta alla kreativa svar och det räcker inte. Man behöver fortfarande en strategisk vision för vad produkten gör, hur den uppfyller användarnas behov och hur den ska lanseras på marknaden.

Jag gillar tanken på förändringen i någons jobb. Många produktchefer arbetar tungt med dokumentation, vilket också har blivit en superkraft eftersom de nu kan ägna mer tid åt att redigera den. Dokumentationen var redan en del av processen, vilket innebär att AI kan tränas på den.

De som tidigare inte skrev ner något måste däremot börja dokumentera för att kunna dra nytta av detta. Produktchefer ligger alltså på sätt och vis steget före. Jag älskar idén om maskiner som skapar första utkast.

Jag har en fråga: använder teamen bara boten för det första utkastet och går sedan vidare till andra delar av kedjan, eller matar de tillbaka resultaten för att förbättra maskinen så att den skapar allt bättre första utkast genom att få tillbaka de redigerade versionerna?

Jyothi Nookula: Vi kallar det här ett engångsanrop. Många antar att AI fungerar så: man matar in något, får en rapport och kan sedan köra vidare. Det är sällan så. Vanligtvis får man ett starkt första utkast, sedan bearbetar man det, tillför sina egna tankar och ber AI kritisera resonemanget eller identifiera områden som kan förbättras.

Sedan får man dess synpunkter och kan säga: den här delen är rimlig, men den andra håller jag inte med om. Det är som att ha en partner som man kan förfina resultatet tillsammans med tills man känner sig trygg med slutresultatet.

Om du behandlar AI-system som något du ger en instruktion till, får ett svar från i ett enda steg och sedan följer blint, fungerar det sällan. Det jag har sett ge bättre resultat är att arbeta iterativt och förbättra resultatet. Därför brukar vi säga att det är lätt att lära ut hur man gör, men mycket svårt att lära ut gott omdöme. Gott omdöme är fortfarande något som produktchefen måste äga.

Galen Low: Jag gillar det där med gott omdöme. Upplever du att många tänker: nu består 30 procent av mitt jobb inte bara av att redigera dokumentation, utan av att prata med en robot? Produktchefsrollen är ju ganska mänsklig. Man gör användarintervjuer och research och får stora mängder data som man inte har en individuell relation till en människa kring, där AI definitivt kan hjälpa.

Men upplever du att det finns en risk att produktledningen förlorar sin mänsklighet, ur ett inställningsperspektiv? En oro kan vara att man tillbringar större delen av sin tid med att prata med och lära upp en robot, vilket inte är samma sak som att prata med en människa.

Jyothi Nookula: Jag vet inte om det handlar så mycket om att prata med en robot. Som jag sa: om det bara är du och AI-systemet som pratar är det en annan sak.

Men du måste fortfarande övertyga intressenter och prata med utvecklingsteamet. Produktchefer befinner sig i ett nav där de måste koppla samman olika team. På sätt och vis handlar det mer om att ha en hjälpsam assistent att brainstorma med.

Jag har sett mina produktchefer, ledare och kollegor använda AI på det sättet. De pratar med systemet för att brainstorma idéer. Det blir mindre robotlikt och mer ett sätt att komma igång och hitta framåt, med en följeslagare som alltid är tillgänglig.

Galen Low: För att spela djävulens advokat: du har arbetat på platser där någon nästan säkert har frågat dig: Jyothi, varför kan vi inte bara automatisera den här processen?

Varför behöver det finnas en människa i loopen? Kan vi inte bara ta alla supportärenden, köra dem genom en agent, låta den prioritera nya funktioner, utveckla funktionerna och lansera dem utan att någon behöver vara involverad?

Du behöver inte säga om det har hänt eller inte, men du kan göra det. Min fråga är också: hur bemöter du ett teknikförst-perspektiv i stället för ett människoförst- eller användarförst-perspektiv, särskilt på den nivå där du har arbetat? I stora teknikföretag finns det press att säga: kan vi inte bara använda tekniken och sedan bestämma vad vi ska göra med den?

Hur argumenterar du mot det och för behovet av människor i loopen?

Jyothi Nookula: Det här möter jag ofta, både när jag konsulterar sådana företag och när mina studenter säger: det här är situationen jag befinner mig i, hur ska jag arbeta? Det är nästan som en sjukdom just nu där alla vill börja med AI. Till vår fördel eller nackdel tycker jag att vi glömmer användarna och deras problem och börjar med tekniken, vilket är väldigt bakvänt.

Det är svårt att säga emot, eftersom de institutionella incitamenten pekar åt fel håll. Ledningar har läst samma tre artiklar om att AI är existentiell. Investerare frågar efter AI-strategin på varje resultatsamtal. Och ingenjörer är genuint entusiastiska, vilket man ser på hackathonerna.

Pressen att göra något med AI är enorm. Men jag återgår till produktens grundprinciper: börja med användaren och problemet, inte algoritmen. I mina kurser säger jag alltid: användare före algoritmer.

När någon kommer in entusiastisk och säger att det finns en ny AI-förmåga, kanske multimodalitet, röst eller något annat, kan du inte vinna genom att säga nej. I stället omformulerar jag frågan: det där är en mycket intressant teknik. Vilket problem försöker vi lösa med den?

Jag ber dem beskriva problemet, inte på ett fällande sätt, utan genom att gå igenom användarens dag. Var passar detta in? Vad försöker användarna göra i dag? Vilket alternativ finns om detta inte existerar?

Vanligtvis händer en av tre saker. För det första inser de att det är en lösning som letar efter ett problem. Energin försvinner då naturligt eftersom de inte kan formulera ett övertygande användarbehov.

För det andra upptäcker de ett verkligt problem, men AI-teknik är inte den bästa lösningen. Det kanske löses bättre med användarupplevelse, introduktion eller genom att laga en annan trasig process. Det kanske finns en enklare deterministisk teknik som passar bättre och där AI vore överdrivet.

Det tredje är det bästa: de hittar ett verkligt problem där AI faktiskt möjliggör något nytt. Där uppstår verklig innovation.

På Amazon gör vi berömt nog något som kallas att arbeta baklänges, där vi skriver ett pressmeddelande. Jag ber mina produktchefer eller kollegor att skriva ett pressmeddelande för produkten. Där ska de beskriva produktens påverkan och kanske lägga in ett användaromdöme.

Det är svårt att låtsas att något är fantastiskt när man genomför den övningen. Jag har sett att det är mycket användbart för att navigera i dessa samtal.

Ibland kommer beslutet uppifrån, till exempel från teknikchefen, och det är svårt att gå emot en teknikchef. Då har jag lärt mig att omformulera situationen: om vi ska göra detta, låt oss åtminstone göra det på ett användbart sätt. Låt oss hitta och lösa ett verkligt problem i stället för att kämpa mot just det här användningsfallet.

Jag kan då säga: det här är bra, men det finns ett annat problem där det skulle vara ännu mer användbart. Vi har data, ett användningsfall och en tydlig avkastning på investeringen. Jag arbetar igenom förslagen och säger: ja, låt oss använda det, men det här andra problemet är mer akut.

Tidigare i karriären trodde jag att mitt jobb var att skydda produktvisionen från distraktioner. Nu inser jag att mitt jobb är att kanalisera energin – att rikta entusiasmen kring ny teknik mot rätt användning och mot de resultat som faktiskt betyder något.

Problemet är inte entusiasmen, utan hur vi kanaliserar den på ett sätt som hjälper användarna. Gå alltid tillbaka till produktens grundprinciper: tänk på användaren och problemet, i stället för att börja med tekniken. Du skulle inte öppna ett Word-dokument och säga: vad ska jag skriva? Börja skriva och se vad som händer.

Galen Low: Var är Clippy när vi behöver honom? Det där var verkligen en snabbkurs i att navigera i produktpolitik. Jag tycker att ditt perspektiv på rollen är mycket användbart.

Många produktpersoner känner sig som grindvakter och försvarare, som den som ska säga vad som kan gå fel och sätta gränser så att man kan hålla fast vid det man bestämde sig för från början.

Jag gillar verkligen idén om att kanalisera energi, eftersom det kan leda till bra saker. Din tredje punkt var: om vi ändå ska göra det, låt oss åtminstone göra det användbart. Det är ett perspektiv jag inte hör så ofta, men det är uppfriskande. Så fungerar företag ibland. Man får inte alltid välja, och man behöver inte alltid få beslutet skriftligt för att senare kunna säga: vad var det jag sa?

Det kan vara konstruktivt. Energin kan användas till något positivt. Jag kommer från en bakgrund inom människocentrerad design, så jag blir alltid glad när människor för tillbaka samtalet till användaren och användarnyttan.

Det är en användbar omformulering: vilket problem försöker vi lösa? Det blir kollaborativt i stället för defensivt och politiskt. Man resonerar tillsammans för att hitta det bästa resultatet.

Apropå resultat: jag kommer att stjäla idén om pressmeddelandet. Vi arbetar baklänges, men inte i den utsträckningen att vi faktiskt kommer fram till pressmeddelandet. Det är ett fantastiskt sätt att beskriva vad man gjorde, varför man gjorde det och vilken effekt det fick.

Vilket användbart verktyg för att få människor att tänka på resultatet, inte bara på att lansera något. Inte bara ta emot beställningar och slutföra jobbet, utan faktiskt föreställa sig vilket resultat vi driver mot. Vad kommer det att göra för människor? Vad kommer vi att vara stolta över att säga när vi är klara? Det är riktigt bra.

Jyothi Nookula: Jag älskar idén med pressmeddelandet. Jag har alltid använt den, även efter att jag slutade på AWS för många år sedan. Jag fortsätter att använda den i mitt arbete. Den tillför ett särskilt perspektiv.

Galen Low: Jag älskar det. Det är så användbart.

Jag undrar om vi kan avsluta med att prata lite om framtiden. Under samtalet har det blivit tydligt att området produktledning förändras en hel del. Produkterna förändras, verktygen och metoderna förändras och förväntningarna på teknisk förståelse, affärsförståelse och leveransstrategi förändras också.

Vilka är dina tre eller fyra viktigaste saker som en produktchef som vill utveckla AI-produkter behöver ha på sitt CV eller i sin portfölj för att sticka ut?

Jyothi Nookula: Tack för att du ställer den frågan. Det är en mycket praktisk fråga, och ärligt talat har det jag letar efter i ett CV förändrats dramatiskt under de senaste två åren.

Det första som får någon att sticka ut är bevis på att personen har byggt något med AI, inte bara pratat om det. Som rekryterande chef har jag en plats att fylla. Jag letar inte efter forskning, utan vill se att du faktiskt har levererat en AI-infödd funktion eller produkt.

Inte bara att du arbetat i ett team som använde AI eller bidragit till en strategi. Jag vill veta vilket problem du löste med AI-produkten, vad AI faktiskt gjorde, hur du utvärderade resultatet och vilka lärdomar som överraskade dig.

Många har inte levererat AI-produkter och undrar hur de ska kommunicera detta. Mitt råd är att bygga själv. Skapa några sidoprojekt. Det är något jag också lär ut i mina kurser, där deltagarna arbetar praktiskt och bygger en fullständig portfölj.

Jag säger till dem att inte behandla det som projekt. Du ska omvandla det till en produkt. Du avslutar inte arbetet, stänger datorn och går därifrån. Dela produkten med vänner och ditt nätverk, låt dem använda den och be om återkoppling. Förbättra sedan produkten utifrån återkopplingen.

Du kan kanske lägga till en Stripe-integration och ta en avgift på en dollar eller 50 cent. Beloppet spelar ingen roll, men gör den till en produkt som genererar intäkter. Om produkten är tänkt att kunna säljas, omvandla den till något som ligger så nära en verklig produkt som möjligt.

Det skapar mycket större effekt på CV:t än att bara säga att du arbetat med ett AI-projekt. Du måste bygga produkter, på arbetet eller utanför arbetet.

Det andra viktiga är att visa teknisk förståelse. Du behöver inte vara maskininlärningsingenjör och jag kräver inte att du ska kunna koda. Men jag behöver se bevis på att du kan ha trovärdiga samtal med ingenjörer om hur systemen fungerar.

På CV:t kan det till exempel synas genom vilka utvärderingsramverk du har använt, hur du har genomfört större tester och vilka avvägningar du har hanterat – fördröjning kontra kvalitet, kostnad kontra kapacitet eller vilka modelltyper och arkitekturer du har arbetat med.

Språket du använder spelar roll. Om CV:t säger att du har använt AI för att förbättra användarupplevelsen säger det mig ingenting. Om du i stället skriver att ni byggde en RAG-arkitektur för att minska hallucinationer i kundsupportens svar och förbättrade träffsäkerheten från X till Y, vet jag vad du byggde.

Jag brukar testa om du kan förklara för en ingenjör varför vi bör använda teknik A i stället för teknik B för ett visst användningsfall. På samma sätt bör du kunna förklara för en affärsintressent varför det tekniska beslutet spelar roll och hur det påverkar affärsresultaten.

Som produktchef befinner du dig i skärningspunkten mellan dessa områden. Din huvuduppgift är att översätta tekniska möjligheter till affärsresultat och affärsvärde och sedan översätta detta tillbaka till tekniska ramverk. Det är den typen av AI-produktchef som presterar bäst.

Den sista punkten är erfarenhet av att navigera i tvetydighet och snabba iterationer. AI-produkter är annorlunda. Modeller uppdateras och funktioner utvecklas, så du måste vara bekväm med tvetydighet och det bör synas i ditt CV.

Om du till exempel berättar att du har lanserat produkter från noll till ett eller arbetat i miljöer med högt tempo visar det att du har hanterat tvetydighet. Ett experimentellt tankesätt kring snabb prototypframtagning, testning och lärande är också viktigt, även i sidoprojekt som du har omvandlat till produkter.

Det här är några förmågor som kan få sökande att sticka ut. Det jag definitivt inte letar efter är en soppa av modeord. Du behöver inte skriva att du använder maskininlärning för att skapa synergier och optimera saker. Det säger mig ingenting.

Inte heller sex olika certifieringar från Coursera eller att du är passionerad av AI. Det är inte sådant som får någon att sticka ut. Om jag ska nämna ett mönster är det inlärningshastighet.

Hur snabbt kan du röra dig? Hur djupt och tekniskt går du? Förstår du hur systemen fungerar tillsammans? Om du försöker ta dig in i AI-produktledning utan direkt erfarenhet kan du skapa den erfarenheten. Du kan bygga något. Ingen hindrar dig.

Det är okej om ditt arbete inte erbjuder AI-möjligheter. Ingen hindrar dig från att bygga själv. Du kan också skriva om vad du lär dig medan du bygger. Det uppstår många utmaningar när man börjar bygga.

Bidra, skapa fallstudier av AI-produkter du beundrar och gör analyser av dem. Fundera sedan på hur du skulle förbättra dem. Tröskeln för att börja är mycket låg nu. Du behöver inte vara expert för att bygga din idé.

Och i branschen har inte många tio års erfarenhet av AI. Alla försöker förstå detta tillsammans. Det som verkligen skiljer människor åt är om de faktiskt gör arbetet för att förstå eller väntar på tillstånd.

Galen Low: Det var en så bra beskrivning av den där konflikten. Jag är säker på att du hör det hela tiden: jag är produktchef, jag ska väl inte förväntas kunna koda?

Men det finns ett mellanskikt, och jag tycker att du förklarade det väldigt bra. Du kanske inte behöver koda, men du behöver ha språket för att översätta mellan affärs- och användarbehov och tekniska konsekvenser.

Du behöver också ett byggartänk, där du förstår tekniken tillräckligt väl för att veta var friktion kan uppstå och vad som kan gå fel. Det räcker inte att säga att du gjorde det du blev tillsagd på ett stort teknikföretag och därför är en bra rekrytering.

Som rekryterande chef vet du inte om personen kan hantera tvetydighet, förstår användaren eller kan tala språket hos de tvärfunktionella team som personen ska samarbeta med. Du vet bara att personen arbetade för ett stort företag i en viss roll. Personen kan ha följt någon annans ledning utan att våga, lära sig snabbt eller utveckla sitt hantverk.

Jyothi Nookula: Därför säger jag: vänta inte på tillstånd, gör det bara. Tröskeln för att prova är mycket låg nu.

Galen Low: Jyothi, tack så mycket för att du tog dig tid att prata med mig i dag. Det har varit väldigt roligt. Innan jag släpper iväg dig, var kan man läsa mer om dig?

Jyothi Nookula: Du hittar mig på LinkedIn under Jyothi Nookula. Du kan också besöka nextgenproductmanager.com, där du kan läsa mer om kurserna jag erbjuder inom AI-produktledning, agentisk AI och PM Accelerator.

Galen Low: Fantastiskt. Jag lägger också in länkarna i programinformationen för dem som lyssnar och i beskrivningen för dem som tittar. Jyothi, tack igen.

Jyothi Nookula: Tack så mycket. Jag har haft så roligt.

Galen Low: Okej, det var allt för dagens avsnitt av podden Digital Project Manager. Om du uppskattade samtalet, prenumerera där du lyssnar. Om du vill ha ännu fler praktiska insikter, fallstudier och arbetsmetoder kan du gå till thedigitalprojectmanager.com. Tills nästa gång – tack för att du lyssnade.