De goede plek tussen autonomie en consistentie

Hoe productteams de juiste balans kunnen vinden

Atlassian Door Atlassian
Onderwerpen zoeken

"Productteams hebben autonomie nodig om effectief te kunnen innoveren. Maar naarmate organisaties (op)schalen, kan die autonomie chaos veroorzaken zonder het juiste kader."

Als Senior Product Manager voor Jira Product Discovery hoor ik deze uitdaging terugkomen in gesprekken met klanten uit alle sectoren en bedrijfsformaten. De vraag komt steeds weer naar voren: hoe stel je teams in staat om autonoom te werken en tegelijkertijd voldoende consistentie te behouden om de organisatie effectief te laten functioneren?

Het breekpunt

Er is een moment waar elke groeiende organisatie mee te maken krijgt. Met een of twee productteams verloopt alles op rolletjes. Als je vijf teams hebt, beginnen er scheuren zichtbaar te worden. Maar als je tien of twintig teams bereikt? Dan gaan er dingen mis.

Ik zie dit patroon voortdurend in gesprekken met onze klanten. Productteams werken niet geïsoleerd: ze moeten samenwerken met het management om de bedrijfsdoelen op elkaar af te stemmen, met technische teams om hun ideeën te ontwikkelen en uit te brengen, en met marketing en verkoop om hun functies te promoten. Als er maar een paar teams zijn die anders werken, kan de rest van de organisatie zich aanpassen. Maar naarmate je (op)schaalt, wordt wat ooit beheersbaar was chaos.

Wat dit breekpunt bijzonder interessant maakt, is dat het vaak het gevolg is van succes, niet van mislukking. Je productteams slagen elk op hun eigen manier: sommige hebben zich gericht op de behoeften van de klant door middel van gezamenlijke ontwerpsessies en verbeteringen in de bruikbaarheid, andere zijn gericht op de stabiliteit van het platform en de systeemprestaties. Elk team werkt op zijn eigen manier goed, met behulp van processen die passen bij hun context. Maar zonder een gemeenschappelijk kader dat alles bij elkaar houdt, wordt juist dit succes onhoudbaar.

Oplossen met extreme maatregelen

Tijdens talloze gesprekken met klanten heb ik twee veelvoorkomende pogingen gezien om dit probleem met de coördinatie van productteams op te lossen. Sommige organisaties proberen volledige standaardisatie af te dwingen, waarbij elk productteam identieke processen, sjablonen en tools gebruikt. Anderen kiezen de tegenovergestelde weg, laten teams volledig onafhankelijk handelen en hopen dat de stukken op de een of andere manier bij elkaar komen.

Geen van beide extremen werkt. Zoals een leider op het gebied van productactiviteiten me vertelde: "Toen we probeerden al onze productteams op dezelfde manier te laten werken, kregen we naleving zonder veel betrokkenheid. De teams volgden de stappen, maar hadden geen motivatie meer." Aan de andere kant leidde volledige autonomie tot fragmentatie en inefficiëntie. Productteams konden de leerervaringen niet effectief delen, belanghebbenden hadden moeite om het grotere geheel samen te stellen en mogelijkheden voor samenwerking werden gemist.

3 elementen om de juiste balans te vinden

De meest succesvolle organisaties pakken deze uitdaging aan met drie belangrijke elementen die zorgen voor evenwicht zonder aan autonomie in te boeten.

Een gemeenschappelijke taal staat voorop: gedeelde manieren om doelen, ontwikkelingsfasen en inspanningen te bespreken die duidelijke communicatie mogelijk maken zonder een proces op te leggen. Vervolgens leggen ze consistente visualisaties vast die teams op hun eigen manier laten werken en belanghebbenden de duidelijkheid geven die ze nodig hebben. Ten slotte maken ze best practices mogelijk door middel van een combinatie van cultuur, flexibele kaders en ondersteunende tools.

In dit artikel onderzoeken we hoe deze elementen samenwerken om de juiste balans te vinden tussen de autonomie van het team en de helderheid van de organisatie. Je ziet specifieke voorbeelden van hoe verschillende soorten productteams - van teams die zich richten op klantgerichte functies tot teams die werken aan de mogelijkheden van het platform - hun unieke aanpak kunnen behouden en tegelijkertijd kunnen bijdragen aan een gemeenschappelijk doel.

Zorgen voor een gemeenschappelijke taal

Een belangrijk besef voor productteams is dat ze niet op dezelfde manier hoeven te werken, ze moeten gewoon dezelfde taal spreken. Door ons werk met klanten hebben we drie belangrijke elementen geïdentificeerd die zorgen voor dit gedeelde begrip zonder dat dit ten koste gaat van de autonomie van het team:

Doelen die teams met elkaar verbinden

Neem bijvoorbeeld een van onze klanten die een bedrijfsbreed doel heeft gesteld om de klanttevredenheid te verhogen tot 80%. Hun productteams hebben dit doel op totaal verschillende manieren benaderd, gebaseerd op hun context:

  • Eén team richtte zich op het verminderen van het aantal klikken dat nodig was om veelvoorkomende acties uit te voeren
  • Een ander team concentreerde zich op het verbeteren van de betrouwbaarheid van het systeem en het verminderen van downtime
  • Een derde team gaf prioriteit aan de nauwkeurigheid van de zoekresultaten

