Tatsache: Die Kommunikation über Produktveröffentlichungen ist problematisch

Der Zweck der Produktveröffentlichungsnotizen besteht darin, Ihre internen Teams (von der Technik bis zum Kundensupport) und Ihre externen Stakeholder (Kunden und Partner) darüber zu informieren, dass es Änderungen am Produkt gegeben hat. In der Technologie, wo sich alles mit Lichtgeschwindigkeit bewegt, ist die Bereitstellung von Produktaktualisierungen über Veröffentlichungsnotizen praktisch ein uraltes Problem.

Jedes Unternehmen, in dem ich gearbeitet habe, hatte Schwierigkeiten, die Veröffentlichungsnotizen "richtig" zu erstellen. Aber es ist schwer, es richtig zu machen; die Bedeutung jeder Änderung oder Produkteinführung variiert je nach Publikum, wie sich diese Änderung auf die Interaktion einer bestimmten Gruppe mit der Funktion auswirkt und wie diese Gruppe das Gesamten Produkt im Alltag nutzt.

Diese Produktveröffentlichungskommunikationen (häufig als Veröffentlichungsnotizen bekannt) müssen an Zielgruppen geliefert werden, die sich für unterschiedliche Dinge interessieren. Als Revenue Empowerment Leader bei Guru sind meine Ansprechpartner alle, deren Fähigkeit, ihren Job zu machen, von der Produktstrategie betroffen ist, einschließlich:

• Die Produkt-/Design-/Ingenieurteams
• Das Verkaufsteam (Verkauf, Innendienst, Account Executives in verschiedenen Segmenten)
• Kundenerlebnis (Success Manager und Supportmitarbeiter)
• Marketing-Team (Produktmarketing, Wachstumsmarketing, Marke, Inhalt, die die GTM-Strategie und Pressearbeit für das Produkt leiten)
• Geschäfts-Entwicklung und Partner

All diese Partner müssen Produktaktualisierungen verarbeiten und sofort herausfinden, inwieweit sie diese Aktualisierungen auf ihre Arbeiten anwenden müssen. Sie müssen auch berücksichtigen, wie sie den Endbenutzern helfen können, die Auswirkungen von Änderungen, die sie haben werden, zu verstehen auf sie.

Die Person (oder das Team), die die Veröffentlichungskommunikationen erstellt, muss alle Zielgruppen berücksichtigen, die das Produktwissen konsumieren werden. Was sind die Implikationen der Veröffentlichung für einen Backend-Ingenieur im Vergleich zu einem potenziellen Kunden im Einzelhandel?

Wie nicht an Veröffentlichungsnotizen herangehen

Obwohl es schwierig ist, die Bedürfnisse verschiedener Zielgruppen zu berücksichtigen, ist es auch einfach nicht skalierbar für einen Produktmanager oder einen Produktmarketing-Manager (PMM), fünf verschiedene Versionen interner Veröffentlichungsnotizen zu schreiben. Meiner Erfahrung nach sind Veröffentlichungsnotizen entweder zu lang und aus dem Kontext geraten oder haben nicht genügend technische Tiefe. Statische Veröffentlichungsnotizen geben uns diesen Einblick nicht und sind oft für den Autor geschrieben, nicht für die Person, die verstehen muss, was sich geändert hat. Ganz ehrlich, sie sind normalerweise verpasste Gelegenheiten.  

Ich habe an stundenlangen, wöchentlichen Anrufen zu Veröffentlichungsnotizen teilgenommen, bei denen eine monotone Stimme aus dem Produktmanagement durch Aufzählungspunkte auf Folien spricht. Nachdem der Anruf beendet ist, erhält derselbe Produktmanager E-Mails, Telefonanrufe (denken Sie daran?), Slacks usw. von allen, von Kundensupport bis Vertrieb, die wissen möchten, was die Änderungen für sie, ihre Kunden und Interessenten bedeuten. Wenn Sie den Anruf verpasst haben, haben Sie Nuancen und Kontext verpasst und stattdessen nur das rohe Änderungsprotokoll erhalten.

Aber es ist nicht die Aufgabe des Produktmanagers, diese heilige Übersetzung durchzuführen; es ist ihre Aufgabe, ein Produkt zu entwickeln, das ein Problem für den Markt löst. Es ist die Aufgabe des PMM, diese Absicht zu übersetzen, damit der Markt ihren Wert versteht.

Das Geheimnis, großartige Softwareveröffentlichungsnotizen zu schreiben

Ich bin ein großer Sound of Music Fan (überraschend, ich weiß) und als Enablement-Fachmann haben die zeitlosen Lektionen in dem Film einen wahren Klang. „Lass uns am Anfang anfangen/Es ist ein sehr guter Ort, um zu beginnen“, geht mir wöchentlich durch den Kopf. Wenn Sie einen Produktlieferprozess gestalten oder umgestalten, müssen Sie die Sprache lernen, bevor Sie das Thema lehren können.

1. Entwickeln Sie ein internes Glossar

