Feit: Communicatie over productreleases is problematisch

Het doel van productreleases is om je interne teams (van engineering tot klantenservice) en je externe belanghebbenden (klanten en partners) te laten weten dat er wijzigingen aan het product zijn. In de technologie, waar alles met lichtsnelheid beweegt, is het leveren van productupdates via release-notities praktisch een eeuwenoud probleem.

Elk bedrijf waar ik voor heb gewerkt, heeft moeite gehad om release-notities "juist" te krijgen. Maar het is moeilijk om het goed te krijgen; het belang van elke wijziging of productlancering varieert afhankelijk van het publiek, hoe die wijziging de interactie van een bepaalde groep met de functie verandert, en hoe die groep het totaalproduct elke dag gebruikt.

Deze communicatie over productreleases (ook wel release-notities genoemd) moet worden geleverd aan doelgroepen die om verschillende dingen geven. Als Revenue Empowerment-leider bij Guru zijn mijn belanghebbenden iedereen wiens vermogen om zijn werk te doen wordt beïnvloed door de productroadmap, inclusief:

• De Product-/Ontwerp-/Engineeringteams
• Het verkoopteam (Verkoopops, Intern verkoop, Account Executives in allerlei segmenten)
• Klantbeleving (Succesmanagers en ondersteuningsmedewerkers)
• Marketingteam (Productmarketing, Groei-marketing, Merk, Content die de GTM-strategie en persoverture voor het product leidt)
• Zakelijke ontwikkeling en partners

Al deze partners moeten productupdates verwerken en onmiddellijk bepalen in hoeverre ze deze updates op hun werk moeten toepassen. Ze moeten ook overwegen hoe ze eindgebruikers kunnen helpen begrijpen welke impact een wijziging op hen heeft.

De persoon (of het team) dat de releasecommunicatie opstelt, moet rekening houden met al het publiek dat de productkennis zal consumeren. Wat zijn de implicaties van de release voor een backend engineer versus een potentiële klant in de retailsector?

Hoe Geen release-notities te benaderen

Hoewel het moeilijk is om rekening te houden met de behoeften van verschillende doelgroepen, is het ook gewoon niet schaalbaar voor een productmanager of productmarketingmanager (PMM) om vijf verschillende versies van interne release-notities te schrijven. In mijn ervaring zijn release-notities ofwel te lang en uit context of hebben ze niet genoeg technische inhoud. Statische release-notities geven ons deze inzichten niet en zijn vaak geschreven voor de auteur, niet voor de persoon die moet begrijpen wat is veranderd. Eerlijk gezegd zijn het meestal gemiste kansen.  

Ik heb uurlange, wekelijkse release-notitiegesprekken meegemaakt waarin een monotone stem van productmanagement de bulletpoints opdia. Nadat de oproep is afgelopen, ontvangt dezelfde productmanager e-mails, telefoontjes (vergeet die niet?), Slacks, enz., van iedereen van klantenservice tot verkoop die willen weten wat de wijzigingen voor hen, hun klanten en prospects betekenen. Als je de oproep hebt gemist, heb je nuances en context gemist, en kreeg je in plaats daarvan gewoon het rauwe changelog.

Maar het is niet de rol van de productmanager om deze heilige vertaling te maken; het is hun taak om een product te bouwen dat een probleem oplost voor de markt. Het is de taak van de PMM om die intentie te vertalen, zodat de markt de waarde ervan begrijpt.

Het geheim van het schrijven van geweldige software release-notities

Ik ben een grote Sound of Music fan (schokkend, ik weet het) en als enablement professional zijn de tijdloze lessen in de film waar. “Laten we beginnen bij het begin/het is een zeer goede plaats om te beginnen,” gaat wekelijks door mijn hoofd. Dus, bij het vormgeven of hervormen van een productleveringsproces, moet je de taal leren voordat je het onderwerp kunt onderwijzen.

1. Ontwikkel een interne woordenschat

De eerste stap in het doorgraven van dit proces is ervoor zorgen dat het hele team dezelfde taal spreekt. Gedeelde terminologie sociaal maken lijkt voor de hand liggend, maar het gebeurt mogelijk niet in je organisatie. Niet weten van acroniemen en het verkeerd begrijpen van taal kan isolerend zijn, wat verwarring en silo's binnen teams kan creëren.

