Hannah Clark får sällskap av Noa Goldman—ansvarig produktchef på Dagshub—för att dela med sig av sitt recept för att vinna intressenternas stöd, bygga relationer och stärka teamets resultat.
Höjdpunkter från intervjun
- Noas bakgrund [0:56]
- Hon arbetade som fullstackutvecklare i åtta år och övergick sedan till att bli produktchef. I dag ligger hennes expertis inom utvecklarverktyg.
- Som utvecklare och nu produktchef tänker hon alltid på användaren och köparpersonan.
- Vilka är några av de bästa metoderna som produktchefer bör ha i åtanke för att arbeta effektivt med utvecklingsteamet? [4:51]
- När ni som produktchefer presenterar något som ni vill utveckla för utvecklarna och forsknings- och utvecklingsteamen är det mycket viktigt att förklara ”varför” och koppla det till affärssidan.
- Visa datan. Om ni förklarar ”varför”, affärssidan och hur det kommer att hjälpa företaget att växa behöver ni belägg och stödja det med rätt data.
- Ge beröm – uppmärksamma och uppskatta deras hårda arbete.
- Några av de bästa metoderna för att säkerställa att funktionsutvecklingen fungerar smidigt [8:11]
- De förbättrade introduktionen på ett företag där hon arbetade som produktchef och lyckades öka konverteringsgraden från 15% till 90%.
- Innan ni presenterar den nya funktionen för teamet bör ni se till att motivet är rätt och att det är rätt sak att göra internt just nu.
- Se till att läsa kartan korrekt – lyssna alltid på affärssidan, håll en lista över användarfunktioner och önskemål och visa användarna hur produkten ska användas.
- Se till att siffrorna är rimliga.
- Formulera en eller två meningar om problemet och varför det är viktigt att lösa det omedelbart.
- Dela upp och erövra – innan ni presenterar funktionen för alla ledare i det tvärfunktionella teamet bör ni försöka ha individuella samtal med varje ledare från varje tvärfunktionellt team – så att de känner sig hörda och lyssnade på.
Om du vill få någon med dig behöver de inte lyssna på dig och de behöver inte hålla med. Du behöver bara få dem att känna att de räknas och är viktiga.
Noa Goldman
- Hur Noa hanterar situationer där det inte finns full enighet över hela linjen [16:34]
- Dela upp och erövra – förklara affärssidan och ”varför” – övertyga dem om att vi alla är i samma team.
- Om någon inte är med på tåget väljer hon hur hon ska övertyga personen – till exempel genom att låta personen få andra funktioner.
- Allt handlar om relationer. När du hjälper någon vill de ofta hjälpa dig tillbaka. Det handlar om att navigera genom de förhandlingarna och se till att alla till slut får det de vill ha.
- Noas metoder för att prioritera funktioner [17:50]
- Hennes ledstjärnemått är verksamheten – det handlar inte om vilka funktioner hon tycker om eller vad hennes team vill utveckla – utan om att hjälpa företaget.
- Hon håller ständigt koll på vad användarna efterfrågar och på verksamhetens önskemål, vad marknadsföringen vill ha och vad som händer på hela marknaden.
- För varje funktion frågar hon – ”Är detta det som kommer att hjälpa företaget att växa mest just nu?” Om svaret är ja blir nästa fråga – ”Är detta det enklaste sättet att utveckla funktionen på?”
- När det gäller prioritering väljer hon alltid det som hjälper verksamheten mest, som är enklast att utveckla och som kräver minst arbete.
Mitt arbete är att hjälpa verksamheten och företaget att växa. Det handlar inte om vilka funktioner jag tycker om eller vad mina team vill utveckla just nu. Det handlar om att hjälpa företaget.
Noa Goldman
Möt vår gäst
Produktchef i själ och hjärta. Noas styrka är att skapa produkter särskilt anpassade för ingenjörer och teknikintresserade nördar. Med sin starka tekniska bakgrund som tidigare mjukvaruingenjör brinner hon framför allt för att omvandla komplicerade tekniska problem till intuitiva lösningar och lättanvända produkter som alla kan förstå och använda. Hon är för närvarande ansvarig produktchef på Dagshub, en plattform för datavetenskapliga projekt. Hon älskar att tala inför publik och missar inte en möjlighet att presentera sina produkter inför en publik.

