“Product operating model” is een term die veel voorbijkomt, maar hij beschrijft iets specifieks: hoe een bedrijf zichzelf organiseert om producten te bouwen, niet alleen features op te leveren.
Gepopulariseerd door Marty Cagan (Silicon Valley Product Group), is het de standaardterm geworden voor wat sterke productbedrijven onderscheidt van bedrijven die simpelweg developers in dienst hebben.
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 op zich, 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
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, gevoed door direct contact met klanten en data.
Uitkomsten boven output
Succes is niet “we hebben dit kwartaal tien features opgeleverd.” Het gaat om of die features daadwerkelijk een resultaat opleverden dat voor het bedrijf telde.
Doorlopend contact met gebruikers en data
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, niet micromanaget
Leiderschap bepaalt het “waarom” en de kaders. Teams bepalen zelf het “hoe”, in plaats van te wachten tot ze precies te horen krijgen wat ze vervolgens moeten bouwen.
Waarom de meeste bedrijven nog niet zo werken
Oude gewoontes zijn hardnekkig: roadmaps bepaald door wie het hardst roept, niemand met echte zeggenschap over productbeslissingen, en “meer developers” behandeld als het complete antwoord op een leveringsprobleem.
Niets daarvan is een kwestie van developer-vaardigheden. Het is een structuurprobleem, en structuur is precies waar een product operating model op ingrijpt.
Hoe dit er in de praktijk uitziet bij Wise Minds
Elke Wise Minds product unit is vanaf dag één op dit model gebouwd: developers en product leiderschap die samenwerken met echte beslissingsbevoegdheid, niet een wachtrij tickets vanuit de backlog van een klant. Bekijk hoe de rollen samen passen voor de volledige uitleg.
Heb je al developers en wil je het operating model zonder een volledig nieuwe hire, bekijk dan software detachering. Begin je vanaf nul, bekijk dan developer inhuren.
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.
Niet per se, in elk geval niet meteen. Belangrijk is dat iemand echte zeggenschap heeft over productbeslissingen, ongeacht de titel, in plaats van dat die zeggenschap verspreid ligt over sales, engineering leads en wie het laatste verzoek indiende.
Ja, vaak zelfs makkelijker dan een groot team. De kern is beslissingsbevoegdheid en direct contact met gebruikers en data, niet teamgrootte. Een klein empowered team kan een veel groter team van featurebouwers voorbijstreven.
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 persoon die goed geïnformeerd is terwijl de rest een spec uitvoert.
