Publieke roadmap uit je issue tracker, drie kolommen

Een publieke roadmap is een lijst van wat jullie van plan zijn te bouwen, gepubliceerd waar klanten hem kunnen zien. Het woord dat het werk doet is van plan: een roadmap is een verzameling beloftes over de toekomst, en elk item erop is er een dat jullie zullen houden of waarvan zichtbaar zal worden dat jullie dat niet doen. Dat is de reden om er een te publiceren, en het is ook de reden waarom de meeste publieke roadmaps binnen een kwartaal verouderen. De versie die overleeft is klein, afgeleid uit data die jullie al onderhouden, en aan het andere eind verbonden met de changelog, zodat een belofte een feit wordt zonder dat iemand hem opnieuw invoert.

Waarvoor dient een publieke roadmap?

Een publieke roadmap vertelt een klant met een verzoek dat het verzoek is gehoord, voordat het wordt uitgebracht. Het is de vroege helft van het sluiten van de loop: “gepland” beantwoordt de vraag “heeft iemand dit gelezen”, en “in ontwikkeling” beantwoordt “gebeurt dit echt”. Geen van beide vervangt de laatste stap, de aanvrager inlichten wanneer het wordt uitgebracht, maar beide verminderen het aantal mensen dat ondertussen vraagt.

Het doet ook iets voor het team: het dwingt een publieke verplichting af, wat de goedkoopste bekende remedie is tegen een backlog dat stilletjes vierhonderd items vasthoudt die niemand zal bouwen.

Drie kolommen, in vaste volgorde, zijn genoeg. Een vierde kolom (“in overweging”, “onder beoordeling”, “backlog”) is waar goede bedoelingen een museum worden, en het is de eerste die klanten leren te negeren.

Zou jullie roadmap publiek moeten zijn?

Maak hem publiek als jullie hem klein en eerlijk kunnen houden; houd hem privé als het alternatief een lange lijst met misschiens is. De kosten van een publieke roadmap hebben niets te maken met het publiceren ervan: elk item erop is nu een vraag die iemand zal stellen, in support, in verkoopgesprekken en in verlengingsgesprekken. Tien items die jullie zullen bouwen zijn een activum. Zestig items die jullie misschien zullen bouwen zijn zestig toekomstige gesprekken over waarom niet.

Twee eerlijke redenen om niet te publiceren: jullie plannen veranderen sneller dan een kwartaal, of jullie concurrentie leest jullie roadmap zorgvuldiger dan jullie klanten. Beide zijn echt, en beide worden beantwoord door minder te publiceren in plaats van niets: alleen “in ontwikkeling”, met “gepland” intern gehouden, vertelt een aanvrager toch dat haar issue beweegt.

Hoe bouw je een publieke roadmap uit GitHub-issues?

Zet een label per kolom op de issues die jullie al bijhouden, en render de gelabelde issues als de roadmap. Niets wordt opnieuw ingevoerd, de roadmap kan niet van het werk afdrijven, en dezelfde issue die begon als klantverzoek beweegt door de kolommen zonder van identiteit te veranderen.

Het mechanisme, zoals wij het draaien:

1. Eén label per kolom, met vast prefix: roadmap:planned, roadmap:building, roadmap:shipped. Elke issue in een verbonden repository die er een draagt verschijnt in die kolom. Een issue zonder een van deze staat niet op de roadmap, wat de meeste issues zijn, wat correct is.
2. De kolommen zijn een geordende array, altijd in dezelfde volgorde. Gepland, in ontwikkeling, uitgebracht. Geen map geïndexeerd op naam, zodat een lezer (of een widget) nooit naar de volgorde hoeft te raden.
3. Als een issue twee labels draagt, wint de verst gevorderde. Iemand zal roadmap:shipped toevoegen voordat roadmap:planned wordt verwijderd; een toestandsmachine gestuurd door “welke webhook laatst binnenkwam” zou het item in verschillende kolommen zetten afhankelijk van de leveringsvolgorde. Beslissen op basis van alleen de labelverzameling maakt het antwoord hetzelfde ongeacht hoe events binnenkomen.
4. Uitgebracht is een labelstatus zoals de andere. De kaart verplaatst wanneer de issue roadmap:shipped krijgt, of wordt gesloten terwijl die het label draagt. De kaart zelf linkt niet naar de changelog-entry; de entry, opgesteld uit de pull request die de issue sloot, is waar de details staan.
5. Serveer hem als data. De roadmap is een JSON-document met die drie kolommen, gepubliceerd naast de changelog-feed met dezelfde cache-headers, zodat een docsite, een widget of een statuspagina hem kunnen renderen zonder tweede integratie. De feed-documentatie heeft de exacte vorm.

Een label is weinig gevraagd van een maintainer, en het is de hele integratie. Geen bord om gesynchroniseerd te houden, geen apart tool om in te loggen, en het verzoek dat de klant registreerde is het item op de roadmap; wanneer het wordt uitgebracht, is het hetzelfde item.

Wat zou een publieke roadmap niet moeten bevatten?

Hij zou geen datums, inschattingen, of iets moeten bevatten waar jullie je over negen maanden voor zouden schamen als ernaar gevraagd wordt. Datums zijn de klassieke fout: een kwartaal op een roadmap wordt een verplichting in een verkoopdeck wordt een ticket genaamd “jullie zeiden Q3”. Kolommen zeggen genoeg. “In ontwikkeling” betekent al “snel genoeg dat iemand eraan zit”.

Hij zou ook de interne backlog niet moeten bevatten. Een roadmap met driehonderd items is een zoekprobleem, geen belofte, en de klant die haar verzoek op positie 212 vindt heeft iets geleerd dat jullie haar niet wilden vertellen.

Hoe verbindt de roadmap met de changelog?

De roadmap en de changelog beschrijven dezelfde issues van twee kanten, één voor de toekomst en één voor het verleden. Niemand verplaatst een kaart op een apart bord. Een maintainer verandert het label op de issue waar hij al in werkte, de entry wordt opgesteld uit de pull request, en wanneer een mens die entry goedkeurt wordt een aanvrager van wie de widget-feedback die issue werd daar ingelicht. De kaart naar uitgebracht verplaatsen blijft een eigen stap, het roadmap:shipped-label, dus maak het onderdeel van dezelfde review; het goedkeuren van de entry doet het niet voor jullie.

Dit is dezelfde loop die het artikel over de feedback-loop beschrijft vanuit de changelog-kant; de roadmap is wat de klant er middenin van ziet. Het overzicht changelog-tools dekt welke producten een roadmap-weergave bieden en welke het als apart bord behandelen, wat het verschil is dat beslist of hij accuraat blijft.

Hoe ziet een goede publieke roadmap eruit?

Hij ziet er kort uit, en elk item erop is een issue die iedereen kan openen. De test is of een klant van een item naar de discussie erachter kan gaan, en van een uitgebracht item naar de entry die beschrijft wat er daadwerkelijk is veranderd. Een roadmap die een lijst van featurenamen is zonder ingang is een brochure.

Een uitgewerkt voorbeeld, als de JSON die een widget zou ophalen:

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

Drie items over drie kolommen zijn een prima goede publieke roadmap. Hij zegt wat er komt, wat er gebeurt, en wat er is gebeurd, en elke regel is controleerbaar. Vijf andere opzetten, van Now/Next/Later tot uitkomstgericht, staan met voorbeelditems in product roadmap voorbeelden.

FAQ

Hoeveel items zou een publieke roadmap moeten hebben? Zo weinig als jullie kunnen verdedigen. Onder de tien in totaal is normaal voor een klein product; meer dan dertig in “gepland” is een backlog verkleed als roadmap.

Zou een publieke roadmap datums moeten hebben? Nee. Kolommen communiceren volgorde zonder een deadline te creëren. Als een klant een datum nodig heeft, is dat een gesprek, geen roadmap-item.

Zouden klanten moeten stemmen op roadmap-items? Stemmen meten wie kwam opdagen, niet wat ertoe doet. Een reactie op de issue die de workaround uitlegt die ze vandaag gebruiken is meer waard dan vijftig stemmen, en kost de stemmer iets, wat het punt is.

Wat gebeurt er met een geannuleerd roadmap-item? Verwijder het label en zeg waarom op de issue. Een publiek “we gaan dit niet doen” maakt deel uit van de loop, en het is het bericht dat de meeste teams nooit versturen.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken