Release notes en stakeholderupdate, dezelfde functie
5 min leestijd
De snelste manier om een opgeleverde functie aan te kondigen is de engineering-changelog in een e-mail te kopiëren en naar iedereen te sturen. Dat krijgt de update de deur uit, maar het betekent ook dat gebruikers implementatiedetails krijgen die ze niet nodig hebben en het management niet de zakelijke inkadering die het eigenlijk wil. Een PM die zojuist een bulkexportfunctie heeft opgeleverd, kan dezelfde alinea, met API-endpoints en limieten, sturen naar zowel de klantgerichte release notes als het Slack-kanaal van het management, en zien dat hij op beide plekken slecht landt.
Waarschuwing
Eén technisch overzicht naar elke doelgroep sturen is geen communicatie, het is verspreiding. Een changelog geschreven voor ontwikkelaars leest als ruis voor gebruikers en als de plank misslaan voor het management.
De functie is één keer opgeleverd. Wat ze betekent, hangt volledig af van wie erover leest.
Waarom één overzicht elke lezer tekortdoet
Een changelog is geschreven om precies te zijn over wat technisch is veranderd. Die precisie is precies wat een gebruiker niet nodig heeft en wat een managementupdate vertaald wil zien naar uitkomsten, niet naar implementatie. Een gebruiker die “paginering toegevoegd aan het exportendpoint” leest, heeft geen idee dat dit betekent dat hij nu meer dan 10.000 rijen tegelijk kan exporteren, en een managementteam dat dezelfde zin leest, heeft geen idee of het een kleine technische opruiming is of de oplossing voor de grootste klantklacht van het kwartaal.
Stel je een bulkexportfunctie voor die is opgeleverd na weken engineeringwerk om een harde limiet van 10.000 rijen te verwijderen die maandenlang supporttickets had opgeleverd. De changelogregel, juist en precies, beschrijft de technische wijziging in termen van paginering en queryoptimalisatie. Noch de gebruiker, die alleen wil weten dat hij nu zijn volledige dataset kan exporteren, noch het management, dat wil weten dat dit een terugkerende bron van klantverloop afsluit, krijgt uit diezelfde zin wat het nodig heeft.
Voor: de engineering-changelog kopiëren, in een e-mail plakken, naar gebruikers en management even goed sturen.
Na: Claude het technische overzicht één keer geven en vragen om een voor elke doelgroep omgevormde versie: wat er veranderde en waarom het hen specifiek aangaat.
Een werkwijze om één update om te vormen voor twee doelgroepen
- 1
Begin bij de echte changelog, niet bij een herinnering aan de functie
De changelog bevat de werkelijke reikwijdte van wat is opgeleverd. Uit het geheugen werken riskeert ofwel te overdrijven wat nieuw is, ofwel een detail weg te laten dat voor een van de doelgroepen telt.
- 2
Noem wat elke doelgroep echt belangrijk vindt
Zeg het expliciet: gebruikers geven om wat er voor hen is veranderd en hoe ze het gebruiken; het management geeft om wat het beweegt, adoptie, omzet, een metriek uit het roadmapdocument. Zonder dat te noemen glijden beide versies naar de technische inkadering.
- 3
Geef elke versie een echte lengte
Een specifiek aantal zinnen of woorden dwingt compressie af naar wat voor die doelgroep het belangrijkst is, in plaats van een licht ingekorte versie van dezelfde uitleg.
- 4
Controleer dat geen enkele versie overdrijft wat is opgeleverd
Vergelijk beide uitkomsten met de echte changelog. Vooral een release note voor gebruikers kan wegglijden naar marketingtaal die meer belooft dan er echt live staat.
Maak van deze engineering-changelog van onze nieuwe bulkexportfunctie een release note van 3 zinnen voor gebruikers en een statusupdate van 100 woorden voor het management.
”Als de functie direct aan een metriek hangt die het management volgt, het aantal supporttickets, een klantverloopsrisico dat in een eerdere roadmapreview is gemarkeerd, loont het die verbinding expliciet te noemen zodat de managementversie opent met de uitkomst in plaats van die te begraven.
Deze functie pakt specifiek de klachten over de exportlimiet aan die we in de roadmapreview van vorig kwartaal als klantverloopsrisico markeerden. Zorg dat de managementversie opent met die verbinding, niet alleen met een algemene beschrijving van de functie.
”
In Claude Tutorial
Een update omvormen voor wat elke lezer echt belangrijk vindt is overdraagbaar.
Dezelfde onderliggende informatie aanpassen aan de echte zorgen van verschillende lezers, in plaats van één versie naar iedereen te sturen, geldt veel verder dan release notes. De app heeft er een volledige les over, met oefeningen die gelden voor elke update met meer dan één doelgroep.
Wanneer de functie niet volledig is opgeleverd
Niet elke update is een schone lancering. Als een functie gedeeltelijk, achter een vlag of voor een beperkte groep is opgeleverd, moeten beide versies dat eerlijk zeggen in plaats van algemene beschikbaarheid te suggereren. Een release note die de beschikbaarheid overdrijft, veroorzaakt een specifieke, voorspelbare kostenpost: gebruikers die de functie niet kunnen vinden en een ticket aanmaken met de vraag waar ze is gebleven.
Tip
Vertel Claude expliciet wat er echt live is en wat nog wordt uitgerold, en vraag beide versies dat nauwkeurig weer te geven. Een release note die te veel belooft over beschikbaarheid creëert meer supporttickets dan ze voorkomt.
Deze functie is live voor 20% van de gebruikers achter een vlag, nog niet algemeen beschikbaar. Herschrijf de release note en de stakeholderupdate om dat nauwkeurig weer te geven, zonder te verzwijgen dat het echte vooruitgang is.
”Het is ook de moeite waard een korte notitie voor support of customer success voor te bereiden vóór een gefaseerde uitrol als deze, zodat ze een juist antwoord klaar hebben als een gebruiker zonder de vlag vraagt naar een functie die hij elders genoemd zag.
Schrijf een korte interne notitie voor het supportteam die de gefaseerde uitrol uitlegt, zodat ze een juist antwoord klaar hebben als een gebruiker zonder de vlag naar deze functie vraagt.
”Lees verder
- Een roadmapdocument schrijven dat de afwegingen uitlegt: waar deze opgeleverde functie begon, als gerangschikt en onderbouwd roadmapitem.
- Supporttickets omzetten in geprioriteerde thema's: de cirkel sluiten met gebruikers wier tickets de behoefte aan deze functie oorspronkelijk aan het licht brachten.
- Een PRD aanscherpen voordat je hem ter beoordeling stuurt: dezelfde discipline, testen bij een lezer die jouw context mist, eerder in het leven van deze functie toegepast.