Maakt een gebrek aan duidelijkheid je product stilletjes kapot?

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot heeft het niet altijd voor 100% bij het juiste eind.

Hannah Clark: Het is praktisch een cliché, maar het gebeurt voortdurend: je zegt iets tegen drie mensen en zij horen alle drie iets anders. En dat is niet zo erg als dat iets is: "Ik ga koffie halen, wil iemand iets?" Maar wanneer je een MVP bouwt met een steeds kortere financiële runway, of probeert iets binnen een strakke deadline te lanceren, kan dat gebrek aan duidelijkheid de doodsteek voor een startup betekenen.

Onze gast van vandaag is Bijan Shahrokhi—hij is de oprichter van Product Management Exercises en Product Monkey AI. Bijan heeft het laatste deel van zijn carrière besteed aan het helpen van productmanagers om productiever te worden en teams beter te managen. En het vermogen om duidelijkheid en afstemming binnen een productteam te brengen, vormt de basis van die vaardigheden. Over een paar minuten deelt Bijan een eenvoudig te herhalen proces dat vooraf wat tijd kost, maar de kracht heeft om een startup die op de rand van de afgrond staat te redden. Laten we beginnen.

Welkom terug, luisteraars. Vandaag spreek ik met Bijan Shahrokhi. Hij is de oprichter van ProductManagementExercises.com en hij heeft onlangs een productiviteitstool gelanceerd speciaal voor productmanagers, genaamd ProductMonkey.ai.

Bijan, heel erg bedankt dat je vandaag bij ons bent.

Bijan Shahrokhi: Heel erg bedankt dat je me hebt uitgenodigd.

Hannah Clark: Geweldig. We beginnen altijd op dezelfde manier. Ik zou het fijn vinden als je ons iets over je achtergrond kunt vertellen en hoe je bent gekomen waar je vandaag bent.

Bijan Shahrokhi: Zeker. Ik ben productmanager in hart en nieren. Ik ben al meer dan tien jaar productmanager, volledig per ongeluk.

Ik wist niet eens wat productmanagement was totdat ik een startup had die niet erg goed liep. Ik vroeg een vriend wat hij dacht dat ik vervolgens zou moeten doen en hij zei tegen me: 'Je zou productmanager moeten worden.' Ik dacht: wacht eens even. Dat klinkt heel interessant, zoals product en het managen van het product. Dat is wat ik wil doen.

Vanaf dat moment werd ik PM. Ik heb de afgelopen tien jaar verschillende dingen gedaan. De eerste paar jaar van mijn carrière werkte ik bij grotere organisaties, bijvoorbeeld bij een bank als productmanager en daarna als productstrateeg. Daarna maakte ik deel uit van twee startups. Bij beide startups lanceerden we het product toen ik bij het bedrijf kwam en één ervan werd binnen anderhalf jaar overgenomen door een grotere speler in het ecosysteem.

De andere was eigenlijk een succesvol project. Op het hoogtepunt was het miljarden dollars waard. Het bestaat nog steeds en maakt nog steeds een enorme groei door. Sindsdien richt ik me de afgelopen jaren vooral op Product Management Exercises. En onlangs hebben we nog een product voor de productmanagementgemeenschap gelanceerd, genaamd ProductMonkey.ai.

Hannah Clark: Geweldig. Vandaag gaan we het hebben over duidelijkheid binnen organisaties, iets waar je persoonlijk erg gepassioneerd over bent. Met duidelijkheid bedoel ik ervoor zorgen dat alle belanghebbenden op één lijn zitten en dezelfde versie delen van wat er gaande is en wat er gebouwd moet worden.

Hoe ziet dat er voor jou uit wanneer een organisatie geen gevoel van duidelijkheid heeft?

Bijan Shahrokhi: Goede vraag. Ik denk dat het grootste en meest voor de hand liggende teken dat een organisatie geen duidelijkheid heeft, zichtbaar wordt wanneer je door de organisatie gaat en verschillende mensen vraagt wat volgens hen de succescriteria zijn voor wat als volgende grote mijlpaal moet worden opgeleverd, en je verschillende verhalen begint te horen.

