Produktwissen erscheint nicht über Nacht. Der gesamte Produktentwicklungsprozess schafft „Experten“ in Bezug auf bestimmte Funktionen und Merkmale und ist die Grundlage für die gesamte Dokumentation, die ihrer Veröffentlichung vorausgeht und folgt.

Teams, die Guru für die Produktaktivierung verwenden, erkennen die Bedeutung einer einzigen verlässlichen Quelle für Wissen, die den gesamten Produktfreigabeverlauf umfasst – von der frühen Entwicklung bis zur laufenden Unterstützung und Wartung. Indem jeder Abteilung ein einheitlicher, zuverlässiger Ort zur Verfügung steht, um von Experten verifiziertes Wissen zu speichern, können alle Beteiligten in diesen bereichsübergreifenden Prozessen bessere Arbeit leisten. Lass uns an einem aktuellen Funktionsrelease bei Guru als Beispiel für die Produktaktivierung in Aktion durchgehen.

Im Januar arbeitete unser neu gegründetes Monetarisierungsteam pod an dem ersten Teil eines Upgrades für die Abrechnungserfahrung in Guru. Dieses Projekt umfasste das gewohnte Produktentwicklungsteam – Produktmanagement, Design, Engineering und Produktmarketing – sowie mehrere andere Stakeholder, darunter Finanzen, Support und Vertriebsoperationen. Dies war ein technisches Update, das eine enge Kommunikation und Koordination zwischen allen beteiligten Teams erforderte sowie umfangreiche Vorbereitungen, um unseren kundennahen Kollegen zu ermöglichen, diese Änderungen selbstbewusst zu kommunizieren. Die folgenden drei Phasen fassen die Hauptwege zusammen, wie wir Guru für die Produktaktivierung rund um Funktionsfreigaben wie diese nutzen.

Phase 1: Funktionsplanung und -entwicklung

Die Produktaktivierung beginnt wirklich, sobald das Projekt eines Produktteams das grüne Licht erhält. Dies könnte eine kleine Funktionserweiterung, ein Seitenneugestaltung oder eine völlig neue Funktion sein. Von dem Zeitpunkt an, an dem die Projektspezifikationen von einem Produktmanager (PM) erstellt und mit Ingenieuren, Designern und anderen Stakeholdern geteilt werden, benötigt jeder Zugang zu verlässlicher, aktueller Dokumentation von verschiedenen Autoren.

Unsere Planung begann im Dezember, wobei unsere PMs einige wichtige Stellen in unseren Abrechnungs- und Checkout-Erfahrungen identifizierten, die einer Auffrischung bedurften. Von dort aus erstellten sie einen Projektplan und begannen mit dem Entwurf der frühen Funktionsspezifikation für das erste Projekt der Serie. Als sie bereit waren, das Team damit zu teilen, planten sie ein Kick-off-Meeting, um das Team über die vorgeschlagenen Änderungen zu informieren und die Zeitpläne zu besprechen. Von diesem Zeitpunkt an war es wichtig, dass jeder, der an dem Projekt beteiligt war, Zugang zu allen relevanten Dokumenten hatte, einschließlich der Projektspezifikationen, Designs, zugehörigen Abrechnungsdokumentationen und mehr.

Da sich diese Dokumente häufig ändern und oft in den frühen Phasen eines Projekts ergänzt werden, ist es wichtig, eine verlässliche Quelle der Wahrheit zu haben, zu der das Team zurückkehren kann. Um sicherzustellen, dass jeder einen einzigen Ort hatte, um diese Ressourcen zu teilen und darauf zuzugreifen, haben wir eine Karte mit aktiven Projektressourcen erstellt, um sie mit dem Team zu teilen. Wir haben dies im Monetarisierungspod-Board platziert, wo alle geeigneten Stakeholder Schreibzugriff haben.

Im gesamten Entwicklungsprozess mussten sich unsere Ingenieure keine Gedanken darüber machen, ob sie Design-Dateien als Lesezeichen setzen oder überprüfen sollten, ob der ihnen letzte Woche gegebene Text noch aktuell war. Stattdessen konnten sie während der Arbeit zur Karte mit aktiven Projektressourcen zurückkehren und sicherstellen, dass sie auf den aktuellsten Informationen aufbauten. Siehe, wie Ingenieurteams Guru verwenden.

Phase 2: Release-Vorbereitung

Wir betrachten Funktionsfreigaben bei Guru als Teamsport. Wenn wir uns dem Ende der Entwicklung nähern, müssen wir sicherstellen, dass wir alle Anforderungen erfüllt, potenzielle Kundenprobleme getestet und die bevorstehenden Änderungen ordnungsgemäß an unsere kundenorientierten Teams kommuniziert haben. Da dies die Phase ist, in der sich Informationen am wahrscheinlichsten schnell ändern, ist es von größter Bedeutung, dass alle Kenntnisse von den jeweiligen Experten bestätigt werden.

Für unser jüngstes Abrechnungsprojekt haben wir eine Woche eingeplant, damit das Team und unsere Stakeholder Qualitätssicherung (QS) durchführen und die neue Kundenerfahrung vor dem Live-Gang testen konnten. Da es sich um ein besonders technisches Projekt handelte, waren mehrere Schritte erforderlich, um Umgebungen einzurichten und auf Tests vorzubereiten, einschließlich der Aktivierung von Funktionsflags und der Bearbeitung eines spezifischen Satzes von Nachgestellt-Checkout-Schritten. Um sicherzustellen, dass alle alle Informationen hatten, die sie für die Teilnahme an den Tests benötigten, entwarf unser Teamleiter im Engineering eine Karte mit Schritt-für-Schritt-Anleitungen für die Teilnahme an der QS. Wir haben diese Karte unserem Pod und unseren Stakeholdern über eine Ankündigung geschickt, um sicherzustellen, dass sie sie gelesen hatten, bevor sie mit den Tests begannen.

