Wie man ein neues Feature ankündigt (ohne Stille)

Die meisten Feature-Ankündigungen sterben in einem Kanal, den niemand zweimal liest: ein Tweet, der vorbeiscrollt, eine Release-Tag-E-Mail unter den anderen zwölf, die eine Abonnentin diese Woche bekommen hat, eine Slack-Nachricht in einem Channel, den die halbe Firma vor Monaten stummgeschaltet hat. Das Feature ist ausgeliefert. Fast niemand, der es genutzt hätte, hat davon erfahren. Das zu beheben liegt weniger daran, eine bessere Ankündigung zu schreiben, sondern den richtigen Kanal für die richtige Leserin zu wählen und die Menschen, die genau darum gebeten haben, direkt zu erreichen, statt darauf zu bauen, dass sie eine Rundfunknachricht bemerken.

Wo sollte ein neues Feature eigentlich angekündigt werden?

An mehr als einem Ort, weil „alle lesen denselben Kanal” nie stimmt. Ein Changelog- oder Feed-Eintrag bedient die Leserin, die nach eigenem Rhythmus nachschaut und das dauerhafte, datierte Protokoll will. Ein In-App-Hinweis bedient die Leserin, die das Produkt schon nutzt und das Feature heute nutzen würde, wenn sie davon wüsste. E-Mail bedient die Leserin, die aktuell nicht im Produkt ist, aber für das richtige Update zurückkäme. Social Media bedient Reichweite über bestehende Nutzerinnen hinaus, fast ohne Zielgenauigkeit.

Keiner der vier reicht allein. Das Changelog ist das eine Dokument, das jedes Release tragen sollte, unabhängig von der Größe, weil es das Protokoll ist, auf das alles andere zurückverweist; die anderen drei sind Verstärkung darauf, gewählt danach, wie groß das Feature tatsächlich ist.

Was sollte die Ankündigung zuerst sagen?

Das Ergebnis, nicht den Mechanismus. „Wir haben eine Caching-Schicht für den Reports-Endpoint gebaut” beschreibt, was das Team gebaut hat. „Reports laden jetzt in unter einer Sekunde” beschreibt, was sich für die Leserin geändert hat, und das ist der Satz, der zum Klicken bringt, weil er „was habe ich davon” im ersten Halbsatz beantwortet statt im dritten. Der Mechanismus gehört in den Changelog-Eintrag oder die Detailseite, nicht in die Überschrift.

Konkretes vor Adjektiven. „Ein schnelleres, leistungsfähigeres Reports-Erlebnis” sagt der Leserin nichts, worauf sie reagieren kann; „Reports laden jetzt in unter einer Sekunde und lassen sich nach Status filtern” sagt genau, was sich geändert hat und was sie ausprobieren sollte. Die zweite Version wirkt auch glaubwürdiger, weil eine vage Behauptung genau so klingt, wie Marketingtext klingt, wenn es nichts Konkretes zu sagen gibt.

Wie unterscheidet sich das von einer Produkt-Update-E-Mail?

Überschneidend, aber nicht identisch. Produkt-Update-E-Mail behandelt den E-Mail-Kanal im Detail, samt Rhythmus, Betreffzeilen und wann ein Digest einem Einzelversand vorzuziehen ist. Eine neue Feature-Ankündigung ist das zugrunde liegende Ereignis; die E-Mail ist einer der vier Kanäle oben, der es tragen könnte, gewählt, wenn das Feature groß genug ist, um einen eigenen Versand zu rechtfertigen, statt im nächsten Digest mitzulaufen. Ein kleines Feature verdient einen Changelog-Eintrag und vielleicht einen In-App-Hinweis. Ein bedeutendes verdient alle vier Kanäle, zeitlich abgestimmt.

Wie erreicht man genau die Leute, die darum gebeten haben?

Das ist die Ankündigung mit dem besten Verhältnis von Aufwand zu Wirkung, und die meisten Teams lassen sie aus. Haben zehn Kunden ein Feature namentlich angefragt, sind genau diese zehn eine direkte, persönliche Nachricht in dem Moment wert, in dem es ausgeliefert wird, unabhängig davon, welche breitere Ankündigung sonst rausgeht. Die Feedback-Schleife zum Kunden schließen behandelt die Mechanik vollständig; zusammengefasst funktioniert das nur, wenn die ursprüngliche Anfrage mit der Anfragerin verknüpft blieb, was eher ein Tracking-Problem ist als ein Ankündigungsproblem. In changeloop gilt: Wenn Widget-Feedback zu einem GitHub-Issue wurde und der gemergte Pull Request es schließt (fixes #142), postet die Freigabe des Changelog-Eintrags einmalig einen „Shipped —

Wie schreibt man den Eintrag selbst?

Dieselbe Disziplin wie bei jedem anderen Release-Notes-Eintrag: mit dem beginnen, was die Leserin jetzt kann, dann jede nötige Einrichtung, die interne Rechtfertigung weglassen. Wie man Release Notes schreibt behandelt die Methode vollständig; eine neue Feature-Ankündigung ist der Fall mit den höchsten Einsätzen, weil sie der Eintrag ist, der am ehesten als Screenshot geteilt und von jemandem gelesen wird, der das Changelog des Produkts noch nie gesehen hat.

Wann sollte man nicht breit ankündigen?

Wenn das Feature noch für eine Teilmenge der Konten ausgerollt wird, es sich wirklich um eine Beta handelt, oder es so bepreist oder gesperrt ist, dass neun von zehn Leserinnen einer breiten Ankündigung es noch gar nicht nutzen könnten. Eine breite Ankündigung für ein Feature, das neun von zehn Leserinnen nicht erreichen können, wirkt wie ein Köder und schadet der nächsten Ankündigung mehr, als sie dieser hier Begeisterung bringt. Die Lösung ist nicht Stille, sondern Umfang: die berechtigten Konten direkt informieren und die breiten Kanäle zurückhalten, bis die Verfügbarkeit mit der Ankündigung gleichzieht.

FAQ

Verdient jedes neue Feature eine eigene Ankündigung? Jedes verdient einen Changelog-Eintrag. Nur die, die bedeutend genug sind, um zu ändern, wie jemand das Produkt nutzt, oder die namentlich angefragt wurden, verdienen die breiteren Kanäle wie E-Mail oder Social Media.

Was ist der beste Kanal für ein kleines Feature? Allein das Changelog, plus ein In-App-Hinweis, wenn das Feature in einem Flow auffindbar ist, in dem die Nutzerin schon steckt. E-Mail und Social Media lohnen sich für Features, die um Aufmerksamkeit bitten dürfen.

Wie kündigt man ein Feature speziell den Leuten an, die es angefragt haben? Die Anfrage vom Moment der Einreichung an mit der Anfragerin verknüpft halten, dann individuell benachrichtigen, sobald es ausgeliefert ist, getrennt von jeder breiteren Ankündigung. Ein geteiltes Status-Label, das eine Anfragerin selbst prüfen kann, reduziert auch, wie viele Einzelnachrichten überhaupt nötig sind.

Braucht eine Feature-Ankündigung einen Screenshot? Bei allem Visuellen ja; ein beschriebenes, aber ungesehenes Feature wird deutlich öfter übersprungen als eines, bei dem Leserinnen eine Vorschau sehen. Bei einer API oder einer Backend-Fähigkeit leistet ein kurzes Codebeispiel dieselbe Arbeit wie ein Screenshot bei einer UI-Änderung.

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: Changelog-Beispiele, Entwicklerdokumentation