Laat me een voorbeeld geven. Stel dat je te maken hebt met een zeer technisch product dat met veel prestatie-indicatoren te maken krijgt, zoals latentie, snelheid, het aantal transacties per seconde of het volume aan taken dat kan worden voltooid. Als dit niet duidelijk wordt gedefinieerd door iemand met een zeer technische rol binnen de organisatie, proberen ze misschien iets te bouwen dat bestand is tegen een extreem hoog aantal transacties.

Maar als je het vraagt aan iemand die meer bedrijfsgericht is en rechtstreeks met klanten werkt, zouden zij zeggen: we moeten gewoon iets de deur uit krijgen zodat we feedback van onze klant kunnen ontvangen. Je weet dat er een gebrek aan duidelijkheid is zodra je gesprekken begint te voeren met mensen in de hele organisatie en verschillende cijfers hoort, of wanneer ze zeggen: 'O, daar hebben we nooit over nagedacht of over gesproken.' Dat is doorgaans een belangrijke waarschuwing voor jou als PM om te beseffen: wacht even, het lijkt erop dat hier een gebrek aan duidelijkheid is.

Hannah Clark: Het klinkt alsof je daar uit eerste hand ervaring mee hebt. Kun je, zonder namen te noemen, een anekdote bedenken?

Bijan Shahrokhi: Zeker. Het laatste project waar ik je over vertelde, dat miljarden dollars waard werd, was een bedrijf dat nog maar een paar maanden verwijderd was van het opraken van zijn geld en nog geen project had gelanceerd.

Ze dachten dat ze nog maar een paar maanden verwijderd waren van de lancering van hun product. Toen ik bij het bedrijf kwam, werd mij aanvankelijk verteld dat we nog maar drie maanden nodig hadden. Nadat ik was begonnen, besefte ik dat wat sommige oprichters in gedachten hadden misschien vijf tot tien jaar van de werkelijkheid verwijderd was.

En wat sommige engineers dachten op te leveren, was ook nog enkele maanden verwijderd. Er zat dus een enorme kloof tussen die twee. Daardoor zaten ze meer dan drie jaar lang in een cyclus van ontwikkelen, omdat het engineeringteam steeds presenteerde alsof het product bijna klaar was. Sommige oprichters of mensen uit de bedrijfsvoering keken dan en zeiden: O, wacht eens even, jullie zijn nog niet klaar.

Dit voldoet niet aan wat wij in gedachten hebben. Ze definieerden opnieuw wat er gebouwd moest worden. Het team ging vervolgens terug naar het bouwen, teleurgesteld en met het gevoel dat het niet echt waardevol was voor de organisatie. Wat we toen deden, was dat ik de eerste drie maanden als hoofd product besteedde aan ontmoetingen met veel belanghebbenden, om echt te begrijpen welke kenmerken sterk uiteenlopende perspectieven binnen de organisatie hadden.

Ik ontdekte bijvoorbeeld dat een bepaald kenmerk volgens de ene helft van de organisatie onderdeel moest zijn van de eerste lancering, terwijl de andere helft dat niet vond. Vervolgens begonnen we veel gesprekken over die specifieke onderdelen en kregen we duidelijkheid over de vraag of ze zouden worden gebouwd. Het was een beslissing met twee opties. Of we zouden een zeer beperkte versie ervan bouwen.

En dit is precies wat we daarvoor zouden doen. Pas daarna kostte het ons ongeveer een jaar om daadwerkelijk een beperkte versie te bouwen van wat aanvankelijk was gezien als: dit is wat we binnen drie maanden gaan lanceren. Eerlijk gezegd kostte het ons alleen al enkele maanden om duidelijkheid te krijgen over wat er binnen een jaar gebouwd zou worden.

Hopelijk is dit een voorbeeld van een situatie waarin je door veel duidelijkheid te brengen daadwerkelijk iets kunt opleveren. Zodra je het hebt gelanceerd, kun je de feedback van je gebruikers, de gemeenschap en het hele ecosysteem gebruiken om te bepalen welke van al die zaken in de pijplijn verder geprioriteerd moeten worden als volgende stap.

