Découvrez comment les équipes de l'entreprise peuvent utiliser Guru pour rendre plus claires et plus efficaces le développement de produits, le lancement et le cycle de promotion.
L'expertise produit ne se manifeste pas du jour au lendemain. L'ensemble du processus de développement de produit crée des « experts » autour de certaines fonctionnalités, et constitue la base de toute la documentation qui précède et suit leur lancement.
Les équipes utilisant Guru pour l'activation produit reconnaissent l'importance d'avoir une source unique de vérité pour les connaissances englobant l'ensemble du cycle de vie de la publication produit – du développement précoce à l'assistance et à la maintenance continue. En fournissant à chaque département un endroit fiable et convenu pour mettre des informations vérifiées par des experts, toutes les parties prenantes de ces processus interfonctionnels peuvent faire un meilleur travail. Passons en revue un lancement de fonctionnalité récent chez Guru comme exemple d'activation produit en action.
Tout au long de janvier, notre nouveau pod de monétisation a travaillé sur la première partie d'une mise à jour de l'expérience de facturation dans Guru. Ce projet a impliqué l'équipe de développement de produit habituelle – gestion de produit, design, ingénierie, et marketing produit – ainsi que plusieurs autres parties prenantes, y compris les finances, le support, et les opérations de vente. Il s'agissait d'une mise à jour technique qui nécessitait une communication et une coordination étroites entre toutes les équipes impliquées, ainsi qu'un travail préparatoire important pour permettre à nos homologues orientés client de parler avec confiance de ces changements. Les trois phases suivantes encapsulent les principales manières dont nous utilisons Guru pour l'activation produit autour des lancements de fonctionnalités comme celui-ci.
Phase 1 : Planification et développement des fonctionnalités
L'activation produit commence véritablement dès qu'un projet de l'équipe Produit obtient le feu vert. Cela pourrait être pour une amélioration mineure de fonctionnalité, une refonte de page, ou une toute nouvelle fonctionnalité. Depuis le moment où les spécifications du projet sont rédigées par un gestionnaire de produit (PM) et partagées avec leurs ingénieurs, designers et autres parties prenantes, chacun a besoin d'un accès à la documentation fiable et à jour d'une variété d'auteurs.
Notre planification a commencé en décembre, avec nos PM identifiant quelques endroits clés au sein de nos expériences de facturation et de paiement qui avaient besoin d'être rafraîchis. De là, ils ont élaboré un plan de projet et ont commencé à rédiger les spécifications initiales de fonctionnalité pour le premier projet de la série. Une fois qu'ils étaient prêts à partager avec l'équipe, ils ont planifié une réunion de lancement pour faire passer les modifications proposées à l'équipe et discuter des délais. À partir de ce moment, il était crucial que tous ceux impliqués dans le projet aient accès à tous les documents liés, y compris les spécifications, les designs, la documentation de facturation, et plus encore.
Étant donné que ces documents changent fréquemment et peuvent être ajoutés souvent au cours des premières étapes d'un projet, il est important d'avoir une source de vérité fiable à laquelle l'équipe peut revenir. Pour s'assurer que chacun ait un endroit unique pour partager et accéder à ces ressources, nous avons créé une Carte de Ressources de Projet Actif à partager avec l'équipe. Nous avons placé cela au sein du tableau du Pod de Monétisation, où toutes les parties prenantes appropriées ont un accès d'auteur.
Tout au long du processus de développement, nos ingénieurs n'avaient pas à se soucier de mettre des signets sur les fichiers de design ou de vérifier si le contenu qui leur a été donné la semaine dernière était toujours à jour. Au lieu de cela, ils pouvaient se référer à la Carte de Ressources de Projet Actif pendant qu'ils travaillaient, s'assurant qu'ils construisaient à partir des informations les plus à jour. Voyez comment les équipes d'ingénierie utilisent Guru.
Phase 2 : Préparation au lancement
Nous considérons les lancements de fonctionnalités comme un sport d'équipe chez Guru. À mesure que nous approchons de la fin du développement, nous devons nous assurer que nous avons satisfait à toutes les exigences, testé les points de douleur potentiels des clients, et correctement communiqué les changements à venir à nos équipes orientées clients. Étant donné que c'est la phase où l'information est le plus susceptible de changer rapidement, il est de la plus haute importance d'assurer que toutes les connaissances sont vérifiées par les experts respectifs.
Pour notre projet de facturation récent, nous avons alloué une semaine à l'équipe et à nos parties prenantes pour réaliser l'assurance qualité (AQ) et tester la nouvelle expérience client avant le passage en direct. Comme il s'agissait d'un projet particulièrement technique, plusieurs étapes étaient nécessaires pour préparer les environnements et les rendre prêts pour les tests, y compris l'activation des drapeaux de fonctionnalité et le passage par un ensemble spécifique d'étapes de paiement répliquées. Pour s'assurer que tout le monde disposait des informations nécessaires pour participer aux tests, notre responsable d'équipe d'ingénierie a élaboré une Carte avec des instructions étape par étape pour participer à l'AQ. Nous avons envoyé cette Carte à notre Pod et à nos parties prenantes par le biais d'une annonce pour nous assurer qu'ils l'avaient lue avant de commencer les tests.
Alors que l'AQ était en cours, il était également important de notifier nos équipes orientées clients des changements à venir pour les préparer à d'éventuelles questions que les prospects ou les clients pourraient avoir. Bien que ces changements soient largement axés sur l'ergonomie et la fiabilité (plutôt qu'un changement d'interface plus large), certaines parties de l'expérience de facturation hérité allaient être modifiées avec ce projet. Pour communiquer ces changements avec suffisamment de temps pour les examiner et poser des questions, nous avons rafraîchi notre Carte de décomposition des fonctionnalités de facturation.
Vous remarquerez que c'est la première fois dans le processus que nous utilisons le mot rafraîchir au lieu de créer, et c'est intentionnel. Nous utilisons des Cartes de décomposition des fonctionnalités comme source vivante de vérité sur les fonctionnalités pour nos équipes orientées clients, ce qui signifie qu'il en existe une pour toutes nos fonctionnalités en direct à tout moment.
Lorsque nous mettons à jour et améliorons une fonctionnalité existante, nous mettons à jour et améliorons la Carte de décomposition des fonctionnalités en conséquence. Cela empêche le vieux problème d'un représentant commercial n'étant pas sûr s'il regarde une documentation obsolète concernant une fonctionnalité et d'envoyer des messages aux ingénieurs dans la panique lors d'un appel. Ils peuvent être certains que la Carte concernant la page de facturation sur laquelle ils se sont appuyés l'année dernière est tout aussi précise cette année, comme vérifié par l'équipe travaillant sur les améliorations.
Phase 3 : Lancement et au-delà
L'application la plus évidente de l'activation produit peut très bien concerner le lancement de la nouvelle fonctionnalité ou de la fonctionnalité améliorée. Des aperçus comme la Carte de décomposition des fonctionnalités ci-dessus aux questions-réponses techniques spécifiques, beaucoup de choses entrent en jeu pour s'assurer que les équipes orientées clients sont équipées de tout ce dont elles ont besoin pour vendre et soutenir chaque lancement. Et à mesure que les fonctionnalités sont itérées et améliorées au fil du temps, il reste essentiel de tenir à jour toute la documentation et de refléter l'état actuel du produit.
Il n'est pas surprenant que les pages de facturation soient incroyablement complexes et nuancées, ce qui signifie qu'il n'y a pas de pénurie de questions potentielles que les clients peuvent avoir alors qu'ils terminent un processus de paiement. Bien que notre expérience de facturation ne soit pas quelque chose dont notre équipe de vente devra probablement parler en détail, c'est un domaine où notre équipe de support aide souvent les clients à naviguer. Pour préparer ce lancement et des améliorations supplémentaires à venir dans notre expérience de paiement, notre responsable d'équipe d'ingénierie a travaillé avec notre champion du support client pour établir une liste de questions fréquentes techniques, qui est complétée au fur et à mesure que de nouvelles questions apparaissent. Cela donne non seulement à l'équipe de support, mais à quiconque répondant aux questions des clients sur la facturation un endroit cohérent à vérifier d'abord avant de contacter notre équipe (et ensuite, d'ajouter à la Carte de FAQ techniques!).
En plus de garder la Carte de FAQ à jour au fur et à mesure des itérations, la Carte de décomposition de fonctionnalités est également maintenue à jour. En plus de noter la date de lancement officielle et des points de discussion importants concernant la nouvelle expérience de facturation, nous relierons d'autres Cartes et ressources connexes, tout comme ce billet de blog. En créant un guichet unique pour accéder à toutes les informations disponibles concernant une fonctionnalité, nous donnons à nos équipes orientées clients la confiance pour parler aux clients et aux prospects avec une perspective pleinement informée.
Pour boucler la boucle, nous ne pouvons pas oublier comment les retours clients et du marché jouent un rôle important dans le cycle de développement produit. Alors que nos équipes apportent de nouvelles fonctionnalités et des fonctionnalités améliorées à nos clients existants et à notre marché, nous recueillons des informations précieuses sur ce qui les aide à mieux travailler, et sur ce qu'ils espèrent que nous nous concentrions ensuite. Documenter et partager ces informations avec notre équipe produit est une partie importante de notre processus de développement itératif, et nous aide à offrir le plus de valeur possible à nos clients. Et la documentation sur comment partager différents modes de retour (enregistrements d'appels, e-mails, etc.) est conservée dans – vous l'avez deviné – Guru.
L'expertise produit ne se manifeste pas du jour au lendemain. L'ensemble du processus de développement de produit crée des « experts » autour de certaines fonctionnalités, et constitue la base de toute la documentation qui précède et suit leur lancement.
Les équipes utilisant Guru pour l'activation produit reconnaissent l'importance d'avoir une source unique de vérité pour les connaissances englobant l'ensemble du cycle de vie de la publication produit – du développement précoce à l'assistance et à la maintenance continue. En fournissant à chaque département un endroit fiable et convenu pour mettre des informations vérifiées par des experts, toutes les parties prenantes de ces processus interfonctionnels peuvent faire un meilleur travail. Passons en revue un lancement de fonctionnalité récent chez Guru comme exemple d'activation produit en action.
Tout au long de janvier, notre nouveau pod de monétisation a travaillé sur la première partie d'une mise à jour de l'expérience de facturation dans Guru. Ce projet a impliqué l'équipe de développement de produit habituelle – gestion de produit, design, ingénierie, et marketing produit – ainsi que plusieurs autres parties prenantes, y compris les finances, le support, et les opérations de vente. Il s'agissait d'une mise à jour technique qui nécessitait une communication et une coordination étroites entre toutes les équipes impliquées, ainsi qu'un travail préparatoire important pour permettre à nos homologues orientés client de parler avec confiance de ces changements. Les trois phases suivantes encapsulent les principales manières dont nous utilisons Guru pour l'activation produit autour des lancements de fonctionnalités comme celui-ci.
Phase 1 : Planification et développement des fonctionnalités
L'activation produit commence véritablement dès qu'un projet de l'équipe Produit obtient le feu vert. Cela pourrait être pour une amélioration mineure de fonctionnalité, une refonte de page, ou une toute nouvelle fonctionnalité. Depuis le moment où les spécifications du projet sont rédigées par un gestionnaire de produit (PM) et partagées avec leurs ingénieurs, designers et autres parties prenantes, chacun a besoin d'un accès à la documentation fiable et à jour d'une variété d'auteurs.
Notre planification a commencé en décembre, avec nos PM identifiant quelques endroits clés au sein de nos expériences de facturation et de paiement qui avaient besoin d'être rafraîchis. De là, ils ont élaboré un plan de projet et ont commencé à rédiger les spécifications initiales de fonctionnalité pour le premier projet de la série. Une fois qu'ils étaient prêts à partager avec l'équipe, ils ont planifié une réunion de lancement pour faire passer les modifications proposées à l'équipe et discuter des délais. À partir de ce moment, il était crucial que tous ceux impliqués dans le projet aient accès à tous les documents liés, y compris les spécifications, les designs, la documentation de facturation, et plus encore.
Étant donné que ces documents changent fréquemment et peuvent être ajoutés souvent au cours des premières étapes d'un projet, il est important d'avoir une source de vérité fiable à laquelle l'équipe peut revenir. Pour s'assurer que chacun ait un endroit unique pour partager et accéder à ces ressources, nous avons créé une Carte de Ressources de Projet Actif à partager avec l'équipe. Nous avons placé cela au sein du tableau du Pod de Monétisation, où toutes les parties prenantes appropriées ont un accès d'auteur.
Tout au long du processus de développement, nos ingénieurs n'avaient pas à se soucier de mettre des signets sur les fichiers de design ou de vérifier si le contenu qui leur a été donné la semaine dernière était toujours à jour. Au lieu de cela, ils pouvaient se référer à la Carte de Ressources de Projet Actif pendant qu'ils travaillaient, s'assurant qu'ils construisaient à partir des informations les plus à jour. Voyez comment les équipes d'ingénierie utilisent Guru.
Phase 2 : Préparation au lancement
Nous considérons les lancements de fonctionnalités comme un sport d'équipe chez Guru. À mesure que nous approchons de la fin du développement, nous devons nous assurer que nous avons satisfait à toutes les exigences, testé les points de douleur potentiels des clients, et correctement communiqué les changements à venir à nos équipes orientées clients. Étant donné que c'est la phase où l'information est le plus susceptible de changer rapidement, il est de la plus haute importance d'assurer que toutes les connaissances sont vérifiées par les experts respectifs.
Pour notre projet de facturation récent, nous avons alloué une semaine à l'équipe et à nos parties prenantes pour réaliser l'assurance qualité (AQ) et tester la nouvelle expérience client avant le passage en direct. Comme il s'agissait d'un projet particulièrement technique, plusieurs étapes étaient nécessaires pour préparer les environnements et les rendre prêts pour les tests, y compris l'activation des drapeaux de fonctionnalité et le passage par un ensemble spécifique d'étapes de paiement répliquées. Pour s'assurer que tout le monde disposait des informations nécessaires pour participer aux tests, notre responsable d'équipe d'ingénierie a élaboré une Carte avec des instructions étape par étape pour participer à l'AQ. Nous avons envoyé cette Carte à notre Pod et à nos parties prenantes par le biais d'une annonce pour nous assurer qu'ils l'avaient lue avant de commencer les tests.
Alors que l'AQ était en cours, il était également important de notifier nos équipes orientées clients des changements à venir pour les préparer à d'éventuelles questions que les prospects ou les clients pourraient avoir. Bien que ces changements soient largement axés sur l'ergonomie et la fiabilité (plutôt qu'un changement d'interface plus large), certaines parties de l'expérience de facturation hérité allaient être modifiées avec ce projet. Pour communiquer ces changements avec suffisamment de temps pour les examiner et poser des questions, nous avons rafraîchi notre Carte de décomposition des fonctionnalités de facturation.
Vous remarquerez que c'est la première fois dans le processus que nous utilisons le mot rafraîchir au lieu de créer, et c'est intentionnel. Nous utilisons des Cartes de décomposition des fonctionnalités comme source vivante de vérité sur les fonctionnalités pour nos équipes orientées clients, ce qui signifie qu'il en existe une pour toutes nos fonctionnalités en direct à tout moment.
Lorsque nous mettons à jour et améliorons une fonctionnalité existante, nous mettons à jour et améliorons la Carte de décomposition des fonctionnalités en conséquence. Cela empêche le vieux problème d'un représentant commercial n'étant pas sûr s'il regarde une documentation obsolète concernant une fonctionnalité et d'envoyer des messages aux ingénieurs dans la panique lors d'un appel. Ils peuvent être certains que la Carte concernant la page de facturation sur laquelle ils se sont appuyés l'année dernière est tout aussi précise cette année, comme vérifié par l'équipe travaillant sur les améliorations.
Phase 3 : Lancement et au-delà
L'application la plus évidente de l'activation produit peut très bien concerner le lancement de la nouvelle fonctionnalité ou de la fonctionnalité améliorée. Des aperçus comme la Carte de décomposition des fonctionnalités ci-dessus aux questions-réponses techniques spécifiques, beaucoup de choses entrent en jeu pour s'assurer que les équipes orientées clients sont équipées de tout ce dont elles ont besoin pour vendre et soutenir chaque lancement. Et à mesure que les fonctionnalités sont itérées et améliorées au fil du temps, il reste essentiel de tenir à jour toute la documentation et de refléter l'état actuel du produit.
Il n'est pas surprenant que les pages de facturation soient incroyablement complexes et nuancées, ce qui signifie qu'il n'y a pas de pénurie de questions potentielles que les clients peuvent avoir alors qu'ils terminent un processus de paiement. Bien que notre expérience de facturation ne soit pas quelque chose dont notre équipe de vente devra probablement parler en détail, c'est un domaine où notre équipe de support aide souvent les clients à naviguer. Pour préparer ce lancement et des améliorations supplémentaires à venir dans notre expérience de paiement, notre responsable d'équipe d'ingénierie a travaillé avec notre champion du support client pour établir une liste de questions fréquentes techniques, qui est complétée au fur et à mesure que de nouvelles questions apparaissent. Cela donne non seulement à l'équipe de support, mais à quiconque répondant aux questions des clients sur la facturation un endroit cohérent à vérifier d'abord avant de contacter notre équipe (et ensuite, d'ajouter à la Carte de FAQ techniques!).
En plus de garder la Carte de FAQ à jour au fur et à mesure des itérations, la Carte de décomposition de fonctionnalités est également maintenue à jour. En plus de noter la date de lancement officielle et des points de discussion importants concernant la nouvelle expérience de facturation, nous relierons d'autres Cartes et ressources connexes, tout comme ce billet de blog. En créant un guichet unique pour accéder à toutes les informations disponibles concernant une fonctionnalité, nous donnons à nos équipes orientées clients la confiance pour parler aux clients et aux prospects avec une perspective pleinement informée.
Pour boucler la boucle, nous ne pouvons pas oublier comment les retours clients et du marché jouent un rôle important dans le cycle de développement produit. Alors que nos équipes apportent de nouvelles fonctionnalités et des fonctionnalités améliorées à nos clients existants et à notre marché, nous recueillons des informations précieuses sur ce qui les aide à mieux travailler, et sur ce qu'ils espèrent que nous nous concentrions ensuite. Documenter et partager ces informations avec notre équipe produit est une partie importante de notre processus de développement itératif, et nous aide à offrir le plus de valeur possible à nos clients. Et la documentation sur comment partager différents modes de retour (enregistrements d'appels, e-mails, etc.) est conservée dans – vous l'avez deviné – Guru.
Découvrez la puissance de la plateforme Guru de première main - faites notre visite interactive du produit
.webp)
