Cette année, nous avons expérimenté plusieurs formats pour interagir avec nos clients/adhérents, grâce au travail remarquable de @danielle sur How We’re Organizing Webinars & Office Hours. Ce type de format est infiniment évolutif car quelques heures du temps de Danielle profitent à une multitude d’utilisateurs futurs. Les heures de bureau sont particulièrement précieuses car elles comblent le fossé entre la communication directe et asynchrone : les personnes ayant des questions directes peuvent les poser en direct, tandis que d’autres peuvent en tirer parti plus tard grâce à la discussion organisée.
Je suis curieux de savoir quels autres types de modèles d’engagement un à plusieurs fonctionnent bien pour les autres.
Un autre petit schéma que j’observe fonctionner bien pour nous est de laisser les personnes les plus proches d’un changement particulier annoncer ce changement via des sujets dédiés.
Dans une certaine mesure, cela a probablement été une évolution naturelle du fait que Discourse est un projet open source. En même temps, je pense que nous avons continué à être intentionnels à ce sujet alors que nous avons grandi et ajouté des personnes dans différents rôles.
Par exemple, nos annonces de fonctionnalités sont généralement faites par quelqu’un qui a réellement travaillé sur cette fonctionnalité (qu’il s’agisse d’un ingénieur, d’un designer ou d’un chef de produit).
Cela permet aux gens de commencer des conversations sur quelque chose qu’ils connaissent, d’une manière qui s’intègre assez bien au processus de construction du produit.
Cela donne à la communauté un endroit pour interagir directement avec les personnes qui construisent une fonctionnalité particulière.
Et cela permet également aux personnes qui la construisent de continuer à s’engager dans les retours de la communauté sur ce sujet, sans avoir à tout surveiller au sein de la communauté ou à mettre en place des systèmes de tri ou de balisage sophistiqués.
J’ai vu d’autres personnes faire des choses similaires ailleurs de manière assez efficace aussi, même si certains détails diffèrent.
Une chose que nous avons essayée, mais sans succès, a été d’organiser des discussions périodiques (tout comme celle-ci) pour demander aux gens leur avis sur différents éléments du produit — un peu comme un feedback en petites portions.
Actuellement, toutes nos catégories exigent quelque chose de précis :
Poser/répondre à des questions, mais cela nécessite soit d’avoir un problème, soit de connaître le produit pour fournir une réponse.
Partager un guide, mais cela exige une certaine expertise produit que personne d’autre n’a partagée et/ou que la documentation ne couvre pas.
Soumettre une demande de fonctionnalité, mais cela implique de proposer une idée que personne d’autre n’a encore eue.
En revanche, proposer des sujets du type « Comment gérez-vous ABC ? » ou « Quel est votre avis sur XYZ ? » permet aux personnes qui ne sont pas des experts du produit de partager leur avis. Malheureusement, notre communauté est encore assez inactive, donc cela n’a convaincu qu’une poignée de lecteurs silencieux de devenir contributeurs, mais je pense quand même que cette approche a du mérite.
Et bravo pour les réunions organisées par Danielle ! Je m’inscris à toutes et je fais de mon mieux pour y assister
Par curiosité, quel était l’objectif final ? Vouliez-vous/aviez-vous besoin des retours des gens ou essayiez-vous de stimuler l’engagement pour une autre raison ?
Je dirais que c’était à 80 % une tentative de stimuler l’engagement et à 20 % le chef de produit qui cherchait à recueillir des retours. L’objectif final était d’offrir aux non-experts (c’est-à-dire aux utilisateurs généraux des produits) un espace sûr pour participer à la conversation.
Je suis maintenant encore plus curieux. S’ils ne font pas partie de votre équipe, quelle est la raison qui vous pousse à les encourager à s’impliquer s’ils n’ont pas de questions naturelles à poser ?
