So vermeiden Sie häufige Fallstricke und sorgen dafür, dass Ihre Product Discovery ein voller Erfolg wird

1. „Wir sind mit den Bedürfnissen unserer User vertraut und wissen, worauf es ankommt“ 

Einer der größten Fehler, den Produktteams häufig machen, besteht in der Annahme, die Wünsche und Bedürfnisse ihrer Nutzerinnen und Nutzer bereits zu kennen. Möglicherweise fallen Sätze wie „Ich spreche aus Kundensicht“ oder „Ich sehe mich als Stellvertreter für unsere Nutzerinnen“. Dies kann dazu führen, dass technische Lösungen in den Mittelpunkt gestellt werden, ohne auf die tatsächlichen Probleme und Bedürfnisse der Kunden einzugehen. 

Dieser Fehler passiert häufig dann, wenn Unternehmen, Stakeholder oder Geschäftsleitung, die auf ihren eigenen Annahmen basierenden Produktvorstellungen umsetzen wollen, ohne kundenseitiges Feedback zu berücksichtigen. Manche Unternehmen sind es vielleicht nicht gewohnt, die User direkt zu Wort kommen zu lassen, während andere mangels effizienter Methoden den zur Ermittlung der Nutzerbedürfnisse erforderlichen Aufwand scheuen.  

Die Bedeutung einer regelmäßigen Kundenkommunikation darf jedoch nicht unterschätzt werden. Geeignete Methoden hierfür sind beispielsweise Kundenforschung, das Einholen von Kunden-Feedback oder der Einsatz quantitativer und qualitativer Tools, um neue Erkenntnisse zu gewinnen und eine gemeinsame Wissensgrundlage hinsichtlich Problemstellung, gewünschter Ergebnisse, Annahmen usw. zu schaffen. 

2. Unternehmensweite Akzeptanz der Product Discovery  

Um das Bewusstsein für die Bedeutung der Product Discovery in Ihrem Unternehmen zu schärfen, ist es wichtig, bei jeder sich bietenden Gelegenheit über die Ergebnisse zu informieren und den Zusammenhang zwischen Product Discovery und Product Delivery herauszustellen.  

Zu diesem Zweck bieten sich beispielsweise entsprechende Präsentationen („Show and Tells“), monatliche Updates oder auch eine eigens hierfür gestaltete „Product-Discovery-Wand“ im Büro an. 

Außerdem sollten Sie im Anschluss an die Auslieferung von Features und Produkten noch einmal auf die Discovery-Phase zurückkommen, um zu veranschaulichen, welches Problem dadurch gelöst bzw. welches Nutzerbedürfnis befriedigt wurde. Damit dürfte der Nutzen der Product Discovery auch den letzten Zweiflern klar werden.  

3. Weitermachen, wenn die Ergebnisse der Product Discovery das Gegenteil nahelegen 

Die Product Discovery kann mitunter auch in eine Zwickmühle führen – insbesondere dann, wenn unbedingt ein bestimmtes Problem gelöst oder ein bestimmtes Feature entwickelt werden soll, obwohl der Discovery-Prozess nahelegt, dass dies keine so gute Idee ist. In solchen Fällen ist es unerlässlich, die Daten und Erkenntnisse, die Ihre Empfehlungen stützen, transparent und ehrlich zu kommunizieren. Seien Sie zudem darauf vorbereitet, Ihre Feststellungen zu verteidigen, und seien Sie sich darüber im Klaren, wann es sich lohnt, für Ihre Sicht zu kämpfen, und wann es besser ist, nachzugeben. 

Sollten Sie überstimmt werden, können Sie die Lösung immer noch iterativ bereitstellen, indem Sie mithilfe eines MVP-Ansatzes weitere Daten und Hinweise sammeln. Auf diese Weise können Sie Ihre ursprünglichen Ergebnisse bestätigen bzw. entkräften und zusätzliche Argumente und Belege für zukünftige Gespräche mit Stakeholdern zusammentragen. 

4. Trennung von Discovery und Delivery

Die Product Discovery bringt einige Herausforderungen mit sich, insbesondere, wenn es darum geht, zu wissen, wann die Zeit reif für den nächsten Schritt ist. Für den Erfolg ist es unabdingbar, dass sich die beteiligten Teams auf jeweils ein bis zwei Problembereiche konzentrieren und die für die Discovery aufgewendete Zeit begrenzen. Erfahrene Discovery-Teams verbringen in der Regel zwei bis vier Wochen mit der Discovery-Phase. Ein wichtiger Gradmesser dafür, ob Sie genug unternommen haben, ist die Zuversicht Ihres Teams bei der Einleitung der nächsten Phase. Außerdem sollten Sie die folgenden Fragen positiv beantworten können: 

• Entwickeln wir das Richtige? 

• Sind alle Voraussetzungen erfüllt, damit wir das Produkt wie geplant entwickeln können? 

Darüber hinaus ist es wichtig, Product Discovery und Product Delivery so gut wie möglich aufeinander abzustimmen. Ist die Markteinführung beispielsweise erst in einigen Monaten geplant, empfiehlt es sich oft, mit dem Start der Discovery-Aktivitäten noch etwas zu warten, damit die Erkenntnisse zum maßgeblichen Zeitpunkt noch frisch sind. Dies erleichtert es dem Team, Verbindungen herzustellen und das Projekt voranzubringen. 

5. Falsche Teamzusammensetzung oder -größe 

Im Idealfall sollte das Discovery-Team aus unterschiedlichen Mitgliedern des Delivery-Teams bestehen (unter anderem Delivery Manager, Technische Leiter, Engineers, Business Analysts sowie UX-Designer), die als eigenes kleines Team zusammenarbeiten und den Product Ownern unterstehen.  

Die Mitwirkung eines bunt gemischten Teams an der Product Discovery führt zu einem besseren Verständnis von Produkten und Nutzern sowie zu einer besseren Abstimmung zwischen Discovery und Delivery und kann die Motivation unter den Teammitgliedern erhöhen. Es ist jedoch unrealistisch, dass sich alle Teammitglieder an der Product Discovery beteiligen. 

Auch wenn bestimmte Rollen austauschbar sind, ändert dies nichts an den Fähigkeiten, die das Discovery-Team mitbringen muss. Dabei geht es vor allem um die drei grundlegenden Bereiche, die im Rahmen der Discovery untersucht werden: Geschäftsrisiko, Technologierisiko und Usability- bzw. Design-Risiko. Ohne ein angemessenes Verständnis dieser Bereiche ist der Discovery-Prozess zum Scheitern verurteilt. Unternehmen versuchen dies häufig zu verhindern, indem sie das Discovery-Team mit erfahrenen Teammitgliedern besetzen, die in der Lage sind, die unterschiedlichsten Funktionen auszuüben, wodurch die Notwendigkeit für einen professionellen User Researcher oder andere Berufsgruppen mit speziellen Fähigkeiten entfällt. 

6. Silos 

Die Entstehung von Silos in mit dem Discovery-Prozess zusammenhängenden Arbeitsbereichen ist ein häufiger Fehler, der den Fortschritt behindern und Risiken erhöhen kann. Silos führen durch erforderliche Übergaben zu Verzögerungen und erzeugen eine Übersetzungsschicht, durch die Kontext verloren geht. Dieses Problem tritt in drei Bereichen auf: 

UX und Design: Die Organisation des UX/UI-Design-Teams bzw. der entsprechenden Abteilung als separates Silo außerhalb des Hauptteams kann künstliche Übergaben zur Folge haben und Schnelligkeit und Qualität des Teams beeinträchtigen. Um dem vorzubeugen, ist es wichtig, UX/UI-Kompetenzen in das Hauptteam zu integrieren und sicherzustellen, dass alle Teammitglieder über die zur Bereitstellung qualitativ hochwertiger Produkte erforderlichen Fähigkeiten und Kenntnisse verfügen. 

Technologie als Silo: Es ist ein Fehler, das Technologieteam nicht am Discovery-Prozess zu beteiligen oder es vom Hauptteam abzugrenzen. Das Technologieteam muss in das übergreifende Discovery-Team integriert sein, um die Ergebnisse von User Research und Analysen zu verstehen. Auf der Grundlage dieser Informationen zeigt sich, wie es am besten zur Befriedigung der festgelegten Nutzerbedürfnisse sowie zur Lösung der relevanten Probleme beitragen kann. 

Silos in der Forschung: Für eine erfolgreiche Entscheidungsfindung ist es wichtig, sowohl quantitatives als auch qualitatives Feedback zu berücksichtigen. Die ausschließliche Berücksichtigung von qualitativem Feedback kann Verzerrungen und fehlerhafte mentale Modelle zur Folge haben. Es ist unerlässlich, beide Informationsquellen zu beachten, um fundierte Entscheidungen zu treffen und nicht in selbsterfüllende Prophezeiungen zu verfallen.