Kürzlich musste ich Stakeholdern einen Lösungsvorschlag präsentieren, und das Meeting lief nicht so gut.

Für einen kurzen Moment glaubte ich, dass das Problem darin bestand, die Meinungen von zu vielen Menschen einzuholen, die dem Problem nicht nahe genug waren, bevor sie etwas vorantreiben konnten – und es gibt definitiv Probleme, wenn Teams nur minimale Autonomie haben. Aber die Realität ist, dass ich es versäumt habe, unser Denken zu zeigen, was wiederum kein Verständnis und Vertrauen aufgebaut hat.

Es war schon eine Weile her, dass ich an einem dieser Treffen teilgenommen und einem „Lenkungsausschuss“ Optionen vorgestellt hatte. Unsere Lösung wurde nicht isoliert entwickelt. Mein Team und ich führten viele Gespräche mit Stakeholdern und Experten aus dem gesamten Unternehmen, viele davon in unserem Meeting, und die Lösung, die wir gefunden hatten, war robust.

Aber aus Übung habe ich ein paar Haftnotizen und Wireframes in ein Miro-Board gepackt und mich darauf konzentriert, was wir tun und warum, vorausgesetzt, wir würden aus Gründen der Formalität wiedergeben, was jeder bereits wusste.

Was wir präsentierten, sah solide aus:

Wo es schief gelaufen ist….

Während die meisten Teilnehmer des Treffens in irgendeiner Funktion an Gesprächen über unsere Initiative beteiligt waren, waren sie nur in die Bereiche involviert, die sich auf ihr Fachwissen bezogen. Architekten wussten von der technischen Umsetzung, aber nicht, welches Problem wir zu lösen versuchten und warum. Der Kundensupport wusste nicht, wie UX-Risiken gemindert wurden und warum sie keine Bedenken mehr darstellten.

Der hohe Detaillierungsgrad, den ich für angemessen für die Gruppe hielt, ließ sie tatsächlich verwirrt und besorgt zurück.

Daraus ergab sich Folgendes:

1. Die Stakeholder waren sich nicht darüber im Klaren, wie sie Mehrwert schaffen und worüber sie Entscheidungen treffen sollten. (und ich war es auch nicht)

2. Stakeholder waren besorgt, dass wir Risiken nicht berücksichtigt hatten

3. Stakeholder haben das Problem oder die Lösung nicht wirklich verstanden

Nachdem wir über die Sitzung nachgedacht und offene Fragen geprüft hatten, stellten wir fest, dass wir durch die Darstellung der Customer Journey, der von uns entdeckten technischen Einschränkungen, der riskanten Annahmen und der Minderung dieser Annahmen die Bedenken der Stakeholder zerstreuen und gleichzeitig erkennen konnten, wo Bedarf besteht ein Ochsen, und wer von.

Wir haben die Screenshots auf unserer Agenda durch eine Customer Journey Map ersetzt.

Und das Mapping sah in etwa so aus…. (Dies ist ein erfundenes Szenario zur Veranschaulichung)

Dann schickten wir das Miro-Board an die Stakeholder zurück und baten sie, alles zu überprüfen und hinzuzufügen, was wir übersehen hatten.

Das Ergebnis

Dies ist die Aktivität, die wir in die ursprüngliche Sitzung hätten aufnehmen sollen, die es ihnen ermöglicht hätte, einen Beitrag zu leisten und ein besseres Verständnis unserer Lösung, der technischen Einschränkungen, mit denen wir es zu tun hatten, und der Überlegungen, die wir angestellt haben, zu vermitteln.

Das Feedback nach dieser Anpassung war wunderbar fokussiert und produktiv. Unsere Stakeholder konnten auf Risiken hinweisen, die wir übersehen hatten, oder auf alternative Wege zur Minderung.

Dies ist ein Prozess, dem ich immer folge, da er hilft, das Team auszurichten und sicherzustellen, dass wir ausreichend nachgedacht haben. Aber dieses Treffen war die Erinnerung, die ich brauchte, dass das Einbeziehen dieser Detailebene für die Interessengruppen niemals schaden wird. Im schlimmsten Fall wird es ignoriert, und in Szenarien wie diesem bringt es Klarheit und Fokus.