Fait : La communication sur la sortie de produit est problématique

Le but des notes de sortie de produit est d'informer vos équipes internes (de l'ingénierie au support client) et vos partenaires externes (clients et partenaires) qu'il y a eu des changements dans le produit. Dans le secteur technologique, où tout va à la vitesse de la lumière, livrer des mises à jour de produit via des notes de sortie est pratiquement un problème ancien.

Chaque entreprise pour laquelle j'ai travaillé a eu du mal à rendre les notes de sortie ''correctes''. Mais c'est une chose difficile à maîtriser ; l'importance de chaque changement ou lancement de produit varie selon le public, la façon dont ce changement modifie l'interaction d'un groupe particulier avec la fonctionnalité, et la manière dont ce groupe utilise l'ensemble du produit au quotidien.

Ces communications de sortie de produit (couramment appelées notes de sortie) doivent être livrées à des publics qui se préoccupent de choses différentes. En tant que leader de l'autonomisation des revenus chez Guru, mes interlocuteurs sont tous ceux dont la capacité à faire leur travail est impactée par la feuille de route du produit, y compris :

• Les équipes Produit/Design/Ingénierie
• L'équipe de ventes (opérations de vente, ventes internes, directeurs de comptes à travers les segments)
• Expérience client (responsables de succès et représentants du support)
• Équipe marketing (marketing produit, marketing de croissance, marque, contenu qui dirigera la stratégie GTM et relations presse pour le produit)
• Développement commercial et partenaires

Tous ces partenaires doivent digérer les mises à jour de produit et déterminer immédiatement dans quelle mesure ils doivent appliquer ces mises à jour à leur travail. Ils doivent également envisager comment ils peuvent aider les utilisateurs finaux à comprendre l'impact que tout changement aura sur eux.

La personne (ou l'équipe) qui rédige les communications de sortie doit prendre en compte tous les publics qui vont consommer les connaissances sur le produit. Quelles sont les implications de la sortie pour un ingénieur backend par rapport à un client potentiel dans le secteur de la vente au détail ?

Comment Ne pas aborder les notes de sortie

Bien qu'il soit difficile de prendre en compte les besoins de différents publics, il n'est pas non plus scalable pour un chef de produit ou un chef de produit marketing (PMM) d'écrire cinq versions différentes de notes de sortie internes. D'après mon expérience, les notes de sortie sont soit trop longues et hors contexte, soit pas assez techniques. Les notes de sortie statiques ne nous donnent pas cet aperçu et sont souvent écrites pour l'auteur, pas pour la personne qui doit comprendre ce qui a changé. Honnêtement, elles sont généralement des occasions manquées.  

J'ai assisté à des appels hebdomadaires d'une heure sur lesquels une voix monotone de la direction produit aborde les points sur des diapositives. Après la fin de l'appel, ce même chef de produit reçoit des e-mails, des appels téléphoniques (souvenez-vous de ceux-là ?), des Slacks, etc., de tout le monde, du support client aux ventes, qui veulent savoir ce que les changements signifient pour eux, leurs clients et prospects. Si vous avez manqué l'appel, vous avez manqué de la nuance et du contexte, et vous avez juste obtenu le changelog brut.

Mais ce n'est pas le rôle du chef de produit de faire cette traduction sacrée ; c'est leur travail de construire un produit qui résout un problème pour le marché. C'est le travail du PMM de traduire cette intention afin que le marché comprenne sa valeur.

Le secret pour écrire de grandes notes de sortie de logiciel

Je suis un grand fan de La mélodie du bonheur (chocant, je sais) et en tant que professionnel de l'autonomisation, les leçons intemporelles du film résonnent. "Commençons par le tout début/c'est un très bon endroit pour commencer," traverse mon esprit chaque semaine. Ainsi, en façonnant ou refaçonnant un processus de livraison produit, vous devez apprendre le langage avant de pouvoir enseigner le sujet.

1. Développer un glossaire interne

La première étape pour approfondir ce processus consiste à faire en sorte que l'ensemble de l'équipe parle le même langage. Socialiser une terminologie partagée semble évident, mais il se peut que cela n'arriver pas dans toute votre organisation. Ne pas connaître les acronymes et mal comprendre les termes peut être isolant, créant de la confusion et des silos entre les équipes.

Exemple : Notre équipe marketing utilise le terme « lancement » pour décrire quand et comment nous allons commercialiser une fonctionnalité. L'équipe d'ingénierie, cependant, utilise le mot « lancement » pour décrire quand une fonctionnalité a été mise en production dans notre environnement de staging. Le lancement spécifique d'une fonctionnalité est « terminé » pour l'ingénierie avant que nos clients n'en soient informés. C'était déroutant et contradictoire en interne.

Personne ne veut être celui qui interpelle publiquement en admettant qu'il ne sait pas ce que cela signifie, ridiculisant par une demande de définitions. Notre solution : Dans un groupe de travail inter-fonctionnel (avec des représentants de l'ingénierie, du produit et du marketing produit), nous avons clarifié la nuance et documenté nos définitions de sortie de produit:

