Iedereen weet nu wel dat een bedrijf in een snel veranderende markt wendbaarheid moet zijn om op tijd in te kunnen inspelen op allerlei ontwikkelingen. Agile werkprocessen stimuleren die wendbaarheid en worden daarom vaak ingezet. Om over langere periodes een koers vast te kunnen houden is een lineaire roadmap handig. Dat lineaire schuurt alleen met de iteratieve agile aanpak.
Het probleem met roadmaps
De Agile Way of Working heeft voordelen als je de productontwikkeling wilt kunnen afstemmen op de veranderende vraag vanuit de markt en wensen vanuit het bedrijf; helderheid over wat wanneer wordt gedaan, de mogelijkheid om nieuwe wensen snel mee te nemen en een proces om obstakels vroegtijdig te benoemen en tackelen. Productroadmaps bieden op een andere manier ook helderheid en inzicht; over wat de visie is, waar we naartoe gaan en welke stappen we nemen om daar te komen.
De uitdaging is vaak om de Agile methodes goed te laten aansluiten op een productroadmap, en omgekeerd: De productplanning in een roadmap wordt lineair weergegeven en kan niet goed de build-measure-learn cyclus verbeelden die een agile ontwikkelproces juist zo effectief maakt. Een productroadmap kan dan als ongewenst gevolg hebben dat de organisatie gaat verwachten dat de oplevering ook lineair en tijdsgebonden is, wat de gewenste flexibiliteit en wendbaarheid in de weg staat. Maar alleen werken vanuit een actuele backlog borgt onvoldoende dat de productontwikkeling op koers blijft met de lange termijn doelen.
Is er een manier om Agile werken en roadmapplanning goed op elkaar te laten aansluiten?
Nut en noodzaak
Een productroadmap is een strategisch document op hoog niveau dat de algemene fasen van de ontwikkeling van een product in kaart brengt. Het is goed om de visie van een product op zo’n manier te verbinden met de bedrijfsdoelstellingen, dat de verschillende stakeholders inzicht hebben in de route die afgelegd gaat worden om de geformuleerde doelen te halen, en om de status van de productontwikkeling op een bepaald moment van te kunnen aflezen. Een productroadmap wordt gemaakt als resultaat van strategische planning, en verwerkt de inzichten van de verschillende stakeholders in een strategische routekaart. Het documenteert zowel de strategische aanpak die wordt gehanteerd als de algemene doelstellingen van een product en inzicht daarin is nodig. Een goede productroadmap kan in principe een hele organisatie op weg helpen met de realisatie van de bedrijfsstrategie.
De bouwstenen
Er zijn verschillende manieren om roadmaps te maken, maar wat je kiest om op je roadmap te zetten hangt af van voor wie je de roadmap maakt; wat wil je dat blijft hangen bij je publiek. Dat bepaalt uiteindelijk ook de opzet, het formaat en het soort informatie dat je in de roadmap wilt zetten. Traditioneel bevat een productroadmap een meerdere van de volgende punten:
- Productvisie – wat je wilt dat jouw product in de toekomst wordt
- Strategische aanpak – een plan dat tot in redelijk detail beschrijft wat men gaat doen om de visie te realiseren.
- Doelen – een in tijd bepaald doel dat op een helderen en eenduidige manier kan worden gemeten.
- Initiatieven – grotere thema’s die functies verenigen die moeten worden gebouwd en geïmplementeerd om het doel te bereiken.
- Features – een stuk functionaliteit vanhet product dat deel uitmaakt.
- Time-frames – globale tijdseenheden waarin, bij benadering een bepaald stuk functionaliteit wordt opgeleverd of een bepaald doel wordt behaald.
- Status markers – om aan te geven wat de status van een onderdeel is (complete, late on schedule, future).
- Meeteenheden – om te kunnen bepalen waaruit een bepaald doel dat behaald moet worden bestaat: e.g. churn rate of organisch verkeer.
Een standaard roadmap
For employees of the [company name] who want to use their expertise to their full potential and as effectively as possible, [product name] is a workflow management system for the visa and travel document application process, that guides the users through their activities in such a way that they can optimally apply their expertise, helping them to accurately perform tasks in compliance with laws and regulations.
Unlike the current process, this software fully digitizes all steps for handling visa- and travel document-application process, enabling more controlled processing of all applications, and more manageable and much speedier processing of the bulk of applications.
The endgoal is fourway:
- Replace the current end of lifecycle software
- Support the transition of the organisation from a decentralised to a centralised one.
- Support the transition of of the current application process from analog to digital
- Optimise the application workflow process
Deze productvisie volgt het format voor een positioneringsstatement dat Geoffrey Moore in zijn boek Crossing the Chasm geeft.
who (statement of the need or opportunity),
[product name] is a (product category)
that (statement of key benefit – compelling reason to buy).
Unlike (primary competitive alternative),
our product (statement of primary differentiation).
In twee korte zinnen wordt kernachtig geformuleerd wat het product voor wie wil zijn en hoe het zich wil onderscheiden.
De productvisie biedt zo een kader voor de productontwikkeling en formuleert het hogere doel dat we willen bereiken.
Wie is in de lead: DE PO OF DE PM?
De product manager (PM) en product owner (PO) houden zich beiden bezig met het communiceren van productdetails. Een PO is verantwoordelijk voor product value, backlog, en user stories, maar het belangrijkste verschil is dat een PO rol alleen binnen scrum-projecten bestaat. Een PO is dus vooral een rol en een Product manager (PM) een beroep. Een product manager kan ook een product owner zijn binnen een scrum-team, maar de PM levert een product roadmap met de visie en strategie, terwijl een PO werkt aan een product backlog en de business / technische requirements specificeert. De Product manager is dus degene die verantwoordelijk is voor de product visie en het opstellen van de product roadmap.
Maar als de rollen gescheiden zijn ontkom je er niet aan hier gezamenlijk werk van te maken.
Hoe kom je aan de input voor je productroadmap
Een product roadmap begint bij het formuleren van je strategie en visie op het product. Interne en externe stakeholders, klanten en afnemers, bieden inzichten die bruikbaar zijn, net zoals ontwikkelingen in de markt en die van concurrenten. Maar uiteindelijk is een visie ook iets wat vanuit een persoonlijk standpunt wordt gemaakt: hier sta jij, vanaf dit punt kijk je naar de toekomst heb je daar een bepaald perspectief op. Dat verwoord je in de productvisie.
Natuurlijk moet je de verwachtingen van alle belanghebbenden en teamleden wel op één lijn kunnen brengen, wat vaak nog een heel gedoe is, maar dan is er ook voldoende input om aan de roadmap te beginnen werken.
Meestal heb je meerdere teams die betrokken zijn bij roadmapping, zoals een development team, UX, test team, marketing, operationeel team, etc. Al die mensen in die teams helpen het product realiseren. Een type roadmap zal dan ook gericht zijn om al deze teams te begeleiden tijdens het ontwikkelingsproces. Het lukt niet om in een roadmap de veelheid aan informatie die voor alle verschillende teams relevant is duidelijk en eenvoudig te houden. Hoe ga je in een overzicht helderheid geven wat de strategie achter de productontwikkeling is, hoe die evolueert en verandert al naar gelang de product- en de marktvereisten, wat een hoge en wat een lage prioriteit heeft en wat alle afhankelijkheden per onderdeel tussen de teams zijn, welke doelen door welk team wanneer gehaald moeten worden, en aan welke bedrijfsdoelstellingen die gelieerd zijn
Wat je presenteert, en hoe je welke informatie communiceert wil je laten afhangen van je publiek, je stakeholders. Je wilt steeds helder de veranderingen door de tijd heen kunnen duiden, zodat voor iedereen duidelijk blijft hoe we ergens gekomen zijn en wat vanaf een bepaald punt de route wordt.
Het is een behoorlijke klus om van een redelijk complex product, dat in meerdere releases zijn uiteindelijke vorm moet krijgen, de productroadmap op te stellen.
En dan ga ik nog voorbij aan het probleem dat na verloop van tijd inzichten veranderen en dan nog een keer en weer opnieuw, en dat de roadmap die veranderende inzichten moet verbeelden. De beste plannen liggen ook meestal in de kast te verstoffen omdat de plannen waarmee je echt werkt steeds averij oplopen door onvoorziene omstandigheden die alles weer overhoop gooien. Roadmapping kan, als je niet oppast een hoofdpijndossier worden omdat je roadmap voortdurend dreigt te verouderden, of onmogelijk is te beheren.
Een productroadmap kan helaas ook niet een one-size-fits-all vorm hebben; zoals gezegd maakt het uit voor wie en met welk doel je een roadmap maakt: dat bepaalt het type, de inhoud en mate van detaillering. De roadmap heeft meestal meer dan één doelgroep, net zoals je product.
Wat laat je hoe zien?
Gaat het je om de strategische koers te bespreken dan moet je focussen op de algemene visie en strategie, niet op de kleine details en overwegingen die voor je ontwikkelteam van belang kunnen zijn. Die kleinere stukjes informatie zijn waardevol maar ontnemen wel het zicht op de strategische keuzes: het moet duidelijk en makkelijk te begrijpen blijven. Voor je ontwikkelteam geldt wellicht meer dat ze ook willen weten welke keuzes ze qua techniek moeten maken, maar vooral wat ze de komende periode moeten gaan ontwikkelen.
Een goede roadmap heeft net de juiste mate van abstractie om wel inzicht te geven in wanneer wat mag worden verwacht, zonder dat het je teveel vastpint op harde datums of het je ontwikkel- en realisatieteam verhindert om flexibel te bepalen wanneer wat het best kan worden opgepakt.
Interne roadmaps zijn over het algemeen bedoeld voor leidinggevenden, het productieteam en verkoop, die een meer strategische kijk hebben op de gegevens. Dus de presentatie van roadmap moet zich dan richten op visie, strategische doelen, tijdlijnen, marktcijfers, enzovoort. Het ontwikkel- en implementatieteam is vaak meer geïnteresseerd in de tactische aspecten, deadlines, en technische details van de uitvoering. Om voor hun echte waarde te hebben moet de roadmap inzicht geven in low-level informatie, over concrete onderdelen van een product, de features of technische aspecten. Een verkoopteam zal weer vooral geïnteresseerd in die combinatie van productkenmerken en productvoordelen die voor klanten interessant zijn. Dan moet uit de roadmap blijken wanneer welke product features beschikbaar komen. Maar je ontwikkelteam moet uit dezelfde roadmap kunnen halen wat er moet worden voorbereid en waar al aan gewerkt moet worden.
Niet zo verwonderlijk dat veel Product Managers worstelen om zowel de strategisch als de uitvoerende aspecten goed in een roadmap samen te brengen, zeker als die ook nog voor een agile team werkbaar moet blijven. Want in het ergste geval verwordt een roadmap tot een release kalender van features, wat dus geen roadmap is, maar waar het senior management je graag aan houdt ook als er veranderingen moeten worden doorgevoerd!
En natuurlijk betrek je je team bij het maken van inschattingen, maar het punt is, en iedere product manager weet dit, dat de data die je op je roadmap zet compleet verzonnen zijn, en het is hoogst onwaarschijnlijk je team ook maar iets zal opleveren zoals geschetst.
Wat is een aanpak om een goede eenduidige roadmap te maken die makkelijk up to date is te houden, kan omgaan met veranderingen en daarbij niet de strategische doelen en kritische tijdschema’s uit het oog verliest?
Lean roadmapping: Now – Next – Later
Een roadmap wil je idealiter lezen als een gids, een routekaart, die het doel op lange termijn aangeeft, helder maakt wat de stappen zijn om daar te komen en flexibel genoeg is om wijzigingen in aan te brengen die nodig zijn om relevant, want up to date, en nuttig te blijven.
Daarom kan je een roadmap het best concentreren op 3 zaken (die dan wel alle 3 op een of andere manier helder moeten worden verbeeld):
- Je visie: wat willen we zijn & waar willen we eindigen.
- Je kompas: in welke algemene richting moeten we gaan om daar te komen.
- Je plan: de reeks stappen, richtlijnen en instructies die we zullen nemen om er daadwerkelijk te komen.
Het ‘Now-Next-Later‘ format is ontworpen om de essentie van deze 3 aspecten in een simpel kader te tonen, maar biedt ook ruimte voor flexibiliteit en dwingt niet af dat je je moet vastpinnen op harde einddata in een toekomst waar je je nog op moet kunnen aanpassen.
De 3 fasen toegelicht:
Met de ‘Now-Next-Later’ aanpak splits je de roadmap op in drie secties (Now, Next, Later) zodat je op elk moment aan stakeholders het volgende detailniveau kan laten zien, terwijl er ruimte blijft om aanpassingen te maken. De roadmap kan gaandeweg worden aangepast om in lijn te blijven met veranderende in- en externe omstandigheden.
Deze fase omvat waar het team in de eerstvolgende sprints aan gaat werken en wat zal worden opgenomen in de eerstvolgende release. In deze fase kan het team specifieke details laten zien over functionaliteit en features, inclusief ontwerpen, prototypes, werkende software en demonstraties.
Deze fase is wat breder dan de Now-fase. Het omvat de zakelijke uitdagingen die het team van plan is aan te pakken in een volgende release van het product. Maar omdat het verder weg is, is het wat algemener omschreven en daarmee flexibeler dan de Now-fase.
Deze Next fase beschrijft bijvoorbeeld waar we aan denken voor een volgende release en waar we nog feedback van klanten van moeten krijgen, en over de high level aanpak op de komende ontwikkelingen. Die fase moeten we wel voorbereiden om de Objectives and Key Results ( OKR’s) goed op te stellen en de stories in de refinement meet te kunnen nemen. Want anders gaat die volgende release niet voldoen aan wat de stakeholders en klanten als ‘business value’ willen opgeleverd krijgen. Er mogen geen features blijven liggen omdat ze nog niet scherp omschreven zijn en daarom niet opgepakt kunnen worden wanneer het nodig is.
In deze fase kijken we op een hoger niveau naar wat er nog veel verder in de toekomst gaat komen. Waar denken we nog meer aan, maar wat komt nog niet in de eerstvolgende releases? Wat is waar in de komende 1 tot 3 jaar behoefte aan is, of waar we mee te maken zullen krijgen. Bijvoorbeeld hoe het technologisch landschap gaat veranderen, wat we moeten doen om ons product voor te bereiden op veranderingen in de markt of andere acties die nodig zijn om waarde te kunnen blijven bieden.
Deze Now, Next, Later-aanpak stelt je in staat om ook conceptueel met klanten en stakeholders te praten over bedrijfsproblemen en technologische keuzes, zonder dat je je al vroeg hoeft vast te leggen op specifieke functionaliteit die beschikbaar gaat komen. Hetzelfde format kan zowel op hoog abstract niveau worden gebruikt voor strategische discussies, als voor het bepalen welk werk moet worden voorbereid voor je ontwikkelteam.
Andere voordelen van deze vorm van roadmapping:
- Het pint je niet vast op specifieke data maar richt zich meer op periodes van tijd en intentie.
- Het verdeelt werk in brokken en helpt zo te begrijpen wat je in welke volgorde moet doen en voorbereiden.
- Het is makkelijk te reorganiseren en is makkelijk om de strategische punten te overzien (bijvoorbeeld tussen “Now” en “Next”) om zo het stappenplan aan te passen zonder alles weg te gooien of opnieuw te moeten beginnen.
- Het kan worden toegepast op veel verschillende soorten situaties (jaarlijkse strategische planning, een re-design / digitaal transformatieproject of een product van de grond af aan).
- Het biedt duidelijk te begrijpen kaders voor iedereen, niet alleen mensen uit het ontwikkelteam, en kan zo breed worden ingezet bij de realisatie.
Benieuwd naar hoe een Now-Next-Later roadmap concreet kan worden ingevuld? In deze vervolg-post heb ik een paar voorbeelden uitgewerkt van hoe een Now-Next-Later roadmap kan worden.
Verantwoording: Er is online veel te vinden over roadmap planning en de Now – Next – Later aanpak. In plaats van daar mijn eigen verhaal aan toe te voegen heb ik de beste informatie die ik vond vertaald en daar deze samengestelde post van gemaakt. De voornaamste bronnen die ik heb gebruikt zijn: