Steeds meer bedrijven maken gebruik van product teams. Maar wat zijn product teams precies? Wie zit in zo’n team, en wat doen deze mensen? Remmelt Blessinga – Product Principal bij AND Digital – loopt door de wie, wat, waar, waarom en hoe van (digital) product teams.

Product, een mishandeld woord. We spreken van product managers, product owners, product marketing managers en product specialisten. En over product designers en product developers. Je hebt een hoofd van product, een principal product manager en een group product manager.

Tel daar alle mogelijke niveaus, van associate tot senior bij op. Enfin, we kunnen nog wel even doorgaan, maar hoe zit dat nou eigenlijk?

Verschillende typen product teams

Een product team, komt in net zoveel vormen als er soorten organisaties zijn voor. Nog ongeacht wie er in die organisaties werken en waar ze in de organogram zijn ingedeeld. Valt een team onder de CTO? Dan zijn ze meer met technisch werk, zoals het onderhouden van de backlog van werk bezig. Ze kijken in detail naar de tactische uitvoering van de plannen van hoger af. Ze houden zich vaker bezig met het “hoe”.

In andere bedrijven zitten ze bij sales of marketing (en kom je vaker de term product marketing manager tegen). Hoe maken we winst? Waar betalen klanten voor? Wanneer kunnen we het leveren? Hoe communiceren we over wat we bouwen? Deze teams hebben de blik meer naar buiten gericht.

Waarom

Het is belangrijk om strategisch de juiste beslissingen te nemen. Om tot die beslissing te komen moet je starten met de waarom vraag. En die waarom begint bij je klanten en het DNA van je eigen organisatie.

Kijk je niet waar de behoefte ligt bij je klanten, dan is er een grote kans dat je het verkeerde ding gaat bouwen. En past het type product (bijvoorbeeld: een nieuwe applicatie) bij je eigen organisatie?

Ik ken een voorbeeld van een bedrijf dat €3,8 miljoen verbrandde aan een product waar eigenlijk geen behoefte aan was. Het idee was tot stand gekomen via gesprekken tussen twee bestuurders. De een is gaan bouwen, de ander ging het betalen. Het was uiteindelijk (pijnlijk) duidelijk dat het product meer een last voor ze zou worden dan een oplossing. De echte problemen werden niet aangepakt. Om het schip weer te keren is een stuk pijnlijker dan het had hoeven zijn.

Stuurloos product team

Je ziet de gevolgen van een stuurloos product team vaak niet meteen terug. Zeker niet als je aan het ontwikkelen bent. Vaak zijn de symptomen redelijk duidelijk. Je merkt het wantrouwen tussen teams. Er ontstaat veel druk op de ontwikkelaars om steeds meer met minder te bouwen. Het gebrek aan een roadmap of een roadmap die niet aan een planning is gekoppeld. Zo heeft alles altijd de hoogste prioriteit en er lijkt steeds weer wat nieuws te zijn.

Vaak is het totaal onduidelijk voor management waar de teamleden nou in hemelsnaam mee bezig zijn. Zeker voor buitenstaanders; je vraagt toch niet zoveel van ze? Waarom willen ze constant meer mensen?

Nog erger is het als leveringen aan een klant vertraging oplopen. En deze klant komt vervolgens terug met een lijst aan eisen waar je niet makkelijk aan kan voldoen. Je hebt ze totaal verkeerd begrepen.

Ideale situatie

Ideaal is een product team dat onafhankelijk in de organisatie staat. En de middelen krijgt die ze nodig hebben. Dit team moet dit soort problemen voor zijn. Ze praten continu met niet alleen de klant, maar ook met de eindgebruiker. Want pas als die er echt op vooruit gaat heeft je product waarde. Een product team werkt bijna altijd iteratief en richting een set doelen (KPIs of OKRs bijvoorbeeld) om waarde brengen, intern en extern. Ze zijn prima in staat die zelf op te stellen.

Het is een continue zoektocht naar nieuwe kansen, manieren om waarde te leveren. Om vervolgens de beste volgorde te bepalen om die waarde te leveren en daar winst op te maken. Het werk van een goed functionerend product team is dan ook nooit in isolatie. Naast met gebruikers praten, moeten ze praten met iedereen binnen de organisatie. Met ontwikkelaars en ontwerpers, met sales, met marketing, zelfs met de CEO.

De bedrijfsdoelen, commerciële kansen, technische kansen en visionaire plannen worden meegenomen. Ze worden gebruikt voor validatie van nieuwe initiatieven. Via een hele serie processen wordt dit samengevoegd tot een product strategie. Hoe zoiets er uit kan zien en hoe je dat opbouwt bespreek ik in een volgend artikel. We houden het bij goed functionerende product teams.

Team opzetten

