Warum es kein richtiges Product Discovery Vorgehen gibtDer Discovery Prozess ist tot. Lang lebe der Discovery Prozess!

Wenn ein Product Team sich der Product Discovery rund um eine neue Mission stellt, ist es die primäre Aufgabe, Unsicherheit zu reduzieren. Die ersten Schritte rund um Alignment und Research-Aufgaben fühlen sich vielleicht noch vorhersehbar und fast schon linear an. Doch spätestens, wenn sich die erste Hypothese als falsch herausstellt, muss man sich mit Kurskorrekturen auseinandersetzen.

Und auch wenn sich die Komplexität einer Discovery manchmal überwältigend anfühlt, ist es keine Lösung ihr mit Standard-Vorgehensweisen anderer Unternehmen zu begegnen. Besser ist es, bei sich selbst zu bleiben.

In diesem Artikel möchte ich mit dir teilen, wieso die Individualität deines Teams die Geheimwaffe für effektive Product Discovery Arbeit ist.

Von “Delivery ohne Hirn” zu “Death by Discovery”

Ich selbst kenne die Schattenseiten von auf Vorhersehbarkeit ausgelegten Product Discovery Prozessen nur zu gut. Ich bin genauso schuld an endlosen Iterationen ohne Entscheidungen und Klarheit.

Nachdem ich 2012 mein CSPO-Zertifikat in den Händen hielt, war ich mir sicher, dass ich so ziemlich alles über moderne Produktentwicklung wusste. Ich war davon überzeugt, dass ich jede brandneue Feature-Idee nur exakt genug als User Story formulieren müsste, um als Produktmanager erfolgreich zu sein. Ich konnte das agile Manifest fehlerfrei zitieren und selbst 3 Uhr nachts über die perfekte User Story-Vorlage referieren.

Meinen Erfolg als Produktmanager definierte ich damals über den Output, den ich in Zusammenarbeit mit meinem Team lieferte und wie exakt die Features den initialen Erwartungen der Stakeholder entsprachen. Ich stellte das kontinuierliche Verbessern unserer Sprint Velocity und das Einhalten von Deadlines über echte Veränderungen des Nutzer- oder Business-Verhaltens. Entsprechend lag mein Fokus auf einem stets gut gefüllten Backlog und dem pünktliche “Shippen” von Features.

Irgendwann begann ich jedoch kritischer darüber nachzudenken, wie neue Themen eigentlich ihren Weg ins Backlog fanden. Es müsste doch andere Ansätze geben, als nur auf Releases von Wettbewerbern zu reagieren, Design-Trends nachzujagen oder die neuesten Lieblings-Projekte aus der Chefetage zu verfolgen.

Nach einiger Zeit als „fleißiger“ Produktmanager, begegnete mir das Konzept rund um Product Discovery und Dual-Track Agile. Diese Herangehensweise passte perfekt zu meinen jüngsten Bedenken und ich verliebte mich schnell.

Leider führte das zunächst zum anderen Extrem: Ich verlor mich in endlosen Product Discovery Iterationen und verließ mich vor allem auf die Discovery-Vorgehensweisen anderer Unternehmen. Wenn ich die Frameworks anderer Firmen nicht exakt umsetzen konnte, fühlte sich das schon oft wie Scheitern an. Und lange Product Discoveries führten nicht zu besseren Ideen, sondern vor allem zu “death by product discovery”.

Rückblickend ist mir klar, dass es mir nicht so sehr um das Überwinden von Unsicherheit ging. Vielmehr ging es um das Auslagern der Verantwortung für die Mission auf Methoden, die auf Medium oder Twitter anzutreffen waren.

Seitdem hat die Zusammenarbeit mit vielen verschiedenen Teams aus verschiedensten Industrien meine Sichtweise auf die „Zutaten“ effektiver Product Discovery verändert und geschärft. Die wohl populärste Visualisierung von Dual-Track Agile hilft Teams zwar, zu verstehen, dass Delivery und Discovery Hand in Hand gehen müssen. Allerdings kann diese auch eine Linearität suggerieren, die weit von der Realität entfernt ist.

