Hoe je als productmanager succesvol bent in een featurefabriek (met Aakash Gupta, The Product Growth Guy)

Lees het transcript:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot heeft niet altijd 100% gelijk.

Hannah Clark: Featurefabriek: zelfstandig naamwoord. Definitie: een softwarebedrijf dat zich richt op het voortdurend bouwen en uitbrengen van nieuwe functies, in plaats van op het bouwen van een product dat gebruikers daadwerkelijk willen. Gebruikt in een zin: “Ik dacht dat ik was aangenomen om het productteam in een gedurfde nieuwe richting te leiden, maar in plaats daarvan werk ik gewoon door in een featurefabriek.”

Zeg eens, zou jouw foto naast die woordenboekdefinitie staan? Die van jou en die van duizenden andere productmanagers, mijn vriend. Dus als dit nu eenmaal de manier is waarop het gaat, wat kun je er dan aan doen?

Mijn gast vandaag is Aakash Gupta, die de iconische Product Growth-nieuwsbrief schrijft. Voordat hij zich fulltime op de nieuwsbrief richtte, werkte Aakash de afgelopen twaalf jaar in senior- en directiefuncties binnen product bij bedrijven als Epic Games, Affirm en Apollo. Dat betekent dat hij vrijwel elk niveau van invloed heeft ervaren dat een productmanager kan hebben.

En zoals je je kunt voorstellen, is Aakash maar al te vertrouwd met de omstandigheden die featurefabrieken creëren. Zijn aanpak voor het werken als productmanager in zulke organisaties is zowel uiterst praktisch als verfrissend realistisch. Dit is een aflevering waar je van begin tot eind goed naar wilt luisteren, dus laten we erin duiken.

Welkom terug bij The CPO Club Podcast.

Aakash, heel erg bedankt dat je vandaag tijd voor ons hebt gemaakt.

Aakash Gupta: Absoluut. Fijn om hier te zijn. En bedankt voor de uitnodiging.

Hannah Clark: Graag gedaan. Kun je ons iets vertellen over je carrière en hoe je bent gekomen waar je nu bent?

Aakash Gupta: Toen ik rond 2008 begon in productmanagement, had ik het gevoel dat het vakgebied nog niet zo ontwikkeld was. Volgens mij werd INSPIRED ongeveer in die periode gepubliceerd. Ik denk dat dat echt veel heeft geholpen. Daarvoor was er misschien een artikel van Ben Horowitz, zoals good product manager, bad product manager. Maar afgezien daarvan was het vakgebied nog niet echt geprofessionaliseerd. Het bestond vooral bij bedrijven en startups in Silicon Valley.

Ik maakte ermee kennis omdat de oprichters van de startup waar ik werkte trouwe volgers waren van alles wat met Y Combinator te maken had. En veel Y Combinator-bedrijven hadden in die tijd productmanagers. Dus hoewel het bedrijf bij mijn komst uit slechts zes mensen bestond, werd ik aangenomen als productmanager. Gelukkig had ik een technische achtergrond: ik had veel apps gecodeerd en programma’s geschreven, en ik had ook wat geëxperimenteerd met Photoshop.

Toen ik begon, sprong ik dus overal bij. Ik ontwierp onze website volledig, ontwierp en herontwierp grote delen van onze app, hoewel mijn ontwerpvaardigheden zeer beperkt waren. Voor onze website beheerde ik ook ons CMS en alle technologie erachter. Als productmanager in een vroeg stadium sprong ik overal bij terwijl ik uitzocht wat productmanagement inhield en het vak leerde kennen. Maar het was echt de stijl van een startup.

Daarna ging ik aan mijn eigen startup werken, Rap to Beats. In feite deed ik daar precies hetzelfde, maar dan met meer programmeerwerk. Ik bouwde veel meer versies van de app. Ik had dus echt een achtergrond als bouwer voordat ik productmanagement inging. Daarna ging ik echt aan de slag in productmanagement bij een bedrijf met de naam thredUP, dat nu beursgenoteerd is.

Ik kwam binnen toen het bedrijf in serie C zat en vertrok tijdens serie E. Samen bouwden we daar veel van de eerste groeiteams op. In 2014 was het verwijzingsprogramma van Uber bijvoorbeeld het grote onderwerp. Ik herinner me dat ons verwijzingsprogramma bij de lancering een enorme groeimotor was. Je kon gewoon zulke eenvoudige dingen doen.

Het was niet eens geoptimaliseerd. Ik begon producten uit te brengen en realiseerde me dat we als productmanager de groeicurve van bedrijven fundamenteel konden veranderen. Toen besloot ik me echt volledig aan het vak productmanagement te wijden. Sindsdien ben ik productmanager geweest bij onder andere Google, Affirm en Epic Games, en meest recent bij Apollo.io, waar ik vicepresident Product was. Nu werk ik fulltime aan de nieuwsbrief.

Hannah Clark: Geweldig. En ik weet dat zoveel mensen er enorm van genieten.

Vandaag richten we ons op featurefabrieken en specifiek op hoe productmanagers kunnen overleven in zo’n featurefabriekorganisatie. Dat is inmiddels bijna een scheldwoord in de sector.

Laten we bij het begin beginnen. Hoe veranderen organisaties in featurefabrieken en waarom komt dit zo vaak voor?

Aakash Gupta: Ik denk eigenlijk dat alle wegen naar de featurefabriek leiden. Stel dat je in een omgeving werkt waarin teams klassiek veel autonomie hebben. Wat er de afgelopen vier à vijf jaar is gebeurd, is een van een paar dingen.

Ofwel heeft de oprichter, zoals bij Airbnb, de controle weer overgenomen en gezegd: dit zijn enkele dingen die ik gebouwd wil hebben. Of productleiders hebben de controle overgenomen door veel ontslagen en reorganisaties door te voeren. Wat ze vaak doen, is voortdurende reorganisaties gebruiken om mensen in bepaalde posities te krijgen en de werkproducten en functies te laten bouwen die zij willen.

Uiteindelijk zeggen CEO’s of productleiders, onder druk van de recente omstandigheden: we kunnen niet zomaar volledige autonomie geven. We kunnen dit niet zomaar overdragen. Soms zie ik productmanagers van 26 jaar oud met vier jaar werkervaring.

We kunnen beslissingen over ons product en ons bedrijf van één miljard dollar niet zomaar aan hen overlaten. Daardoor bepalen productmanagers zelfs in traditioneel autonome omgevingen, tot aan Google en Netflix toe, niet plotseling honderd procent van de routekaart.

Vaak bestaan er parallel een bottom-up- en een top-downproces dat onzichtbaar blijft. In het bottom-upproces komt de productmanager met ideeën en dient die in voor de planning. Maar als je kijkt naar de uiteindelijke uitkomst, bestaat veel daarvan uit zaken die leidinggevenden moesten goedkeuren, waar ze van overtuigd moesten worden of die ze zelf hadden bedacht.

Daarom denk ik dat veel mensen in een autonome omgeving een façade optrekken rond OKR’s en kwartaalplanning, terwijl het eindresultaat uiteindelijk toch een featurefabriek is. Misschien is in eerste instantie slechts een kwart van de bedrijven echt autonoom, waarna ze afglijden naar een featurefabriek.

Bij de overige 75 procent van de bedrijven zit ongeveer 30 procent in een verandertraject. Die bedrijven begrijpen dat ze naar agile moeten overstappen en dat ze productmanagers meer autonomie moeten geven. Maar wat er opnieuw gebeurt, is dat productmanagers bij hun samenwerking met ontwerp, engineering, bedrijfsvoering en sales — bijvoorbeeld in de bank- en zorgsector, waar veel digitale transformatie plaatsvindt — te maken krijgen met mensen die nog gewend zijn aan de manier van werken van een featurefabriek en aan de watervalmethode.

Zelfs als de productorganisatie die veranderingen wil doorvoeren, duurt het jaren. Ik sprak met Marty Cagan en hij zei dat het drie jaar duurt. Volgens mij klopt dat ongeveer. Het duurt zo’n drie jaar. Sommige bedrijven zitten dus in die tussenfase. Productmanagers worden daar verantwoordelijk gehouden voor meetwaarden, terwijl hun tegelijkertijd wordt voorgeschreven welke functies ze moeten bouwen.

Het is een rommelig tussenstadium. En dan is er de laatste groep: overduidelijk waterval, overduidelijk featurefabrieken, en veel organisaties vinden dat prima. Als je met een gemiddelde productmanager bij Apple praat, bepalen de leidinggevenden veel van de product- en functiebeslissingen. Jony Ive en Steve Jobs namen toen hij er nog was veel van de belangrijkste beslissingen.

Dat model kan dus nog steeds succesvol zijn. Mensen denken: het werkt niet. Marty zei dat de beste bedrijven allemaal autonoom zijn, maar ik heb gemerkt dat alle wegen naar de featurefabriek leiden.

Hannah Clark: Als je die gedachtegang volgt, zie je dat het logisch in elkaar zit.

Laten we enkele stappen bespreken die je uiteenzet in het artikel dat je hierover hebt geschreven. Als je het artikel nog niet hebt gelezen: het is heel interessant hoe je het onderwerp hebt opgesplitst en hoe je een enigszins controversieel standpunt inneemt over hoe je moet reageren als productmanager in een featurefabriek. Kun je, voordat we naar de stappen gaan, iets vertellen over jouw standpunt en de overeenstemming die je specifiek met Melissa Perry hebt?

Aakash Gupta: Ik denk dat er idealisten en realisten zijn. Aan de idealistische kant heb je mensen als Marty Cagan, Teresa Torres en John Cutler. Ik ben dol op alle drie, bewonder hen en lees alles wat ze schrijven. Maar ik denk dat zij geloven dat je als productmanager moet proberen je organisatie te transformeren als je in een featurefabriek werkt.

Dat is fundamenteel wat zij verkondigen. Veel van de hulpmiddelen en inzichten die ze zo gul gratis delen, draaien daarom. Ik houd van hen en heb respect voor hen, maar dat is wat zij geloven. Ikzelf, Melissa Perry en anderen zoals Clair Vaux en Powell Hearn zitten wat meer aan de realistische kant van het spectrum. Dat betekent: als productmanager denk ik niet dat je, tenzij je misschien acht of tien jaar ervaring hebt en minstens de titel group productmanager of hoger draagt, werkelijk de ervaring of invloed hebt om je hele organisatie effectief te transformeren.

Denk in plaats daarvan misschien aan een andere strategie. Waarom zeg ik dat? Omdat ik zoveel mensen die idealistische levenswijze heb zien proberen te volgen. Een anekdote die sommigen misschien van mij hebben gehoord — omdat ik die waarschijnlijk als een langspeelplaat blijf herhalen — is dat ik de subreddit over productmanagement graag sorteer op de populairste berichten aller tijden.

Volgens mij is het nog steeds zo dat in acht van de tien berichten productmanagers zeggen: ik haat mijn baan, mijn baan is ellendig. Als je de details leest, gaat het om productmanagers in een featurefabriek. Sommige citaten zijn bijvoorbeeld: ik ben productmanagement ingegaan na het lezen van INSPIRED en dacht dat ik de routekaart zou kunnen bepalen, maar ik ben slechts iemand die opdrachten van de CEO uitvoert.

Dit is een uiterst veelvoorkomend scenario. Mensen zitten expliciet bij de 75 procent van de bedrijven die featurefabrieken zijn en zijn ongelukkig met hun baan omdat ze dat ook daadwerkelijk zijn. Om al die verwarring te voorkomen — ik heb immers veel lezers van de nieuwsbrief die in productmanagement werken — is mijn realistische advies: omarm het gewoon. Geef je over aan de fabriek. Je bent beter af als je weet dat je in een fabriek werkt. Dan kun je zeggen: goed, wat moet ik als fabrieksarbeider doen om dit te omarmen en vooruit te komen?