Voorbeeld: Ons marketingteam gebruikt de term “lancering” om te beschrijven wanneer en hoe we naar de markt gaan met een functie. Het engineeringteam gebruikt echter het woord “lancering” om te beschrijven wanneer een functie is vrijgegeven aan onze stagingomgeving. De functie specifieke lancering is “af” voor engineering voordat onze klanten erover weten. Dit was verwarrend en intern tegenstrijdig.

Niemand wil degene zijn die publiekelijk toegeeft dat hij niet weet wat iets betekent door om definities te vragen. Onze oplossing: In een cross-functionele werkgroep (met vertegenwoordiging van engineering, product, productmarketing) hebben we de nuance uitgewerkt en onze productrelease-definities gedocumenteerd:

Opmerking: Als een van de kaarten niet kan worden geladen, vernieuw dan gewoon de pagina!

2. Wat moet er in je release-notities worden opgenomen

Nadat een gedeelde taal is vastgesteld en je team in staat is om de release-terminologie duidelijk te maken, kun je je notities schrijven. Het makkelijkste is om een herbruikbare sjabloon te maken voor het schrijven van release-notities. Op deze manier raken belanghebbenden vertrouwd met het formaat na een paar iteraties, en bespaart het je de moeite om elke keer weer het wiel opnieuw uit te vinden.

Minimaal bevatten goede release-notities:

• De releasedatum(gegevens)
• Intern en extern
• Een beschrijving van de functie of bug
• De product(en) die worden beïnvloed (als je er meer dan één hebt)
• Als je meerdere softwareproducten hebt, wil je misschien ook versienummers opnemen
• Waar er intern vragen kunnen worden gesteld

Geweldige release-notities bevatten echter ook:

• Verwachte veelgestelde vragen (FAQs)
• Link naar nieuwe openbare documentatie, indien beschikbaar
• Voor functies:
• De naam van de functie
• Screenshots van hoe de functie eruitziet
• Video van hoe de functie gedemonstreerd wordt
• Waarom de functie bestaat
• Hoe het relevante koper-/klantpersonages beïnvloedt

Hier is de sjabloon die we intern gebruiken (voel je vrij om te kopiëren!):

💡Opmerking: Het is nuttig om direct verantwoordelijke individuen voor deze taak aan te wijzen (in plaats van het aan een groepsinspanning over te laten waar niemand de verantwoordelijkheid heeft). Engineering- of Productmanagers moeten de technische kant van de notities (naam/versie/product/data/screenshots) beheersen, terwijl Productmarketingmanagers of Sales Engineers de contextuele informatie (koper-personas/waarom het ertoe doet) moeten beheersen.

Een strategie voor het implementeren van een productleveringsproces

Creëer een consistent communicatieformaat

Nu je de terminologie hebt verenigd en je sjabloon hebt geschreven, is de volgende stap om het eens te worden over een consistent leveringsmedium (bijv.: Slack, e-mail, Loom, Guru, Google Docs) en methodologie. Een consistent leveringsmedium zorgt ervoor dat je release-notitiebelanghebbenden weten waar ze naartoe moeten gaan of moeten kijken of zich moeten abonneren (om op de hoogte te zijn) van een release.

Dit is ook essentieel voor veranderbeheer omdat je meestal iemand meerdere keren iets moet vertellen om ervoor te zorgen dat ze het volledig absorberen. Afhankelijk van het type release, de wijzigingen aan de UI/UX (gebruikersinterface en gebruikerservaring), en de impact op de klant, moet je release-notitiepubliek productkennis ontvangen (te pushen). Bij Guru hanteren we zowel push- als pullmethoden.

De Pull: Waar kennis te vinden

Voor ons kunnen belanghebbenden onze Slack #release-notes kanaal volgen, waar een consistent en verteerbaar formaat voor alles van bugfixes tot net-nieuwe functies is. Houd er rekening mee dat je respectievelijke doelgroepen zich niet alleen bewust moeten zijn dat de releases plaatsvinden (via de pull in Slack of e-mail), maar nog belangrijker, ze moeten weten waarom die release in context belangrijk is.