Som produktchefer är det verkligen viktigt att förklara ”varför” och koppla det till affärssidan när ni presenterar något som ni vill utveckla för utvecklarna och R&D-teamen.
Noa Goldman
Resurser från det här avsnittet:
- Prenumerera på nyhetsbrevet från The CPO Club
- Anslut till Noa på LinkedIn
- Besök Dagshub
Relaterade artiklar och poddar:
Läs transkriberingen:
Vi provar att transkribera våra poddavsnitt med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.
Hannah Clark: Låt mig beskriva situationen: du befinner dig i ett mötesrum med alla dina viktigaste intressenter. Till vänster ser du hur kundansvarig direktör avslutar ett mejl. Till höger har utvecklingschefen armarna i kors och granskar din presentation med skepsis. Du är dessutom ganska säker på att den ledande produktdesignern bedömer layouten på dina bilder. På något sätt måste du få alla dessa personer att röra sig i samma riktning. Men innan du kan göra det måste du få dem att lita på dig. Så hur vinner du deras förtroende och får deras stöd?
I dag har jag sällskap av Noa Goldman, ledande produktchef på DagsHub. Noas karriär började inom programvaruutveckling, så hon har erfarenhet från båda sidorna – vilket innebär att hon vet hur svårt det kan vara att vinna gehör i tvärfunktionella team och till slut komma fram till en stark lösning på kundernas problem. Noa delade med sig av sitt recept för att få med sig intressenter, bygga relationer och stärka teamets resultat. Då sätter vi igång.
Tack så mycket för att du är med oss, Noa.
Noa Goldman: Tack. Jag är glad över att vara här. Tack för att ni bjöd in mig.
Hannah Clark: Ja, roligt att ha dig här. Noa, du har en bakgrund inom programvaruutveckling, vilket jag är säker på har varit användbart på många sätt. Jag skulle gärna vilja att du berättar lite om hur det har påverkat ditt sätt att arbeta med produktledning.
Noa Goldman: Absolut. Jag var fullstackutvecklare i åtta år. En del av tiden var under min militärtjänstgöring. En del var på små nystartade företag och stora bolag. Sedan övergick jag till att bli produktchef, och i dag ligger min expertis inom området utvecklarverktyg, där det har hjälpt mig mycket att själv ha varit utvecklare.
Det har förstås påverkat mig mycket. För det första utvecklade det en stark vana att tänka på användaren och även köparprofilen. Jag vet att de flesta produktchefer säger att detta är väldigt viktigt för dem och att de ständigt tänker på användaren och köparprofilen. Men utifrån min erfarenhet gör de ofta inte det.
Eftersom jag har varit utvecklare och nu är produktchef för utvecklarverktyg tänker jag alltid på både användaren och köparprofilen. Om vi till exempel har en ny funktion som vi vill lansera, eller kanske en ny produkt som vi vill introducera, tänker jag alltid på mig själv när jag provar funktionen. Hur skulle jag känna inför den här funktionen?
Hur skulle min kollega känna inför den? Hur skulle vi använda den? Vad mäts vi på? Det här är något som jag tycker är mycket viktigt men som ofta förbises. När man lanserar en specifik funktion vill man alltid tänka på hur användaren mäts, alltså utifrån vad, och om funktionen eller den specifika produkten kommer att hjälpa användaren att förbättra sina resultat eller hjälpa dem med deras mätvärden och med hur ledningen ser på dem i just det användningsfallet.
Det har alltså självklart påverkat min vana att tänka på användarprofilen, men det har också hjälpt mig mycket när det gäller köparprofilen. För jag upplever återigen att köparprofilen ständigt lämnas utanför när man lanserar nya funktioner och produkter.
När vi försöker lansera en ny produkt tänker jag alltid: Okej, vilka personer ingår i inköpsprocessen? Vilka är involverade? Vem ska fatta beslutet? Jag tänker till exempel på mig själv. Som utvecklare skulle jag gå till min teamledare med en ny funktion eller produkt och säga: Hej, det här är bra.
Och teamledarna skulle säga: På vilket sätt hjälper det oss, eller varför ska vi betala det här specifika företaget? Därför försöker jag alltid tänka på även de här profilerna. Det här är en mycket stor del av att vara produktchef, men min bakgrund som utvecklare har verkligen hjälpt mig. Jag tror också att den har påverkat mig mycket när det gäller prioriteringar.
För varje ny funktion behöver jag inte alltid gå och fråga teamledaren. Jag tycker att det här är en process som kan vara lite svår för teamledare eller utvecklingschefer när produktchefen hela tiden frågar hur lång tid något kommer att ta eller vilka insatser som krävs. Jag tycker därför att det är något jag till stor del kan göra på egen hand, till en viss gräns.
Det har hjälpt mig och påverkat mig mycket. Men jag tror att det viktigaste jag tog med mig från att vara utvecklare är relationerna till de andra utvecklarna. Jag vet hur jag kände inför produktchefen som utvecklare, och jag vet hur mina kollegor kände inför dem. Det är inte alltid trevligt och roligt, och de håller inte alltid med produktchefen.
Det jag tog med mig från det är att jag vill att utvecklarna jag arbetar med ska känna sig bra med mig och vilja hjälpa mig. Jag vet hur viktig relationen är, och jag vet – eller åtminstone tror jag att jag vet – hur man vinner deras förtroende. Därför vet jag hur jag ska välja vad som är värt att kämpa för, vad som är viktigare och vad som är mindre viktigt. Jag tror att insikten om att det här förtroendet är viktigt hjälpte mig mycket, eftersom jag själv först var utvecklare.
Hannah Clark: Jag skulle vilja höra lite mer om det. Om en produktchef som lyssnar försöker samarbeta så bra som möjligt med sitt utvecklingsteam – utan förbittring och spänningar – vilka är några av de bästa metoderna som produktchefer bör ha i åtanke för att arbeta effektivt med utvecklingsteamet?
Noa Goldman: Ja, okej. Det uppstår förstås många konflikter ibland, och det kan bli frustrerande för båda sidor. Eftersom jag har varit på båda sidorna känner jag igen det väl. Jag tror att en av de viktigaste sakerna är att alltid förklara varför – att förklara och koppla det till verksamhetssidan.
Vi produktchefer befinner oss mitt i allting och pratar hela tiden. Vi samarbetar ständigt med marknadsföringsteamet, säljteamet eller den högre ledningen. Det gör utvecklare inte lika ofta. När man presenterar något man vill utveckla för utvecklarna och utvecklingsteamen är det väldigt tydligt för en själv som produktchef vad man vill ha, varför man vill ha det och hur det är tänkt att hjälpa företaget.
Men utvecklarna som hör det för första gången kommer inte nödvändigtvis att kunna koppla ihop alla delar. Därför är det mycket viktigt att förklara varför och koppla det till verksamheten. Jag vet att jag själv inte alltid skulle hålla med om någon kom och bad mig göra något, eftersom jag kanske inte förstår varför. Men om någon förklarar varför, vad anledningen är och hur det ska hjälpa företaget, är det mycket mer sannolikt att jag ställer mig bakom det, eller åtminstone är öppen för ett samtal. Jag tycker att det här är mycket viktigt. Som produktchefer är det mesta av vårt arbete beroende av andra.
Vi gör sällan själva något som innebär att utveckla en funktion eller sköta marknadsföringen. Vi måste alltid förklara för andra vad vi vill göra. Därför är det mycket viktigt att förklara varför och koppla ihop delarna utifrån verksamhetsperspektivet. Jag tycker också att det är mycket viktigt att visa data. Om du förklarar varför, förklarar verksamhetsnyttan och hur det ska hjälpa företaget att växa, behöver du bevis – du måste styrka det med rätt data.
Jag är säker på att alla, eller de flesta produktchefer, skulle säga att de är datadrivna. Men i just sådana här situationer, när du visar något för utvecklingsteamet, är det särskilt viktigt att vara datadriven. Du vill att de ska lita på dig, du vill vinna deras förtroende och du vill få dem med dig. Det här är ytterligare en mycket viktig sak.
En annan sak jag har lärt mig med tiden är – det låter kanske konstigt – att helt enkelt ge beröm. Som jag sa tidigare beror mycket av vårt arbete på andra. När någon, till exempel en utvecklare, ställer sig bakom arbetet och gör det hårda jobbet med att utveckla en funktion, är det mycket viktigt att uppmärksamma och uppskatta det samt ge beröm och säga ”Bra jobbat” eller ”Väl gjort”, både enskilt och i ett större forum så att alla får veta det.
Personligen vill jag göra ett bra jobb när någon uppskattar det jag gör. Jag vill fortsätta och hjälpa till. Så jag skulle säga att det är de sakerna som hjälper mig mest i samarbetet med utvecklingsteamet.
Hannah Clark: Ja, jag tycker att det där med beröm är så viktigt i nästan alla roller. Det är en av de enkla sakerna som människor verkar glömma, trots att det gör så stor skillnad i alla typer av tvärfunktionellt samarbete.
På det temat: när du tänker på samarbete med tvärfunktionella team utöver själva utvecklingsteamet, vilka är några av de bästa metoderna du har upptäckt för att se till att utvecklingen av funktionen fungerar smidigt och att alla är på samma sida, oavsett vilket kompetensområde de tillhör?
Noa Goldman: Jag minns en specifik funktion som verkligen hjälpte mig att skapa mitt eget recept för hur man hanterar långsiktiga funktioner som kräver mycket arbete och tid. Det var en särskild funktion. Vi förbättrade introduktionen på ett företag där jag arbetade som produktchef, och vi lyckades faktiskt öka konverteringsgraden från 15 % till 90 %.
Det var fantastiskt, men resan var mycket lång. Jag var en junior produktchef, så det var verkligen tufft för mig att arbeta med tvärfunktionella team och samarbeta med marknadsföring, försäljning och den högsta ledningen. Men det var där jag skapade min egen handbok för hur man gör. Det första steget, innan man presenterar den nya funktionen för teamet, är att se till att motivet är rätt och att det internt verkligen är rätt sak att göra just nu.
Innan jag presenterar något för andra vill jag själv känna mig säker och se till att jag gör rätt sak. Oavsett hur arbetskrävande funktionen är försöker jag alltid säkerställa att jag har läst kartan rätt – vilket innebär att alltid lyssna på verksamhetens behov och önskemål, föra en lista över användarnas funktionsönskemål och se hur användarna använder produkten.
Jag försöker alltid se till att jag har en karta över hur saker ser ut just nu, vad som är viktigt för företaget och vad som inte är det. När en stor funktion kommer in är det första jag gör att själv försäkra mig om att det är rätt sak. Jag jämför den med kartan jag har och kontrollerar: Okej, är det här det som är mest meningsfullt att göra nu? Jag är bekväm med det här, och det är det här vi ska göra.
Jag ser alltså till att jag själv står bakom beslutet. När jag har gjort det dubbelkontrollerar jag med hjälp av data. Jag säkerställer att siffrorna är rimliga. Jag städar upp dem ordentligt, går igenom dem och ser till att siffrorna är logiska och att genomförandet av den här långsiktiga funktionen kommer att öka det vi vill uppnå.
Jag ser också till att det inte bara är jag som har förälskat mig i en specifik funktion. Datan övertygar faktiskt mig om att det här är rätt sak att göra. När jag själv är helt övertygad om att det är rätt sak att göra hittar jag ett mycket tydligt sätt att presentera det. Det innebär att jag försöker formulera en eller två meningar om problemet och varför det är viktigt att lösa det direkt.
De meningarna ska kunna förklara det både för den mest tekniska och den minst tekniska personen i rummet. Eftersom det är ett tvärfunktionellt teamarbete vill jag att försäljning, marknadsföring, den högsta ledningen och utvecklingsteamets teamledare tydligt ska förstå: det här är problemet, och så här kommer det att hjälpa verksamheten att förbättras när vi löser det.
Jag ser till att presentera det så tydligt att en fyraåring skulle förstå, och sedan tar jag den data som jag redan har städat upp och presenterar den mycket tydligt. Det låter kanske konstigt, men man måste alltid säkerställa att datan är väldefinierad och väl presenterad. Grönt är till exempel bra. Rött är dåligt. Använd rätt diagram.
Det här är sådant som låter trivialt, men som ofta inte presenteras på rätt sätt. Jag ser till att problemet och datan som styrker det presenteras på ett mycket bra och tydligt sätt, så att alla i rummet förstår. Det är det andra steget. Det tredje steget låter kanske konstigt, men i min bok kallar jag det ”Dela upp och erövra”. Det kan låta lite negativt, men det är det inte alls.
Det betyder helt enkelt att jag, innan jag presenterar funktionen för hela rummet och alla ledare i det tvärfunktionella teamet, försöker ha enskilda samtal med varje ledare från varje tvärfunktionellt team. Det tar mycket längre tid, men det är värt det. Jag sitter enskilt med marknadschefen, försäljningschefen, utvecklingschefen och alla andra som är involverade i processen och som jag behöver övertyga om att ställa sig bakom den.
På det sättet får jag först och främst dem att känna sig hörda och lyssnade på. Som jag sa tidigare: om du vill få någon med dig behöver de inte lyssna på dig och de behöver inte hålla med. De har annat i tankarna. Om du vill få dem med dig måste du få dem att känna att de räknas och är viktiga.
Att sitta med dem enskilt och ha ett kort eller långt samtal, eller vad som än behövs, är värt det även om det tar lite längre tid. Det hjälper dem att känna sig hörda, och när de känner sig hörda vill de hjälpa dig. Den andra saken det gör är att det verkligen förbereder mig för nästa steg, som är mötet med alla i samma rum.
Jag vet redan hur alla känner. Jag är förberedd på deras frågor och vet hur jag ska svara på det de kommer att säga om funktionen. Slutligen hjälper de enskilda samtalen dig eftersom andra ofta har riktigt bra idéer som du vill integrera i funktionen.
Det får dem självklart att känna sig mer delaktiga eftersom deras idéer räknas, men de kan också ha bra idéer som du vill höra. Genom att ha de här enskilda samtalen kan du faktiskt skapa en bättre funktion som de flesta i teamet vill vara med och utveckla. Det här är alltså ett steg: att ha ett enskilt samtal med var och en.
Utifrån min erfarenhet kommer de flesta involverade redan att stå bakom arbetet vid det här laget, eftersom de känner sig delaktiga i processen och hörda. Nästa steg blir ett teammöte där alla samlas i samma rum. Det är lite tufft.
Det gör en lite nervös, men vid det här laget ska du vara förberedd eftersom du har haft alla dessa enskilda samtal. Du samlar alla i samma rum och presenterar sedan helt enkelt samma sak som du presenterade individuellt. Du har de där en eller två meningarna som beskriver problemet på ett mycket enkelt sätt, du har datan och du har redan pratat med alla i rummet.
Så du gör det igen och presenterar det på nytt. Vid det här laget kommer de flesta att stå bakom arbetet, eller åtminstone vara öppna för en diskussion. Det du vill uppnå i mötet är först och främst att se till att alla blir hörda i samma forum, i ett större sammanhang, och att få med dig de flesta.
Du kommer aldrig, eller nästan aldrig, att få med dig alla i rummet. Men när alla känner att de har blivit hörda är de åtminstone öppna för idén. Vid det här steget bör de flesta stå bakom den. Det här är alltså det sista steget för att få alla med sig. Stegen därefter kallar jag helt enkelt för att ”ta scenen”.
När alla är positiva till eller arbetar med att utveckla funktionen och processen redan går framåt måste du se till att ständigt uppdatera alla. Ta scenen, oavsett om det sker varje vecka eller varje månad, eller använd ett befintligt avstämningsmöte och ägna några minuter åt att uppdatera alla. Jag tycker om att alltid visa de visuella förändringarna.
Jag gillar att dela upp en stor funktion i mindre, snabba vinster. Då kan vi visuellt se förändringarna och framstegen. Genom att uppdatera alla håller du engagemanget vid liv. De vill höra om arbetet, de ser att vi gör framsteg och det hjälper verkligen. Det är också ett bra tillfälle att visa data om funktionen redan har lanserats, och att visa både framgångar och misslyckanden.
Se bara till att vara mycket tydlig och ärlig kring processen, så kommer alla att vara med. Det är också ett utmärkt tillfälle att återigen höra deras tankar och idéer och vad de tycker om de framsteg vi redan har gjort. Att göra detta under hela utvecklingen av funktionen är i princip det som ska hjälpa alla tvärfunktionella team att hela tiden stå bakom arbetet och vilja hjälpa till.
Hannah Clark: Det är en fantastisk process. Jag tycker också att den är mycket tydlig att följa. Men jag är nyfiken på vad som händer och hur du agerar när rummet är mer splittrat, när det inte finns full enighet eller när det inte finns tillräckligt mycket samsyn för att en funktion ska kunna gå vidare. Hur hanterar du något sådant?
Noa Goldman: Om jag är säker på att det här är rätt sak att göra och att det är meningsfullt för företaget försöker jag alltid tänka på att vi i slutändan är ett och samma team och att vi alla vill att företaget ska lyckas. Jag försöker återigen dela upp och erövra, förklara verksamheten och varför, och övertyga dem om att vi alla tillhör samma team.
Till slut fungerar det. Om det fortfarande inte fungerar försöker jag välja mina strider. Om någon till exempel inte står bakom arbetet försöker jag välja hur jag ska övertyga personen – kanske genom att låta dem få igenom andra funktioner eller hjälpa dem att driva sin agenda på ett visst sätt.
För mig handlar allt återigen om relationer. När du hjälper någon vill de ofta hjälpa dig tillbaka. Det handlar alltså om att navigera genom de här förhandlingarna och se till att alla till slut får det de vill.
Hannah Clark: Ja, det låter rimligt. Om vi byter fokus lite till prioritering – som jag alltid säger är funktionsprioritering en stor del av att hantera och utveckla funktioner. Vilka är dina framgångsrecept eller några av de metoder du använder för att prioritera funktioner?
Noa Goldman: Jag har mitt eget ledstjärnemått, och det är verksamheten. Vad företaget än behöver för att växa är mitt ledstjärnemått. Det är det jag jämför allt med. I slutändan är mitt arbete att hjälpa verksamheten och företaget att växa.
Det handlar inte om vilka funktioner jag tycker om eller vad mina team vill utveckla just nu. Det handlar om att hjälpa företaget. Jag beskrev kartan som jag alltid har. Jag håller ständigt koll på vad användarna efterfrågar, verksamhetens önskemål, vad marknadsföringen vill ha och hela marknaden.
Jag försöker tänka på verksamheten. För varje funktion frågar jag: Okej, är det här det som kommer att hjälpa företaget att växa mest just nu? Om det verkar rimligt och svaret är ja ställer jag nästa fråga: Är det här det enklaste sättet att utveckla funktionen på?
När det gäller prioritering väljer jag alltid det som hjälper verksamheten mest, som är enklast att utveckla och som kräver minst arbete. Det är de två frågorna jag ställer mig. Om du kan besvara dem kan du prioritera allting.
Hannah Clark: Vi börjar få slut på tiden, men jag ville avsluta med något lite roligare. Jag har börjat fråga några av våra gäster om musik, vilket kommer lite från vänster. Oavsett om du lyssnar på musik på jobbet eller utanför jobbet: finns det någon artist, något album eller någon musikgenre som du verkligen gillar just nu?
Noa Goldman: Wow. Det var en väldigt rolig fråga. Jag är så glad att du ställde den. Jag vet inte ens varför jag blir så glad. Jag lyssnar definitivt på musik hela tiden. Jag försöker göra det när jag arbetar med saker som inte kräver så mycket tänkande, för annars blir jag förvirrad. Den artist jag främst lyssnar på just nu är Paulo Nutini.
Jag vet inte om du har hört talas om honom, men han är fantastisk. Han släppte precis ett nytt album som jag älskar, och min dröm är att se honom spela på en konsert. Det kommer förmodligen inte att hända, men jag ska arbeta på det, så vi får se.
Hannah Clark: Vad roligt. Jag har inte hört talas om honom, men jag hoppas att vi kan sätta ihop en spellista för produktchefspodden med musik från alla våra gäster.
Noa Goldman: Det skulle jag gärna vilja.
Hannah Clark: Ja, jag ska gärna kolla upp honom. Tack så mycket för att du var med oss i dag, Noa. Jag uppskattar verkligen din tid, och jag älskar att du gav oss ett recept som är ett så bra och lättföljt format för att få konkret kunskap. Jag uppskattar verkligen att du tog dig tid.
Noa Goldman: Tack. Jag tyckte verkligen mycket om det. Tack så mycket.
Hannah Clark: Tack för att ni lyssnade. För fler bra insikter, guider och verktygsrecensioner kan du prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Du kan höra fler samtal som detta genom att prenumerera på Produktchefspodden där du brukar lyssna på poddar.
