#3 – Product Discovery als Zugang zu guten Ideen

Ein neues Seminar im Rahmen des Product Owner Bootcamps: Dieses Mal zum Thema Product Discovery.
Ein neues Seminar im Rahmen des Product Owner Bootcamps: Dieses Mal zum Thema Product Discovery. - Foto: canva.com/stroisch.EU

Leider konnte ich am dritten Abend des Bootcamps Product Owner nicht persönlich teilnehmen. Zum Glück wird ja alles per Video aufgezeichnet und darauf basiert dieser Blogbeitrag. Das Thema dieses Moduls: die Product Discovery.

Auftakt: Dies ist ein Blog-Beitrag zum Modul „Product Strategy & Discovery“ des Bootcamp Product Owner der Digitale Leute School. Am Mittwoch, 27. September 2023, zeigte dabei Nikkel Blaase die Möglichkeiten der Product Discovery auf. Leider konnte ich daran nicht persönlich teilnehmen, weshalb dieser Blogartikel auf Grundlage der Videoaufzeichnung erstellt wurde. Mein Anspruch ist es hier NICHT, allumfassend zu berichten, sondern ich möchte ein paar Impulse weitergeben, die mich selbst bewegt haben.

Die Product Discovery als Ausgang

„Von der Geburt über die Ausführung bis zum Markteintritt und dann den Marktaustritt“

(Definition des Product-Life-Cycles)

Die Product Discovery dient dazu, den zugrundeliegenden Problemen und Bedürfnissen auf den Grund zu gehen. Hintergrund – und das ist ja auch immer wieder Diskussions- und Anregungspunkt bei Design Thinking – ist, dass man doch besser sich zunächst mal gezielt das Problem verstehen sollte, bevor man gleich mit der Lösung um die Ecke kommt.

Wir alle neigen dazu, uns auf eine Lösung zu fokussieren, die eigene ist dabei natürlich immer die beste und vernünftigste, und uns dabei mit anderen Teammitgliedern in ehrlich gesagt nicht sehr fruchtbaren Lösungsdiskussionen zu verheddern. In schlechten Teams ist das dann auch noch recht abwertend gegen andere Lösungen, in denen dann häufig – mir ist das sehr oft so passiert – am Ende ohnehin der Chef, der denkt, er hätte die Weisheit mit Löffeln gefressen, sich für eine – nämlich seine – Lösung entscheidet. Aber auch in guten Teams neigt man dann dazu eine „Feature Factory“ aufzubauen.

Und somit betont Nikkel in dieser Session – völlig zu Recht – immer wieder, dass der Ausgang einer Ideenfindung das zugrundeliegende Problem und das zugrundeliegende Bedürfnis sein sollte und nicht die Lösung. Und das bleibt solange abstrakt, bis man es selbst mal ausprobiert hat.

Der Grund bzw. die Motivation für die Product Discovery, also dieser Ideengenerierung, sind in der Praxis zwei Anlässe:

  • Nutzer können sehr einfach von der eigenen Lösung zu einer anderen wechseln; Innovation soll das am Ende verhindern
  • oder umgekehrt: Nutzer anderer Lösungen sollen animiert werden, zur eigenen zu wechseln; Innovation kann dies anstoßen.

Entsprechend ergeben sich daraus zwei Grundgedanken, die Innovation antreiben:

Das Bedürfnis bleibt das gleich, aber es gibt immer wieder neue, vielleicht bessere Lösungen, dieses Bedürfnis zu befriedigen. Und entsprechend ist es wichtig, selbst immer die bessere Lösung anzubieten.

„Wenn Du Dich nicht selbst kannibalisierst, macht es jemand anderes“

(Steve Jobs)

Die zweite Grundmotivation ist es, schneller neue Lösungen zu adaptieren.

Mögliche Innovationsmodelle

Nikkel stellt hierzu ein Modell vor, wie sich Innovation unterscheiden lässt (zum Beispiel weiter beschrieben in einem Artikel im Medium-Magazin):

  • Architektonische Innovationen
  • Inkrementelle Innovationen
  • Disruptive Innovationen
  • Radikale Innovationen

Das zugrundeliegende Prozessmodell

Nach kurzen Abstechern zum 3-Horizon-Model, geht es nun um den Prozess. Und hier gibt es einen interessanten Ansatz: Nikkel trennt nämlich den Product Life Cycle in drei – sich gegenseitig verknüpfende – Prozesse auf:

  • Design Thinking: mit Empathize, Define, Ideate, Prototype, Test, also dem Prozessmodell, wie es von der d.school propagiert wird und welches sich auch super in den Double Diamond integrieren lässt.
  • Lean Start-Up: als Prozessmodell im Anschluss an den Design-Thinking-Prozess mit ganz ähnlichen Phasen
  • Agile: Die Implementierung mit agilen Methoden, wie etwa SCRUM

Tatsächlich sehe ich persönlich das anders: Ich würde die Design-Thinking-Phase und die Lean-Start-Up-Phase nicht auftrennen, sondern zusammenfassen. Denn letztendlich sind es beides Methoden vor der Implementierung.

Und außerdem würde ich daraus auch nicht zwangsläufig einen agilen Implementierungsprozess ableiten: Es kann genauso sinnvoll sein, im Anschluss eine Wasserfall-Methode, also etwa PMI oder Prince2 zur Implementierung zu nutzen. Das hängt zum einen von der entwickelten Lösung ab und zum anderen auch sehr stark davon, wie das Unternehmen selbst aufgestellt ist. Wenn es agile Umsetzungsmethoden erst aufwändig implementieren müsste, wäre es damit potenziell überfordert. Ich bin auch nicht der Meinung, dass agile Methoden immer die überlegeneren sind, tatsächlich ist das empirisch bisher mitnichten belegt.

