Je productmanager moet inward- EN outward-facing zijn

• De outward-facing rol die marktgericht is. Mensen met deze rol hebben contact met klanten en gebruikers, doen onderzoek naar marktkansen en bepalen aan welke hoogwaardige vereisten het product moet voldoen. Dit is een bijzonder belangrijke rol, want je kunt alleen bepalen wat er gebouwd moet worden door naar de markt te kijken. Wat hebben gebruikers precies nodig? En wat moet je leveren zodat het product voldoet aan de behoeften op de markt? Deze rol wordt in de meeste organisaties ingevuld door mensen met een functie zoals productmanager, productmarketeer, CEO, CxO of businessanalist.
• De inward-facing rol is gericht op ontwikkeling. Mensen met deze rol beheren de ontwikkelingsbacklog voor een (Scrum) softwareontwikkelingsteam en bepalen en prioriteren de gedetailleerde productvereisten. Het belang van deze rol moet niet worden onderschat, vereisten moeten immers correct worden vertaald voor en geïmplementeerd door het (software) ontwikkelingsteam. Als dit niet correct verloopt, dan ziet geen enkel product ooit het daglicht. Deze rol wordt in de meeste organisaties vervuld door een product owner, functioneel analist, architect of lead developer.

Beide rollen zijn altijd aanwezig in een productorganisatie, impliciet of expliciet. De outward- en inward-facing taken worden doorgaans verdeeld over verschillende mensen: twee rollen, twee personen.

We gaan in deze blog dieper in op de reden waarom het verdelen van outward- en inward-facing rollen over verschillende mensen geen goed idee is en zelfs bepaalde problemen oplevert.

Waarom het opsplitsen van outward- en inward-rollen tot problemen leidt

De outward- en inward-facing rollen worden weliswaar door veel organisaties opgesplitst, maar veel thought leaders in de productwereld zijn het daar niet mee eens (kijk voor meer informatie hier, hier, hier en ook hier). Het verdelen van outward- en inward-rollen over verschillende personen gaat gepaard met enkele fundamentele gebreken.

• De afstand tussen het daadwerkelijke ontwikkelingsteam en de gebruiker wordt groter. Het ontwikkelingsteam maakt elke week honderden beslissingen met betrekking tot het product. Dit kunnen alleen weloverwogen beslissingen zijn als er diepgaand inzicht is in de klant en de gebruiker.
• Er ontstaat een extra communicatiestap: van de gebruiker naar outward-facing, naar inward-facing, naar het ontwikkelingsteam. Er is een grotere kans dat zaken 'over de schutting worden gegooid'. Zelfs de hoogwaardige vereisten worden verkeerd geïnterpreteerd. Dit resulteert in zogenaamde ‘cake wrecks’.

• Het splitsingsmodel is gebaseerd op een misvatting: het gegeven dat de transitie van hoogwaardige vereisten naar gedetailleerde vereisten eenrichtingsverkeer zou zijn. De hoogwaardige vereisten worden doorgaans gedefinieerd door de out-facing persoon. De gedetailleerde vereisten worden gedefinieerd door de inward-facing persoon. Dit is echter gebaseerd op een onjuist beeld van softwareontwikkeling: hoogwaardige vereisten kunnen niet onafhankelijk van gedetailleerde vereisten worden bepaald. Laatstgenoemde zal altijd van invloed zijn op de eerstgenoemde. Het verdelen van deze taak tussen twee verschillende mensen levert een enorme overhead op ten aanzien van communicatie, samenwerking en afstemming.
  
• Het is bij opgesplitste verantwoordelijkheden vaak niet duidelijk wie de product owner is. Niemand gedraagt of voelt zich volledig verantwoordelijk voor het product.

Een productmanager moet beide rollen vervullen

Om bovenstaande problemen te verhelpen verdient het de voorkeur om slechts één persoon verantwoordelijk te stellen voor productdefinitie. Outward-facing en inward-facing, handelend op hoogwaardig en gedetailleerd niveau, marktgericht en gericht op ontwikkeling. Twee rollen, één persoon. Er is slechts één persoon verantwoordelijk voor het product en er zijn zodoende minder overdrachtsmomenten en de afstand tussen ontwikkeling en gebruiker wordt verkort. Deze persoon krijgt in de productwereld doorgaans de functie productmanager. Ze zijn verantwoordelijk voor de gehele productontwikkelingscyclus:

