Een product operating model beschrijft hoe een bedrijf zich organiseert om producten te bouwen: wie beslist wat er gebouwd wordt, hoe die beslissingen tot stand komen en hoe teams worden afgerekend op resultaat. De term is gepopulariseerd door Marty Cagan van Silicon Valley Product Group.
Hieronder lees je wat een product operating model inhoudt, de kernprincipes, hoe het verschilt van Scrum en hoe wij het bij Wise Minds toepassen, inclusief waar wij ons terughouden.
Wat is een product operating model?
Het is de operationele structuur achter hoe een bedrijf beslist wat er gebouwd wordt, wie dat beslist en hoe die beslissingen daadwerkelijk tot stand komen. Het is geen procesraamwerk en ook geen organogram. Het is de combinatie van teamstructuur, beslissingsbevoegdheid en werkwijze die bepaalt of een bedrijf structureel de juiste dingen bouwt.
De kernprincipes van het product operating model
Empowered productteams, geen feature teams
Een feature team krijgt een spec en bouwt die. Een empowered team krijgt een probleem om op te lossen en de ruimte om de beste oplossing te bepalen.
Uitkomsten boven output
Succes is niet tien opgeleverde features dit kwartaal. Het gaat erom of die features een resultaat opleverden dat voor het bedrijf telde.
Doorlopende discovery
Teams die verantwoordelijk zijn voor uitkomsten hebben een constante stroom van echt gebruikerscontact en gebruiksdata nodig, niet één onderzoeksfase aan het begin van een project.
Strategie die richting geeft
Leiderschap bepaalt het “waarom” en de kaders. Teams bepalen het “hoe”.
Waarom de meeste teams nog op aannames bouwen
De meeste klanten die wij spreken kennen de term niet en weten niet wat het van hen vraagt. Wat wij veel vaker zien is een team dat de volgende versie van het product bouwt op aannames en niets anders. Niemand controleert of de vorige release iets bewoog dat ertoe deed.
Hoe wij het product operating model toepassen bij Wise Minds
Wij volgen het niet als vast raamwerk. We gebruiken wat nuttig is en we zijn er zelf nog naartoe aan het bewegen.
Het begint met een strategische roadmap. Voordat we bouwen, bepalen we de uitkomsten per periode. Het maakt niet uit of een team intern is of in dienst van een ander bedrijf: de mensen moeten afgestemd zijn op de juiste uitkomst, niet op vanity metrics.
In veel klantomgevingen sluiten onze mensen aan bij de meetings van de klant. Als dat niet kan, bespreken we elke klantmeeting achteraf tot in detail. Ook betrekken we onze developers steeds meer bij productideeën, doelen en beslissingen.
Het werkt ook met een kleine, gedeelde opzet. Een product expert die voor meerdere teams werkt, kan snel van context wisselen en diep werk plannen voor elk product. Volgens onze ervaring is dat veel efficiënter. Hoe die gedeelde rollen samenpassen lees je in hoe wij een softwareteam structureren.
Product operating model vs. Scrum
In de praktijk botsen de twee. Scrum zet de klant buiten het team en voegt een product owner toe die de klant vertegenwoordigt. Zo plugt Scrum het team in op de wereld van de klant, en indirect op de klanten van de klant. Het product operating model gaat verder: het hele team, inclusief development, wordt betrokken bij de beslissing wat er gebouwd wordt. Beide combineren heeft zijn uitdagingen.
Waarom wij ernaartoe bewegen
Code schrijven gaat zo snel dat de bottleneck van een productteam verschuift naar leiderschap en richting. Als developers zelf kunnen bepalen wat ze hierna doen, valt die bottleneck weg. Een product manager of product owner hoeft geen enorme backlog klaar te hebben voordat een developer kan beginnen.
De moeilijkheid is dat je hiervoor een specifiek soort developers nodig hebt. Het lukt niet met developers die zich alleen richten op code schrijven.
Waar wij ons terughouden
Uitkomsten boven output en strategie die richting geeft zijn principes waar we volledig achter staan. Empowerment van het team wordt ook belangrijker, maar het betekent niet dat je een duidelijke lijn van aansturing verliest. Zonder die lijn verlies je verantwoording.
Doorlopend klantcontact vinden we ook niet per se noodzakelijk, en veel van onze mensen vragen er niet om.
Moet je naar een product operating model?
Ja. Laten we kijken wat het in jouw situatie zou betekenen. Wij geloven dat het kan leiden tot geweldige uitkomsten.
Een Wise Minds product unit is hoe wij er vandaag mee werken. Heb je al developers en wil je meer structuur eromheen, bekijk dan software detachering. Begin je vanaf nul, bekijk dan een ontwikkelteam inhuren. Lees ook het verschil tussen een product owner en een product manager.
Voor het verschil tussen teams die features aangereikt krijgen en teams die een uitkomst bezitten, zie feature team vs productteam.
Veelgestelde vragen
Is een product operating model gewoon Agile onder een andere naam?
Nee. Agile beschrijft hoe software gebouwd wordt, in sprints of iteraties. Een product operating model beschrijft wie beslist wat er gebouwd wordt en waarom. Je kunt Agile-ceremonies draaien zonder empowered productteams, en empowered teams hebben geen specifiek Agile-raamwerk nodig.
Hebben we een Chief Product Officer nodig om een product operating model te draaien?
Niet per se, in elk geval niet meteen. Belangrijk is dat iemand echte zeggenschap heeft over productbeslissingen, ongeacht de titel.
Kan een klein team een product operating model draaien?
Ja, vaak zelfs makkelijker dan een groot team. De kern is beslissingsbevoegdheid en een koppeling aan uitkomsten, niet teamgrootte.
Wat is het verschil tussen een feature team en een productteam?
Een feature team bouwt wat het te horen krijgt. Een productteam is verantwoordelijk voor een uitkomst en bepaalt zelf hoe die bereikt wordt.
Hoe verschilt dit van gewoon een goede product manager hebben?
Een sterke product manager helpt, maar het model is groter dan één rol. Het hele team moet de bevoegdheid hebben om beslissingen te nemen, niet slechts één goed geïnformeerd persoon terwijl de rest een spec uitvoert.