Unbenommen davon: Ich mag die agilen Methoden sehr und würde es auch immer agil versuchen 😉 Ich selbst würde Design Thinking und Lean Start-Up auch als agile Methoden bezeichnen, so dass ich den Implementierungsprozess in Abgrenzung dazu nicht „Agile“ nennen würde, sondern eben einfach „Implementierung“.

Was ist ein Framework?

Tatsächlich geht Nikkel in der abschließenden Fragerunde auch noch mal auf die Frage ein, ob Design Thinking das einzige Innovationsprozessmodell ist. Und er führt aus, dass zum Beispiel auch die Jobs-to-Be-Done-Methode bzw. der Morphologische Kasten eigene „Frameworks“ sind.

Ich finde nicht, dass es eigene Frameworks sind. Und um das zu verdeutlichen, möchte ich einmal kurz darstellen, was ich für ein Framework halte (jeder darf hier sehr gerne eine eigene Meinung haben ;-): Ein Framework gibt ausschließlich einen Ordnungsrahmen vor, verweist auf Muster (patterns) und auf ein Prozessmodell. Es ist in diesem Sinne methoden- und tooloffen, gibt also nicht minutiös vor, welche Methoden oder Tools in diesem Rahmen konkret genutzt werden.

In diesem Sinne sind Jobs-to-Be-Done und morphologische Kästen einfach nur Methoden oder Tools. Design Thinking hingegen ist ein Framework oder vielleicht der Klammerbegriff für eine Ansammlung von Frameworks (denn es gibt hier nicht nur ein Prozessmodell); tatsächlich gibt es nicht DAS Design Thinking und nur bestimmte Methoden und Tools, die hier in der Praxis verwendet werden.

Hier noch ein kurzer Nicht-Empfehlungs-Tipp für Jobs-to-be-Done: Das Buch „Jobs to be Done“ von Anthony W. Ulwick beginnt mit einer seitenlangen Selbstbeweihräucherung des Autors, der sagt, dass sich Wirtschaftsnobelpreisträger Clayton Christensen stark auf ihn beziehen würde; sorry Anthony, dass Du nicht den Wirtschaftsnobelpreis bekommen hast… Tatsächlich habe ich mich selbst sehr stark über Blogbeiträge an diese Methode herangearbeitet.

Und nun zu meinem Lieblingsthema: Genau deshalb ist SCRUM ebenfalls kein Framework, es hat allenfalls Framework-Charakter. Der Hintergrund ist, dass hier das Wie auch viel zu stark – meines Erachtens oftmals sehr dogmatisch – festgelegt ist, etwa, wenn es ums Daily geht oder die Dauer einer Retrospektive. Design Thinking ist völlig frei in den gewählten Methoden und Tools, hilft allenfalls bei der Einordnung, in welchen Phasen sie gut verwendbar sind.

Tools in den Übungen

Ich konnte ja leider nicht live an dieser Session teilnehmen, weshalb ich die Übungen nicht mitmachen konnte. Vorgestellt wurden hier zwei Tools:

  • How-might-we…?: Die HMW-Methode ist im Design-Thinking-Umfeld sehr beliebt. Sie hilft stark bei der Definition einer konkreten Herausforderung rund um eine Zielgruppe und ein zugrundeliegendes Problem, ist also zunächst mal sehr stark im Problemraum verortet (wobei ich sie in meiner Adaption des Design-Thinking-Modells auch zur Schnittstelle zwischen Problem- und Lösungsraum aufgemotzt habe, letztendlich ist vieles einfach eine Frage der Anwendung…). Zusammengefasst: „Wie können wir [Herausforderung] für [Zielgruppe] mit folgendem zugrundeliegenden Problem [Problem] erreichen.“
  • Design Studio: Die Design-Studio-Methode kannte ich bisher zumindest mit dieser Begrifflichkeiten nicht. Denn letztendlich ist es eine Mischung aus individuellem Brainstorming/Brainwriting, bei dem im Anschluss die Ergebnisse gegenseitig vorstellt und diskutiert werden; und das vielleicht in zwei Runden. Also ähnlich, wie ich es zum Beispiel in Kombination mit dem High-Low-Grid auch praktiziere. Nikkel sagt, dass in der Praxis die erste Brainwriting-Phase stark durch die Quantität und die zweite Brainwriting-Phase stärker durch Qualität geprägt ist. Nikkel schlägt die Methode vor, um mehr in konkrete Lösungen einzusteigen, aber ich denke, man kann damit auch gut den Problemraum erörtern – es hängt immer von der Fragestellung ab.

Wichtig ist mir hier zu sagen: Brainwriting/Brainstorming sind – so, wie es Alex F. Osborn bereits 1939 vorgeschlagen hat – immer rein quantitative Methoden, die IMMER zunächst alleine realisiert werden. Erst die Diskussion wird dann im Team geführt. Es ist ein Irrglaube, dass Brainstorming im Team sinnhaft durchgeführt werden kann! Hintergrund ist, dass wir hier die gegenseitige Beeinflussung der Teammitglieder untereinander zunächst ausschalten wollen. Vor diesem Hintergrund gibt es auch keine richtigen, falschen, schlechten oder guten Ideen oder eine richtige oder falsche Art, wie konkret nun Brainstorming inhaltlich gestaltet ist.

Herausforderung: Es mangelt nicht an Ideen, aber es ist schwer, herauszufinden, war wirklich gute Ideen sind.

Abschließender Hinweis: Immer ist es eine sehr subjektive Zusammenfassung, die ich hier verfasse. Siehst Du Dinge anders, möchtest darüber diskutieren – melde Dich gerne bei mir!

Schreibe einen Kommentar