Der erste Schritt, um diesen Prozess zu durchdringen, bedeutet, dass das gesamte Team die gleiche Sprache spricht. Das Teilen gemeinsamer Begriffe scheint offensichtlich, aber es könnte in Ihrer Organisation nicht stattfinden. Unkenntnis von Abkürzungen und Missverständnisse in der Sprache können isolierend wirken und Verwirrung und Silos zwischen den Teams schaffen.

Beispiel: Unser Marketingteam verwendet den Begriff „Launch“, um zu beschreiben, wann und wie wir mit einer Funktion auf den Markt gehen. Das Engineering-Team verwendet jedoch das Wort „Launch“, um zu beschreiben, wann eine Funktion in unsere Staging-Umgebung veröffentlicht wurde. Der funktionsspezifische Launch ist für das Engineering „fertig“, bevor unsere Kunden davon erfahren. Das war verwirrend und intern widersprüchlich.

Niemand möchte derjenige sein, der öffentlich zugibt, dass er nicht weiß, was etwas bedeutet, indem er um Definitionen bittet. Unsere Lösung: In einer funktionsübergreifenden Arbeitsgruppe (mit Vertretern aus Ingenieurwesen, Produkt, Produktmarketing) haben wir die Nuancen herausgearbeitet und unsere Produktveröffentlichungsdefinitionen dokumentiert:

Hinweis: Wenn einige der Karten nicht geladen werden können, aktualisieren Sie einfach die Seite!

2. Was in Ihren Veröffentlichungsnotizen enthalten sein sollte

Sobald eine gemeinsame Sprache festgelegt ist und Ihr Team in der Lage ist, die Veröffentlichungsbegriffe zu artikulieren, können Sie Ihre Notizen schreiben. Das Einfachste ist, eine wiederverwendbare Vorlage für das Schreiben von Veröffentlichungsnotizen zu erstellen. Auf diese Weise machen es sich die Stakeholder nach ein paar Iterationen mit dem Format vertraut und erspart Ihnen die Mühe, jedes Mal das Rad neu zu erfinden.

Mindestens beinhalten gute Veröffentlichungsnotizen:

• Das Veröffentlichungsdatum(e)
• Intern und extern
• Eine Beschreibung der Funktion oder des Fehlers
• Das oder die betroffenen Produkt(e) (wenn Sie mehr als eines haben)
• Wenn Sie mehrere Softwareprodukte haben, möchten Sie möglicherweise auch Versionsnummern angeben
• Wo innerhalb Fragen gestellt werden können

Tolle Veröffentlichungsnotizen beinhalten jedoch auch:

• Erwartete häufig gestellte Fragen (FAQs)
• Link zur neuen öffentlichen Dokumentation, falls verfügbar
• Für Funktionen:
• Der Name der Funktion
• Screenshots, wie die Funktion aussieht
• Video, wie die Funktion demonstriert wird
• Warum die Funktion existiert
• Wie es relevante Käufer-/Kunden-Personas beeinflusst

Hier ist die Vorlage die wir intern verwenden (fühlen Sie sich frei, sie zu kopieren!):

💡Hinweis: Es ist hilfreich, direkt verantwortliche Personen für diese Aufgabe zu benennen (anstatt es einer Gruppenarbeit zu überlassen, bei der niemand verantwortlich ist). Ingenieure oder Produktmanager sollten den technischen Teil der Notizen verantworten (Name/Version/Produkt/Daten/Screenshots), während Produktmarketing-Manager oder Vertriebsingenieure für die kontextuellen Informationen verantwortlich sein sollten (Käufer-Personas/warum es wichtig ist).

Implementierung einer Produktlieferprozessstrategie

Erstellen Sie ein konsistentes Kommunikationsformat

Jetzt, da Sie die Terminologie vereinheitlicht und Ihre Vorlage geschrieben haben, ist der nächste Schritt, sich auf ein konsistentes Übertragungsmedium (z. B.: Slack, E-Mail, Loom, Guru, Google Docs) und eine Methodik zu einigen einigen. Ein konsistentes Übertragungsmedium sorgt dafür, dass Ihre Kontingentabhängigen wissen wohin sie gehen oder schauen oder abonnieren sollen (um) um über eine Veröffentlichung informiert zu sein.

Dies ist auch entscheidend für Change Management, da Sie normalerweise jemandem mehrfach etwas sagen müssen, um sicherzustellen, dass er es vollständig aufnimmt. Je nach Art der Veröffentlichung, den Änderungen an der UI/UX (Benutzeroberfläche und Benutzererfahrung) und den Auswirkungen auf den Kunden muss Ihr Publikum an den Veröffentlichungsnotizen gepushed werden (zum Push). Bei Guru verwenden wir sowohl Push- als auch Pull-Methoden.

Der Pull: Wo Wissen zu finden ist

