Product Discovery

Kennen Sie diese Situation? In Ihrem Unternehmen ist man ganz begeistert von einer bestimmten Produktidee und Sie als Produktmanager sollen dieses Produkt definieren. Ihnen wird gesagt, dass die Entwickler in vier Wochen mit ihrem derzeitigen Projekt fertig sein werden. Das heißt, dass Sie sich so viel Zeit nehmen können, wie Sie wollen, solange Sie in vier Wochen fertig sind…

Sie sagen, das sei kein Problem (immerhin haben Sie manchmal nur wenige Tage Zeit, da klingen vier Wochen traumhaft). Sie werden sogar all die tollen Methoden nutzen, über die ich immer so viel spreche. Sie werden mit der Bewertung der Möglichkeiten anfangen, um das zu lösende Problem zu verstehen. Dann führen Sie Interviews mit echten Nutzern durch und erstellen eine vorläufige Liste mit Anforderungen. Zu Anfang der zweiten Woche sollten Sie also bereits mit einem Interaction Designer an einem Prototyp arbeiten können. In der dritten Woche werden Sie Tests mit diesem Prototyp durchführen können und in der vierten Woche werden Sie die Details der Use Cases ausarbeiten und den Prototyp und die Spezifikationen mit den Entwicklern überarbeiten.

Die Realität bei der Product Discovery

Das klingt echt toll – was in Wirklichkeit geschieht, ist allerdings meistens nicht ganz so toll: Während der Kundengespräche ganz zu Anfang stellt sich heraus, dass die Kunden nicht so begeistert von dem Produkt sind, wie es das Management war, und/oder Sie haben Schwierigkeiten damit, einen Prototyp zu entwerfen, mit dem die Kunden klarkommen, und/oder die Kunden finden die im Prototyp umgesetzten Ideen nicht wirklich toll. Jetzt ist die Zeit allerdings um und die Entwickler sind bereit. In den nächsten drei bis sechs Monaten wird also das gleiche nutzlose und langweilige Produkt entwickelt, das man schon als Prototyp gesehen hat. Wenn das Produkt dann geliefert wird, ist das Management zu Recht von dem Ergebnis enttäuscht.

Was ist das Problem?

Das Problem liegt nicht bei der Zuverlässigkeit der Software. Die Entwickler können also nichts dafür – immerhin haben sie nur gebaut, was Sie von ihnen verlangt haben. Jeder weiß also, dass es Ihr Fehler als Produktmanager ist.

Es bringt nämlich nichts, mit den Nutzern zu sprechen, Prototypen zu entwickeln und diese zusammen mit den Nutzern zu testen, wenn man das, was man dabei lernt, nicht umsetzt.

Der Gedanke, Anforderungen und Design als eine sequenzielle, vorhersehbare und geplante Phase im Produktentwicklungsprozess zu sehen, ist so tief in unserer Branche verankert, dass es oft sehr schwer für Produktorganisationen ist, diese Gewohnheit abzulegen.

Sie müssen es aber tun. In Produktorganisationen muss man verstehen, dass das Erfinden neuer Produkte grundsätzlich ein kreativer Prozess ist. Es ist eher eine Kunst als eine Wissenschaft. Ich nenne diese Phase daher lieber “Product Discovery” als “Anforderungen und Design”.

Der Begriff "Product Discovery" unterstreicht zwei besonders wichtige Punkte:

• Erstens muss man herausfinden, ob es da draußen wirklich Kunden gibt, die dieses Produkt haben wollen. Das bedeutet, dass man den Markt definieren und die Produktmöglichkeit von seinen Kunden bestätigen lassen muss.

• Zweitens muss man eine Lösung für dieses Problem finden, die nutzbar, nützlich und umsetzbar ist. Und das bedeutet, dass man das Produkt entwerfen und es dann gemeinsam mit den Kunden und dem Entwicklungsteam validieren muss.

Product Discovery in der Pharmaindustrie

Die Pharmaindustrie ist ein extremes Beispiel. Einen Markt zu finden ist nicht weiter schwierig – es gibt immer genug Probleme, die es sich lohnt, zu lösen (z. B. Leben retten, Leben verlängern oder die Verbesserung der Lebensqualität). Die Lösung dafür zu finden, ist der schwierige Teil. Wenn die Pharmaunternehmen mit der “Discovery Phase” beginnen, ist ihnen vollkommen bewusst, dass es keine Garantie dafür gibt, dass sie eine Lösung finden werden oder wie lange der Prozess dauern wird. In dieser Branche muss man also mit dieser Ungewissheit zurechtkommen (und das Risiko schlägt sich in den Preisen der Produkte nieder).

