Een roadmapdocument schrijven dat de trade-offs uitlegt
5 min leestijd
De meeste roadmapdocumenten zijn een gerangschikte lijst zonder zichtbare redenering. Dat werkt prima tot een stakeholder vraagt waarom feature B boven feature A staat, en het eerlijke antwoord een mix is van onderbuikgevoel en wie het laatst heeft gevraagd, wat niet goed standhoudt in de vergadering. Een PM die een roadmap met zes punten presenteert aan een kamer vol stakeholders, elk met hun eigen favoriete feature, kan de hele vergadering besteden aan het mondeling verdedigen van de volgorde in plaats van te verwijzen naar redenering die al op de pagina stond.
Waarschuwing
Een gerangschikte lijst zonder redenering is geen besluit, het is een plaatshouder voor een. De eerste lastige vraag in de kamer onthult of de rangschikking daadwerkelijk doordacht was.
Een roadmap die zijn eigen volgorde niet kan uitleggen, is geen roadmap. Het is een lijst die wacht om opnieuw bevochten te worden.
Waarom een ongemotiveerde reden elke keer opnieuw wordt bevochten
Rangschikken op onderbuikgevoel kan juist zijn, maar niemand anders kan het beoordelen, dus heeft elke stakeholder met een andere intuïtie grond om terug te duwen. Zonder zichtbare redenering herhaalt hetzelfde trade-offgesprek zich in de volgende vergadering, en de daaropvolgende. Een roadmap gepresenteerd als een kale gerangschikte lijst nodigt precies het soort debat uit dat een goed onderbouwde versie voorkomt, omdat er niets op de pagina staat waarmee een sceptische stakeholder iets kan, behalve het geheugen van de PM over waarom elke keuze werd gemaakt.
Stel je een kwartaalreview van de roadmap voor waarin een engineeringlead vraagt waarom een feature met kleinere impact boven een feature staat met duidelijk groter verwacht bereik. Als het eerlijke antwoord alleen in het hoofd van de PM leeft, "het voelde gewoon urgenter", verandert de vergadering in een real-time onderhandeling met wie het hardst duwt. Als dezelfde vraag al op de pagina beantwoord is, "feature A staat hoger ondanks kleiner bereik omdat het een partnerintegratie met een contractuele deadline volgende maand ontgrendelt", verschuift het gesprek naar of die redenering standhoudt, wat een veel productievere plek is om naartoe te gaan.
Voor: rangschik features op instinct, presenteer de lijst, besteed de vergadering aan het vanaf nul verdedigen van de volgorde.
Na: geef Claude de kandidaat-features met hun inspanning en impact, krijg een gerangschikte roadmap terug met de redenering per plek uitgeschreven, en loop de vergadering binnen met de trade-offs al op de pagina.
Een werkwijze voor een roadmap met zichtbare redenering
- 1
Som kandidaten op met echte inspannings- en impactschattingen
Geef echte cijfers, ook ruwe, engineeringweken voor inspanning, verwachte getroffen gebruikers voor impact, in plaats van vage labels zoals "groot" of "klein". Vage input levert een rangschikking op zonder iets stevigs erachter.
- 2
Vraag om een rangschikking met een genoemde reden per item
Vraag om twee zinnen onderbouwing per feature, niet alleen een gerangschikte lijst. De redenering is wat de roadmap verdedigbaar maakt in een kamer vol mensen met hun eigen meningen.
- 3
Vraag wat de rangschikking zou veranderen
Zodra je een eerste versie hebt, vraag welke features het dichtst bij wisselen van plek staan, en wat waar zou moeten zijn om dat te laten gebeuren. Dit is waar de echte trade-offs, niet alleen de uiteindelijke volgorde, zichtbaar worden.
- 4
Toets de redenering aan wat stakeholders daadwerkelijk belangrijk vinden
Vergelijk de gestelde redenering met wat je weet dat de mensen in de kamer belangrijk vinden, omzet, retentie, technische schuld. Een rangschikking die alleen inspanning en impact weerspiegelt, kan het echte gesprek nog altijd missen.
Hier zijn 6 kandidaat-features met ruwe inspanningsschattingen en verwachte impact. Rangschik ze in een Q3-roadmap, en schrijf twee zinnen die elke rangschikking onderbouwen.
”Als bekend is dat een specifieke stakeholder één dimensie zwaarder laat wegen dan andere, zeg, engineeringleiderschap geeft meer om vermindering van technische schuld dan deze rangschikking nu weerspiegelt, is het de moeite waard om Claude te vragen de rangschikking te wegen met die prioriteit expliciet benoemd, in plaats van één rangschikking te presenteren die impliciet veronderstelt dat iedereen dezelfde prioriteiten deelt.
Engineeringleiderschap heeft technische schuld gesignaleerd als een grotere prioriteit dan deze rangschikking nu weerspiegelt. Laat me zien hoe de volgorde zou veranderen als het verminderen van technische schuld even zwaar zou wegen als gebruikersimpact, zodat ik beide versies kan vergelijken voor de vergadering.
”
In Claude Tutorial
De redenering achter een rangschikking zichtbaar maken is overdraagbaar.
Een onderbuikbeslissing omzetten in een met gestelde, controleerbare redenering gaat breder dan roadmaps. De app heeft hier een volledige les over, met oefeningen die overgaan op elke prioriteringsbeslissing die je moet verdedigen.
Wanneer twee features werkelijk dicht bij elkaar liggen
Soms is het eerlijke antwoord dat twee features dicht genoeg bij elkaar liggen dat beide volgordes verdedigbaar zijn. Dat is de moeite waard om rechtstreeks te zeggen in plaats van valse zekerheid te presenteren over een specifieke rangschikking. Een roadmap die elke rangschikking met identieke zekerheid presenteert, nodigt een stakeholder uit om hard te duwen op een nek-aan-nekrace alsof het een vaststaand besluit was, terwijl de eerlijkere en uiteindelijk overtuigendere zet is om het vanaf het begin als een nek-aan-nekrace te benoemen.
Tip
Vraag Claude te signaleren welke rangschikkingen nek-aan-nek zijn versus duidelijk vaststaand. Een roadmap die eerlijk is over zijn nek-aan-nekraces is geloofwaardiger dan een die elke rangschikking met dezelfde zekerheid presenteert.
Kijkend naar deze gerangschikte lijst van 6 features, welke paren liggen dicht genoeg bij elkaar dat de volgorde redelijkerwijs zou kunnen omslaan? Wees specifiek over wat er zou moeten veranderen om dat te laten gebeuren.
”Voor een paar dat werkelijk nek-aan-nek staat, is het de moeite waard te vragen of er een praktische tiebreaker is buiten inspanning en impact om die het met meer vertrouwen zou beslechten, een afhankelijkheid, een seizoensdeadline, een toezegging al gedaan aan een klant, in plaats van de roadmap te laten rusten op een willekeurige muntopgooi-volgorde.
Deze twee features staan nagenoeg gelijk op inspanning en impact. Is er een praktische tiebreaker, een afhankelijkheid tussen hen, een externe deadline, iets voorbij de cijfers, dat de ene duidelijk de betere keuze zou maken om eerst te bouwen?
”Lees verder
- Supporttickets Omzetten in Geprioriteerde Thema's: waar de impactschattingen waarop een roadmaprangschikking steunt vaak vandaan komen.
- Een Verschenen Feature Omzetten in Release Notes en een Stakeholderupdate: wat er gebeurt zodra een roadmapitem daadwerkelijk verschijnt.
- Een PRD Schrijven Vanuit een Eenregelig Featureverzoek: een roadmapplek omzetten in een specificatie zodra die geprioriteerd is.