Maar hoe bouw je zo’n team zodat je aan de slag kan? Dat blijkt vaak nog een hele klus. Zeker als er al een bestaande structuur is, die niet dezelfde prioriteiten kent. De sleutel tot echt succes is dan ook dat er een mandaat bestaat. De zelfstandige bevoegdheid voor het bouwen van een productstrategie en producten. Zonder kan een team niet veel. Ze verworden tot een soort veredelde planning en notitie afdeling. Met veel frustraties en uiteindelijk de uitstroom van talent tot gevolg.

Een product manager met mandaat van hoger management kan keihard nee zeggen tegen een idee of doel. En zorgt dat er documentatie bestaat waarin beschreven staat waarom niet. In het begin doet dat pijn, later voelt het vaak als een opluchting omdat er duidelijkheid en richting is.

Met een mandaat kan dit team vragen stellen, en dat is eigenlijk wat het product team het beste doet. Het snappen wat we doen, waarom we het doen, en hoe we het doen, en dat zichtbaar maken voor het hele bedrijf.

Mensen, mensen, mensen

Het vraagt om mensen die communicatief heel sterk zijn. Snappen hoe een programmeur denkt, maar ook de taal van sterk zakendoen spreken. Want je hebt te maken met de business. Het luisteren en vertalen van wensen van mensen, die of heel erg op een eiland zitten of juist overal bij betrokken willen zijn.

Dus als eerste zoek je deze werknemers. Daarbij is domeinkennis fijn, maar zolang het een leergierig iemand is niet eens echt nodig. Waarom? Omdat de domein specifieke informatie toch vaak vertaald zal moeten worden naar niet-technische partijen. Marketing, sales, de ontwerpers enz. Zolang het product team het product kan leren begrijpen op basis van wat ze van de experts horen zit je goed.

Daarbij blijven de processen en tactieken bijna altijd hetzelfde tussen domeinen. Heb de lef om een omgeschoolde vertaler aan te nemen die bijna geen ervaring in de IT heeft. Uit ervaring kan ik zeggen dat dat prima werkt. Het was een van de beste product owners die ik in een team heb mogen hebben. Hij kon luisteren en uitleggen, en was niet bang om te laten weten wanneer hij iets niet snapte; dat is ideaal.

En dan?

Na het vinden van de juiste mensen en een eerste stap naar de juiste bedrijfscultuur. Dan hangt het af van de grootte van je organisatie en het volume aan informatie die rondgaat.

Bij een kleine onderneming of een startup komt je weg met een klein team dat alles holistisch bekijkt. Groei je iets dan krijg je te maken met een groter aantal klanten, of een marketing team dat steeds veeleisender lijkt. Of er komt meer druk vanuit sales en steeds meer vraag om zekerheid vanuit business development. Je kunt dan gaan denken aan een product manager en product owner split.

De een is bezig met tactisch kijken hoe iets het beste gebouwd kan worden met het ontwikkelingsteam en itereren. De product manager valideert voor het überhaupt zover komt. Deze kijkt naar het verfijnen van de strategie en houdt alle betrokkenen tevreden.

Dat is maar een van vele keuzes en mogelijkheden. Het belangrijkste is blijven overwegen wat de organisatie (en je klanten) verder gaat brengen. Het richting geven van doelen vanuit een product oogpunt. Daar zijn vaak nieuwe processen voor nodig, de ‘product ways of working’. Denk aan stakeholder management sessies. Of strakke agile ceremonies.

Het belangrijkste is vaak dat je transparant blijft en een ‘buy-in’ creeert via sterke validatie en onderzoek. Dat doe je niet allemaal in een keer, dus een beknopte routekaart naar ‘maturity’ komt vaak goed van pas. De routekaart maakt duidelijk welke fase van het proces eerst komt, en hoe de andere verbeteringen daarop voortbouwen.

Hoe het dan verder gaat is moeilijk te voorspellen. De split tussen tactisch en strategisch is voor iedereen anders. Wat leidend is vanaf hier is de bedrijfsvisie. Het is de product visie die de bedrijfsvisie waar moet maken. Of in ieder geval de visie dichterbij moet brengen. Bij het ene bedrijf bouw je dan een product team rondom onderdelen van software. Of heb je zo’n breed portfolio dat er meerdere producten zijn waar je een team omheen kan bouwen.

Bij grote organisaties kan het beide nodig zijn. Dan zijn er meerdere producten die zo groot zijn dat ze per onderdeel sturing nodig hebben. In dat geval kom je termen zoals “group” vaker tegen. Dan heb je iemand nodig die kijkt hoe alle plannen van al deze onderdelen samen gaan komen. Dat kan niet alleen bij software architect liggen.

Het belangrijkste doel van het product team blijft het bevrijden van informatie. Zolang ze in staat worden gesteld dat te doen, en je de juiste mensen hebt zitten, komt dat vanzelf goed. De rest is een kwestie van gereedschapskisten open trekken.