Weder lassen sich Discovery-Iterationen immer an Sprintrythmen angleichen, noch sollten Teams sich unter Druck gesetzt fühlen „immer“ Discovery-Artefakte in einen Sprint zu überführen.

Teilweise begegneten Teams der Unsicherheit einer Product Discovery mit noch genaueren Plänen über den Ablauf, oder vordefinierten Checklisten, was es zu beachten galt.

Diese Beobachtungen ließen mich überdenken, wie sich Teams selbstständig den oft unvorhersehbaren Herausforderungen von Product Discovery stellen können. Dabei wurde mir klar, dass es nicht um den einen Prozess gehen kann. Vielmehr geht es darum, Teams mit Fähigkeiten, Methoden und Selbstvertrauen auszustatten um sie in ihren individuellen Vorgehensweisen zu stärken.

Das hat natürlich auch viel mit der Unternehmenskultur zu tun, kann jedoch auch von jedem Teammitglied ausgehend angegangen werden. Verantwortung für die Product Discovery zu übernehmen ist einer der wichtigsten Schritte, um von einem Feature Factory Team zu einem “empowerten” Product Team zu werden.

Vom Delivery-Fokus zu wirkungsorientierter Discovery-Arbeit

Wenn Unternehmen sich entschließen, den Problemraum rund um eine neue Mission vom Team explorieren zu lassen, erfordert das einiges an Umdenken. War man bisher auf das möglichst effiziente Abarbeiten von Backlogs fokussiert, ist man vielleicht versucht, die Delivery-Prinzipien auf die Discovery zu übertragen.

Doch um aus einer Product Discovery echten Mehrwert für die Weiterentwicklung des Produkts zu ziehen, müssen sich Teams von einigen Gewohnheiten aus ihrem Delivery-Alltag verabschieden.

In vielen Firmen sind die Abläufe auf dem Delivery-Track durch Frameworks wie Scrum klar geregelt. Es gibt „korrekte“ Routinen und Abläufe innerhalb des Teams. Und für einen zweiwöchigen Sprint steht zwar das Sprint Goal im Vordergrund, dessen Erreichung wird aber häufig durch vordefinierten Output definiert. Zudem soll die Velocity stetig verbessert werden um zu messen, wie viel schneller das Team im Produzieren von Output wird.

Für die Herausforderungen einer Product Discovery sind einige dieser Ansätze jedoch nur bedingt geeignet.

Aus der Vogelperspektive lassen sich die möglichen (!) Phasen einer Product Discovery für ein gemeinsames Verständnis so herunterbrechen:

Und obwohl diese Phasen idealerweise aufeinander aufbauen, so bedingen sie sich nicht gegenseitig. Und schon gar nicht suggeriert das „Bearbeiten“ eines dieser Felder automatischen Erfolg für jede Product Discovery.

Die größte Herausforderung (und gleichzeitig der größte Mehrwert) einer Discovery liegt im Entdecken und Verstehen des Problemraums. Diese Einblicke sind aber oftmals schwieriger „echtem“ Business-Mehrwerten zuzuordnen und daher schwieriger für Kollegen und Stakeholder zu akzeptieren. Daher erfordert das Stakeholdermanagement während einer Discovery besonderes Fingerspitzengefühl. Statt sich “buy-in” durch vorgezogene Feature Diskussionen zu „erschwindeln“, sollten Product Teams Ergebnispräsentationen auf Problem- und Wirkungsebene fokussieren.

Durch das Verständnis der Nutzer und relevanter Verhaltensänderungen („worth changing“), lassen sich Ideen entwickeln, die die Firma, die Unit oder das Produkt tatsächlich voranbringen. Die konkreten nächste Arbeitsschritte in einer Discovery lassen sich zwar durchaus teilweise kurzfristig planen (Ausarbeitung einer Survey, Ideation-Session, Validierung via Smoke Test, usw.). Die Ergebnisse und daraus abgeleiteten nächsten Schritte, jedoch nicht immer.

Ein Anti-Pattern wäre in diesem Sinne, das Team daran zu messen, ob sie es am Ende der Discovery geschafft haben, durch alle Phasen zu kommen. Das mag vielleicht etwas darüber aussagen, wie vielfältig die eingesetzten Methoden waren, gibt aber keine Indikation darüber, wie passend die Schritte für die eigentliche Herausforderung waren.

Und wo wir gerade von Timing sprechen: Es gibt eine feine Linie zwischen Alibi-Discovery und endlosen Iterationen ohne Erkenntnis. Eine Alibi-Discovery erkennst du daran, dass das Team zwar „Discovery“ machen soll, aber weder Zeit noch Ressourcen für z.B. Research hat. Ein weiteres Warnsignal ist, dass jede neu entwickelte Idee auch ohne Validierung wieder auf die Ursprungsidee der Stakeholder zurück gebogen wird.

Das gemeinsame (!) Setzen einer Timebox für eine Discovery-Mission kann hilfreich für die ersten Gehversuche eines Discovery-Teams sein. Dabei geht es aber nicht darum, am Ende des Zeitraums eine Checkliste abgearbeitet zu haben um auf jeden Fall ein „perfektes“ Discovery-Ergebnis präsentieren zu müssen. Vielmehr sollte das Team nach einem „best effort“ Ansatz versuchen, in dieser Zeit die Unsicherheit der Mission so weit wie möglich zu reduzieren.

Welche Phasen der Discovery und Tools einem Team jedoch dabei helfen, sollte es selbst entscheiden und das regelmäßig mit seinem Umfeld teilen, um nicht als „Black Box“ wahrgenommen zu werden.

Statt sich starr an einmal definierte Frameworks und Abläufe zu halten, ermutige ich daher Teams und Unternehmen, individuelle Product Discovery Methodenkoffer aufzubauen. Ziel sollte es dabei sein, dem Team nicht nur bei der allernächsten Herausforderung zu helfen, sondern sie mit dem Rüstzeug für zukünftige Missionen auszustatten.

Die Existenz dieses Methodenkoffers, in Kombination mit Vertrauen des Umfeldes in selbstbestimmte Auswahl und Durchführung von Methoden, ist der entscheidende erste Schritt, um Product Teams mehr Verantwortung für ihre Product Discovery übernehmen zu lassen.

Das Übertragung von bestehenden Prozessen, Abläufen und „Ritualen“ zur Strukturierung einer Discovery fördert hingegen eine output-orientierte Herangehensweise. Dabei sollte es stets darum gehen, Teams Lösungen für Probleme mit viel Wirkung entdecken und validieren zu lassen.

Zusammenfassung

Ich denke, es ist an der Zeit, sich von der Vorstellung „richtiger“ Product Discovery zu verabschieden. Komplexe Unternehmensumgebungen, stetig wechselnde Herausforderungen und immer diverser werdende Teamzusammensetzungen erfordern eine Abkehr von Richtig und Falsch, was diesen Teil der Produktentwicklung angeht.

Und damit will ich nicht Discovery-“Werkzeuge” wie Fokusgruppen, übereifrige Survey-Versuche, HiPPo-basierte Ideengenerierung oder nicht signifikante A/B Tests verteidigen. Es ist wichtig, dass Teams wissen, welche Methoden für welchen Einsatzzweck am besten geeignet sind und wie sie am effektivsten eingesetzt werden können. Dabei geht es aber in erster Linie um das Verstehen sinnvoller Kombinationen, die auf die jeweilige Herausforderung passen.

Unternehmen sind nicht aufgrund eines bestimmten vordefinierten Product Discovery Prozesses erfolgreich. Sie sind erfolgreich, wenn sie Teams ermutigen und mit den notwendigen Skills ausstatten, ihren eigenen Weg zu gehen.

Und wenn du noch auf Erlaubnis wartest deinen eigenen Weg zu gehen… Hiermit hast du sie.