Hoe je een nieuwe feature aankondigt (zonder stilte)
5 min lezen
De meeste featureaankondigingen sterven in een kanaal dat niemand twee keer leest: een tweet die voorbijscrolt, een e-mail op releasedag begraven onder de andere twaalf die een abonnee die week kreeg, een Slack-bericht in een kanaal dat het halve team maanden geleden dempte. De feature kwam uit. Bijna niemand die het zou gebruiken, kwam erachter. Dat oplossen heeft minder te maken met een betere aankondiging schrijven en meer met het juiste kanaal kiezen voor de juiste lezer, en mensen die er expliciet om vroegen rechtstreeks bereiken in plaats van erop te vertrouwen dat ze een algemeen bericht opmerken.
Waar hoort een nieuwe feature eigenlijk aangekondigd te worden?
Op meer dan één plek, want “iedereen leest hetzelfde kanaal” is nooit waar. Een changelog- of feedregel bedient de lezer die op eigen tempo checkt en het permanente, gedateerde overzicht wil. Een melding in de app bedient de lezer die het product al gebruikt en de feature vandaag zou gebruiken als ze wisten dat die bestond. E-mail bedient de lezer die momenteel niet in het product zit maar zou terugkomen voor de juiste update. Social media bedient bereik voorbij bestaande gebruikers, met bijna geen targeting.
| Kanaal | Beste voor | Zwakte |
|---|---|---|
| Changelog / feed | Het permanente overzicht; lezers op eigen tempo | Passief; doet niets voor wie nooit checkt |
| Melding in app | Gebruikers die al aanwezig zijn en vandaag zouden handelen | Bereikt niemand die nu niet ingelogd is |
| Niet-actieve gebruikers die hiervoor zouden terugkeren | Snel begraven onder andere mail; heeft een echte onderwerpregel nodig | |
| Social media | Bereik voorbij bestaande gebruikers | Bijna geen targeting; korte houdbaarheid |
Geen van de vier is alleen voldoende. De changelog is het ene document dat elke release hoort te dragen ongeacht de grootte, omdat het het overzicht is waar al het andere naar terugverwijst; de andere drie zijn versterking daarbovenop, gekozen naar hoe groot de feature echt is.
Wat moet de aankondiging eerst zeggen?
Het resultaat, niet het mechanisme. “We voegden een cachelaag toe aan het rapporten-endpoint” beschrijft wat het team bouwde. “Rapporten laden nu in minder dan een seconde” beschrijft wat veranderde voor de lezer, en dat is de zin die de klik oplevert, omdat die “wat heb ik eraan” beantwoordt in de eerste bijzin in plaats van de derde. Het mechanisme hoort in de changelog-regel of de detailpagina, niet in de kop.
Concreet vóór bijvoeglijke naamwoorden. “Een snellere, krachtigere rapportenervaring” vertelt de lezer niets waar ze op kunnen handelen; “rapporten laden nu in minder dan een seconde en kunnen gefilterd worden op status” vertelt precies wat er veranderde en wat te proberen. De tweede versie komt ook geloofwaardiger over, omdat een vage bewering precies klinkt zoals marketingtekst klinkt als er niets concreets te zeggen valt.
Hoe verschilt dit van een productupdate-e-mail?
Overlappend maar niet identiek. Productupdate-e-mail behandelt het e-mailkanaal specifiek, inclusief cadans, onderwerpregels, en wanneer een digest een losse verzending verslaat. Een nieuwe-featureaankondiging is de onderliggende gebeurtenis; e-mail is een van de vier kanalen hierboven die het zou kunnen dragen, gekozen wanneer de feature groot genoeg is om een eigen verzending te rechtvaardigen in plaats van mee te liften in de volgende digest. Een kleine feature verdient een changelog-regel en misschien een melding in de app. Een significante verdient alle vier de kanalen, in de tijd op elkaar afgestemd.
Hoe bereik je precies de mensen die erom vroegen?
Dit is de aankondiging met het beste rendement, en bijna elk team slaat hem over. Als tien klanten
een feature met naam aanvroegen, verdienen die tien mensen een directe, persoonlijke boodschap op
het moment dat hij uitkomt, los van welke bredere aankondiging er ook uitgaat. De feedbackloop met de klant sluiten
behandelt de mechaniek volledig; de samenvatting hier is dat dit alleen werkt als het
oorspronkelijke verzoek gekoppeld bleef aan de aanvrager, wat meer een bijhoudprobleem
is dan een aankondigingsprobleem. Bij changeloop geldt: wanneer widgetfeedback een GitHub-issue werd en de
gemergede pull request dat issue sluit (fixes #142), plaatst het goedkeuren van de changelog-regel
eenmalig een “Shipped —
Hoe schrijf je de regel zelf?
Dezelfde discipline als elke andere release notes-regel: begin met wat de lezer nu kan doen, gevolgd door benodigde setup, sla de interne rechtvaardiging over. Hoe schrijf je release notes behandelt de volledige methode; een nieuwe-featureaankondiging is het geval met de hoogste inzet, omdat het de regel is die het meest waarschijnlijk gescreenshot, doorgestuurd, en gelezen wordt door iemand die nog nooit de changelog van het product zag.
Wanneer kondig je iets niet breed aan?
Wanneer de feature nog wordt uitgerold naar een subset accounts, echt een beta is, of zo geprijsd of afgeschermd is dat negen van de tien lezers van een brede aankondiging het nog niet zouden kunnen gebruiken. Een brede aankondiging voor een feature die negen van de tien lezers niet kunnen gebruiken, leest als lokaas, en verbrandt vertrouwen in de volgende aankondiging meer dan het enthousiasme opbouwt in deze. De oplossing is geen stilte, het is bereik: informeer de in aanmerking komende accounts rechtstreeks, en houd de brede kanalen achter tot beschikbaarheid de aankondiging inhaalt.
FAQ
Verdient elke nieuwe feature een eigen aankondiging? Elke verdient een changelog-regel. Alleen degene die significant genoeg zijn om te veranderen hoe iemand het product gebruikt, of expliciet met naam werden aangevraagd, verdienen de bredere kanalen zoals e-mail of social media.
Wat is het beste kanaal voor een kleine feature? Alleen de changelog, plus een melding in de app als de feature vindbaar is in een flow waar de gebruiker al in zit. E-mail en social media zijn de moeite waard voor features die aandacht vragen rechtvaardigen.
Hoe kondig je een feature aan bij de mensen die er specifiek om vroegen? Houd het verzoek gekoppeld aan de aanvrager vanaf het moment van registratie, en informeer individueel bij uitkomen, apart van elke bredere aankondiging. Een gedeeld statuslabel dat de aanvrager zelf kan checken, vermindert ook hoeveel individuele berichten er sowieso nodig zijn.
Heeft een featureaankondiging een screenshot nodig? Voor alles visueels, ja; een beschreven maar ongeziene feature wordt veel vaker overgeslagen dan een waar lezers een preview van kunnen zien. Voor een API of backend-capaciteit doet een kort codevoorbeeld hetzelfde werk als een screenshot bij een UI-verandering.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.