Hannah Clark: Ja, en het is ook een enorme prestatie om zo'n kloof te dichten; het lijkt op het eerste gezicht een onmogelijke taak. Het is dus behoorlijk krachtig om die aanpak te hanteren. Als we een stap terug doen, wat zijn volgens jou dan enkele bredere gevolgen wanneer een organisatie geen processen voor duidelijkheid in haar cultuur heeft ingebouwd, niet alleen binnen het productteam?

Bijan Shahrokhi: De grootste impact is dat ze er meestal niet in slagen iets te lanceren, en dat is een groot probleem. Er zijn veel geweldige projecten die nooit het daglicht zien omdat ze in feite zonder geld komen te zitten voordat ze inkomsten in hun bedrijf kunnen gaan pompen. Dit is helaas een nog hardere realiteit bij projecten die op onderzoek en ontwikkeling zijn gebaseerd. Zulke projecten zijn vaak zeer wetenschappelijk van aard en proberen echt een doorbraak te realiseren, en worden meestal geleid door oprichters met een sterke academische achtergrond.

En bij mensen met een sterke academische achtergrond—en ik bedoel dit niet negatief, want ik heb zelf ook een sterke technische en academische achtergrond en ik denk dat dat positief is—gebeurt het volgende: wanneer een organisatie door hen wordt geleid, streven ze naar perfectie. Omdat ze perfectie nastreven, blijven ze bouwen, bouwen en bouwen, en voegen ze steeds meer toe. Ze maken zich voortdurend zorgen over extreme scenario's die, eerlijk gezegd, niet eens het einde van de wereld betekenen als ze zich tijdens de incubatie- of vroege fasen van een project voordoen.

Het resultaat is dat ze nooit lanceren en dat de wereld nooit te zien krijgt wat hun visie voor deze nieuwe technologie was.

Hannah Clark: Ja, dat hele idee van 'af versus perfect' is iets waar we voortdurend mee worstelen: de perfectionist tegenover de mensen die gewoon willen lanceren, toch? Een gebied waarvan ik denk dat we het erover eens kunnen zijn dat duidelijkheid ontzettend belangrijk is, is het ontwikkelen van een MVP. Dat is volgens mij een gebied dat erg vatbaar is voor allerlei misstappen en miscommunicatie die uiteindelijk rampzalig kunnen zijn.

Wat zijn enkele veelvoorkomende valkuilen waar teams die MVP's bouwen zich bewust van moeten zijn, en welke oplossingen zijn er om ze te vermijden?

Bijan Shahrokhi: Ik denk dat de grootste fout die ik startups heb zien maken met het concept MVP, is dat ze het verwarren met het opleveren van een kapot product dat niet eens bruikbaar is.

Ik heb dit zo vaak gezien. Zonder namen te noemen geef ik een voorbeeld. Ik ben bijvoorbeeld investeerder in een bepaald product dat een bedrijfsoplossing is. Ik ben er zeer gepassioneerd over en enthousiast over. Vanaf dag één was de reden voor mijn enthousiasme dat ik mezelf het product zag willen gebruiken.

Ik kon me voorstellen dat mijn organisatie, Product Management Exercises, het dagelijks zou willen gebruiken. De grootste belemmering voor onze daadwerkelijke adoptie ervan is dat het zo veel fouten bevat dat we het niet eens kunnen gebruiken. Het is dus heel belangrijk dat wij als productleiders hier aandacht aan besteden en ervoor zorgen dat we bij een MVP niet praten over een product met zoveel fouten dat het de waardepropositie van het product niet kan overbrengen.

Je moet er dus nog steeds voor zorgen dat de belangrijkste gebruikerservaring, of de kernwaarde van het product die je aan de gebruiker probeert te leveren, van begin tot eind goed en soepel werkt. Je kunt veel zaken die niet noodzakelijk zijn buiten de scope laten, maar je moet ervoor zorgen dat je die kernervaring van het product kunt leveren.

Ik denk dat dit een van de grootste fouten is die ik bedrijven heb zien maken: ze begrijpen verkeerd wat MVP betekent en denken dat het betekent dat je gewoon iets kapots kunt lanceren.