Remarque : Si certaines cartes ne se chargent pas, rafraîchissez simplement la page !

2. Ce qu'il faut inclure dans vos notes de sortie

Une fois qu'un langage partagé est établi et que votre équipe peut articuler la terminologie de sortie, vous pouvez rédiger vos notes. La chose la plus simple à faire est de créer un modèle réutilisable pour écrire des notes de sortie. Ainsi, les parties prenantes deviennent familières avec le format après quelques itérations, et cela vous évite le tracas de devoir réinventer la roue à chaque fois.

Au minimum, de bonnes notes de sortie incluent :

• La date(s) de sortie
• Interne et externe
• Une description de la fonctionnalité ou du bogue
• Le(s) produit(s) impacté(s) (si vous en avez plus d'un)
• Si vous avez plusieurs produits logiciels, vous pouvez également vouloir inclure les numéros de version
• Où des questions peuvent être posées en interne

De bonnes notes de sortie incluent cependant aussi :

• Questions fréquemment posées anticipées (FAQ)
• Lien vers la nouvelle documentation publique, si disponible
• Pour les fonctionnalités :
• Le nom de la fonctionnalité
• Captures d'écran de ce à quoi ressemble la fonctionnalité
• Vidéo de comment démontrer la fonctionnalité
• Pourquoi la fonctionnalité existe
• Comment cela impacte les personas acheteurs/client pertinents

Voici le modèle que nous utilisons en interne (n'hésitez pas à copier !) :

💡Remarque : Il est utile d'assigner des individus directement responsables de cette tâche (plutôt que de laisser cela à un effort collectif où personne ne s'en occupe). Les chefs de produit ou les chefs de produit d'ingénierie devraient gérer le volet technique des notes (nom/version/produit/dates/captures d'écran), tandis que les chefs de produit marketing ou les ingénieurs de vente devraient gérer les informations contextuelles (personas acheteurs/pourquoi cela compte).

Mettre en œuvre une stratégie de processus de livraison de produit

Créer un format de communication cohérent

Maintenant que vous avez unifié la terminologie et rédigé votre modèle, la prochaine étape est de s'accorder sur un support de livraison cohérent (c'est-à-dire : Slack, e-mail, Loom, Guru, Google Docs) et une méthodologie. Un support de livraison cohérent assure à vos interlocuteurs des notes de sortie de savoir où ils doivent aller ou chercher ou s'abonner (pour obtenir) pour être au courant d'une sortie.

Ceci est aussi essentiel pour la gestion du changement car vous devez généralement dire quelque chose à quelqu'un plusieurs fois pour vous assurer qu'il l'absorbe entièrement. En fonction du type de sortie, des changements apportés à l'UI/UX (interface utilisateur et expérience utilisateur), et de l'impact sur le client, votre public de notes de sortie aura besoin d'être poussé vers des connaissances produits (à pousser). Chez Guru, nous utilisons à la fois des méthodologies de poussée et de tirage.

Le tirage : Où trouver des connaissances

Pour nous, les parties prenantes peuvent suivre dans notre canal Slack #release-notes, où il existe un format cohérent et digeste pour tout, des corrections de bogues aux fonctionnalités entièrement nouvelles. Gardez à l'esprit que vos publics respectifs doivent non seulement être au courant que les sorties ont lieu (via le tirage dans Slack ou par e-mail), mais plus important encore, ils doivent savoir pourquoi cette sortie a de l'importance dans le contexte.

