Öffentliche Roadmap aus dem Issue-Tracker, drei Spalten

Eine öffentliche Roadmap ist eine Liste dessen, was ihr zu bauen beabsichtigt, veröffentlicht dort, wo Kundinnen sie sehen können. Das Wort, das die Arbeit leistet, ist beabsichtigt: Eine Roadmap ist eine Menge von Versprechen über die Zukunft, und jeder Punkt darauf ist einer, den ihr entweder haltet oder sichtbar nicht haltet. Das ist der Grund, eine zu veröffentlichen, und es ist auch der Grund, warum die meisten öffentlichen Roadmaps innerhalb eines Quartals veralten. Die Version, die überlebt, ist klein, wird aus Daten abgeleitet, die ihr ohnehin pflegt, und ist am anderen Ende mit dem Changelog verbunden, sodass ein Versprechen zur Tatsache wird, ohne dass es jemand neu eingibt.

Wofür ist eine öffentliche Roadmap da?

Eine öffentliche Roadmap sagt einer Kundin mit einer Anfrage, dass die Anfrage gehört wurde, bevor sie ausgeliefert wird. Sie ist die frühe Hälfte des Loop-Schließens: “Geplant” beantwortet die Frage “hat das jemand gelesen”, und “In Arbeit” beantwortet “passiert das wirklich”. Keines von beiden ersetzt den letzten Schritt, der anfragenden Person bei Auslieferung Bescheid zu geben, aber beide verringern die Zahl der Leute, die in der Zwischenzeit nachfragen.

Sie tut auch eines für das Team: Sie erzwingt eine öffentliche Verpflichtung, was die günstigste bekannte Kur gegen ein Backlog ist, das still vierhundert Punkte hortet, die niemand bauen wird.

Drei Spalten, in fester Reihenfolge, reichen. Eine vierte Spalte (“wird geprüft”, “in Überlegung”, “Backlog”) ist der Ort, an dem gute Absichten zu einem Museum werden, und sie ist die erste, die Kundinnen lernen zu ignorieren.

Sollte eure Roadmap öffentlich sein?

Macht sie öffentlich, wenn ihr sie klein und ehrlich halten könnt; haltet sie privat, wenn die Alternative eine lange Liste von Vielleichts ist. Der Preis einer öffentlichen Roadmap hat nichts mit der Veröffentlichung selbst zu tun: Jeder Punkt darauf ist jetzt eine Frage, die jemand stellen wird, im Support, in Vertriebsgesprächen und in Vertragsverlängerungen. Zehn Punkte, die ihr bauen werdet, sind ein Aktivposten. Sechzig Punkte, die ihr vielleicht bauen werdet, sind sechzig zukünftige Gespräche darüber, warum nicht.

Zwei ehrliche Gründe, nicht zu veröffentlichen: Eure Pläne ändern sich schneller als ein Quartal, oder eure Konkurrenz liest eure Roadmap sorgfältiger als eure Kunden. Beide sind real, und beide werden beantwortet, indem man weniger statt nichts veröffentlicht: nur “In Arbeit”, mit “Geplant” intern gehalten, sagt einer anfragenden Person trotzdem, dass sich ihr Issue bewegt.

Wie baut man eine öffentliche Roadmap aus GitHub-Issues?

Setzt ein Label pro Spalte auf die Issues, die ihr ohnehin trackt, und rendert die beschrifteten Issues als Roadmap. Nichts wird neu eingegeben, die Roadmap kann nicht von der Arbeit abdriften, und dasselbe Issue, das als Kundenanfrage begann, wandert durch die Spalten, ohne seine Identität zu ändern.

Der Mechanismus, so wie wir ihn betreiben:

1. Ein Label pro Spalte, mit festem Präfix: roadmap:planned, roadmap:building, roadmap:shipped. Jedes Issue in einem verbundenen Repository, das eines davon trägt, erscheint in dieser Spalte. Ein Issue ohne eines davon ist nicht auf der Roadmap, was die meisten Issues sind, was korrekt ist.
2. Die Spalten sind ein geordnetes Array, immer in derselben Reihenfolge. Geplant, in Arbeit, ausgeliefert. Keine nach Namen indizierte Map, damit eine Leserin (oder ein Widget) die Reihenfolge nie erraten muss.
3. Trägt ein Issue zwei Labels, gewinnt das am weitesten fortgeschrittene. Jemand wird roadmap:shipped hinzufügen, bevor roadmap:planned entfernt wird; eine Zustandsmaschine, die sich nach “welcher Webhook zuletzt ankam” richtet, würde den Punkt je nach Zustellreihenfolge in verschiedene Spalten setzen. Die Entscheidung allein aus der Label-Menge zu treffen macht die Antwort unabhängig davon, wie Events eintreffen.
4. Ausgeliefert ist ein Label-Zustand wie die anderen. Die Karte wandert, wenn das Issue roadmap:shipped bekommt oder geschlossen wird, während es dieses Label trägt. Die Karte selbst verlinkt nicht zum Changelog-Eintrag; der Eintrag, entworfen aus dem Pull Request, der das Issue geschlossen hat, ist der Ort, an dem die Details stehen.
5. Liefert sie als Daten aus. Die Roadmap ist ein JSON-Dokument mit diesen drei Spalten, veröffentlicht neben dem Changelog-Feed mit denselben Cache-Headern, sodass eine Doku-Seite, ein Widget oder eine Status-Seite sie ohne zweite Integration rendern können. Die Feed-Dokumentation hat die genaue Form.