Hannah Clark: Ja. Er is dus bijna een kamp dat niet wil wachten met lanceren totdat alles perfect is, en vervolgens is er de andere kant van het spectrum. Dat is logisch.

Je hebt een vrij intensief proces om duidelijkheid binnen organisaties te verkrijgen, waar je eerder al op hintte. Als luisteraars die aanpak zouden willen kopiëren en in hun eigen workflow zouden willen plakken, welke stappen zouden ze dan moeten volgen om ervoor te zorgen dat ze met iedereen in het team op één lijn komen?

Bijan Shahrokhi: Bedankt voor die vraag. Het is interessant dat je dit vraagt, want veel mensen bij PM Exercises vinden dit proces erg nuttig. Eerlijk gezegd is het vrij eenvoudig en draait het er vooral om het moeilijke werk vroeg te doen, voordat je daadwerkelijk aan een project begint. Het bestaat uit duidelijke stappen en ik loop er kort met je doorheen.

In principe besteed je eerst veel tijd aan het creëren van afstemming binnen de organisatie via een stapsgewijs proces. Pas wanneer je denkt dat iedereen op één lijn zit, begin je. Interessant is dat deze aanpak in veel grotere organisaties is overgenomen, bijvoorbeeld in financiële instellingen.

Maar toen we van Waterval naar de methode van Agile en Scrum gingen, dachten we dat dit betekende dat je geen duidelijkheid hoefde te hebben over waar je naartoe ging en alleen hoefde te weten wat je de komende twee weken zou doen. Nee, dat was niet de bedoeling van Agile. De bedoeling van Agile was dat je elke twee weken iets betekenisvols oplevert, terwijl je duidelijk weet waar je over enkele maanden naartoe probeert te gaan.

Hoe doe je dat? Mijn aanpak is bijvoorbeeld dat ik, wanneer ik een project of product leid waarvan ik merk dat er veel onduidelijkheid is, als eerste één-op-één-gesprekken plan met de belanghebbenden van mijn product. Het moet één-op-één zijn, niet in een groepsomgeving, want wat er gebeurt is dat iemand een mening deelt over gevoelige onderwerpen.

Vervolgens springt iemand anders ertussen en ben jij als de spreekbuis van het product niet in staat om alle benodigde context goed te verwerken. Je moet dus iedereen afzonderlijk spreken en ervoor zorgen dat je hun perspectieven echt begrijpt. Stel dat je met een afweging te maken hebt: moeten we X bouwen of niet? Dat is een binaire beslissing, maar dit model werkt ook voor veel andere zaken.

Je spreekt hen, vraagt hun perspectief op waarom iets wel of niet moet worden gedaan en vraagt ook: met welke zaken moet ik rekening houden wanneer ik deze beslissing neem? Ze zullen je waarschijnlijk vier of vijf verschillende dingen noemen die voor hen in hun wereld erg belangrijk zijn.

Vooral in de wereld van onderzoek en ontwikkeling wordt dit nog belangrijker. Hoe technischer je product is, of hoe meer technische afhankelijkheden het heeft met andere tools binnen de organisatie, hoe belangrijker het wordt, omdat er inhoudelijke experts zijn. Je gaat naar de volgende persoon, daarna naar de volgende, en spreekt iedereen één-op-één.

Na verloop van tijd gebeurt er een van twee dingen: je eigen mening over wat de juiste beslissing bij de afweging zou moeten zijn, wordt sterker, of je ontwikkelt nieuwe meningen. Of je afwegingen veranderen en je beseft dat bepaalde zaken moeilijker of juist eenvoudiger zijn dan je aanvankelijk dacht, waarna je ze aanpast.

Wat je ondertussen doet, is dat je, naarmate je op één-op-één-basis meer informatie verzamelt, teruggaat naar sommige van die mensen en zegt: weet je, toen ik aanvankelijk met je sprak, vertelde je me dat dit je drie grootste zorgen waren. Op basis van mijn gesprekken met anderen denk ik dat ze geen probleem zouden moeten zijn.