Productmanagers kunnen op één en dezelfde dag met het ontwikkelingsteam discussiëren over user story X, een marktverkennend user interview uitvoeren, in gesprek gaan met de CEO over de toekomst van het product en een Scrum-planningsmeeting voeren met het ontwikkelingsteam.

• Product Discovery (outward-facing)
  • het verkennen van kansen op de markt, 
  • het bepalen van een duidelijke productstrategie,
  • contact met gebruikers en klanten en het analyseren van hun behoeften, 
  • het op één lijn brengen van alle belanghebbenden,
  • het creëren en testen van mogelijke oplossingen. 
• Softwareontwikkeling (inward-facing) 
  • het beheer van de solution backlog (zoals user story's), 
  • het bepalen van prioriteiten,
  • het communiceren en samenwerken met het ontwikkelingsteam over de gewenste functies,
  • het valideren van geleverde werkzaamheden.
  

Productmanagers kunnen op één en dezelfde dag met het ontwikkelingsteam discussiëren over user story X, een marktverkennend user interview uitvoeren, in gesprek gaan met de CEO over de toekomst van het product en een Scrum-planningsmeeting voeren met het ontwikkelingsteam.

Tips om al dat werk te verdelen

Maar, maar ... het lukt me nooit om die enorme markt te overzien, user interviews en discovery-stappen af te handelen, productstrategieën te definiëren, gedetailleerde specificaties te verwerken, mijn story backlog te beheren en tegelijkertijd ook nog mijn ontwikkelingsteam aan te sturen. Dit is onmogelijk!

Ja, productbeheer is inderdaad veel werk. Dat is een van de redenen waarom veel bedrijven toch de voorkeur geven aan het opsplitsen van deze taken (door bijvoorbeeld zowel een Productmanager als een Product Owner aan te stellen). De werkdruk wordt zodoende over verschillende mensen verdeeld. Om dit schaalbaarheidsprobleem te omzeilen en de rollen niet te hoeven splitsen in outward- en inward-facing volgen hier twee technieken die kunnen worden toegepast.

1. Twee Productmanagers. Kies in plaats van voor een breed inzetbaar outward-facing persoon en een breed inzetbaar inward-facing persoon voor twee productmanagers die zich beiden concentreren op een kleiner gedeelte van het productproces. Productmanagers zijn verantwoordelijk voor hun aandeel: outward- en inward-facing, op hoogwaardig en gedetailleerd niveau. Het is doorgaans een goed idee om het productproces op te splitsen in verschillende (sub-)domeinen en te verdelen over (aparte) teams die verantwoordelijk zijn voor die domeinen. Deze inzichten kun je terugvinden in Domain Driven Design (DDD), het Spotify Model en Conway’s Law. De schaalbaarheid van het product wordt verbeterd als de taken van de productmanager op deze structuur worden afgestemd. Let op: er is nog steeds een overkoepelende productvisie voor het volledige product vereist om de grenzen binnen elk domein te kunnen bepalen. Binnen het domein ligt de verantwoordelijkheid in zijn geheel bij de desbetreffende productmanager.
2. Zorg dat je team je ondersteunt. Stel een Core Product Team samen bestaande uit de nodige experts op het gebied van technology, UX en business. Verdeel de discovery- en ontwikkelingstaken onder de teamleden. Zorg echter dat jij als productmanager de verantwoordelijkheid over het productdomein behoudt. Het complete ontwikkelingsteam kan tijdens de volgende stap worden ingezet om te helpen met Product Discovery, het verkleinen van het overdrachtsproces en de afstand tot de gebruiker. Dit wordt dual-track ontwikkeling genoemd. Dit onderwerp is aan bod gekomen ineen andere blog, kijk hier voor meer informatie.

Takeaway

Samenvattend: zorg dat de product-(team)structuur zo wordt georganiseerd dat iedereen erbij betrokken wordt en dat problemen met het verdelen van outward- en inward-facing rollen worden omzeild. Stel één persoon aan die verantwoordelijk is voor beide rollen, binnen de begrenzingen van het eigen subdomein. Stel indien nodig een tweede productmanager aan. Beperk het aantal overdrachtsmomenten, verkort de afstand tussen ontwikkeling en gebruiker en zorg dat duidelijk is wie verantwoordelijk is voor het product (domein) op hoogwaardig en gedetailleerd niveau.

Meer weten over productbeheer? Meld je aan voor onze training over productbeheer (voor productmanagers en product owners)! Klik hier voor meer informatie of neem rechtstreeks contact met me op .