Für uns können die Stakeholder unserem Slack #release-notes Kanal folgen, wo es ein konsistentes und verdauliches Format für alles von Fehlerbehebungen bis hin zu brandneuen Funktionen gibt. Denken Sie daran, dass Ihre jeweiligen Zielgruppen nicht nur wissen müssen, dass die Veröffentlichungen stattfinden (über den Pull in Slack oder E-Mail), sondern vor allem müssen sie wissen, warum diese Veröffentlichung im Kontext wichtig ist.

Das Wissen, dass eine Veröffentlichung einfach sein wird oder stattgefunden hat, ist nicht wertvoll, es sei denn, Ihr Team kann tatsächlich etwas damit tun. Um ein konsistentes Format zu entwickeln, das den richtigen Kontext bietet, habe ich Vertriebsmitarbeiter, Vertriebsentwicklungsmitarbeiter, Business Development-Leute (die ganze Palette) befragt, um unsere Vorlage für die Produktlieferung zu erstellen, die wir die „Feature Breakdown Card“ nennen, die Sie oben finden.

Wenn ein Ingenieurmanager mit der Entwicklung einer neuen Funktion beginnt, werden die direkt verantwortlichen Personen über Asana informiert, um die funktionsspezifische Feature Breakdown Card unter Verwendung der Vorlage für Veröffentlichungsnotizen zu erstellen. Die neue Feature Breakdown-Card wird zur robusten, einzigen Quelle der Wahrheit oder dem "Gehirn der Funktion", die wir veröffentlichen. Fachexperten (SME) – wie PMM und Vertriebsingenieure – fügen Details hinzu, warum die Veröffentlichung wertvoll ist, für wen sie am wichtigsten ist, und bieten gegebenenfalls Hinweise zur Demonstration der Funktion im Rahmen einer größeren Geschichte.

Die Stakeholder der Veröffentlichungsnotizen, insbesondere die Account Executives, greifen immer wieder auf dieselben Karten zurück, weil sie gelernt haben, dass das dynamische Wissen auf der Feature Breakdown Card vertrauenswürdig, relevant und anwendbar ist. Die Zielgruppen sprechen nun sowohl dieselbe Sprache als auch aus demselben (dynamischen) Handbuch. Ein Rückgriff auf die Feature Breakdown Card ist immer noch Teil einer „Pull“-Methode, da er im eigenen Tempo erfolgt und zur Vorbereitung auf einen Verkaufs- oder Supportanruf dient oder wenn ein Interessent eine Frage zu der Produktstrategie hat.

Der Push: Proaktives Bereitstellen von Wissen

Die Push-Methode kommt ins Spiel, wenn Wissen über eine Veröffentlichung zeitkritisch und für bestimmte Teams wichtig ist. Hier wird dies durch die Ankündigungs Funktion von Guru erreicht. Basierend auf den Auswirkungen auf mein internes Publikum, push ich eine Ankündigung über Guru an eine relevante Gruppe. Ich kann dann einen Bericht sehen über jene, die die Warnung anerkannt oder gelesen haben, und die, die es nicht getan haben, öffentlich beschämen erinnern.  

Warum eine wissensorientierte Kultur der Schlüssel ist 🗝

Trotz all dem oben genannten ist es nicht so einfach, sich auf Terminologie zu einigen, großartige Veröffentlichungsnotizen zu schreiben und einen Mechanismus für die dynamische Produktlieferung zu schaffen. Teams müssen in der Lage sein, über Wissen zusammenzuarbeiten und im Laufe der Zeit Feedback zu geben. Feedback zu geben und Wissen zu verbessern, indem man es teilt, ist Teil der Rollen und Verantwortlichkeiten von jedem im Team.

Für uns bedeutet das, dass, wenn Wissenskonsumenten (in diesem Fall Stakeholder von Veröffentlichungsnotizen) eine Frage haben oder etwas Neues lernen, sie auf der Feature Breakdown Card kommentieren. Wir integrieren auch Fragen, die in Slack gestellt und beantwortet werden, indem wir kommentieren, um das Wissen kontinuierlich zu verbessern. Der Fachexperte (normalerweise der PMM) wird dieses neue Wissen oder die relevante Frage überprüfen und in den Kontext der speziellen Feature Breakdown Card eingeben.

Wir machen auch alle unsere Veröffentlichungsnotizen leicht zugänglich, indem wir sie entweder in den bevorstehenden oder den veröffentlichten Bereichen unserer Feature Breakdown Board platzieren, wo sie intern weiter organisiert werden können. Auf diese Weise sind sie auf einen Blick leicht zu verfolgen. Wenn Sie Guru nicht verwenden, empfehlen wir, eine Seite für Veröffentlichungsnotizen oder ein verlinktes Änderungsprotokoll zu erstellen.

Wie bei jedem anderen Prozess entwickelt sich auch dieser ständig weiter. Produktlieferung und Veröffentlichungsnotizen sind nie so einfach wie einmal und fertig. Mit den sich ändernden Bedürfnissen Ihres Unternehmens sollten sich auch Ihre Prozesse, Verantwortlichkeiten und Vorlagen ändern. Aber durch das Streben nach einfacher Verständlichkeit, Kontext und Benutzerfreundlichkeit kann man nichts verlieren.