De kennis dat een release simpelweg zal plaatsvinden of heeft plaatsgevonden is niet waardevol tenzij je team er daadwerkelijk iets mee kan. Om een consistent formaat te ontwikkelen dat passende context biedt, heb ik verkoopvertegenwoordigers, accountontwikkelingsvertegenwoordigers, medewerkers voor zakelijke ontwikkeling (de hele handel) ondervraagd om ons sjabloon voor productlevering tot stand te brengen dat we de “Feature Breakdown Card” noemen, die je hierboven kunt vinden.

Wanneer een Engineering Manager begint met de ontwikkeling van een nieuwe functie, worden direct verantwoordelijke individuen gewaarschuwd via Asana om de functie-specifieke Feature Breakdown Card te maken met de release-notities sjabloon. De nieuwe Feature Breakdown card wordt de robuuste, enkele bron van waarheid of de "brein van de functie" die we uitbrengen. Onderwerpen deskundigen (SME) — zoals PMM en sales engineers — voegen details toe over waarom de release waardevol is, voor wie het het meest belangrijk is, en waar nodig begeleiding over hoe de functie als onderdeel van een groter verhaal te demonstreren.

De release-notities belanghebbenden, vooral Account Executives, keren steeds terug naar dezelfde kaarten omdat ze hebben geleerd dat de dynamische kennis op de Feature Breakdown Card betrouwbaar, relevant en toepasbaar is. Publiek zijn nu zowel met elkaar in gesprek als lezen uit hetzelfde (dynamische) handboek. Een terugkeer naar de Feature Breakdown Card is nog steeds onderdeel van een “pull” methode omdat het zelfgesteund is, en gedaan wordt ter voorbereiding voor een verkoop- of ondersteuningsgesprek, of als een prospect een vraag heeft over de roadmap.

De Push: Proactief kennis verstrekken

De Push-methode komt in beeld wanneer kennis over een release tijdgevoelig en kritisch is voor specifieke teams. Hier wordt dit bereikt via Guru’s aankondigingen functionaliteit. Op basis van de impact op mijn interne doelgroepen, push ik een aankondiging via Guru naar een relevante groep. Ik kan dan een rapport zien van degenen die de waarschuwing hebben erkend of gelezen en publiekelijk schamen herinneren die dat niet hebben gedaan.  

Waarom een kennisgestuurde cultuur de sleutel is 🗝

Ondanks al het bovenstaande is het niet zo simpel als het eens worden over terminologie, het schrijven van geweldige release-notities en het creëren van een mechanisme voor dynamische productlevering. Teams moeten in staat zijn om samen te werken over kennis en in de loop van de tijd feedback te geven. Feedback geven en kennis verbeteren door deze te delen, is onderdeel van de rollen en verantwoordelijkheden van iedereen in het team.

Voor ons betekent dit dat wanneer kennisconsumenten (in dit geval, stakeholders van release-notities) een vraag hebben of iets nieuws leren, ze op de Feature Breakdown Card commentaar geven. We incorporeren ook vragen die in Slack zijn gesteld en beantwoord, door commentaar te geven als een manier om de kennis continu te verbeteren. De desbetreffende deskundige (typisch de PMM) zal die nieuwe kennis of relevante vraag beoordelen en opnemen, en deze in context plaatsen in de specifieke Feature Breakdown card.

We maken ook al onze release-notities gemakkelijk toegankelijk door ze in de secties 'aankomende' of 'gelanceerde' van ons Feature Breakdown Board te plaatsen, waar ze intern verder kunnen worden georganiseerd. Op deze manier zijn ze gemakkelijk te volgen in één oogopslag. Als je geen Guru gebruikt, raden we aan om een pagina met release-notities te maken of een changelog te linken.

Zoals met elk ander proces, evolueert deze voortdurend. Productlevering en release-notities zijn nooit zo eenvoudig als one-and-done. Naarmate de behoeften van je bedrijf veranderen, moeten je processen, verantwoordelijkheden en sjablonen met hen meeveranderen. Maar door te streven naar een eenvoudig begrip, context en gebruiksvriendelijkheid, kun je niet verliezen.