Hannah Clark: Ik denk dat die instelling veel te maken heeft met hoe goed we het doen in elke moeilijke situatie. Maar het hoeft niet moeilijk te zijn.

Laten we de stappen uit je artikel doornemen, te beginnen met je overgeven aan de fabriek, waar je al op hebt gezinspeeld. Wanneer werd voor jou duidelijk dat dit echt een noodzakelijke stap in het proces was?

Aakash Gupta: Door mislukte pogingen tot transformatie. Ik heb bijvoorbeeld in verschillende soorten omgevingen gewerkt. Veel productmanagers hebben bijvoorbeeld nooit in een gameomgeving gewerkt. Ik werkte bij Epic Games aan Fortnite. Veel mensen denken bij een featurefabriek aan een CEO, chief product officer of chief design officer die voorschrijft wat er moet gebeuren. In een gamebedrijf zijn het meestal de ontwerpers die met allerlei fantastische dingen komen, samen met de creatieve mensen. Ze zeggen: dit wordt geweldig.

Veertienjarigen zullen dit de gaafste ervaring ooit vinden. Vervolgens stoppen ze de volgende seizoensrelease vol met de gaafste ervaringen ooit. Als productmanager zag ik dat er veel laaghangend fruit was op het gebied van prestaties, onboarding en updates. Als iemand Fortnite ooit heeft bijgewerkt: tot op de dag van vandaag is er veel verbeterd, maar ik heb het onlangs nog bijgewerkt.

Het was een bestand van 42 gigabyte. Mijn computer deed er twee uur over en ik gebruik een Mac, wat verschrikkelijk is. Daarna duurde het installeren van de update nog ongeveer vijftig minuten. We hebben het dus over extreme wrijving, twee keer per week. In de winkel voor geld verdienen lag er ook veel laaghangend fruit: er waren eenvoudige manieren om meer varianten te creëren voor mensen die jaarlijks drie- of vierduizend dollar in de winkel uitgeven.

Maar om mensen die vooral gaven om wat cool was te overtuigen, had ik kunnen zeggen: hé, we moeten ons richten op resultaten in plaats van op uitvoer, en niet op coole functies. Daar luisterde niemand naar. Ik probeerde dat dus echt. Daarna werkte ik bij Affirm, waar de planning zeer gecentraliseerd was.

Ik dacht: goed, ik ben GPM, mijn team gaat zich op meer onduidelijke problemen richten. Dat werd helemaal niet geaccepteerd tijdens mijn eerste planningscyclus. De leidinggevenden keken ernaar en vroegen: hebben jullie wel iets gedaan? De routekaarten van alle anderen waren veel gedetailleerder, met geweldige wireframes van hun functies en een analyseteam dat tot op zeven significante cijfers had berekend wat de gevolgen voor omzet en winst zouden zijn.

Je zag er dus vreselijk uit. Ik heb deze fouten zelf gemaakt en coach inmiddels veel productmanagers. Ik ontmoet veel productmanagers omdat ze een beetje moeite hebben met hun carrière of een lagere prestatiebeoordeling hebben gekregen dan ze wilden.

Als ik dieper onderzoek, doen we vaak een 360-gradenbeoordeling. Dan blijkt dat hun ontwerpers en engineers zeggen: ja, zijn PRD’s waren niet gedetailleerd genoeg. Ik merk dat deze productmanagers denken dat ze in een autonome wereld leven, maar in werkelijkheid werken ze in een featurefabriek. En in een featurefabriek is een geweldige, zeer gedetailleerde PRD vereist.

Ze missen die basisprincipes en presteren daardoor slechter. Alles bij elkaar komt het erop neer dat je je prestaties moet verbeteren. In mijn praktijkervaring in deze verschillende omgevingen heb ik niet gezien dat je onmiddellijk verandering kunt bewerkstelligen. De enige plek waar dat mij echt lukte, was toen ik directeur en vicepresident werd.

Toen ik bij thredUP en Affirm werkte, bestond mijn baan er juist uit de werkwijzen van de organisaties naar een hoger niveau te tillen. Als dat gebeurt, moet je er heel bewust stukje bij beetje aan werken. Het is goed dat we hebben gedefinieerd wat een featurefabriek is, want je kunt zeggen: ik ga elk onderdeel van de featurefabriek langzaam aanpakken, want het is een antipatron. Mijn punt als loopbaanadvies is echter: als je nog niet op een bepaald niveau zit, moet je dat antipatron niet proberen te repareren.

Hannah Clark: Daarmee komen we bij de volgende stap: je aanpassen aan de omgeving. Wat je schreef gaat over focussen op je echte baan: doe je echte baan. Kun je die stap en de bijbehorende deelstappen wat verder toelichten?

Aakash Gupta: Wat ik geweldig vind, is dat de werkproducten die ik in elk van mijn banen als productmanager maakte — vooral de producten die goed werden ontvangen — volledig verschillend waren. Bij Epic Games ging het uiteindelijk om presentaties van coole functies.

Vaak zat ik tot twee uur ’s nachts met een technisch ontwerper en maakten we een speelbare demo van de coole functie met vage graphics. Dat was wat goed werkte. Als ik naar Affirm kijk, heb ik de omgeving al een beetje beschreven. Daar werkte het juist goed toen ik kwam met een geweldige routekaart met impactinschatting, vol gegevens in spreadsheets en modellen voor de inschatting van de impact. Volledig tegengesteld dus.

Je moet daarom beoordelen hoe succes in productmanagement er in jouw omgeving uitziet. Ik raad aan om mensen te interviewen die al het langst productmanager zijn bij jouw bedrijf. Dat is een goede manier. Kijk ook naar productmanagers die recent promotie hebben gemaakt.

Blijf daarbij niet aan de oppervlakte. Wat ik aanraad, is om met deze persoon te gaan lunchen. Misschien hoef je tijdens de eerste lunch nog niet te diep te graven. Probeer eerst waarde voor die persoon te bieden. Nadat je een sterke relatie hebt opgebouwd en die persoon je helpt als mentor, kun je vragen stellen als: schrijf je voor elke functie een PRD? Kun je je beste PRD delen? Kun je je laatste promotiedossier delen? Kun je je laatste één-op-éénnotities met je manager delen? Heel praktische vragen, maar je kunt ze niet zomaar aan iedereen stellen als die persoon geen vriend van je is.

Maak die persoon dus eerst tot vriend en misschien ook tot mentor. Ik raad niet aan om expliciet te vragen of iemand je mentor wil zijn. Veel mensen willen juist zien dat hun productmanagers en productleiders een eigen zwaartepunt hebben. Ze zullen denken: hij of zij onderzoekt dingen en wil echt succesvol zijn.

Zie deze gesprekken als je eigen productonderzoek. Wanneer je ergens begint, interview je klanten, niet-klanten, concurrenten en andere mensen binnen je bedrijf. Voer daarnaast een direct één-op-één gesprek met je technische leider, engineeringmanager, ontwerper, gebruikersonderzoeker, analist en waarschijnlijk ook je manager en de manager boven je manager, waarin je rollen en verantwoordelijkheden duidelijk vastlegt.

Wees expliciet. Vraag je ontwerper bijvoorbeeld: wat vind je ervan als een productmanager schetsen en wireframes maakt? De meeste ontwerpers zullen zeggen: nee, daar ben ik misschien niet zo in geïnteresseerd. Sommigen zeggen dat het prima is, zolang het maar niet in Figma staat. Je moet die nuances kennen. Begrijp dus hoe je met jouw specifieke belanghebbenden moet werken.

Een fout die ik bij sommige mensen zie die zulke gesprekken voeren, is dat ze aannemen dat hun baan als productmanager hetzelfde is als die van een productmanager in een ander team. Maar de ontwerper, engineer en analist met wie je werkt hebben hun eigen verwachtingen. Iedereen wil de berg van productleiderschap beklimmen om vicepresident te worden.

Richt je voorlopig echter op de ene stap vóór je. Richt je op de mensen om je heen en maak een soort overeenkomst. Zodra je die overeenkomst hebt, kun je ermee experimenteren en zien wat goed wordt ontvangen en wat niet. Misschien weet de engineeringmanager bijvoorbeeld niet dat de engineers in zijn team graag worden uitgenodigd voor gesprekken met klanten. Dat leer je alleen in de praktijk.

Blijf dus goed afgestemd op je kleine groep. Dit is basaal loopbaanadvies, maar ik zet het hier omdat het draait om begrijpen wat jouw baan als productmanager inhoudt. Ik denk niet dat er twee identieke banen als productmanager bestaan.

Hannah Clark: Het klinkt alsof je in elke werkomgeving met de mensen met wie je het nauwst samenwerkt een soort microcultuur vormt. Het is dus belangrijk om de nuances van die cultuur te begrijpen, te weten welke taal iedereen spreekt en ervoor te zorgen dat de verwachtingen over en weer op elkaar aansluiten.

Dat sluit aan bij wat je zei over één-op-één gesprekken met mensen die al langere tijd succesvol zijn in de functie.

De volgende stap in je ontwikkeling is het creëren van een promotiepad. Die mensen spelen daarin een belangrijke rol. Kun je iets vertellen over die strategie om voor jezelf zo’n carrièreroutekaart te maken?

Aakash Gupta: In een featurefabriek is er meestal een zeer consistente reeks criteria waaraan je moet voldoen. Die criteria zijn vaak ongeschreven, onuitgesproken en worden door je eigen manager verkeerd geïnterpreteerd. Veel mensen vertrouwen daarom sterk op hun eigen manager. Ik heb zelfs mensen in mijn team gehad die behoorlijk vasthoudend met mij over promotie spraken. Wat ze niet begrepen en waar ik hen op moest coachen, was dat ik niet de enige ben die over hun promotie beslist.

Neem Affirm als voorbeeld. Ik schrijf een dossier voor je dat ik bij een promotiecommissie indien. Die commissie bestaat uit iedereen in het productleiderschap op of boven mijn niveau. Al die mensen leveren dus op zijn minst een bijdrage aan het gesprek. Nadat je mij hebt overtuigd, moet je realistisch gezien elke productleider op of boven mijn niveau ervan overtuigen dat die iets positiefs over je te zeggen heeft.

Je moet met hen samenwerken. Dat heeft bij Affirm daadwerkelijk gewerkt. Het draait om begrijpen wat onuitgesproken blijft. Ik werkte met productmanagers bij Affirm die moeite hadden om promotie te maken. Eén van hen was naar mijn mening al ongeveer drie jaar senior productmanager en had veel goed werk verricht.

Ik begon regelmatig één-op-één met haar te spreken, hoewel ze niet in mijn team zat, en tijdens de volgende cyclus werd ze gepromoveerd. Dit was het advies dat ik haar gaf: ik zat bij je vorige promotiecommissie en alleen je manager sprak voor je op. Haar manager had haar dat advies niet gegeven.

Je kunt dus niet altijd op je eigen manager vertrouwen. Vorm relaties met andere managers die mensen promotie laten maken. Zoek deze mensen, bouw relaties op. Wees opnieuw eerst een vriend en werk misschien eerst met hen samen, zodat ze kunnen zien dat je goed bent.

Ga daarna naar hen toe met een vraag als: hé, wat is jouw ervaring met promotiecommissies? De beste inzichten die ik daarover heb gekregen, kwamen opnieuw persoonlijk, tijdens een drankje na het werk. Dan leer je echt wat er speelt.

Sommige mensen hanteren een werkweek van negen tot vijf en veertig uur. Dat is prima, maar ik zou zeggen: haal donderdag en vrijdag vier tot vijf uur ’s middags uit je schema en maak er acht tot negen uur ’s avonds van. Dat is voor deze gesprekken veel effectiever.

Gebruik die tijd om te leren hoe mensen promotie maken. Veel mensen hebben mij gevraagd hoe ik zo snel vicepresident ben geworden. Het fundamentele antwoord is dat ik de promotiepaden bij verschillende bedrijven begreep. Bij vrijwel elk bedrijf waar ik kwam, maakte ik binnen een of twee jaar promotie. Ik kreeg mensen aan mijn team toegevoegd en meer verantwoordelijkheid. Dat kwam doordat ik volledig gefocust was op dat promotiepad.

Toen ik mijn vrienden vroeg of ze hierover met iemand hadden gesproken of wat ze hierover wisten, wisten ze vaak niet eens dat er bij Affirm een promotiecommissie bestond. Er is dus echt een kenniskloof. Die kenniskloof opvullen is stap één. Stap twee is nadenken over je unieke sterke punten.

Als productmanager laat iedereen ergens steken vallen. Misschien is je feedback op ontwerpen een acht op tien. Misschien is je vermogen om lastige belanghebbenden te managen een zeven op tien. Wat het ook is, benut je sterke punten. Voor mij was schrijven een duidelijk voorbeeld.

Zet daar dan echt op in. Hoe kun je een wekelijkse update maken? Hoe kun je een geweldige productstrategie delen met meer productteams dan normaal? Zo benut je je sterke punten binnen de unieke promotiecriteria.

Dat deed ik door mijn schrijfwerk vaak te delen. Ik zei dan: hé, dit onderdeel van mijn strategie voor de productleider van de afdeling Foundations heeft gevolgen voor het productteam van Foundations. Voordat we onze routekaart afronden, wil ik een screenshot hiervan met jullie delen. Dat wekte genoeg interesse om de rest van het document te bekijken en te zeggen: wauw, hij levert goed productwerk.

Het gaat dus om het benutten van je sterke punten tegenover die criteria.

Hannah Clark: Dit is ontzettend slim en praktisch. Ik waardeer die praktische aanpak enorm.

De volgende stap is het verbeteren van geïsoleerde werkwijzen. Waar verwijst die stap precies naar en wat zijn concrete voorbeelden van manieren waarop mensen deze vaardigheden kunnen aanscherpen?

Aakash Gupta: Vooral op GPM-niveau en hoger hoort dit op organisatieniveau te gebeuren.

Je moet dus met bepaalde teams experimenteren met wat ik nu ga zeggen en bewijzen dat het werkt. Zit je onder GPM-niveau, voer het dan binnen je eigen team uit. Nadat je in de één-op-één gesprekken waarin je afspraken maakte met je ontwerp-, engineering- en analysepartners hebt bewezen dat je succesvol kunt zijn binnen hun verwachtingen, is het tijd om een niveau hoger te gaan.

Vraag ook om hun feedback en pas bepaalde zaken aan op basis van wat zij zeggen. Mijn advies is als volgt. Ik heb veel met deze volgorde geëxperimenteerd tijdens het coachen van mensen en dit blijkt de effectiefste volgorde van technieken om vooruitgang te boeken.

Nummer één zijn analyses van functieresultaten. Ik vind dat deze in een featurefabriek weinig bedreigend zijn. We hebben een functie uitgebracht. Die kwam van Brian Chesky, de CEO, maar hij wil wel weten wat er is gebeurd en waarom. In featurefabrieken merk ik dat leiders echt willen weten waarom iets is gebeurd.

Productmanagers rapporteren vaak: A presteerde beter dan B, dus ik ga verder met A. Dat is minder indrukwekkend dan: A presteerde beter dan B omdat… Plotseling beïnvloed je wat er daarna gebeurt. Ook al luisteren ze in een featurefabriek misschien niet naar wat er daarna komt, het volgt wel uit jouw verhaal.

Een concreet voorbeeld: stel dat je bij Airbnb werkt en zojuist de totale prijs hebt uitgebracht omdat Brian Chesky zei dat je die moest bouwen. Dan wil je naar hem teruggaan met wat er is gebeurd en waarom. We weten dat het conversiepercentage voor aankopen zal dalen, maar de vraag is hoeveel. We weten dat de NPS zal stijgen omdat mensen niet meer verrast worden door de prijs.

We denken dat het conversiepercentage zal stijgen zodra mensen iets aan hun winkelwagen toevoegen en hun boeking afronden. We weten dus dat de conversie bovenaan de trechter op de kaartpagina zal dalen en op de aankooppagina zal stijgen, maar we weten nog niet wat het totale effect zal zijn.

Brian zal dat interessant vinden. Vervolgens komen de gegevens binnen. Het is verrassend: het conversiepercentage daalde op de kaartpagina slechts met 2 procent, maar steeg op de aankooppagina met 6 procent. Het totale conversiepercentage steeg dus met 4 procent. Zijn briljante idee was blijkbaar briljant.

We zien een stijging van 4 procent. Waarom gebeurde dat? Ga verder, zou ik zeggen. Interview nog een paar mensen, observeer hen en praat met je gebruikersonderzoeker. Misschien ontdek je dat mensen vroeger toch al geen vertrouwen hadden in onze kaartprijs van 357 dollar. Ze vertrouwden die prijs niet en daardoor hebben we een vertrouwensprobleem opgelost.

Je kunt dan naar Brian gaan en zeggen: hé, de reden dat de totale prijs het conversiepercentage verbeterde — ook op de kaartpagina — is dat mensen heel weinig vertrouwen hadden in onze prijs per nacht.

Hij kan vervolgens vragen waar mensen nog meer weinig vertrouwen in ons hebben. Misschien vertrouwen ze sommige van onze beoordelingen niet of hebben ze weinig vertrouwen in bepaalde Airbnb Plus-locaties. Vervolgens kun je op basis daarvan een routekaart maken.

Ik heb dit lange voorbeeld gegeven om uit te leggen dat analyses van functieresultaten weinig bedreigend zijn en je op weg helpen.

Het tweede interessante onderdeel is de inschatting van de impact. Productmanagers zijn vaak verantwoordelijk voor resultaten, terwijl hun uitvoer wordt opgelegd. In die wereld is het effectief om, wanneer je een uitvoer krijgt, de sterkst mogelijke onderbouwing te maken met zo veel mogelijk gegevens over hoe die functie zal presteren.

De CEO van thredUP geloofde bijvoorbeeld dat een uitbreiding van het verwijzingsprogramma van 10/10 naar 30/30 de volgende maand plotseling 5 procent meer omzet zou opleveren. Ik gebruikte de meest genereuze aannames, het grootste aantal gedeelde uitnodigingen en het hoogste aantal geaccepteerde verwijzingen uit onze beste campagnes. Toen ik alles samenvoegde, was het duidelijk dat ik maximaal op 0,1 procent extra maandelijkse omzet uitkwam.

Daarna was voor hem duidelijk dat deze functie het doel niet zou bereiken. Het opstellen van een financieel model voor de impact is nummer twee.

Nummer drie is probleemonderzoek. Veel mensen zetten de kar voor het paard en willen eerst onderzoek doen. Ik zeg dat onderzoek nummer drie is. Je bent begonnen met analyses van functieresultaten en met het inschatten van de impact voordat functies worden gebouwd. Wanneer je vervolgens een uitvoer krijgt, zeg je: bedankt voor het wireframe, meneer de CEO of vicepresident. We gaan nu goed onderzoek doen en nemen je mee in het proces.

Je laat video’s zien en gebruikt bijvoorbeeld nieuwe software zoals Dovetail om in dertig seconden de belangrijkste inzichten te tonen. Dit zijn de problemen met die oplossing. Vervolgens toon je het nieuwe ontwerp. Sommige mensen doen dat al. Dan breid je het uit naar probleemonderzoek: het probleem dat je met dit ontwerp probeerde op te lossen, kun je volgens ons beter in een heel ander deel van het product oplossen. Dat is 3A en 3B: oplossingsonderzoek en probleemonderzoek.

Nummer vier is overstappen op OKR’s. Daarmee komen we echt op het terrein van de GPM. Als principal productmanager raad ik je waarschijnlijk niet aan om OKR’s in te voeren als de rest van het bedrijf dat niet doet. Ben je GPM, dan zijn OKR’s volgens mij zeer effectief zodra je teams onderzoek doen.

Veel mensen doen OKR’s als tweede stap, na onderzoek. Ze hebben dan echter nog niet de vaardigheid ontwikkeld om functieresultaten te analyseren en impact in te schatten. Ik merk dat de OKR’s van zulke bedrijven onzin zijn. Ze missen over het algemeen al hun OKR’s. Ik zou zeggen dat dit waarschijnlijk voor 90 procent van de bedrijven geldt.

Daarom hanteer ik deze bewuste volgorde. Daarna komen tussen de OKR’s de OKPS-bomen, die helpen om OKR’s met problemen en oplossingen te verbinden. Tot slot komen productstrategieën. Het grappige is dat iedereen denkt dat productmanagement productstrategie is, maar ik denk niet dat je een productstrategie kunt schrijven zolang je niet de controle hebt over de volledige OKPS-boom. Tot die tijd schrijft de CEO in feite jouw productstrategie. Zodra je volledige autonomie hebt, kun je productstrategie toevoegen.

Hannah Clark: De volgende stap is natuurlijk het opbouwen van je coalitie. We hebben al gesproken over het vormen van hechte relaties met ontwerp- en engineeringcollega’s. Heb je een voorbeeld uit je eigen praktijk van hoe dit kan uitpakken?

Aakash Gupta: Laten we naar Epic Games gaan. We hadden het al over die situatie. Relaties vormden de kern van elk succes waarbij ik daar invloed had. Ik wilde vooral werken aan de prestaties van Fortnite.

Fortnite is een spel met een hoge vaardigheidsdrempel. Mensen spelen het tweeduizend uur per jaar, alsof het een voltijdbaan is. Mensen zijn er voortdurend mee bezig. Dat komt doordat je er meer uit haalt naarmate je er meer uren in stopt. Er zijn spelers die op dat niveau concurreren en technieken die je kunt leren.

Het probleem is dat je vaardigheidsplafond lager komt te liggen als je veel vertraging hebt of een slechte beeldsnelheid. In de gegevens zag ik dat mensen met slechte prestaties, omdat ze een slechte computer of internetverbinding hadden, na ongeveer duizend tot tweeduizend uur vaak afhaakten. Mensen met goede prestaties bleven twaalf- tot veertienduizend uur spelen.

Sommige mensen spelen Fortnite nog steeds. Het spel is al heel lang geleden uitgebracht. Dat was mijn belangrijkste inzicht, maar ik kon niet simpelweg met dat inzicht beginnen zoals ik dat bij Google misschien wel zou doen. Ik kon niet zeggen: daarom geven we prestaties prioriteit.

Ik moest invloed opbouwen bij belangrijke ontwerpers en engineers. Ik ontdekte dat er iemand was die Jason heette. Hij had Call of Duty gemaakt en leidde nu Fortnite. Uiteindelijk nam hij alle beslissingen over wat er in Fortnite gebeurde. Hij had veel respect voor de hardst werkende engineers en ontwerpers, de mensen die 120 uur per week werkten.

Zij brachten alles uit. In de gamewereld is dat helaas de realiteit. Sommige mensen werken er alsof ze in investment banking zitten. Jason had terecht veel respect voor hen. Ik besloot dat dit de mensen waren die ik in mijn coalitie moest opnemen.

Omdat ze zo hard werkten, hadden ze geen tijd om te zien hoe alles wat ze deden presteerde. Dat was mijn ingang. Zoals ik zei: analyses van functieresultaten zijn je ingang. Ik begon hen te laten zien: jullie hebben Fortnite Hoofdstuk 2, Seizoen 4, Patch 6.4 uitgebracht. Dit is wat er gebeurde. Niemand vertelde hen hoe Patch 6.4 presteerde, laat staan hoe Hoofdstuk 2, Seizoen 4 het deed.

Ik kwam met informatie als: Patch 6.4 had deze effecten op het spel. Het gebruik van sluipschutters steeg met 8 procent. Het aantal kills daalde met 6 procent. Spelers met een lage vaardigheidsclassificatie versloegen spelers met een hoge classificatie vaker dan ooit tevoren.

Ze raakten enthousiast over hun harde werk en begonnen te luisteren naar wat ik zei. Ik voegde daar inzichten over prestaties aan toe. Spelers met een latentie van meer dan 200 milliseconden haakten sneller af dan ooit. Door geweren, ballers en auto’s aan het spel toe te voegen, verloren spelers met een ping van meer dan 100 milliseconden hun vaardigheidsclassificatie in ongekend hoog tempo.

Dergelijke inzichten hielpen hen om prestaties geleidelijk in het spel mee te nemen. Ze begonnen te beseffen hoeveel invloed prestaties op het spel hadden en we verbeterden de prestaties aanzienlijk. Dit is een voorbeeld van strategisch nadenken over wie mijn coalitie moest en kon vormen, zodat ik de relatie en invloed van achter naar voren kon opbouwen.

Hannah Clark: Dat is op zoveel niveaus slim. Je bouwt geweldige relaties op, mensen vertrouwen je en je wordt bijna vanzelf invloedrijk. Geweldig.

Voordat we afronden, wil ik enkele veelgemaakte fouten bespreken die je productmanagers in featurefabrieken ziet maken. Een daarvan is natuurlijk niet erkennen dat je voorbestemd bent om in een featurefabriek te werken. Welke andere fouten kunnen we bespreken?

Aakash Gupta: Er zijn er ongeveer zes. De eerste is dat mensen alleen uitvoermaatstaven najagen. Ze hebben mijn advies gehoord en zich aan de fabriek overgegeven. De fabriek geeft om de snelheid van Jira-storypunten, het aantal grote functies dat ik op tijd uitbreng en hoe weinig ik de deadline van een functie verschuif.

Dat is het enige waarop ik optimaliseer. Ik denk dat dit nog steeds een fout is. Je moet nog steeds naar de resultaten van al je functies kijken. Overgave aan de fabriek betekent niet dat je geen goed productwerk meer doet. De fabriek kan je vragen een vreselijke functie zonder impact te bouwen, maar ik wil dat je vóór het bouwen nog steeds je productgevoel gebruikt.

Dat doet twee dingen. Ten eerste neem je aan de randen de juiste beslissingen over de verdeling van middelen waar dat mogelijk is. Ten tweede ontwikkel je de vaardigheid om goed productwerk te leveren. Ik zie dat mensen een featurefabriek binnengaan en dat hun vaardigheden achteruitgaan.

Ik zeg dan: Ben werkte vier jaar bij de featurefabriek van J.P. Morgan en volgens mij is hij een slechtere productmanager dan toen ik hem bij Google kende. Zulke dingen zijn echt gebeurd. Het gaat er dus om je vaardigheden te blijven ontwikkelen en nog steeds te begrijpen welke invloed alles wat je uitbrengt heeft op meetwaarden en gebruikers.

De tweede fout die productmanagers in featurefabrieken maken, is dat ze door de jacht op grote functies en de enthousiaste CEO technische schuld op een gegeven moment verwaarlozen. De ontwikkelervaring komt steeds opnieuw ter sprake. De bouwtijd is drie uur. Voor een eenvoudige wijziging ben ik een dag bezig. Maar je blijft zeggen: Fortnite Seizoen 16 komt eraan en dat moeten we uitbrengen, dus we moeten dit negeren.

Dat is zeer gebruikelijk. Ik zie het bij de meeste productmanagers in featurefabrieken. Ik denk aan toevallige en opzettelijke technische schuld. Toevallige technische schuld komt voort uit je gebruikerservaring en die wil ik beperken. Ik wil tijd vrijmaken om die aan te pakken.

Opzettelijke technische schuld ontstaat wanneer je achter een grote functie aanrent en compromissen sluit. Zolang je dat bewust doet en de functie van nul naar één en vervolgens naar honderd gaat, is het goed om later terug te komen en de problemen te herstellen.

De derde fout is het negeren van gebruikersfeedback. Ik zei terloops dat je zelfs je wireframe kunt laten zien en aanpassen. Voor sommige mensen is dat al een grote stap, maar dat zou voor geen enkele productmanager een grote stap moeten zijn. Als ik vraag hoeveel gebruikers je de definitieve ontwerpen van een grote functie hebt laten zien, zegt ongeveer de helft van de productmanagers: bij onze laatste grote functie hebben we die aan geen enkele gebruiker laten zien. We moesten om de een of andere reden haast maken.

Dat is een enorme fout. Zelfs als je vastzit in een featurefabriek, staat je carrière op het spel. Alles wat je team uitbrengt, vormt je cv en bepaalt of je wordt ontslagen of promotie maakt. Zorg er dus voor dat het de best mogelijke versie is van dat slechte idee.

Fout vier is FOMO de routekaart laten bepalen. Dat is de klassieke reden waarom we featurefabrieken hebben. HubSpot brengt een CRM uit, dus wij moeten een CRM hebben. Typefully heeft berichten voor LinkedIn, dus onze Twitter-tool Tweet Hunter moet berichten voor LinkedIn hebben. We zijn bang klanten kwijt te raken. Misschien is onze grootste klant vertrokken. Plotseling willen we alles bouwen wat die klant had kunnen behouden.

