Wat is een software roadmap?
Een roadmap is een overzicht van waar jouw software de komende periode heen gaat. Geen strakke planning met datums en mijlpalen, maar een levend document dat antwoord geeft op één vraag: "Wat doen we wel, wat doen we hierna, wat doen we later, en wat is nog niet zeker?"
Het is een instrument dat oorspronkelijk uit de productontwikkeling komt en daar inmiddels gemeengoed is. Maar ook bij maatwerksoftware — waar jij de opdrachtgever bent en wij de ontwikkelpartner — werkt het verrassend goed. Het sluit het gat tussen "vandaag een mailtje sturen over een bug" en "ooit nog dat grote nieuwe onderdeel bouwen".
Het probleem zonder roadmap
Veel softwaretrajecten lopen volgens een ritme dat je vast herkent. Een directielid heeft een idee, stuurt een mail. Een gebruiker vindt een bug, meldt het via WhatsApp. Iemand bedenkt tijdens een meeting dat het wel handig zou zijn als de software ook X kon. En al die ideeën zweven rond — in inboxen, in agenda's, in hoofden.
Wat ontbreekt is overzicht. Niet alleen voor jou als opdrachtgever, maar ook voor het ontwikkelteam. Zonder roadmap weet de ontwikkelaar pas dat er een groot stuk werk eraan komt op het moment dat het dringend wordt. Geen tijd meer om architectuur vooraf goed te overdenken, geen ruimte om bestaande code daar alvast op aan te passen, geen ruimte om kennis op te bouwen rond een nieuwe technologie die je gaat gebruiken.
De gevolgen zijn voorspelbaar: ad-hoc oplossingen die later opgeschoond moeten worden, sprongen in scope die niet kloppen met wat technisch handig is, en frustratie aan beide kanten omdat de ander "altijd alles te laat doorgeeft".
Now / Next / Later: het framework
De roadmap die we in Cody gebruiken volgt het Now / Next / Later-framework dat in 2014 door Janna Bastow (medeoprichter van ProdPad) werd gepopulariseerd. Zij beschreef het destijds als reactie op de eindeloze Gantt-charts waar productteams aan vasthielden — en die altijd verkeerd bleken. Bron: ProdPad — The Now-Next-Later Roadmap.
Het idee is simpel: in plaats van te doen alsof we weten wanneer iets exact klaar is, groeperen we werk in tijdshorizons met steeds meer onzekerheid. We hebben er bij Cody een vierde emmer aan toegevoegd, "Future", voor ideeën die nog te ver weg liggen om over te beslissen:
- Now — hier werken we nu aan. Korte termijn, dagen tot weken. Wat er op de werkbank ligt.
- Next — hierna aan de beurt. Komende maand of twee. Concreet genoeg om over te beslissen.
- Later — wel gepland, geen datum. Meestal binnen dit kwartaal of halfjaar. Optioneel met kwartaal-tag.
- Future — misschien ooit. Verkennend. Geen belofte dat het echt gaat gebeuren.
Wat dit zo effectief maakt is dat de mate van detail en zekerheid afneemt naarmate je verder de toekomst in kijkt. Now-items zijn helder en uitvoerbaar. Future-items zijn richtingen, geen plannen. Dat is eerlijk — dat is hoe softwareontwikkeling daadwerkelijk werkt.
Hoe het werkt in Cody
Issues op de roadmap zetten
Issues in Cody beginnen meestal in de backlog — alles wat ooit gemeld of bedacht is. Vanuit de backlog open je een dialoog waarin je een of meerdere openstaande issues zoekt, selecteert en in één keer aan een emmer toevoegt (eventueel direct met een kwartaal-tag). Niet alles hoeft op de roadmap: kleine bug-fixes en snelle aanpassingen lopen gewoon door de backlog. De roadmap is voor zaken waar je vooruit over wilt nadenken.
Drag-and-drop tussen emmers
Prioriteiten veranderen — en dat is geen probleem. Een item in Later kan verschoven worden naar Next als het urgenter wordt, of juist andersom als iets toch even kan wachten. Het bord werkt als een Kanban: sleep een kaartje van de ene kolom naar de andere. De volgorde binnen een kolom is ook aanpasbaar, zodat de bovenste items de hoogste prioriteit hebben.
Optioneel: kwartaal-tag
Soms wil je toch iets meer houvast geven dan "later". Aan elk item op de roadmap kun je een kwartaal-tag hangen — bijvoorbeeld Q3 2026. Je krijgt de keuze uit de eerstvolgende zes kwartalen. Geen exacte datum, wel een globale richting. Daarmee weet het ontwikkelteam: dit zou rond dat kwartaal aan de beurt moeten zijn. Handig voor capaciteitsplanning, niet zo strikt dat het bij scope-wijziging direct misgaat.
Bucket-tag op de issuelijst
In de issuelijst zie je per regel direct in welke emmer een issue zit (met optioneel het kwartaal erbij op desktop). Dus als iemand door de openstaande issues scrolt, ziet hij of zij meteen: "dit staat in Next, dat komt er binnen een paar weken aan". Geen apart tabblad openen, geen vragen aan een PM.
Voor jou als opdrachtgever: jouw ambities op één plek
Het belangrijkste voordeel van een roadmap voor jou is dat je niets meer hoeft te onthouden. Elke keer dat je denkt "we moeten ook eens X gaan doen", zet je het op de roadmap in de juiste emmer. Geen losse mailtjes meer, geen agendanotities die je later niet meer terugvindt, geen "ik dacht dat ik dat ergens had opgeschreven".
Daarnaast geeft het je grip op je eigen tempo. Als de roadmap leeg is in Now en Next, is dat een teken: óf we leveren op tempo, óf er liggen kansen die je nog niet hebt benoemd. Als er juist te veel in Now staat, is dat een teken dat er prioriteiten moeten — niet alles kan tegelijk. De roadmap dwingt je vriendelijk om keuzes te maken die je toch al maakt, maar nu zichtbaar.
En misschien wel het belangrijkste: het maakt je ambities expliciet. Veel opdrachtgevers hebben wel een visie waar de software heen moet, maar die zit vooral in hun hoofd. Door dat op te schrijven in Later- en Future-items wordt het bespreekbaar — voor je team, voor stakeholders, voor ons als ontwikkelpartner.
Voor de ontwikkelaar: vooruit kunnen denken
Dit is waar veel opdrachtgevers het belang van de roadmap onderschatten. Een goede ontwikkelaar werkt niet alleen aan wat nu moet, maar houdt rekening met wat eraan komt. Dat heeft een paar concrete redenen:
- Architectuurkeuzes vooraf — als we weten dat over twee maanden een groot nieuw onderdeel komt, kunnen we de keuzes die we nu maken daar al op afstemmen. Andersom is het ingewikkeld: code die net is geschreven voor situatie A moet alsnog herschreven worden voor situatie B die je had kunnen voorzien.
- Refactoring en technical debt — weet je dat er iets groots aankomt op een bepaald deel van de software? Dan is het slim om dat deel daarvoor op te schonen. Zonder vooruitzicht: ad-hoc patchwerk dat zich opstapelt.
- Capaciteitsplanning — wij plannen onze beschikbaarheid en die van eventuele specialisten (denk aan iemand met diepe AWS-kennis voor een infra-migratie) vooruit. Een roadmap geeft daar inzicht in.
- Kennisopbouw — als er een feature aankomt die een specifieke technologie of integratie vereist die we nog niet eerder hebben gedaan, kunnen we daar vroegtijdig research in steken. Dat scheelt fouten en tijd op het moment dat het echt moet.
- Beslissingen koppelen — soms heeft een Later-item gevolgen voor een Now-item ("als we dat later toch doen, zou ik dit nu anders bouwen"). Zonder zichtbare roadmap mis je die afhankelijkheden.
Met andere woorden: de roadmap is niet alleen een communicatie-instrument, het is een planningsinstrument voor de ontwikkelaar. Hoe meer wij vooruit kunnen kijken, hoe doordachter de software wordt en hoe minder herstelwerk later. Dat is geen luxe — het is de manier waarop softwareontwikkeling op de lange termijn kostenefficiënt blijft.
Wat de roadmap níet is
Voor de duidelijkheid: een roadmap in Cody is geen sprint-planning. We werken niet met sprints van twee weken waarin een vaste hoeveelheid werk afgemaakt moet zijn — dat past niet bij de manier waarop maatwerksoftware in de praktijk loopt, met zowel ad-hoc bugs, lopend onderhoud en grotere features tegelijkertijd.
Het is ook geen commitment. Een item in Later betekent niet "dit gaan we doen". Het betekent "dit is een serieuze richting waar we over willen blijven praten". Bij elke verschuiving is heronderhandelen prima — sterker nog, dat is precies waar de roadmap voor bedoeld is. Roman Pichler beschrijft dit als de "goal-oriented roadmap": gericht op richting en doelen, niet op een lijst af te vinken features. Bron: Roman Pichler — The Goal-Oriented Product Roadmap.
Beginnen met een roadmap
Heb je nog geen roadmap en wil je er een opzetten voor jouw project? Een goede start is:
- Loop de backlog door en pak er de issues uit die meer zijn dan een snelle fix. Plaats ze in een eerste emmer op gevoel.
- Schrijf op wat niet in de backlog staat — de ambities die alleen nog in je hoofd zaten. Plaats ze in Later of Future.
- Verschuif net zolang tot het klopt: Now is het meest urgente werk, Next volgt direct, Later is de richting voor dit jaar, Future is verkennend.
- Plan een korte review elke 4–6 weken om de roadmap actueel te houden. Tussendoor schuiven en toevoegen mag altijd.
De beste roadmap is de roadmap die je daadwerkelijk gebruikt. Liever vier kort doordachte emmers die elke maand kloppen, dan een uitgebreide Gantt-chart waar niemand meer naar kijkt.
Werk je met Coding Agency? Dan zit de roadmap al klaar in Cody — vraag ons om je rond te leiden. Werk je nog niet met ons en wil je weten hoe wij dit voor jouw software inrichten? Plan een vrijblijvend kennismakingsgesprek.