Ein Label ist eine kleine Bitte an eine Maintainerin, und es ist die ganze Integration. Kein Board, das synchron zu halten ist, kein separates Tool zum Einloggen, und die Anfrage, die die Kundin eingereicht hat, ist der Punkt auf der Roadmap; wenn er ausgeliefert wird, ist es derselbe Punkt.

Was sollte eine öffentliche Roadmap nicht enthalten?

Sie sollte keine Daten, Schätzungen oder irgendetwas enthalten, wonach ihr in neun Monaten ungern gefragt würdet. Daten sind der klassische Fehler: Ein Quartal auf einer Roadmap wird zu einer Verpflichtung in einem Vertriebs-Deck wird zu einem Ticket namens “ihr habt Q3 gesagt”. Spalten sagen genug. “In Arbeit” bedeutet bereits “bald genug, dass jemand daran sitzt”.

Sie sollte auch nicht das interne Backlog enthalten. Eine Roadmap mit dreihundert Punkten ist ein Suchproblem, kein Versprechen, und die Kundin, die ihre Anfrage auf Position 212 findet, hat etwas gelernt, das ihr ihr nicht sagen wolltet.

Wie verbindet sich die Roadmap mit dem Changelog?

Roadmap und Changelog beschreiben dieselben Issues von zwei Seiten, eine für die Zukunft und eine für die Vergangenheit. Niemand verschiebt eine Karte auf einem separaten Board. Eine Maintainerin ändert das Label auf dem Issue, an dem sie ohnehin gearbeitet hat, der Eintrag wird aus dem Pull Request entworfen, und wenn ein Mensch diesen Eintrag freigibt, wird eine anfragende Person, deren Widget-Feedback zu diesem Issue wurde, dort informiert. Die Karte nach “Ausgeliefert” zu verschieben ist trotzdem ein eigener Schritt, das Label roadmap:shipped, also macht es zum Teil desselben Reviews; die Freigabe des Eintrags erledigt das nicht für euch.

Das ist derselbe Loop, den der Artikel zum Feedback-Loop von der Changelog-Seite aus beschreibt; die Roadmap ist das, was die Kundin in der Mitte davon sieht. Die Übersicht Changelog-Tools deckt ab, welche Produkte eine Roadmap-Ansicht bieten und welche sie als separates Board behandeln, was der Unterschied ist, der entscheidet, ob sie akkurat bleibt.

Wie sieht eine gute öffentliche Roadmap aus?

Sie sieht kurz aus, und jeder Punkt darauf ist ein Issue, das jemand öffnen kann. Der Test ist, ob eine Kundin von einem Punkt zur Diskussion dahinter gelangen kann, und von einem ausgelieferten Punkt zum Eintrag, der beschreibt, was sich tatsächlich geändert hat. Eine Roadmap, die eine Liste von Feature-Namen ohne Zugang ist, ist eine Broschüre.

Ein durchgerechnetes Beispiel, als das JSON, das ein Widget abrufen würde:

{
  "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"
}

Drei Punkte über drei Spalten sind eine völlig gute öffentliche Roadmap. Sie sagt, was kommt, was passiert, und was passiert ist, und jede Zeile davon ist überprüfbar. Fünf weitere Layouts, von Now/Next/Later bis ergebnisbasiert, mit Beispielpunkten zeigt Product-Roadmap-Beispiele.

FAQ

Wie viele Punkte sollte eine öffentliche Roadmap haben? So wenige, wie ihr verteidigen könnt. Unter zehn über alle Spalten ist normal für ein kleines Produkt; mehr als dreißig in “Geplant” ist ein Backlog im Kleid einer Roadmap.

Sollte eine öffentliche Roadmap Daten haben? Nein. Spalten kommunizieren Reihenfolge, ohne eine Frist zu schaffen. Braucht eine Kundin ein Datum, ist das ein Gespräch, kein Roadmap-Punkt.

Sollten Kundinnen über Roadmap-Punkte abstimmen? Stimmen messen, wer aufgetaucht ist, nicht was zählt. Ein Kommentar auf dem Issue, der den Workaround erklärt, den sie heute nutzen, ist mehr wert als fünfzig Stimmen, und er kostet die abstimmende Person etwas, was der Punkt ist.

Was passiert mit einem gestrichenen Roadmap-Punkt? Das Label entfernen und auf dem Issue sagen, warum. Ein öffentliches “das machen wir nicht” ist Teil des Loops, und es ist die Nachricht, die die meisten Teams nie senden.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Entwicklerdokumentation, Changelog-Tools im Vergleich