Dat is volgens mij een enorme fout. Probeer leidinggevenden de omvang van een functie te laten zien. Dat bedoelde ik met impactinschatting. Nadat je functieresultaten hebt geanalyseerd, gaat het om de vraag welke populatie je kunt bereiken.

Je wilt een volledig nieuw product aan onze suite toevoegen. Ons laatste nieuwe product wordt door 0,2 procent van de gebruikers gebruikt. Denk je echt dat we moeten investeren in nog een product dat 0,2 procent van onze gebruikers zal gebruiken? Wanneer je FOMO ziet bij degene die je featurefabriek aanstuurt, is dat een duidelijke waarschuwing.

Hier moet je misschien afwijken van de featurefabriek. Fout vijf is je team opbranden. Dat komt vaak voor, zelfs in autonome omgevingen. Snel uitbrengen is belangrijk, maar een goed gemotiveerd en gezond team levert doorgaans de beste resultaten.

Met een opgebrand team haal je misschien 10 procent groei, maar voor een groeiverschil van 50 procent wil je dat je team optimaal functioneert. Als productmanager moet je dus pleiten voor betere hulpmiddelen, een budget voor leren en ontwikkeling en een goed gepland teamuitje.

Dit is mijn favoriete persoonlijke techniek. Ik organiseer of bepleit dit vaak. Ik vraag mijn baas: hé, we hebben een grote functie uitgebracht of staan op het punt die uit te brengen. Het zou geweldig zijn als mijn productteam bij elkaar kon komen om dat te vieren.

Vroeger nam ik brownies mee voor ontwikkelaars wanneer ze een grote functie hadden uitgebracht. Ik gaf ontwerpers een high five wanneer het ontwerp goed was. Zulke kleine dingen hebben volgens mij in elke featurefabriek een groot effect, want niet alleen de productmanager is vaak ongelukkig. Ook ontwerpers en engineers zijn gefrustreerd.

Fout zes is het grotere geheel uit het oog verliezen. We krijgen wat, wat en nog eens wat. We vergeten vaak het waarom. Ik heb het waarom besproken in de context van meetwaarden en gebruikersproblemen.

Vergeet ook de productstrategie niet. Hoewel ik productstrategie als laatste stap heb genoemd, wil je die vaardigheid ontwikkelen. Het vak productmanagement is de afgelopen drie à vier jaar sterk ingekrompen. Er zijn simpelweg minder banen voor productmanagers, terwijl productontwerp en productengineering blijven groeien. Die groeien ten koste van productmanagement.

Als we willen dat productmanagers succesvol zijn in een omgeving waarin banen verdwijnen, moeten we proberen invloed uit te oefenen op productstrategie. Zelfs als je de featurefabriek omarmt en stap voor stap geïsoleerde werkwijzen verbetert, zal er in elke fabriek 10 tot 15 procent van de routekaart zijn waarop je invloed kunt uitoefenen. Er is ook 10 tot 15 procent van de sprint waarop de ontwerper of engineeringmanager wil dat je meedoet.

Je maakt nog steeds deel uit van het team, ook al is het een fabriek en hebben we ons overgegeven aan wat de fabriek belangrijk vindt. Zorg ervoor dat de functies die je uitbrengt strategisch buitengewoon sterk zijn.

Een van de beste productmanagers in een featurefabriek werkt nog steeds bij Epic Games. Ik ken ook iemand die nog bij Affirm werkt. Elke functie die deze productmanagers uitbrengen, verandert de koers van het bedrijf.

Ze brengen niet zo vaak hun eigen functies uit omdat ze in deze omgeving vastzitten. Maar wanneer ze dat wel doen, verandert dat alles. Bij Affirm bracht deze persoon machine learning uit om leningen te ordenen die je zou moeten terugbetalen. Het was een zeer diepgaande toepassing aan de backend, maar het verbeterde het terugbetalingspercentage met ongeveer 15 procent. Dat gaf Affirm een leidend voordeel in de sector. Je hebt gezien dat de aandelenkoers met 300 à 400 procent is gestegen.

Hij heeft dus een enorme impact. Dat is volgens mij wat mensen zou moeten motiveren. Ik zit vast in een featurefabriek. Ik heb 45 minuten naar Aakash en Hannah over de featurefabriek geluisterd. Probeer zulke geniale functie-ideeën te bedenken en ze in te plannen waar dat mogelijk is.

Hannah Clark: Dat is een echte mic-drop. Aakash, heel erg bedankt dat je tijd hebt gemaakt om met ons te praten. Waar kunnen de vijf mensen die luisteren en je nog niet volgen je online vinden?

Aakash Gupta: Idealiter via de nieuwsbrief. Ik zit op Substack. Ik weet dat sommige mensen die pop-up voor hun e-mailadres niet prettig vinden.

Je kunt gewoon op negeren klikken en verder lezen als je wilt. Tegenwoordig praat ik voor een gemiddeld artikel met meer dan tien mensen. Voor mijn laatste artikel had ik een gastmedewerker. We spraken ieder met tien mensen en interviewden hen. We kregen echt inzicht. Het is dus niet het soort productcontent dat je misschien op LinkedIn of X ziet en waarvan je denkt: hij maakt gewone productcontent, net als iedereen.

Dit zijn onderzoeksstudies met echte mensen. Voor het zoeken naar banen in productleiderschap spraken we met productleiders die onlangs vicepresident of directeur waren geworden. We spraken met recruiters die daadwerkelijk mensen in de sector plaatsen. Wat ik probeer te doen, is echte gegevens en inzichten bieden. Als mensen daarin geïnteresseerd zijn, is dat waar ik aan werk en waar ze me kunnen vinden.

Hannah Clark: Geweldig. We zien je daar. En heel erg bedankt dat je hier was.

Aakash Gupta: Graag gedaan, bedankt.

Hannah Clark: Bedankt voor het luisteren. Abonneer je voor meer geweldige inzichten, praktische handleidingen en beoordelingen van hulpmiddelen op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit horen door je overal waar je podcasts beluistert te abonneren op The CPO Club.