Product owner, werk aan je strategische helikopterblik
Het idee van Scrum is simpel, maar briljant: je voegt iedere sprint de functies toe die het meeste waarde hebben en je levert aan het eind van iedere sprint een werkend product op voor je gebruikers. De belofte is dat je zo je budget altijd optimaal spendeert aan het leveren van business value. Maar iedereen die aan digitale producten werkt, weet dat de praktijk weerbarstiger is…
Agile zijn is essentieel voor het omgaan met de dynamiek van een techproject, je budget effectief in te zetten en verandering te omarmen, ook als hij halverwege je project gebeurt.
Maar het idee dat snel features uitrollen de beste manier is om te leren wat de markt wil, is bijna altijd een utopie. Ja, in theorie kun je iedere 2 weken een nieuw versie releasen, usage-data verzamelen en op basis daarvan je backlog aanpassen of eventueel een pivot maken. In de praktijk werkt dit vrijwel nooit. Trouwens, ook als dit wel lukt zijn er betere manieren om te leren. Het bouwen en dan weer schrappen van features is namelijk veel duurder dan het vooraf valideren ervan.
Hoe ‘done’ is ‘done’?
Meestal zorgen wetgeving, infrastructuur, procedures en koudwatervrees dat het resultaat van een sprint de markt zelfs helemaal niet – of pas veel later – bereikt. Onder druk van de omstandigheden zwakt de definition of done al snel af naar iets als ‘opgeleverd naar Acceptatie’. Ondertussen wordt, door allerlei interne factoren, het MVP steeds groter en wordt de launch uitgesteld.
En zonder releases geen gebruiksdata. Maak je je voor je marktkennis dus afhankelijk van je releasesnelheid, dan neem je een groot risico. Agile werken werkt dus alleen in combinatie met ‘top-down’, strategisch nadenken. Want waar harde data ontbreken, heeft ook een agile ontwikkelproces visie, strategie en kaders nodig.
De 4 belangrijkste risico’s
Het ontwikkelen van een digitaal product begint als een idee, vaak in het hoofd van een CEO, founder of businessmanager, een businesscase en voldoende investeringsgeld bij elkaar komen. Maar een idee en een businesscase zijn altijd theorie.
Het is de taak van de product owner om het investeringsbudget zo efficiënt mogelijk te gebruiken om het idee om te zetten in concrete marktwaarde en zo de businesscase werkelijkheid te laten worden. Als dat klinkt als een enorme uitdaging, is dat omdat het ook een enorme uitdaging is.
De risico’s die een bedrijf loopt bij het matchen van een innovatie aan de markt zijn serieus en kunnen worden ingedeeld in 4 categorieën:
- Het product werkt, maar klanten kopen/gebruiken het niet (het ‘waarderisico’). Je zult niet de eerste zijn die een prachtige oplossing bouwt voor een niet-bestaand probleem…
- Het product voorziet in een behoefte, maar gebruikers vinden of begrijpen het niet (het ‘bruikbaarheidsrisico’)
- Het idee is goed, maar je krijgt het technisch niet voor elkaar (‘Haalbaarheidsrisico’ en ‘schaalbaarheidsrisico’)
- De oplossing werkt, klanten gebruiken het, maar jouw organisatie kan het qua sales, marketing, service of legal niet ondersteunen, of het businessmodel als geheel functioneert niet (dit is het ‘levensvatbaarheidsrisico’)
De vraag die iedereen jou als product owner steeds stelt is: ‘Wat moeten we nu gaan bouwen?’
Bij het iedere keer weer vinden van een goed antwoord, is het slim tackelen van deze risico’s cruciaal.
Eén klein probleempje…
Er is één klein probleempje: je hebt geen idee. Je weet pas of een feature aanslaat als je hem uitrolt en de beschikking krijgt over usage data. En dat is dus makkelijker gezegd dan gedaan. Aan het begin van het project heb je sowieso nog geen data en komt de beslissing dus neer op jouw strategische visie op klant, markt en product.
Je moet die visie niet alleen ontwikkelen, maar ook goed onderbouwen met argumenten. Ten eerste moet je namelijk je opdrachtgever of CEO overtuigen, die ook een visie heeft op waar het heen moet. Meestal zijn dit mensen met een sterke persoonlijkheid, die niet bang zijn om stellig te zijn over wat ze willen en wat niet. Heeft de CEO besloten dat een bepaalde feature de absolute moneymaker gaat worden, maar wil jij toch het team eerst andere dingen laten bouwen? Dan heb je een pittige discussie voor de boeg waarin je met objectieve en stevige onderbouwing moet komen.
Aan de andere kant wil je developmentteam aan het werk. Begaafde, gedreven professionals die zinvol, uitdagend werk willen doen. En die al na een halve dag zonder zo’n uitdaging onrustig worden. Ook zij hebben overal een mening over en willen dus een onderbouwd verhaal horen over waarom je bepaalde keuzes (niet) maakt.
Alles is een aanname
De onderbouwing van je visie haal je uit een brede, strategisch blik op risico’s. Want aan het begin van het project is dan misschien alles een aanname, maar niet in iedere aanname zit evenveel risico. Investeer dus wat tijd in het in kaart brengen van je belangrijkste aannames en het risico dat erbij hoort.
Stel bij ieder deel van de businesscase de vragen:
- Welke aanname ligt hieronder?
- Wat is de impact op het project als deze aanname niet blijkt te kloppen?
- Hoe kan ik deze aanname zo goedkoop mogelijk testen (spoiler: veel van de aannames kun je testen zonder iets te bouwen)
Zo vind je uit waar de grootste risico’s zitten. En welke aannames je dus als eerste moet gaan testen. Iedere aanname heeft zijn eigen meest effectieve manier van testen, maar of je nu deskresearch doet, interviews, data-analyse of UX-workshops: ze kosten allemaal tijd. Plan die tijd in je roadmap.
Lanceer het eerder dan comfortabel voelt
En, over roadmap en runway gesproken: hoe kort je runway ook is, toch is het slim om hem niet helemaal te gebruiken voor het bouwen van een MVP. Want een app live zetten is prachtig, maar in feite begint het werk dan pas. Nu je klanten je software echt gaan gebruiken, krijg je eindelijk je usage data en kun je dus eindelijk leren van echte gebruikers. Het zou zonde zijn als dat precies het moment is dat ook je ontwikkelbudget op is. Stel dus altijd doelen voorbij het MVP en lanceer je MVP het liefst voordat het comfortabel voelt. Het binnenhalen van de eerste 10 betalende klanten bijvoorbeeld. Of het aanboren van een nieuwe nichemarkt. Communiceer deze doelen duidelijk met je stakeholders en reserveer er budget voor.
Samen werken aan de strategische helikopterblik
Dit alles betekent dat je je tech-team af en toe bij moet sturen en je CEO moet vragen om wat budget aan markt- en klantresearch uit te geven. Dat lijkt inefficiënt, maar door nu kennis te verzamelen en slim strategisch na te denken, bespaar je later in het traject veel budget.
Durf, om je CEO en investeerders aan boord te krijgen bij deze aanpak, ook aannames in hun visie bloot te leggen en neem deze mee in je validatieplan. Zo ontwikkel je samen een ‘strategische helikopterblik’ op je product, waarbij je tijdens het hele project in de gaten houdt hoe het product bij de bedrijfsstrategie past, hoe de investering het best rendeert en hoe het product uiteindelijk geld zal opleveren.
Wil je meer lezen over onze visie op de rol van de PO? En wil je onze 4 gouden tips om als product owner succesvolle projecten op te leveren en te werken aan je eigen status in de organisatie? Bekijk dan ons whitepaper Waarom je geen product owner wilt worden (en 4 dingen die je moet doen als je al PO bent en succesvolle innovaties wilt afleveren)