Während die QS durchgeführt wurde, war es auch wichtig, unsere kundenorientierten Teams über die bevorstehenden Änderungen zu informieren, um sie auf mögliche Fragen von Interessenten oder Kunden vorzubereiten. Obwohl diese Änderungen größtenteils auf Benutzerfreundlichkeit und Zuverlässigkeit ausgerichtet waren (im Gegensatz zu einer größeren Schnittstellenänderung), würden einige Teile der alten Abrechnungserfahrung mit diesem Projekt geändert. Um diese Änderungen rechtzeitig zu kommunizieren, damit sie geprüft und Fragen gestellt werden konnten, haben wir unsere Karte zur Übersicht der Abrechnungsfunktion aktualisiert.

Du wirst feststellen, dass dies das erste Mal im Prozess ist, dass wir das Wort auffrischen anstelle von erstellen verwenden, und das ist absichtlich. Wir verwenden Funktionsübersichtskarten als lebende Quelle der Wahrheit über Funktionen für unsere kundenorientierten Teams, was bedeutet, dass es für alle unsere aktiven Funktionen zu jeder Zeit eine gibt. 

Wenn wir eine vorhandene Funktion aktualisieren und verbessern, aktualisieren und verbessern wir die Funktionsübersichtskarte entsprechend. Dies verhindert das alte Problem, dass ein Vertriebsmitarbeiter unsicher ist, ob er veraltete Dokumentation über eine Funktion sieht, und Ingenieure in Panik anschreibt, während er bei einem Anruf ist. Sie können sich sicher sein, dass die Karte über die Abrechnungsseite, auf die sie im letzten Jahr angewiesen haben, auch dieses Jahr genau ist, wie von dem Team, das an den Verbesserungen arbeitet, verifiziert.

Phase 3: Freigabe und darüber hinaus

Die offensichtlichste Anwendung von Produktaktivierung könnte sehr wahrscheinlich rund um die Einführung einer neuen oder verbesserten Funktion sein. Von Übersichten wie der oben genannten Funktionsübersichtskarte bis hin zu hoch-technischen, spezifischen Fehlerbehebungs-Q&A, fließt viel Arbeit in die Sicherstellung, dass kundenorientierte Teams alles haben, was sie benötigen, um jede Freigabe zu verkaufen und zu unterstützen. Und da Funktionen im Laufe der Zeit immer wieder aktualisiert und verbessert werden, bleibt es von entscheidender Bedeutung, dass alle Dokumentation aktuell und dem aktuellen Stand des Produkts entsprechend gehalten wird.

Es gibt keinen Zweifel, dass Abrechnungsseiten unglaublich komplex und nuanciert sind, was bedeutet, dass es nicht an potenziellen Fragen mangelt, die Kunden haben könnten, während sie einen Checkout-Prozess abschließen. Während unsere Abrechnungserfahrung nicht etwas ist, worüber unser Vertriebsteam wahrscheinlich zu viele Details sprechen muss, ist es ein Bereich, in dem unser Support-Team oft Kunden hilft. Um uns auf diese Einführung und weitere bevorstehende Verbesserungen unserer Checkout-Erfahrung vorzubereiten, arbeitete unser Teamleiter im Engineering mit unserem Kundenunterstützungspaten zusammen, um eine Liste technischer FAQs zusammenzustellen, die bei neuen Fragen ergänzt wird. Das gibt nicht nur dem Support-Team, sondern jedem, der Kundenfragen zur Abrechnung beantwortet, einen konsistenten Ort, an dem sie zuerst nachsehen können, bevor sie sich an unser Team wenden (und dann, die Informationen zur technische FAQ-Karte hinzufügen!).

Neben der Aktualisierung der FAQ-Karte im Verlauf der Iterationen wird die Funktionsübersichtskarte ebenfalls aktuell gehalten. Neben der Angabe des offiziellen Veröffentlichungsdatums und wichtiger Gesprächsthemen zur neuen Abrechnungserfahrung verlinken wir auch auf andere verwandte Karten und Ressourcen, genau wie diesen Blogbeitrag. Indem wir einen One-Stop-Shop zum Zugriff auf alle verfügbaren Informationen über eine Funktion schaffen, geben wir unseren kundennahen Teams das Vertrauen, mit Kunden und Interessenten voll informiert zu sprechen.

Um diesen Zyklus zu schließen, dürfen wir nicht vergessen, wie Kunden- und Marktfeedback eine wichtige Rolle im Produktentwicklungszyklus spielt. Während unsere Teams neue und verbesserte Funktionen für unsere bestehenden Kunden und den Markt bringen, sammeln wir wertvolle Einblicke, was ihnen hilft, besser zu arbeiten, und auf was sie hoffen, dass wir uns als Nächstes konzentrieren. Diese Informationen zu dokumentieren und mit unserem Produktteam zu teilen, ist ein wichtiger Teil unseres iterativen Entwicklungsprozesses und hilft uns, den unseren Kunden den größtmöglichen Wert zu bieten. Und die Dokumentation, wie man verschiedene Feedbackformen (Anrufaufzeichnungen, E-Mails usw.) teilt, wird – ja, du hast es erraten – in Guru aufbewahrt.