De route naar high performing teams

Prioriteren, valideren, roadmap opstellen

Prioriteiten stellen. Dat klinkt vrij eenvoudig toch? In de praktijk blijkt dat lastig. Want hoe bepaal je precies wat prio heeft? En dan: hoe hou je eraan vast? Oorzaak van de mist is vaak een gebrek aan focus en effectief productmanagement. Veel werk! Weinig mensen! Spoed!

Als alles even belangrijk is, zou dat een luxeprobleem zijn voor een productmanager. Gewoon een extra dosis developers toevoegen. Alles is evenveel waard, dus de opdrachtgever trekt glimlachend de knip. 

Daar zit de mismatch.

Want zonder de juiste prio’s, ga je zien dat de omzet niet evenredig groeit met de berg werk. Je verdrinkt langzaam in de groeiende backlog, je team presteert steeds slechter. Het lukt maar niet om focus te bepalen. 

De oplossing? Na ‘n paar maanden weer een nieuw strijdplan. Meer managers schieten te hulp. Meer stakeholders.

Dit is de oorzaak

Klinkt bekend? Ik zie het keer op keer fout gaan. Want wat er écht gebeurt: productteams worstelen met vergelijken van waarde. Degene die het hardst roept, wordt tevreden gehouden. Daardoor is de balans weg. 

Zo los je het op

Implementeer heldere processen, die werken in vrijwel alle organisaties. Doe je dit goed? Echt, je ziet prestaties verbeteren. Er wordt méér werk verzet, klanttevredenheid neemt toe.

Stap 1: positie van het productteam

Positioneren kan op verschillende manieren. Ik zie vaak dat bedrijven kiezen om een productteam onder te brengen bij de CTO. Of soms bij sales of marketing. Heel af en toe bij business-development. 

Dat zorgt al voor een roldefinitie die meer nadruk legt op de doelen van het team:

• Bij tech is meer aandacht voor het bouwen van de oplossing 
• Sales legt alle nadruk snel op klanten binnenhalen 

Het liefst hou je een productteam onafhankelijk en zelfsturend. Rapporteren gebeurt aan Head of Product of Chief Product Officer. Die rapporteert weer aan de CEO of COO.

Daardoor bekijkt het team vanuit alle perspectieven de waarde van een project. Dat helpt valideren vóór er ook maar iets is gedaan. Hoe groter de organisatie, hoe belangrijker. Je wilt niet dat teams elkaar in de weg zitten. 

Een valkuil

Soms zie ik vervelende politieke situaties als een productteam niet leidend is. Er is getouwtrek tussen verschillende teams. Iemand moet de keuze maken, de knoop doorhakken. De productmanager is spin in het web, dus de aangewezen persoon.

Maar hóe en op basis waarvan maak je keuzes? 

Stap 2: valideren en prioriteren

Een productmanager heeft een brede scope: sterke technologie, goede sales en waarde voor de eindgebruiker.  

Valideren en prioriteren doe je dus met een breed blikveld. Mijn houvast is vaak: Desirability, Feasibility en Viability.

Oftewel, de DFV-analyse:

Desirability: waarom wil je klant ‘het product’? Wat is de waarde? Of welk probleem wordt opgelost? 

Gesprekken met eindgebruikers en designers zijn dan verhelderend, is mijn ervaring. Ze vormen altijd mijn startpunt, waardoor ik kan filteren. Nóg een voordeel: de informatie is voeding voor user stories en andere documentatie. Dat helpt het team om te begrijpen waar het product voor is.

Feasibility: simpelweg, wat is haalbaar? Meestal maakt een gesprek met developers duidelijk of de wens haalbaar is en binnen budget. 

Je pelt het gewenste product af:

• Stel dat bouwen 3 jaar duurt, kan downsizen of opknippen?
• Heeft het dan nog wel waarde? 
• Is er een betere manier om die te realiseren? 
• Hoeveel mensen, welke expertise en onderliggende systemen zijn nodig?

En bij grote organisaties kijkt GDPR of compliance om de hoek: 

• Mág je dit wel echt bouwen? 
• Zijn er nog speciale voorwaarden? 

Viability: kan er winst behaald worden? Wie is bereid te betalen voor wat we willen bouwen? Of kapitaliseren we onze investering op een andere manier? Misschien wel door interne waarde of versnelling van een ander project.

Dit is vaak een goed moment om de OKR’s of KPI’s van het team of bedrijf onder de loep te nemen. Ik check of mijn prioriteiten daaraan bijdragen.

Soms kijk ik ook naar sustainability. De kosten op lange termijn en of we nog verder groeien. Maar meestal vind ik dit pas relevant als we tussen een boel gevalideerd werk moeten kiezen.

Stap 3: filter kosten versus moeite

Door validatie is het veel inzichtelijker wat de verschillende features kosten en opleveren. Ik filter nog meer zodat we features kunnen vergelijken: 

• Weinig moeite, veel waarde: dat is laaghangend fruit. Die neem ik bijna altijd op. 

• Kost iets veel moeite maar staat er veel waarde tegenover? Dat verspreid ik het liefst over een langere roadmap. Ik zoek dan meestal consensus bij het grotere team: iedereen eens met deze focus? 

