Ein Changelog ist der günstigste Marketingkanal, den die meisten SaaS-Firmen links liegen lassen. Du lieferst ohnehin aus; das Changelog macht das nur sichtbar: für Nutzer, die abwägen, ob das Produkt noch lebt, für Interessenten, die dich mit der Konkurrenz vergleichen, und für dein eigenes Team, wenn es zurückschaut, was tatsächlich fertig geworden ist. So führst du eines, das gelesen wird.
1. Schreib für Nutzer, nicht für Git
Der häufigste Fehler ist, Commit-Messages zu veröffentlichen. „Auth-Middleware refaktoriert“ sagt einem Kunden nichts. Jeder Eintrag sollte die einzige Frage beantworten, die der Nutzer hat: Was kann ich jetzt, was vorher nicht ging?
Schwach: „Bulk-Export-Endpunkt zu API v2 hinzugefügt.“ Besser: „Du kannst jetzt alle Rechnungen auf einmal exportieren: Markiere beliebig viele Rechnungen und wähle Exportieren.“
Nenne zuerst das Ergebnis, dann den Weg dorthin. Hat eine Änderung kein Ergebnis, das Nutzer sehen, gehört sie wahrscheinlich in ein internes Log, nicht ins Changelog.
2. Ordne jeden Eintrag einer Kategorie zu
Changelogs werden überflogen und selten von oben nach unten gelesen. Ein paar einheitliche Labels (Neu, Verbessert, Behoben) führen Leser in Sekunden zu dem, was sie interessiert. Erfinde keine Taxonomie mit zwölf Kategorien: Drei oder vier Labels decken fast alles ab, und Einheitlichkeit zählt mehr als Präzision. Die meisten Changelog-Tools bilden das als Typfeld an jedem Eintrag ab (Kookee bringt diese Kategorien von Haus aus mit), und über dieses Feld filtert dein Frontend die Einträge auch nach Typ.
3. Wähle einen Rhythmus, den du durchhältst
Ein Changelog, dessen letzter Eintrag vier Monate alt ist, ist schlimmer als gar keins: Es sieht verlassen aus. Nimm dir einen Takt vor, den du halten kannst: wöchentlich, wenn du laufend auslieferst, pro Release, wenn du bewusst versionierst. Bündeln hilft: Drei kleine Fixes ergeben einen ordentlichen Wocheneintrag, und ein großes Feature verdient einen eigenen.
Der Trick für die Disziplin: Mach das Schreiben des Changelogs zu einem Teil des Release-Prozesses statt zu etwas, woran man hinterher denkt. Steht ein Feature nicht im Changelog, ist es nicht ausgeliefert.
4. Gib Einträgen stabile URLs und Versionen
Jeder Eintrag braucht einen eigenen Slug und eine dauerhafte URL. Dann lassen sich Einträge aus Support-Antworten, Social-Media-Posts und Vertriebs-E-Mails verlinken, und über solche Links wird ein Changelog größtenteils gelesen. Versionierst du dein Produkt, schreib die Version an den Eintrag; wenn nicht, reicht das Datum.
5. Zeig es dort, wo deine Nutzer schon sind
Die öffentliche Changelog-Seite ist das Archiv; Leser bringt erst die Verbreitung. Diese Wege lohnen sich:
In-App-Ankündigung: ein kleines Banner oder Badge, wenn etwas Nennenswertes erscheint. Daher kommen die meisten Aufrufe.
Ein RSS-Feed: kostet kaum etwas, und Power-User und Aggregatoren nutzen ihn.
E-Mail-Digests nur für große Releases: höchstens monatlich, sonst merkst du es an den Abmeldungen.
Kommt das Changelog aus einer Content-API, ist die Ausspielung auf mehreren Kanälen trivial: Dieselben Einträge speisen die öffentliche Seite, das In-App-Panel und den Feed, und nichts wird doppelt geschrieben.
6. Lass Leser reagieren
Ein Changelog ist auch ein Feedback-Instrument. Einfache Reaktionen auf Einträge zeigen dir, welche Releases angekommen sind, und den Leser kosten sie fast keine Mühe. Kommentare gehen weiter: Nutzer sagen dir, wenn die „Verbesserung“ ihren Workflow kaputt gemacht hat, und das hörst du besser am Changelog-Eintrag als in einer Kündigungsumfrage. Wenn du Kommentare zulässt, beantworte sie auch.
7. Schließ den Kreis mit deinem Feedback-Board
Am meisten bewirkt der Changelog-Eintrag, der seinen Ursprung nennt: „Ihr habt es euch gewünscht (47 Stimmen auf unserem Feedback-Board), und jetzt ist es live.“ Verlinkst du ausgelieferte Einträge zurück auf die Feature-Wünsche, aus denen sie entstanden sind, belegt das, dass die Feedback-Schleife echt ist, und die Nutzer schreiben daraufhin besseres Feedback. Liegen Feedback-Board und Changelog im selben System, ist das ein Link zwischen zwei Einträgen statt eines Copy-and-paste-Rituals.
8. Übersetze, wenn dein Produkt übersetzt ist
Verkaufst du in mehreren Sprachen, sagt ein rein englisches Changelog allen anderen Kunden leise, dass sie Kunden zweiter Klasse sind. Changelog-Einträge sind kurz und sachlich, die günstigsten Inhalte, die du je übersetzen wirst. Mit einem Content-Backend, das Sprachversionen pro Eintrag kennt, hängst du Übersetzungen an denselben Eintrag, und jeder Leser bekommt seine Sprache. Parallele Changelogs musst du dann nicht pflegen.
9. Lösch keine Historie
Ein altes Changelog ist ein Beleg: für dein Tempo, für deinen langen Atem und dafür, wie du frühere Störungen gehandhabt hast. Behalte alles, halte es durchsuchbar und die URLs stabil. Interessenten, die dich gründlich prüfen, lesen weiter zurück, als du denkst.
Was du vermeiden solltest
Aufgeblasene Marketingsprache. „Ein revolutionäres, völlig neues Erlebnis“ für eine neu gestaltete Einstellungsseite verspielt Vertrauen. Schlichte Sprache gewinnt.
Stille Breaking Changes. Hat sich ein Verhalten so geändert, dass bei jemandem ein Workflow oder eine Integration nicht mehr funktionieren könnte, ist das Changelog das Mindeste an Vorwarnung: Sag, was sich geändert hat, wann und was zu tun ist.
Screenshots von Text. Schreib echten Text und nimm Bilder nur zur Unterstützung; Text ist durchsuchbar, übersetzbar und barrierefrei.
Ein Changelog, das nur Entwickler pflegen können. Braucht ein Eintrag einen Pull Request und ein Deployment, hinken die Einträge den Releases hinterher. Schreib die Einträge in einem Dashboard, liefere sie per API aus und lass deine App sie rendern. Ein Update zu schreiben sollte Minuten dauern, keinen Release-Zyklus.
Eine Minimalvorlage
Für jeden Eintrag:
Titel: das Ergebnis für den Nutzer, eine Zeile
Typ: Neu | Verbessert | Behoben
Version/Datum
Text: 2–6 Sätze – was sich geändert hat, warum es zählt, wo man es findet
Link: Doku oder das Feature selbstFang damit an, halte den Rhythmus ein Quartal lang und schau dann auf die Zahlen: Aufrufe der Changelog-Seite, Zahl der Reaktionen, geöffnete In-App-Ankündigungen. Ein gutes Changelog ist kein Pflichtdokument. Es ist der laufende Beleg, dass die Entscheidung für dein Produkt richtig war, jede Woche neu.