Hetzelfde doel met verschillende benaderingen, maar iedereen begreep hoe hun werk bijdroeg aan het grotere geheel.

Fasen die voor duidelijkheid zorgen

Succesvolle organisaties dwingen teams niet tot starre processen maar standaardiseren mijlpalen. Atlassian heeft vier belangrijke fasen gevonden die voor verschillende soorten productteams werken:

  1. Afvragen: Volledig begrip van het probleemgebied
  2. Ontdekken: De oplossing is afgemeten en gevalideerd
  3. Maken: Functie die in verschillende regio's wordt geïmplementeerd
  4. Impact: Resultaten gemeten na 3 maanden

Als een productteam zegt dat ze zich in de fase "Ontdekken" bevinden, weet iedereen wat dat betekent: ze begrijpen het probleem en valideren oplossingen. Maar hoe komen ze daar? Dat is voor elk team verschillend.

Logische evaluatie van de inspanning

Het derde onderdeel is een algemeen kader voor het meten van de inspanning. Dat betekent niet dat de schattingen van elk team op dezelfde manier werken, maar dat ze hun schattingen vertalen in een gemeenschappelijke taal. Platformteams houden misschien rekening met de complexiteit van het systeem en de implementatierisico's, terwijl andere productteams zich richten op de complexiteit van de gebruikersinteractie. Beide teams kunnen deze beoordelingen daarna overbrengen op een manier die iedereen begrijpt.

Alles samenbrengen

Wil je een voorbeeld van het samenbrengen van deze drie elementen? Bekijk mijn webinar, Hoe Product Operations de juiste balans kan vinden tussen autonomie en consistentie, waarin ik een praktisch voorbeeld geef van hoe twee verschillende teams op heel verschillende manieren kunnen werken om hetzelfde doel te bereiken.

Project management

Keeping multiple product initiatives on track is no small feat. The product operations manager supports product managers by coordinating complex projects and timelines, tracking progress against product roadmaps, and managing the countless dependencies between teams. They anticipate potential roadblocks and clear the path for on-time delivery.

Consistente visualisaties maken

Nu er een gemeenschappelijke taal is, is de volgende uitdaging om werk zichtbaar te maken in de hele organisatie. Hier staan veel productteams voor een bekende uitdaging: de driemaandelijkse roadmap.

Dit gebeurt vaak. Productteams zijn uren bezig met het opstellen van hun roadmaps, elk met behulp van indelingen die bij hun werk passen. Sommigen maken gedetailleerde spreadsheets aan omdat ze complexe afhankelijkheden bijhouden. Anderen geven de voorkeur aan slidedecks voor presentaties van belanghebbenden. Weer anderen houden hun roadmaps in technische tools bij om dicht bij het ontwikkelingswerk te blijven.

What businesses need product operations?

Het resultaat? Product Operation-teams staan voor een onmogelijke taak. Ze moeten ofwel elk team dwingen hun roadmaps opnieuw op te stellen in een gestandaardiseerde indeling (tijdrovend en foutgevoelig), ofwel proberen om zelf verschillende indelingen te consolideren (nog tijdrovender en foutgevoeliger).

De oplossing is niet om iedereen tot dezelfde tool te dwingen, maar om visualisatiebenaderingen op te stellen die geschikt zijn voor zowel productteams als belanghebbenden. Zo doen succesvolle organisaties dat:

Visualisatie bij de bron

In plaats van informatie tussen tools te kopiëren, visualiseren toonaangevende organisaties gegevens waar deze zich bevinden. Het ene productteam geeft bijvoorbeeld de voorkeur aan een bordweergave die is geordend op basis van ontwikkelingsfasen, terwijl een ander een tijdlijnweergave nodig heeft om complexe afhankelijkheden te beheren. Elk team volgt zijn eigen workflow, maar belanghebbenden kunnen een uniforme roadmapweergave bekijken met consistente informatie over doelen, fasen en tijdlijnen voor alle teams. Niet meer kopiëren en plakken tussen tools, geen handmatige updates meer op meerdere plaatsen.

Gemeenschappelijke elementen, verschillende weergaven

Het succes van consistente visualisaties begint met het begrijpen van je doelgroep. Hoewel productteams gedetailleerde informatie nodig hebben voor hun dagelijkse werk, richten belanghebbenden zich doorgaans op een kleinere reeks kritieke elementen waarmee ze de voortgang kunnen begrijpen en beslissingen kunnen nemen. Meestal komt het neer op een paar cruciale elementen:

  • Doelen waaraan het werk bijdraagt, zodat het leiderschap de voortgang in de richting van de bedrijfsdoelstellingen kan volgen
  • Huidige ontwikkelingsfase (Afvragen, Ontdekken, Maken, Impact), die een duidelijk beeld geeft van voortgang en volgende stappen
  • Verwachte tijdlijnen voor de levering, waardoor een betere coördinatie tussen teams en met externe belanghebbenden mogelijk is