Dit is het argument. Vertel me waarom ik het bij het verkeerde eind heb, of vertel me of ik gelijk heb. Tijdens deze heen-en-weergesprekken, die tijd kosten, ontdek je uiteindelijk dat veel van de problemen waarmee het team kampte eigenlijk het gevolg waren van een gebrek aan communicatie. Niemand besteedde echt tijd aan het duidelijk uiteenzetten van al deze verschillende afwegingen aan de verschillende belanghebbenden binnen de organisatie, en daardoor werden veel zaken opgelost.

Na verloop van tijd krijg je steeds meer duidelijkheid over al die verschillende afwegingen waarop je moet letten. Deze aanpak kan trouwens ook werken voor productprioriteiten; daar kunnen we later nog wat meer over praten. Op een gegeven moment merk je misschien dat er een paar onderwerpen overblijven waarover nog steeds verschillende meningen bestaan. De helft van het team vindt bijvoorbeeld dat een bepaald kenmerk erg belangrijk is, laten we zeggen beveiliging. De andere helft vindt juist dat beveiliging als kenmerk niet zo belangrijk is.

Ze hebben daar hun eigen redenen voor. Dit is het moment waarop je een groepsbijeenkomst organiseert. Dan zeg je: om deze beslissing te nemen is dit een kenmerk dat voor ons zeer relevant is. Er zijn twee verschillende perspectieven. Ik wil graag dat we hierover praten. Via dat livegesprek kun je meestal tot een beslissing komen.

Soms zijn er enkele actiepunten, zoals: laten we dit verder onderzoeken. Prima. Dan organiseer je de volgende bijeenkomst en kom je terug met: dit was ons oorspronkelijke doel, we hebben onderzoek gedaan en dit is de nieuwe bevinding. Wat doen we? Maar je komt tot een beslissing. Zodra je heel duidelijk hebt welke afwegingen er zijn, wordt het voor jou als team veel gemakkelijker om te beslissen of je vanuit het perspectief van de afweging een bepaalde richting inslaat, of dat het om de productprioriteiten gaat. Dan kun je zeggen: goed, we hebben besloten dat dit onze prioriteit is en daar gaan we ons op richten.

Op zeer hoog niveau zie ik het zo: stap één is beginnen met één-op-één-gesprekken waarin je het perspectief van ieder individu echt goed begrijpt. Stap twee is, indien nodig, heen en weer gaan tussen hen om ervoor te zorgen dat alle punten waarover zij van mening verschillen aan het einde van de dag zijn behandeld. Als dat niet zo is, markeer je ze voor groepsgesprekken.

Stap drie bestaat vervolgens uit de groepsgesprekken. Uiteindelijk leidt dit tot een samenhangende productstrategie, productspecificatie of set productprioriteiten. Voor elk van deze verschillende scenario's kan er een extra tussenstap nodig zijn. Bij productprioriteiten moet je bijvoorbeeld meer nadenken over het doel.

Misschien moet je aan het begin wat tijd besteden aan de boodschap: ons doel is om snel iets op te leveren en ervan te leren. Daarna wil je nagaan of iemand het niet met je eens is. Als iedereen akkoord gaat, geweldig, dan kun je doorgaan met dit proces.

Hannah Clark: Ik wil graag wat meer praten over productprioriteiten in het algemeen. Ik denk dat dit iets is wat zelfs wanneer we relatief dicht bij consensus zijn, of het gevoel hebben dat we het eens zijn over de doelstellingen en hoe succes eruitziet, nog steeds moeilijk kan zijn: het afwegen van concurrerende prioriteiten.

Er bestaan natuurlijk honderden verschillende kaders voor het prioriteren van productfuncties. Welke methoden heb je gebruikt die volgens jou het meest succesvol en breed toepasbaar zijn bij het werken met concurrerende prioriteiten in deze contexten?

Bijan Shahrokhi: Een van de benaderingen die ik gebruik, is om ze te scoren en er vanuit een paar verschillende invalshoeken naar te kijken.

De eerste is de impact die deze specifieke functie of dit product volgens mij zal hebben op mijn doelgroep of mijn beoogde gebruikers. De tweede is de waarschijnlijkheid dat we die impact daadwerkelijk kunnen realiseren. In veel gevallen weet je namelijk niet zeker of je nieuwe product daadwerkelijk aanslaat bij de doelgroep.

In dat geval is de waarschijnlijkheid lager. De derde is de eenvoud van de implementatie. De formule die ik in gedachten heb is: "impact maal de waarschijnlijkheid van de impact plus de eenvoud van de implementatie". Voor impact gebruik je een schaal van één tot vijf, waarbij vijf de hoogste impact en één de laagste impact betekent.

Voor de eenvoud van implementatie geldt voor mij: als het een vijf is, betekent dat dat het gemakkelijk te implementeren is. Als het een één is, betekent het dat er veel inspanning nodig is. Daarna krijg je een score. Wat ik prettig vind aan deze aanpak is dat hij objectief is. Via het proces waar ik het net over had, met stap één, twee en drie, kun je vergelijkbare gesprekken voeren.

Je kunt teruggaan naar een teamlid en zeggen: kijk, op basis van mijn gesprekken met iedereen is dit mijn tabel met de belangrijkste projecten binnen de organisatie. Dit is mijn visie op hun scores vanuit het perspectief van impact en implementatie-inspanning. Op basis van mijn scores is dit het resultaat: dit zijn de projecten met de hoogste score.

Vervolgens kunnen zij tegen je zeggen: volgens mij mis je deze drie projecten waar we ook aan werken. Of: dit ene project dat je hebt opgenomen, moet in drieën worden gesplitst omdat het veel groter is dan je denkt. Ze kunnen ook aangeven dat ze het niet met je eens zijn over de impact of de benodigde inspanning. Maar nu voer je zeer objectieve gesprekken, waarbij het meer om de onderwerpen zelf gaat.

Interessant aan dit soort scoresystemen is dat je niet probeert in te schatten hoe lang alles zal duren. Je kijkt er relatief naar, in vergelijking met andere projecten. Daardoor is het veel gemakkelijker om snel tot een soort consensus te komen over hoeveel waarde iets zal opleveren of hoeveel inspanning het zal kosten. Dat leidt ertoe dat je een reeks duidelijk gedefinieerde prioriteiten hebt en kunt zeggen: deze vijf zaken zijn waar we ons het komende kwartaal op richten.

Elke keer dat er een nieuw onderwerp bijkomt, of een nieuw personeelslid of iemand anders binnen de organisatie naar je toekomt en zegt: dit moeten we doen, kijk je naar je prioriteitentabel en zeg je: laten we eens kijken. We hebben het besproken en besloten dat het om deze reden nu geen prioriteit is, maar zodra we deze twee of drie zaken hebben afgerond, geven we er prioriteit aan.

Soms ontdek je dat er nog aanvullende zaken moeten worden toegevoegd. We kunnen ook bespreken hoe je over zulke scenario's kunt nadenken.

Maar ik denk dat deze aanpak objectiever is en het voor je gemakkelijker maakt om tot prioriteiten te komen.

Hannah Clark: Dat waardeer ik. We hebben het eerder bij The Product Manager gehad over het depersonaliseren van feedback en van sommige van deze prioriteringsgesprekken, zodat mensen niet het gevoel krijgen dat er een persoonlijke reden is waarom hun favoriete project of agenda een lagere prioriteit heeft gekregen of in een andere volgorde is geplaatst dan zij vinden dat zou moeten.

Dat is een zeer voorschrijvende methode. Ik waardeer dat echt. Sorry, wat zei je ook alweer dat je wilde bespreken? Je zei dat we daar zo meteen op terug zouden komen, een moment geleden.

Bijan Shahrokhi: Ik zei dat we ook kunnen bespreken hoe mensen soms binnenkomen en zeggen: dit moet een prioriteit zijn. Vervolgens besef je dat het, om welke reden dan ook, inderdaad een prioriteit moet zijn.

Hoe ga je daarmee om? Ik zei dat je, wanneer dat gebeurt, kunt nadenken over hoe je het aanpakt. Je kunt het niet zomaar aan de lijst met prioriteiten toevoegen. Je moet nadenken over de vraag: als we dit willen doen, hoe doen we dat dan zonder dat het de snelheid van oplevering van de al bestaande prioriteiten beïnvloedt?

