4In meinem letzten Artikel habe ich von meinen eigenen Erfahrungen mit Product Discovery-Prozessen berichtet. Sowohl als Produktmanager, als auch als Product Coach, bin ich immer wieder zu der Erkenntnis gelangt, dass eine Product Discovery so individuell sein muss, wie das Team, das sie durchführt.
Obwohl dieser Ansatz bei vielen Teams auf den ersten Blick viel Zustimmung erhält, ist es normal, im Alltag ins Stocken zu geraten. Welche Methoden wende ich denn nun jetzt an, wenn ich meinen eigenen Prozess gestalten möchte? Wie kann ich mich effektiv durch den Problemraum bewegen? Und welche Product Discovery-Fallstricke gilt es zu vermeiden?
In diesem Artikel möchte ich daher auf drei konkrete Bereiche der Product Discovery eingehen und praktische Vorgehensweisen für die direkte Anwendung mit euch teilen.
Tipp 1: Mit Impact Mapping auf Verhaltensänderungen statt Lösungen fokussieren
Stakeholder interessieren sich meistens entweder für High-Level Business-KPIs oder konkrete Features, die sie schon im Kopf haben. Daher fällt es ihnen oft schwer zu verstehen, was eigentlich der Mehrwert einer strukturierter Product Discovery ist.
Mit entsprechend viel Confirmation Bias starten dann auch viele Missionen: Teams wird gesagt, dass sie auf jeden Fall discovern sollen. Was die Stakeholder jedoch erwarten, ist, dass jede neue Erkenntnis entweder die bestehenden Ideen unterstützt oder jede im Prozess entwickelte Idee sowieso umgesetzt wird.
Die Discovery Teams fühlen sich wie zwischen Baum und Borke. Auf der einen Seite sollen Lösungen gefunden werden, die firmenweite Ziele wie Umsatz, Nutzerwachstum oder Zufriedenheit unterstützen. Auf der anderen Seite driften viele Diskussionen sofort in Lösungen ab, die Management, Stakeholder oder Teammitglieder schon im Kopf haben.
Ein Gegenmittel zum vorzeitigen Auswählen einer Lösung ist das Identifizieren von und Fokussieren auf Verhaltensänderungen. Im Kern bezeichnet das den “Nachher”-Zustand deiner Nutzer, nachdem sie eine Lösung für ihr Problem in Form eines Features oder Produkts bekommen haben. Eine faktenbasierte Vorstufe zur Lösung, auf die es sich entsprechend leichter zu einigen sein dürfte.
Eine effektive Methode um dabei die vielversprechendste Lösung auszuwählen ist das Impact Mapping. Im Original 2012 von Gojko Adzic entwickelt, nutze ich mittlerweile eine von mir abgewandelte Variante in Trainings und meiner Arbeit mit Teams.
In einer Impact Map werden fünf Arten von Fragen beantwortet:
- WHY: Die übergreifende firmenweite Metrik als Ziel, das für diese Mission am wichtigsten ist. (Impact)
- WHO: Welche internen oder externen Nutzergruppen eine Rolle bei der Zielerreichung eine Rolle spielen können. (Actor)
- HOW: Welche Verhaltensweisen bei den Actors erkannt wurden, die es sich zu ändern lohnt. (Outcome)
- WHAT: Konkrete Lösungen, die die Verhaltensänderungen herbeiführen können. (Output)
- WHETHER: Mit welchen Experimenten validiert wird, ob die erdachten Lösungen tatsächlich valide sind. (Experiment)
Das Ziel einer Impact Map ist es aufzuzeigen, dass zur Erreichung der Firmenziele der Lösungsraum erst nach einem klaren Verständnis des Problems betreten werden sollte. Durch diszipliniertes Durcharbeiten der einzelnen Level einer Impact Map, kann sich das Team auf jeden Schritt fokussieren, ohne zu früh in Lösungen zu denken.
Zusätzlich hilft die Impact Map dabei, erarbeitete Discovery-Insights zu visualisieren und somit ihre Erkenntnisse und Fortschritte kontinuierlich den übergeordneten Business-Zielen zuordnen zu können.
Ein vereinfachtes Impact Mapping aus der Perspektive einer Immobilien-Firma (zum Vergrößern anklicken)
Die Ergebnisse der Product Discovery werden signifikant besser, wenn Teams aufzeigen können, welcher Benutzergruppe sie zuerst “helfen” wollen. Nur so kann es gelingen, Stakeholdern, der Chefetage und Teammitgliedern einen klaren Pfad durch manchmal schwer greifbare Aktivitäten aufzuzeigen.
Tipp 2: Research-Fragen vor der Auswahl der Methoden definieren
Während immer mehr Firmen den Mehrwert von User Research im Allgemeinen, und für Product Discovery im Speziellen, anerkennen, springen Teams noch viel zu oft direkt in die Gestaltung einer Survey oder eines Interview-Leitfadens.
Genau so, wie wir zuerst Verhaltensänderungen vor Lösungen definieren, gilt es, zuerst die richtigen Research-Fragen zu finden, bevor wir dafür die effektivsten Research-Methoden auswählen.
Aber was sind eigentlich Research-Fragen? Research-Fragen beschreiben, was du wissen willst. Sie unterscheiden sich von dem, was du Personen fragen kannst oder was in eine Umfrage gehört. Die Leitlinien für deine Research-Fragen ergeben sich aus der Produktstrategie, sowie dem generellen Alignment rund um deine Product Discovery Mission.
Beispiele für Research Questions:
- Was bringt Menschen dazu, für Teamkommunikation Produkt x statt Produkt y zu wählen?
- Was hassen Menschen an ihren aktuellen Intranetlösungen?
- Wie gut beantwortet die neueste Version der Marketing-Website die Fragen potenzieller Kunden?
- Wie erstellt Unternehmen x seine Produkt-Roadmaps?
Fragen wie diese kannst du vielleicht in einem Interview stellen, aber dann ist es halt… 💩
Im Ernst: Solche Fragen sind nicht hilfreich dabei, echte Insights von deinen Research-Teilnehmern zu erhalten. Sie sind entweder zu breit definiert, laden zu zu viel Spekulation, Interpretation und Schätzungen ein oder der Kunde kann sie schlichtweg nicht beantworten.
Hast du deine Research-Fragen definiert, kannst du die Research-Methoden aus deinem Product Discovery Arsenal auswählen, die sich für die Beantwortung eignen. Zum Beispiel:
Je nach Methode musst du deine Research-Frage dann in Fragen oder Aufgaben übersetzen, die der Nutzer sinnvoll beantworten kann.
Eine einzelne Research-Methode reicht jedoch nicht aus, die gesamte Perspektive einer Nutzergruppe zu verstehen. Die “Wahrheit” liegt oftmals an der Schnittstelle zwischen dem Einsatz von qualitativen und quantitativen Methoden.
Ein schönes Beispiel liefert hier Spotify aus einer Product Discovery rund um Werbung für Nutzer des “Free”-Angebots:
In diesem Projekt hat Spotify einerseits Probanden für eine dreiwöchige Tagebuchstudie rekrutiert und deren Antworten rund um die Wahrnehmung von Werbung mit den tatsächlichen Tracking Logs abgeglichen. So konnten sie die tatsächliche Gesamt-Experience verstehen und sowohl das WARUM, als auch das WIE hinter dem Nutzerverhalten abbilden.
Für Klarheit und Alignment rund um deine Research-Aktivitäten in der Product Discovery, empfehle ich das explizite Auflisten und Zuordnen von Research-Fragen, Research-Methoden und den gewonnenen Erkenntnissen. So bringst du mehr Transparenz und Struktur in diesen sonst unübersichtlichen Teil deiner Discovery:
Je vielfältiger deine eingesetzten Research-Methoden sind, um so wichtiger ist eine “Single Source of Truth” für deine Erkenntnisse. Nicht nur für deine eigene Dokumentation, sondern vor allem zum Abholen und Überzeugen von Teammitgliedern und Stakeholdern. Digitale Kollaborations-Tools wie Miro oder Mural eignen sich dafür z.B. hervorragend (mehr zur Discovery-Arbeit in Remote Teams in einem späteren Artikel).
Doch egal, welche Methode du wählst und wie du dein Vorgehen strukturierst. Zu bedenken ist, dass jegliche Research-Methode nur Symptome oder Indizien aufdeckt aber noch keine echten Bedürfnisse.
Tipp 3: Ideation außerhalb der “Product Bubble”
Es kann verlockend sein, direkt nach dem “Betreten” des Lösungsraums tonnenweise Sticky Notes mit den Feature-Ideen des Produktteams und der Stakeholder zu füllen. Effektive Ideation als Teil einer Product Discovery erfordert aber mehr, als nur Ideen-Backlogs zu verschriftlichen. Nach der harten Arbeit rund um Alignment und Research, neigen Product Teams manchmal dazu, es sich zu bequem zu machen, in dem sie unter sich bleiben
Besonders wenn es zu Beginn der Ideation Phase um Quantität geht, können Teams extrem von den diversen Perspektiven von Kollegen aus anderen Abteilungen wie Sales oder Support profitieren. Auch wenn eine Session mit Mitgliedern außerhalb des Discovery-Teams vielleicht etwas länger im Aufbau braucht, so stehen am Ende nicht nur objektiv betrachtet bessere Ideen zu buche. Zusätzlich können Product Teams damit auch automatisch das Standing für ihre Mission im Unternehmen steigern.
Häufig nimmt der/die Produktmanager*in oder ein Agile Coach die Rolle des Moderators in so einem Workshop ein. Hier ein paar praktische Hilfestellungen, solltet ihr euch zum ersten Mal in so einer Rolle wiederfinden:
- Es ist wichtiger, sich auf die Interaktion mit den Teilnehmern zu konzentrieren, als auf das Einhalten einer starren Agenda
- Je “exotischer” eine Abteilung, desto höher der Mehrwert für deren Einbeziehung (z. B. Rechtsabteilung, Einkauf)
- Das Abholen neuer Teilnehmer zum Status Quo funktioniert am besten mit den Work-in-Progress-Materialien eurer Discovery. Statt bunter PowerPoint-Charts, könnt ihr hierfür z.B. eine Impact Map einsetzen.
- Das Ziel von Ideation-Sessions ist zwar das Generieren vieler Ideen, jedoch nicht für so viele Problemstellungen wie möglich. Fokussiert euch auf 1-3 Herausforderungen per Session, um nicht zu viel Wechsel zwischen Kontexten zu erzwingen.
- Formuliert die Challenge einer Ideation-Runde eher als “How might we…”-Statement, statt plattes “Wir suchen Lösungen für Problem xyz.”. Erfahrungsgemäß fällt es Teilnehmern dadurch leichter, über den Tellerrand hinaus zu blicken, wenn es um neue Ideen geht.
- Setzt auf ein “Together Alone” Prinzip bei der Durchführung: Jedem/jeder Teilnehmer*in wird Zeit für Stillarbeit an den eigenen Ideen eingeräumt. Dies wird durch regelmäßiges Teilen, Priorisieren und Aussortieren mit der gesamten Gruppe ergänzt. So kombiniert ihr fokussiertes Arbeiten der einzelnen Teilnehmer, mit der Rekombination durch Gruppeninteraktion.
Cross-funktionale Ideenfindung ist eine hervorragende Möglichkeit, Stakeholder-Unterstützung für die Mission und die nächsten Schritte zu erhöhen. Wenn die Teilnehmer den Ansatz mögen, werden sie auch die Folgeschritte der Product Discovery unterstützen.
Product Teams sollten jedoch darauf achten, die Erwartungshaltung zu managen. Nur, weil eine Idee an der Wand hängt, garantiert das keine Umsetzung. Außenstehende Kollegen bekommen schnell leuchtende Augen und warten auf ein Auftauchen “ihrer” Idee auf einer Roadmap. Als Moderator so eines Workshops ist es wichtig, dies zu Beginn und spätestens am Ende der Session erneut, deutlich zu machen.
Zusammenfassung
Egal wie unvorhersehbar eine Product Discovery zu sein scheint. Wenn sich ein Product Team an konkreten Gewohnheiten für die einzelnen Phasen orientiert, gibt es ihnen und dem Umfeld Sicherheit und Vertrauen in die nächsten Schritte.
Dabei ist keiner der von mir beschriebenen Tipps als “Silver Bullet” zu sehen. Vielmehr möchte ich die Vielzahl an Möglichkeiten, sich durch eine Product Discovery zu arbeiten, aufzeigen und die Anwendung in der Praxis zugänglich machen.
Es geht nicht um die eine Methode, die ihr können müsst. Es ist viel wichtiger, eine breite “Product Discovery Toolbox” aufzubauen, und für die richtige Herausforderung, die effektivste Methode einzusetzen.
Habt ihr weitere Tipps für eine erfolgreiche Product Discovery? Ich freue mich auf eure Kommentare. Auf meinem Blog habe ich noch ein paar weitere Materialien zusammengestellt, die euch im Product Discovery-Alltag unterstützen. Dafür einfach hier entlang.
Die Impact map soll ja bei der Confirmation Bias helfen und sich auf den Impact fokussieren und die zusammenhänge von Why, Who, How, What zu den Experimenten visualisieren. Meine Erfahrung damit zeigt, dass dann Experimente manchmal auch konkrete Features sind die man ausprobiert.
Nun frag ich mich wie die Impact Map hier die Confirmation Bias unterbindet? Kann es nicht auch hier wieder dazu kommen, dass man Feature-Ideen im Kopf hat und sich den Weg vom Why einfach „schön bastelt“ damit genau das was man wollte an Lösungen/Features dabei heraus kommt? Vermutlich ist jede Methode irgendwie anfällig für solche Phänomene.
Ich denke mir manchmal: Vielleicht muss man die Discovery an „unbeteiligte“ auslagern um wirklich sicher zu gehen nicht der Confirmation Bias zu erliegen.
Was meist du dazu Tim?
Ich glaube es tut nicht gut, die ganze Discovery auszulagern. Schließlich ist das die Kern-(Innovations)-Wertschöpfung eines Produktteams. Darüber hinaus fehlt Unbeteiligten, also Teamfremden, in der Regel das genaue Domänenwissen und die Kenntnis der eingesetzten Technologie und Systeme. Ein ziemlich hoher Preis zur Vermeidung des Confirmation Bias… und sobald die Unbeteiligten die erste tolle Idee haben, können sie genau so dem Confirmation Bias zu Opfer fallen.
Statt der ganzen Discovery könnte man aber das gesamte Validieren (Lab-Tests, A/B-Tests, etc.) auslagern um hier neutrale Bewertungen zu bekommen. Natürlich muss man negative Testergebnisse dann immer noch ernst nehmen…
Ich versuche immer, mantra-artig zu wiederholen: Fall in love with the problem, not with the solution. Aber es ist hart…
Moin Jan,
vielen Dank für deinen Kommentar und Sorry für die verspätete Antwort. Ich habe mich im Rahmen eines Webinars mal im Detail mit dem Confirmation Bias-“Problem” auseinandergesetzt.
Ich bin bei Wolf, dass ein komplettes Auslagern eher kontraproduktiv ist. Ich würde lieber befürtworten, dass alle Mitglieder des Product Teams ihre Discovery-Skills (inkl. Interviews führen und auch “sauber” beobachten) ausbauen.
Der beste “kurzfristige” Hack, den ich oft empfehle ist, dass, mindestens beim Interview eines Prototypen, die Personen, die am wenigsten in der Erstellung involviert waren, den Test durchführen. So kann man echte Neugier beim Nachfragen erzeugen und vorbeugen, dass Nutzer mit Suggestiefragen in eine bestimmte Richtung geschubst werden.
Um “unterwegs” vorzubeugen, dass man zu früh in den Lösungsraum geht, funktioniert auch oft das Verproben als “How might we…”-Challenge gut. Lässt sich das, was wir gerade diskutieren, als echte Challenge formulieren, um Leute zu inspirieren?
“How might we build a e-mail dashboard reporting feature?” wird wenige Leute zu neuen Ideen ermutigen. Wenn man hingegen noch im (validierten) Problemraum ist, klingt das eher nach: “How might we make it easier for Account Managers to share campaign reports with their clients faster?”. Mit Fokus darauf, für wen man ein Problem löst, und welcher Outcome (aka Verhaltensänderung) eigentlich im Fokus steht.
Ich hoffe, das waren hilfreiche Impulse. :)
Hi Wolf, Hi Tim,
Die Idee mit dem auslagern ist sicher nicht die richtige. Aber wie man sieht führen kontroverse Impulse zu einer guten Konversation die wir hier haben.
Ich sehe das ganz genau wie ihr. Discovery sollten so viele Teilnehmer (im besten fall alle) machen die an der Lösung des Problems beteiligt sind. Das tolle daran ist ja, das die besten Lösungen zu einem Problem oft durch die Kombination von Ideen verschiedenster Disziplinen entstehen. Das ist ja grad die Stärke der rossfunktionalen Teams. Daher gilt das sicher alles auch für das Impact Mapping.
Ich finde auch den Impuls richtig vielleicht unbeteiligte den Test durchführen zu lassen. Wenn es um das Problem im Discovery Team geht, da könnte es vielleicht auch funktionieren einen seniorigen Produkt Manager oder UX Designer zu haben, der viel Erfahrung hat diesem Bias entgegenzuwirken. Ich glaube mit Erfahrung und dem Wissen über diese Fallstricke, kann man damit gut genug umgehen. Eine Garantie ist das natürlich nicht.