Het komt zelden voor dat er na deze stappen nog veel werk overblijft voor een tweede filtersessie. 

Bijna klaar voor de roadmap

Na validatie en filteren op kosten versus moeite is prioritiseren een kwestie van capaciteit plannen. Ik zoek eerst een logische volgorde van dingen die ik wil doen op basis van de software-architectuur of bedrijfsdoelen. 

Daarna zijn stel ik me andere vragen, op basis waarvan ik features op de roadmap plaats:

Komt er een marketing-event waar een feature heel goed bij past? Zijn er partners of belangrijke klanten die al lang vragen om iets? Zorgt een feature voor een veel sterker platform? Kunnen we support tickets verminderen en klanten beter helpen? 

De roadmap ≠ planning

Focus houden, daar begon ik mee. Maar het is niet altijd alleen een kwestie van weten wat waarde heeft. Zeker in nieuwe organisaties die hard groeien, zie ik vaak dat er veel verzoeken blíjven komen. Dat kan het productteam overweldigen. Een roadmap biedt dan uitkomst!

Vaak wordt een roadmap verward met een planning. In pijnlijke gevallen bakt een bedrijf een excel met gantt chart. 

Een roadmap is per definitie NIET tijdgebonden. 

Het is een logische volgorde van dingen om op te focussen. Liefst meetbare doelen, zodat de volgende stap zichzelf aandient. Maar meer flexibiliteit kan ook. Waarom geen tijdgebonden roadmap? Omdat planningen onbetrouwbaar en rigide zijn. Zeker in zoiets complex als software-ontwikkeling. 

Een valkuil (deel 2)

Je bent geneigd tot aannames van wat haalbaar is. In plaats van de benodigde inspanningen te matchen met je resources. Een betere aanpak: doelen stellen en op basis van velocity tracking en resource planning onderzoeken hoe lang het duurt om die doelen te behalen. Het validatieproces geeft het productteam handvatten om te bepalen wat reëel is. 

Samen streven naar consensus
Het idee is dat de kernwaarde die je wil leveren op zichzelf staat en in logische volgorde gepresenteerd wordt. Het productteam stelt op basis van de productstrategie en bedrijfsdoelen een roadmap op en presenteert die aan het grotere team. 

Dit team bestaat vaak uit (bijvoorbeeld) de CX-lead, lead engineer, sales-lead en product-lead. Zo is elk perspectief vertegenwoordigd. Deze stakeholders moeten aftekenen en instemmen met de volgende fase. Als er consensus bestaat, is er niemand die de kar ineens de andere kant op stuurt. 

Meestal doe ik dit in een maandelijkse meeting met productmanagers en product owners. Daarin lichten ze hun validatieproces toe om duidelijk te maken waar we op focussen. In sommige gevallen kan je een lijst features als roadmapfase neerzetten. Je legt jezelf dan wel aan de ketting. Want voor iedere wijziging moeten alle stakeholders weer aftekenen. 

Het verschilt per organisatie, soms focus je op winstdoelen of waarde voor de gebruiker.

Complex maar noodzakelijk

Het blijft een complex verhaal. Maar met een duidelijke structuur en instemming van alle betrokkenen kan een bedrijf een stuk efficiënter te werk gaan. 

Het is veel werk voor het productteam, maar essentieel om te zorgen dat het juiste wordt ontwikkeld. Als een organisatie deze strategie echt omarmt, is een bijkomend voordeel dat dezelfde logica op alle niveaus toepasbaar is. Of het nou gaat om een intern proces, opstarten van een nieuw team of nieuw product. 

Uiteindelijk zie je dit natuurlijk terug in de eindcijfers. Want efficiënt werken, betekent dat je méér doet met mínder mensen. Door goed te valideren weet je zeker dat er betaald wordt voor alle kostbare arbeidsuren!

Over Remmelt Blessinga:

Remmelt Blessinga is product principal bij AND Digital's club Aletta in Amsterdam. Zijn achtergrond is in Business Informatics. Zo heeft hij heeft in samenwerking met PwC gewerkt aan het ontwikkelen van Virtual Reality training voor Fortune 500 bedrijven, zoals Meta en AT&T. Remmelt is gespecialiseerd in requirements engineering, product strategie validatie en ondernemerschap. Hij heeft twee eigen bedrijven gehad; een game studio die apps ontwikkelde voor de Chinese markt en een deep learning startup actief in de Westlandse teelt. 

Over AND Digital:

Het is de missie van AND Digital om de kloof in digitale skills te overbruggen. Daartoe versnellen we de digitale vaardigheden van ambitieuze organisaties. Zo mixen we onze technische vakkennis en product expertise met onze bekroonde aanpak op talentontwikkeling.

Zo kunnen onze klanten direct aan de slag om betere digitale producten te ontwikkelen en high-performance (digitale) teams te bouwen. Tegelijkertijd ontwikkelen ze cruciale vaardigheden om voorbereid te zijn op de digitale journey van morgen.

Benieuwd hoe AND Digital jouw organisatie kan helpen bij het versnellen van jouw digitale succes? Plan een vrijblijvend iets met Jeroen Kleinhoven in.