Wir haben in diesem Jahr dank der hervorragenden Arbeit von @danielle unter How We’re Organizing Webinars & Office Hours mit verschiedenen Formaten experimentiert, um mit unseren Kunden/Mitgliedern in Kontakt zu treten. Diese Formate sind unendlich skalierbar, da ein paar Stunden von Danielles Zeit unzähligen zukünftigen Nutzern zugutekommen. Office Hours sind besonders wertvoll, weil sie die Lücke zwischen direkter und asynchroner Kommunikation schließen – Personen mit direkten Fragen können diese live stellen, während andere später von der kuratierten Diskussion profitieren können.
Ich bin gespannt zu hören, welche anderen One-to-Many-Engagement-Modelle bei anderen gut funktionieren.
Ein weiteres kleines Muster, das bei uns gut funktioniert, ist, dass die Personen, die einer bestimmten Änderung am nächsten stehen, Ankündigungsthemen zu dieser Änderung erstellen.
In gewisser Weise war dies wahrscheinlich ein natürliches Ergebnis daraus, dass Discourse ein Open-Source-Projekt ist. Gleichzeitig denke ich, dass wir dies auch weiterhin bewusst praktiziert haben, während wir gewachsen sind und Personen in verschiedenen Rollen hinzugefügt haben.
Zum Beispiel werden unsere Feature-Ankündigungen in der Regel von jemandem getätigt, der tatsächlich an diesem Feature gearbeitet hat (sei es ein Ingenieur, Designer oder Produktmanager).
Dies ermöglicht es den Leuten, Gespräche über etwas zu beginnen, über das sie etwas wissen, und das passt recht gut in den Prozess der Produktentwicklung.
Es gibt der Community einen Ort, um direkt mit den Menschen in Kontakt zu treten, die ein bestimmtes Feature entwickeln.
Und es ermöglicht auch den Entwicklern, weiterhin Feedback der Community zu diesem Thema zu erhalten, ohne alles in der Community beobachten oder ausgeklügelte Triage- oder Tagging-Systeme entwickeln zu müssen.
Ich habe auch andere gesehen, die ähnliche Dinge an anderen Orten recht effektiv machen, auch wenn einige Details abweichen.
Eines, was wir versucht, aber nicht erfolgreich umgesetzt haben, waren regelmäßige Diskussionen (genau wie diese), um die Meinungen der Leute zu verschiedenen Aspekten des Produkts einzuholen – fast wie stückchenweises Feedback.
Derzeit erfordern unsere Kategorien allesamt etwas Spezifisches:
Fragen stellen/beantworten, aber dafür muss entweder etwas schiefgelaufen sein oder man muss das Produktwissen haben, um eine Antwort zu geben
Einen Leitfaden teilen, aber dafür braucht man etwas Produktexpertise, die noch niemand geteilt hat und/oder die die Dokumentation nicht abdeckt
Einen Feature-Request einreichen, aber dafür muss man eine Idee haben, die noch niemandem eingefallen ist
Aber ein „Wie gehst du mit ABC um?“ oder „Was denkst du über XYZ?“ ermöglicht es auch Leuten, die keine Produktexperten sind, ihre Meinung einzufließen zu lassen. Leider ist unsere Community immer noch ziemlich inaktiv, sodass sich nur ein paar Lurker zu Mitwirkenden entwickelt haben, aber ich finde, die Taktik hat trotzdem ihre Berechtigung.
Außerdem: Hut ab vor den Treffen, die Danielle organisiert! Ich melde mich für alle an und gebe mein Bestes, um dabei zu sein
Aus Neugier: Was war das Endergebnis? Wolltest du/brauchtest du Feedback von den Leuten oder versuchtest du, das Engagement aus einem anderen Grund zu stimulieren?
Ich würde sagen, es war zu 80 % ein Versuch, das Engagement zu fördern, und zu 20 % ein Versuch des Product Managers, Feedback zu sammeln. Das Endergebnis war, Nicht-Experten (also den allgemeinen Nutzern der Produkte) einen sicheren Raum zu bieten, um sich an der Unterhaltung zu beteiligen.
Jetzt bin ich noch neugieriger. Wenn sie nicht aus deinem Team kommen, was ist dann der Grund, warum du sie ermutigen willst, sich zu engagieren, wenn sie keine eigenen natürlichen Fragen haben?