La connaissance qu'une version simplement va avoir lieu ou a eu lieu n'est pas précieuse à moins que votre équipe puisse réellement en faire quelque chose. Pour développer un format cohérent qui fournirait un contexte approprié, j'ai interrogé des représentants des ventes, des représentants du développement de comptes, des personnes du développement commercial (le travail), pour établir notre modèle de livraison de produit que nous appelons « carte de décomposition des fonctionnalités », que vous pouvez trouver ci-dessus.

Lorsqu'un responsable de l'ingénierie commence le développement d'une nouvelle fonctionnalité, les personnes directement responsables sont alertées via Asana pour créer une carte de décomposition de fonctionnalité spécifique en utilisant le modèle de notes de sortie. La nouvelle carte de décomposition des fonctionnalités devient la source unique fiable ou le « cerveau de la fonctionnalité » que nous sortons. Les experts en la matière (EM) — tels que le PMM et les ingénieurs de vente — incluent des détails sur pourquoi la sortie est précieuse, pour qui cela importe le plus, et, le cas échéant, des conseils sur la manière de démontrer la fonctionnalité dans le cadre d'une histoire plus large.

Les parties prenantes des notes de sortie, en particulier les responsables de comptes, reviennent encore et encore sur les mêmes cartes parce qu'elles ont appris que les connaissances dynamiques sur la carte de décomposition des fonctionnalités sont fiables, pertinentes et applicables. Les publics parlent maintenant tous le même langage et lisent à partir du même (dynamique) manuel. Un retour à la carte de décomposition des fonctionnalités fait toujours partie d'une méthode de « tirage » car elle se fait à un rythme autonome, et permet de se préparer à un appel de vente ou de soutien, ou si un prospect a une question sur la feuille de route.

Le Pousser : Fournir proactivement des connaissances

La méthode Push entre en jeu lorsque les connaissances sur une version sont sensibles au temps et critiques pour certaines équipes. Ici, cela se fait grâce à la fonctionnalité annonces de Guru. En fonction de l'impact sur mes publics internes, je pousse une annonce via Guru à un groupe pertinent. Je peux alors voir un rapport de ceux qui ont reconnu ou lu l'alerte et honteusement rappeler publiquement à ceux qui ne l'ont pas fait.  

Pourquoi une culture axée sur la connaissance est la clé 🗝

Malgré tout ce qui précède, ce n'est pas aussi simple que d'accord sur la terminologie, de rédiger des notes de sortie de qualité et de créer un mécanisme pour une livraison dynamique du produit. Les équipes doivent être capables de collaborer autour des connaissances et de donner des retours de manière continue. Pour nous, cela signifie que lorsque les consommateurs de connaissances (dans ce cas, les parties prenantes des notes de sortie) ont une question ou apprennent quelque chose de nouveau, ils commentent sur la carte de décomposition des fonctionnalités.

Pour nous, cela signifie que lorsque les consommateurs de connaissances (dans ce cas, les parties prenantes des notes de version) ont une question ou apprennent quelque chose de nouveau, ils commentent la carte de décomposition des fonctionnalités. Nous intégrons également les questions posées et répondues dans Slack en commentant comme moyen d'améliorer continuellement les connaissances. L'expert en la matière (généralement le PMM) examinera et intégrera ces nouvelles connaissances ou questions pertinentes, les contextualisant dans la carte de décomposition des fonctionnalités particulière.

Nous rendons également toutes nos notes de sortie facilement accessibles en les plaçant soit dans les sections à venir soit dans celles lancées de notre tableau de décomposition des fonctionnalités, où elles peuvent être further organisées en interne. De cette façon, elles sont faciles à suivre d'un coup d'œil. Si vous n’êtes pas utilisant Guru, nous vous recommandons d'essayer de créer une page de notes de sortie, ou un changelog lié.

Comme pour tout autre processus, celui-ci évolue constamment. La livraison de produit et les notes de sortie ne sont jamais aussi simples qu'une fois pour toutes. À mesure que les besoins de votre entreprise changent, votre processus, vos responsabilités et vos modèles devraient évoluer avec eux. Mais en cherchant à garantir une compréhension facile, un contexte et une utilité, vous ne pouvez pas perdre.