Je hebt dus een paar andere mogelijkheden. Eén daarvan is dat je iets van die lijst moet verwijderen. Het moet een lagere prioriteit krijgen. Vervolgens wordt het via het scoresysteem vervangen door dat nieuwe onderwerp. Een andere mogelijkheid is dat je extra middelen inzet die aan dit nieuwe prioriteitsonderwerp werken. Het principe dat je volgt is dat de zaken op je prioriteitenlijst niet langzamer worden alleen omdat je een extra onderwerp aan de lijst toevoegt.

Naar mijn mening is dit de taak van een productmanager, al is dat in sommige organisaties niet zo. Daar begint het probleem dat zaken niet worden opgeleverd.

Ik denk dat een goede PM hier goed op let en ervoor zorgt dat, wanneer nieuwe informatie aan het licht komt en iets anders daardoor prioriteit moet krijgen, hij of zij nadenkt over hoe daarmee om te gaan. Ik verwijder iets van de lijst of zorg ervoor dat ik extra middelen krijg die eraan kunnen werken zonder dat dit de snelheid waarmee ik het andere onderwerp oplever beïnvloedt.

Hannah Clark: Fascinerend. Ik wilde een beetje van onderwerp veranderen, nu we bijna aan het einde van onze tijd komen, omdat ik wat wilde praten over productiviteit. Dat is iets waar je ook erg gepassioneerd over bent en waarschijnlijk een belangrijke reden waarom je hebt besloten ProductMonkey.ai op te richten.

Ik vroeg me af of je algemene productiviteitstips voor ons publiek hebt en of je wat informatie kunt geven over Product Monkey AI die mensen interessant zouden kunnen vinden. Het is een heel interessante tool.

Bijan Shahrokhi: Zeker. Wat ik met Product Monkey AI doe, is het automatiseren van de ene taak die volgens mij zeer noodzakelijk is voor ons als PM's en die ik niet graag doe: veel tijd besteden aan het schrijven van gedetailleerde vereisten en acceptatiecriteria, om de redenen die ik eerder noemde.

Wat we met Product Monkey AI doen, is zoveel mogelijk informatie verzamelen over het specifieke project waaraan je werkt, over je organisatie en over de specifieke gebruikersstroom waarmee je te maken hebt.

Met de juiste begeleiding van jou en met behulp van AI kunnen we je vervolgens gedetailleerde productvereisten, acceptatiecriteria, testsituaties en zelfs gebeurtenissen en meetgegevens geven waarop je moet letten wanneer je het product bouwt. Je kunt dit direct meenemen en eraan beginnen te werken. Je krijgt een snelle eerste versie, die ongeveer 80% van het werk vormt voor je tickets voor het engineeringteam en je PRD's, voordat je ze in de juiste documenten onderbrengt.

Daarna besteed je je tijd aan de laatste 20% om ze af te maken. Een van de voordelen die wij als PM's kunnen leveren, zoals ik al zei, is het brengen van duidelijkheid. Ik denk dat Product Monkey AI dat daadwerkelijk kan doen door de tijd te verkorten die PM's nodig hebben om duidelijkheid te brengen aan engineeringteams.

Hannah Clark: Dat is fantastisch. Ik weet zeker dat veel luisteraars veel waarde in die tool zullen vinden. Bijan, heel erg bedankt dat je vandaag bij ons was. Waar kunnen mensen je online volgen als ze willen zien waar je nog meer mee bezig bent?

Bijan Shahrokhi: Ze kunnen naar Twitter of X komen, zoals we het nu noemen. Mijn X-account is bijan_sha. Je kunt me daar vinden. Je kunt ook naar PM Exercises of Product Management Exercises gaan. Zoek op een van beide en je komt op onze website terecht, waar je ook contact met me kunt opnemen.

Hannah Clark: Geweldig. Heel erg bedankt voor je tijd.

Bijan Shahrokhi: Heel erg bedankt dat je me hebt uitgenodigd.

Hannah Clark: Bedankt voor het luisteren. Abonneer je op onze nieuwsbrief via theproductmanager.com/subscribe voor meer geweldige inzichten, praktische handleidingen en recensies van tools. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je ook naar podcasts luistert.