Prioriteren product features

Waarom is prioriteren zo moeilijk?

Alhoewel het stellen van de juist prioriteiten eenvoudig klinkt, is dit in de praktijk vaak lastig. Een paar redenen waarom:

• Appels met peren. Features en wensen prioriteren is en blijft toch vaak het vergelijken van entiteiten die op verschillende manieren bijdragen aan de business doelstellingen. Een Tell-a-Friend feature kan zorgen voor meer gebruikers, maar uitbreiden naar bijvoorbeeld andere landen ook. En een gebruiksvriendelijkere app zorgt ervoor dat klanten meer gebruik maken van de app en langer klant blijven. Een goed AI chatbot bespaart kosten én zorgt voor meer tevreden klanten. En investeringen in een schaalbare architectuur maakt het bedrijf meer toekomstvast. Hoe vergelijk je die goed met elkaar?

• Key stakeholders die veel invloed hebben in de organisatie. Denk aan de CEO die vindt dat er iets moét gebeuren. De grote klanten die klaagt om weg te gaan als een feature niet wordt gebouwd. Op zich kunnen de gevraagde wensen zinvol zijn. Maar dat hoéft niet altijd....

• Persoonlijke belangen. Dit heb ik veel gezien. Een Marketing manager die als persoonlijke target heeft en daarom een bepaalde feature wil. Op een Manager Operations die geen wijzigingen wil omdat het de stabiliteit en performance in gevaar brengt. Of gewoon 'niet kan'...

• Consistentie. Voor een goede prioritering is het van essentieel belang dat dit steeds op een zelfde manier gebeurt. Als de ene maand klanttevredenheid de belangrijkste driver is, de andere maand kostenbesparing, en de volgende maand omzet, en de maand daarna internationale expansie, krijg je een dwarrelstrategie. Medewerkers haken af, de klant begrijpt het ook niet meer.

Verschillende manieren om te prioriteren

Er zijn veel manier om te komen tot prioriteiten. WSJF is een zeer veel gebruikte methode, en wordt daarom uitgebreid besproken. Daarnaast zijn er echter ook andere methoden zoals de impact versus effort matrix, de RICE methode en MoSCoW. Hieronder wordt dieper ingegaan op deze methoden.

Deze drie factoren, plus de Job Size, worden vervolgens met de stakeholders gepokerd met de Fibonacci getallen. Voor wie die niet kent: pokeren is gezamenlijk een getal vaststellen, en de Fibonacci getallen zijn: 1, 2, 3, 5, 8, 13, 21, 40, 60, 100. Oftewel: steeds de laatste twee voorgaande getallen optellen. Van belang daarbij is dat per kolom (beoordelingscriterium) er steeds één uitgekozen wordt die een 1 heeft. Dus die relatief weinig waarde toevoegt of heel simpel te implementeren is. Zie figuur onder. En dan is het een kwestie van optellen van de eerste drie en delen door de Job Size. Et voilá, daar is een prioritering. Alles wat veel waarde oplevert en weinig kost: doen! Veel waarde, hoge effort: (als volgende) doen. Lage waarde en lage effort: later. Lage waarde, hoge effort: u raad het al.. Niet doen.

Wat maakt WSJF handig?

Hierboven is beschreven hoe WSJF werkt. Maar waarom is dit nu handig?

1. Appels met appels. Door alle Features op dezelfde criteria te beoordelen, op en opdezelfde manier te beoordelen, hebben we een betere vergelijking tussen de Features. Helemaal 'appels met appels' wordt het natuurlijk nooit, maar we komen wel dichtbij

2. Consistentie. We beoordelen telkens op exact dezelfde manier. Met dezelfde mensen. Dus die Feature van de CEO die met zijn handen op tafel slaat, of van een stakeholder die met een grote bos bloemen langskomt? Die gaan ook gewoon dit proces in.

3. Gezamenlijkheid. Het beoordelen van de Features gebeurt in overleg met alle (belangrijke) stakeholders. Iedereen kan dus zijn zegje doen. En vooral: er vindt discussie plaats in het team waarom een bepaalde Feature meer waarde levert dan een andere. Dit leidt - als het goed is - tot een gedragen besluit.