Gründe für Schwierigkeiten mit der Product Discovery

Und obwohl wir alle wissen, dass es schwierig ist und dass die Mehrheit aller Software Releases Misserfolge sind, weil sie nicht die gewünschten Ziele erfüllen, bestehen wir bei der Entwicklung von Software immer noch darauf, die Discovery Phase genauso zu planen wie den Bau eines Gebäudes.

Besonders das Management hat Schwierigkeiten mit dem Konzept von Product Discovery. Und ich glaube, dass es zwei Gründe dafür gibt:

• Erstens ist der Discovery Prozess nicht berechenbar. Das Management hat Angst, dass man monatelang an etwas arbeitet und nichts dabei herumkommt. Wenn man einfach loslegt und irgendetwas entwickelt, kann man wenigstens behaupten, etwas geliefert zu haben. Das ist wohl der selbe Grund, warum so viele Manager nicht gut mit Scrum klarkommen, denn sie wollen genau wissen, wie viele 30-tägige Sprints man brauchen wird, bis man fertig ist.

• Zweitens werden die Entwickler in einer Produktorganisation für Software immer als knappe Ressource angesehen. Der Gedanke, dass ein Team von Entwicklern herumsitzt und nichts tut, außer Kicker zu spielen, treibt das Management in den Wahnsinn.

Ironischerweise ist es genau diese Argumentation, die dazu führt, dass die Entwickler als Ressource verschwendet werden.

Fast jedes Unternehmen nutzt den eben beschriebenen Discovery Prozess. Anstatt sich mehrere Wochen mit einem Prototypen zu beschäftigen, lassen sie das gesamte Entwicklungsteam ganze Release-Zyklen durchführen, um die Software zu entwickeln, die dann durch die Qualitätssicherung geht und in Produktionssysteme eingesetzt wird. Das ist der Grund, warum so viele Unternehmen drei oder sogar mehr Releases und ein bis zwei Jahre benötigen, bevor sie etwas Nützliches und Nutzbares bekommen. Sie nutzen die Entwicklungsorganisation, um einen sehr sehr teuren Prototyp zu bauen, und machen ihre Kunden zu unfreiwilligen Testpersonen.

Das ist auch der Grund dafür, dass so viele Start-Ups keinen Erfolg haben. Sie haben einfach nicht das nötige Kapital, um zwei Jahre zu warten, bevor sie durchstarten können. Also, schnappen Sie sich deren Entwickler, lassen Sie sie ihr Bestes geben und warten Sie ab, was passiert.

Fazit

Start-Ups sowie großen Unternehmen rate ich daher, ihre Kräfte auf diesen viel schnelleren Discovery Prozess zu konzentrieren. Sobald sie dann eine Lösung gefunden haben, die funktioniert (die nutzbar, nützlich und umsetzbar ist), dreht sich alles um die Entwicklungsarbeit. Bis zu diesem Punkt müssen sie noch nicht so viele Entwickler haben. Die Entwickler, die sie haben, können und sollten aktiv an dem Discovery Prozess teilnehmen. Bis zu einem gewissen Punkt können die Entwickler während des Discovery Prozesses auch schon die Infrastruktur vorbereiten.

Sie können Ihrem Management helfen, den Product Discovery Prozess zu verstehen. Wenn Sie konsequent darauf hinweisen, dass es Ihre Pflicht ist, darauf zu achten, dass die Entwickler auch etwas Nützliches und Nutzbares schaffen, und Sie sich an den Bemühungen für eine erfolgversprechende Lösung beteiligen, werden Sie den Fokus des Managements auf diese äußerst wichtige Phase im Produktentwicklungsprozess lenken können.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt. 

Großartige Produkte erschaffen

=> Discovery vs Delivery bei Produkten.

Werde Product Owner

=> Besuche eins unserer Certified Scrum Product Owner Trainings und lerne mehr über die Rolle des Product Owners.

Eine Produktstrategie entwerfen

Erkenne, wie sich deine Unternehmensstrategie vs. Produktstrategie unterscheidet.