4. Make it small! Een kernprincipe van WSJF is dat er gedeeld wordt door de Job Size. Per definitie scoren Features die snel te implementeren zijn dus een hoog getal. De uitdaging is dan ook om Features zo te definiëren dat ze met in beperkte hoeveelheid tijd te realiseren zijn.

5. It's all relative. Het gaat bij WSJF niet zozeer de absolute benadering, maar vooral ook de onderlinge relatieve vergelijking. Welke Feature levert meer dan de andere? Een valkuil is om te veel de discussie aan te gaan over de getallen. 'Bij concurrent A komt x% uit de zakelijke markt. Dus we moéten een zakelijke propositie ontwikkelen want dat levert ons ook x% van de omzet'.

6. OKR's. Bij het beoordelen worden de Features in het team besproken. Vaak gebruik ik daar een soort 'one-pager' template voor per Feature waarbij degene die de Feature inbrengt ook moet aangeven wat de Feature voor waarde levert. Deze input kan ook heel goed worden gebruikt om OKR's vast te stellen. En bovendien voorkomt het dat Features worden ingebracht met een zeer rooskleurig beeld.

Valkuilen van WSJF

Is WSJF de heilige graal? Zeker niet. Er is zeker ook een aantal mogelijke valkuilen. Ik benoem er een paar uit eigen praktijk:

• Biased input. Het is zeer menselijk. Je 'eigen' Features net iets mooier maken dan ze zijn. Misschien omdat ze in je target staan. Of gewoon omdat je er zelf heel enthousiast van wordt. Om dit te voorkomen is het aan te raden de benefits van een Feature intern door iemand te laten beoordelen die relatief onafhankelijk is. Bijvoorbeeld een controller. Een andere maatregel is de inschattingen die worden gebruikt bij het beoordelen van een Feature te gebruiken als KPI/OKR na oplevering. Mijn ervaring is dat de schattingen dan al snel een heel stuk realistischer worden.

• Alles op 1. Een gevaar uit de praktijk is dat veel features op vrijwel alle 'opbrengst' criteria hoog worden beoordeeld. Dus dat alle features hoog worden gerankt op zowel Business Value, Time Criticality als op Opportunity Enablement / Risk Reduction. In dat geval is alles even belangrijk en bepaalt feitelijk alleen de job size de prioritering. Dit is te voorkomen door echt voor alle features in elke kolom een '1' te scoren. Het gaat immers altijd om relativiteit.

• Niet meetbaar. Als de impact van een nieuwe Feature niet meetbaar is, dan is het eigenlijk altijd goed. Of altijd niet goed. Het punt is: je wéét het gewoon niet. Dus, mijn advies: alleen Features bespreken als je van te voren weet hoe je die kunt meten. Met een dashboard die voor iedereen inzichtelijk is. Natuurlijk, er kunnen uitzonderingen zijn. Maar ik ken ze eigenlijk niet. Vaak is het claimen dat iets niet meetbaar is, vooral het verstoppen. Geen verantwoordelijkheid durven nemen.

• Niet gedragen door directie. Klinkt misschien voor de hand liggend. Maar als een directie naast het WSJF proces nog andere Features in de Product Roadmap zet, dan wordt het fuzzy. En demotiverend.

• Geen duidelijke visie en overal OKR's. Misschien wel belangrijker dan je initieel denkt. Maar hoe ga je Features beoordelen op hun bijdrage als je niet goed weet wat de visie van het bedrijf en product is? Of als die vaag zijn? Of elk kwartaal volledig anders?

• Opportunity Enablement / Risk Reduction. In mijn ervaring altijd heel lastig om deze goed te sizen. In de praktijk noem ik deze ook wel eens anders om iets gerichtere discussies te hebben.

Wat is WSJF?

WSJF is een manier van prioriteren, met als uitgangspunt dat de features die de meeste waarde opleveren per geïnvesteerde tijd, als eerste worden gebouwd. Met als achterliggende idee dat op deze manier zo snel mogelijk waarde wordt geleverd aan de klanten. Dit principe wordt 'Cost of Delay' genoemd: hoe langer je wacht met het opleveren van een functionaliteit, hoe meer waarde verloren gaat.

De WSFJ probeert verschillende features op een zelfde manier te beoordelen. Dit gebeurt door enerzijds de waarde van de Feature of Epic te beoordelen, en anderzijds de verwachte effort die het kost om deze Feature te realiseren. De waarde van de Feature wordt volgens de theorie van SAFe / WSJF als volgt beoordeeld:

• User / Business Value: wat levert de Feature op? Hoeveel draagt het bij aan de winst / omzet?

• Time Criticality: is er een harde deadline? Bijvoorbeeld omdat er wetgeving aan komt waaraan simpelweg voldaan moet worden? Of omdat er bijvoorbeeld een datum is dat gebruikers doorgaans een dienst afnemen (denk aan een zorgverzekering einde van het jaar, of een zomervakantie boeken in maart/april). Of simpelweg omdat bepaalde software of hosting niet meer ondersteund wordt wat een gevaar oplevert voor de stabiliteit van het platform.

• Opportunity Enablement / Risk Reduction: de lastigste van de drie. Het gaat hier met name om zaken als: stelt dit ons in staat eenvoudiger te schalen? Verminderen we hiermee onze risico's? Creëren we hiermee nieuwe opportunities in de markt?

De 2x2 matrix Impact versus Effort

De Impact versus Effort matrix plot de features in een matrix waarin de verwachte opbrengsten van een feature worden afgezet tegen de inspanning. Er zijn ook andere varianten van deze matrix zoals de Urgency versus Importance matrix.

RICE: reach, impact, confidence, effort

De RICE methode is een iets verfijnde versie van de effort-impact matrix.

• Reach: hoeveel gebruikers verwachten we te bereiken met de nieuwe feature? Bijvoorbeeld uitgedrukt in aantal transacties per maand of aantal nieuwe klanten.

• Impact: hoeveel draagt het bij aan het behalen van strategische doelstellingen. Uit te drukken in minimaal (0,25) tot 3 voor enorme impact.

• Confidence: hoeveel vertrouwen is er dat de feature succesvol zal zijn? Varieert van (theoretisch) 0% tot 100%.

• Effort: hoeveel kost het om de feature te ontwikkelen?

Net als bij de WSJF worden hier de 'opbrengst' factoren gedeeld door de effort. Enige verschil is dat hier de factoren boven de streep met elkaar worden vermenigvuldigd in plaats van opgeteld. Dit betekent dat in het geval een van de drie factoren erg laag is, de totale score ook erg laag zal zijn.

MoSCoW

Een old school manier van prioriteren waarin onderscheid wordt gemaakt naar Must haves, Should have, Could have en Will not have. Eenvoudig toe te passen, maar in de praktijk biedt dit weinig houvast. Ten eerste omdat er in de praktijk vaak veel Features in de Must have categorie worden ingedeeld, anderzijds om de wijze waarop de prioritering plaatsvindt niet eenduidig is.

Hoe vertalen we de prioritering naar een roadmap?

Bijna! De prioritering geeft een goede input voor de roadmap. Maar helemaal 1:1 vertalen? Helaas, dat gaat niet. Dat kan verschillende oorzaken hebben.

• Te veel Features in een beperkte aantal teams vallen. Natuurlijk is er dan een optie om te gaan schuiven met teams. Of Features te beleggen bij nieuwe teams. Of teams in andere omgevingen / code bases te laten werken. Maar het is goed om te realiseren dat dat inwerktijd kost. Een team is immers pas na zo'n 6 - 12 maanden pas weer vol op stoom. En soms kan het ook gewoon niet. Omdat niet alle developers alle code beheersen.

• Technische afhankelijkheden. Sommige Features moeten nu eenmaal afhankelijk van een andere Feature.

• En toch is dit belangrijker. Tja, dat klinkt niet echt onderbouwd. Maar het kan voorkomen. Dat kan ook prima. Mits dit maar met het team wordt besproken en besloten. En er niet één iemand zijn mening (telkens) doordrukt.

En dus: welk model?

Elk model heeft zijn eigen kenmerken en beperkingen:

• WSJF: zeer gedegen methode, zorgt voor 'buy-in' van deelnemers, is object. En zeker goed bruikbaar in de praktijk. Vergt wel aardig wat discipline en commitment (tijd) van de deelnemende stakeholders

• Impact/effort matrix: levert snel visueel resultaat. Minder objectief dan WSJF en daarom minder goed toepasbaar voor prioriteren veel features

• RICE: geeft goede discriminerend onderscheid tussen de features.

• MoSCoW: achterhaalde methode. Maar handig voor bijvoorbeeld een eerste grove prioritering.