Gescheiterte Produkte
Anmerkung: Dieser Artikel ist die schriftliche Version einer Rede, die ich für Entwickler bei der Craft Conference und für Produktmanager und Designer bei Mind The Product gegeben habe.
In diesem Artikel möchte ich über die Ursachen sprechen, aufgrund derer so viele Produkte scheitern.
Warum scheitern Produkte und Produkteinführungen?
Bei den meisten Unternehmen sehe ich die gleiche grundlegende Arbeitsweise und das ist nicht ansatzweise mit der Arbeitsweise von wirklich guten Unternehmen vergleichbar.
Lassen Sie mich noch ein Wort der Warnung aussprechen, denn diese Diskussion kann deprimierend sein, besonders wenn Sie direkt von diesem Thema betroffen sind. Wenn das also der Fall sein sollte, bitte ich Sie einfach um ein wenig Durchhaltevermögen.
Der Produktentwicklungsprozess
Schauen wir uns zuerst einmal an, welchen Prozess die meisten Unternehmen immer noch nutzen, um ihre Produkte zu entwickeln. Ich werde versuchen, das vorerst noch nicht zu bewerten, sondern einfach nur den Prozess zu beschreiben:
Alles beginnt mit Ideen. In einem Großteil der Firmen kommen diese Ideen von der Geschäftsleitung, den wichtigsten Stakeholdern, den Geschäftsinhabern oder großen Kunden (bzw. potenziellen Kunden). In jedem Fall gibt es eine ganze Reihe von Dingen, die wir für die unterschiedlichen Bereiche eines Unternehmens tun müssen.
Als nächstes werden die Ideen in den meisten Unternehmen in einer Roadmap priorisiert und das hat zwei Gründe: Erstens will man, dass an den wertvollsten Dingen zuerst gearbeitet wird, und zweitens will man einschätzen können, wann diese Dinge fertig sein werden.
Dafür gibt es so gut wie immer eine vierteljährliche oder jährliche Planungssitzung, in der die Führungskräfte die Ideen durchgehen und eine Product Roadmap aushandeln. Um alles jedoch priorisieren zu können, benötigen sie erst eine Art Business Case für jedes Item.
Einige Firmen erarbeiten formelle Business Cases, andere eher informelle, aber bei beiden geht es darum, die folgenden zwei Dinge herauszufinden:
1) Wie viel Geld können wir damit verdienen?
2) Wie viel Geld bzw. Zeit wird es kosten? Aus diesen Informationen wird dann die Roadmap erstellt, meistens für das nächste Quartal, aber manchmal sogar für ein ganzes Jahr.
An diesem Punkt gibt es den Marschbefehl für das Produkt und die Technologie und normalerweise werden die Arbeiten dann nach Priorität erledigt.
Wenn es eine Idee an die Spitze der Prioritätenliste geschafft hat, spricht der Produktmanager als Erstes mit den Stakeholdern, um die Idee auszuarbeiten und „Anforderungen” zu formulieren.
Das können User Stories sein oder aber eine Art Funktionsspezifikation; der Zweck sollte jedoch in jedem Fall die Kommunikation mit den Designern und Entwicklern sein, die das Produkt bauen sollen.
Sobald man alle Anforderungen hat, wird das User Experience Design Team (vorausgesetzt es gibt ein solches Team in dem Unternehmen) gebeten, sich um das Interaction Design, Visual Design, und im Falle von Hardware, um das Produktdesign zu kümmern.
Zum Schluss erreichen die Anforderungen und Designspezifikationen die Entwickler. Das ist normalerweise der Punkt, an dem Agile ins Spiel kommt.
Der Part der Entwickler im Entwicklungsprozess
Die Entwickler teilen die Arbeit dann in Iterationen ein, die in Scrum „Sprints” genannt werden. Es dauert dann etwa 1-3 Sprints, um die Idee umzusetzen.
Im besten Fall sind QA-Tests in den Sprint eingebunden. Wenn nicht, wird das QA-Team einige Tests nachschieben, um festzustellen, ob die Idee wie gewünscht funktioniert und ob keine anderen Probleme auftreten (auch Regression genannt).
Sobald man vom QA-Team grünes Licht bekommt, wird die Idee endlich deployed und erreicht den Nutzer.
Fast alle Unternehmen, in die ich komme, egal ob groß oder klein, arbeiten schon seit vielen Jahren auf diese Weise. Und doch beklagen sich alle dieser Unternehmen durchweg über den Mangel an Innovation und die lange Zeitspanne, bis eine Idee endlich in den Händen der Kunden landet.
Agile vs. Wasserfall
Ihnen ist vielleicht aufgefallen, dass, obwohl ich Agile erwähnt habe und heutzutage fast jeder angeblich agil arbeitet, der eben beschriebene Prozess im Grunde genommen ein Wasserfall-Prozess ist. Fairerweise muss ich sagen, dass die Entwickler oft so viel aus Agile herausholen, wie es ihnen in diesem Wasserfall-Prozess möglich ist.
Okay, das ist vielleicht die Vorgehensweise der meistens Teams, aber warum ist das immer notwendigerweise die Ursache für so viele Probleme?
Warum scheitern deswegen so viele Produkte?
Ich werde versuchen, Ihnen den Zusammenhang zu zeigen, warum diese verbreitete Arbeitsweise tatsächlich meistens für das Scheitern der Produkte verantwortlich ist.
Ich könnte jetzt eine gefühlte Ewigkeit über die Probleme mit diesem Prozess reden, aber ich werde einfach die Top 10 der schwerwiegendsten Probleme mit dieser Arbeitsweise auflisten. Auch wenn jedes einzelne dieser zehn Probleme ein wirklich schwerwiegendes ist und ein Team zu Fall bringen könnte, haben die meisten Unternehmen viele oder sogar alle dieser Probleme auf einmal.
1) Fangen wir oben an – die Ideenquelle. Dieses Modell führt zu umsatzorientierten Sonderangeboten und stakeholderorientierten Produkten. Zu diesem Thema gibt es viel zu sagen, aber fürs Erste möchte ich einfach nur sagen, dass dies nicht die besten Quellen für Produktideen sind. Eine andere Folge dieses Ansatzes ist die fehlende Ermächtigung des Teams, denn bei diesem Ansatz sind sie nur für die Umsetzung zuständig – Söldner
2) Sprechen wir über die Schwachstelle bei den Business Cases. Nur damit Sie mich nicht falsch verstehen, ich finde Business Cases grundsätzlich gut, zumindest für Ideen, die eine größere Investition darstellen. Aber die Art und Weise, wie die meisten Firmen sie zu diesem Zeitpunkt erstellen, um eine priorisierte Roadmap zu erhalten, ist wirklich lächerlich. Erinnern Sie sich and die zwei Dinge, die jedem Business Case zugrunde liegen? Wie viel man verdienen wird und wie viel es kosten wird? Zu diesem Zeitpunkt können wir das einfach nicht wissen, weil wir keine Ahnung von auch nur einem dieser beiden Faktoren haben.
Wir können einfach nicht wissen, wie viel wir verdienen werden, denn das hängt hauptsächlich davon ab, wie gut unsere Lösungen sein werden. Wenn das Team super Arbeit leistet und extrem erfolgreich ist, kann das den gesamten Kurs des Unternehmens verändern. Andererseits ist die traurige Wahrheit aber, dass die meisten Produktideen absolut nichts einbringen. Und das ist nicht übertrieben. Ich meine wirklich nichts. Auf jeden Fall ist eine der wichtigsten Lektionen bei der Produktentwicklung, zu wissen, was wir nicht wissen können. Und wir können an diesem Punkt einfach noch nicht wissen, wie viel Geld wir verdienen werden.
Genauso haben wir keine Ahnung, was uns die Entwicklung des Produkts kosten wird. Ohne eine konkrete Lösung ist auch das ziemlich schwer einzuschätzen. Viele erfahrene Entwickler werden sich weigern, so früh eine Einschätzung abzugeben, allerdings werden einige auch den guten alten „T-Shirt” Kompromiss eingehen: Sagt wenigstens, ob es „Small, Medium, Large oder Extra Large” ist!
Firmen wollen nun mal priorisierte Roadmaps und dafür benötigen sie ein System, um die Ideen einschätzen zu können. Also spielen die Leute eben das Business Case Spiel mit.
3) Als nächstes kommt ein sogar noch größeres Problem. Unternehmen stehen total auf Roadmaps. Ich habe schon viele Roadmaps gesehen und die meisten davon sind im Prinzip nur priorisierte Feature-Listen. Das Marketing braucht dieses Feature für eine Kampagne. Der Vertrieb braucht dieses Feature für einen neuen Kunden. Jemand will PayPal integrieren. Ich denke, Sie haben verstanden, was ich meine.
Allerdings gibt es ein Problem und es ist vielleicht das größte von allen. Ich nenne es die „zwei unbequemen Wahrheiten über Produkte”.
Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen einfach nicht funktionieren wird. Es gibt so viele Gründe, warum eine Idee nicht funktioniert. Am häufigsten passiert es wohl, dass die Kunden einfach nicht so begeistert von der Idee sind wie wir. Also benutzen sie das Produkt nicht. Manchmal wollen sie es nutzen, aber es ist so kompliziert, dass es mehr Ärger als Nutzen bringt. Also ist das Resultat das gleiche: die Kunden nutzen es nicht. Manchmal würden die Kunden das Produkt lieben, aber es stellt sich heraus, dass damit viel mehr Aufwand verbunden ist, als wir dachten und wir einfach nicht das Geld und die Zeit haben, es zu entwickeln.
Ich versichere Ihnen, dass mindestens die Hälfte der Ideen auf Ihrer Roadmap nicht das liefern wird, was Sie sich erhofft hatten. Und nebenbei, die wirklich guten Teams gehen davon aus, dass mindestens drei Viertel der Ideen nicht so funktionieren, wie wir dachten.
Als ob das noch nicht schlimm genug wäre, ist die zweite Wahrheit, dass man sogar bei Ideen, die wirklich Potenzial haben, normalerweise mehrere Iterationen braucht, bis man sie so weit umgesetzt hat, dass sie tatsächlich den benötigten Geschäftswert liefert. Wir nennen das „Time To Money”.
Das Wichtigste, was ich im Hinblick auf die Produktentwicklung gelernt habe, ist, dass man diesen beiden Wahrheiten einfach nicht entkommen kann – egal wie schlau man ist. Ich hatte das große Glück, mit vielen wirklich außergewöhnlichen Produktteams arbeiten zu dürfen. Der Unterschied ist, wie man mit diesen Wahrheiten umgeht.
4) Die Rolle des Produkts in diesem Modell: eigentlich würde ich gar nicht von dem Produkt als Rolle sprechen. Im Grunde genommen ist es eher eine Form des Projektmanagements. In diesem Modell geht es eher darum, Anforderungen zu sammeln und sie für die Entwickler zu dokumentieren. Glauben Sie mir, das hier hat mit modernem Produktmanagement gar nichts zu tun.
5) Ähnlich ist es mit der Rolle des Designs. An diesem Punkt ist es schon viel zu spät, um durch Design einen wirklichen Wert zu schaffen. Dann hilft man sich gerne mit dem sogenannten „Lipstick on the pig”-Modell. Das Kind ist bereits in den Brunnen gefallen und wir versuchen einfach nur, das zu verschleiern. Die UX Designer wissen, dass das nicht gut ist, versuchen aber alles so gut und einheitlich wie möglich aussehen zu lassen.
6) Wodurch einem bei diesem Modell die meisten Chancen entgehen, ist wohl die Tatsache, dass die Entwicklung erst so spät in den Prozess einbezogen wird. Man sagt, wenn man seine Entwickler nur zum Schreiben von Code hat, entgeht einem die Hälfte des Werts, den sie einem bieten könnten. Entwickler sind normalerweise die beste Quelle für Innovation und dennoch werden sie erst gar nicht in den Prozess einbezogen.
7) Nicht nur die Entwickler, sondern auch die Prinzipien und Hauptvorteile von Agile kommen hier viel zu spät ins Spiel. Teams, die Agile auf diese Weise nutzen, bekommen lediglich etwa 20% des Werts und Potenzials der agilen Methoden. Hier bezieht sich Agile nur auf die Auslieferung, aber der Rest der Organisation und des Kontextes ist weiterhin alles andere als agil.
8) Der gesamte Prozess ist sehr projektbezogen. Ein Unternehmen finanziert Projekte, stellt das Personal für die Projekte ein, treibt die Projekte voran und setzt sie um. Leider sind Projekte aber nur Output, bei der Produktentwicklung geht es aber um Outcome. Dieser Prozess führt unweigerlich zu verwaisten Projekten. Okay, irgendetwas wurde am Ende released, erfüllt aber nicht den eigentlichen Zweck. Was soll das ganze also? Das ist ein großes Problem und kommt dem ziemlich nahe, wie wir unsere Produkte bauen.
9) Die größte Schwäche des alten Wasserfallprozesses ist und war schon immer die Tatsache, dass das ganze Risiko am Ende zum Vorschein kommt. Die Validierung durch den Kunden geschieht einfach viel zu spät.
Sie haben hoffentlich schon von Lean Startup Methoden gehört, die so ziemlich das genaue Gegenteil davon darstellen. Das Hauptprinzip davon ist, Verschwendung zu minimieren und die größte Verschwendung ist, ein Feature oder Produkt zu designen, zu bauen, zu testen und zu deployen, nur um dann herauszufinden, dass es nicht gebraucht wird. Ironischerweise glauben viele Teams, dass sie die Prinzipien von Lean anwenden, folgen aber eigentlich nur dem oben beschriebenen Prozess. Und dann erkläre ich ihnen, dass sie ihre Ideen auf die teuerste und langsamste Weise ausprobieren, die wir kennen.
10) Und zu guter Letzt, während wir mit dem Prozess beschäftigt sind und unsere Zeit und unser Geld verschwenden, stellen die Opportunitätskosten für die Dinge, die eine Organisation stattdessen hätte tun können und sollen, den größten Verlust dar. Diese Zeit und all das Geld bekommen wir niemals wieder.
Ich bin nicht sehr überrascht, dass so viele Unternehmen so viel Geld und Zeit investieren und so wenig dafür bekommen. Ich hatte Sie ja gewarnt, dass das deprimierend werden könnte.
Die gute Nachricht ist, dass ich Ihnen versichern kann, dass die besten Teams nicht ansatzweise so arbeiten, wie ich es beschrieben habe.
Zusammenfassung
Ich habe schon viele Artikel über die unterschiedlichen Aspekte der besten Teams geschrieben. Bei Product Discovery geht es darum, wie wir erfolgreiche Lösungen für unsere Probleme finden. Es ist eine aktive und fortlaufende Art der Zusammenarbeit zwischen den Bereichen Produkt, User Experience Design und Entwicklung. [Continuous Discovery und Continuos Delivery](/de/product-owner/discovery-vs-delivery/ "Discovery vs. Delivery) laufen parallel. Features auf Roadmaps (Output) werden durch Geschäftsprobleme ersetzt, die gelöst werden sollen (Outcome). Das Ziel ist, dass das Produkt so gut wie möglich zur Nachfrage des Marktes passt (Product/Market Fit).
Wenn Ihr Unternehmen immer noch an diesem alten, überholten Prozess festhält, können Sie nun hoffentlich Licht ins Dunkel bringen und frisch in die Zukunft starten. Und ich hoffe das gelingt Ihnen, bevor Sie von einem Startup oder Konkurrenten überholt werden, der viel schneller und effektiver ist als Ihr Unternehmen.
Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.
Mustertabelle für den Product Backlog
=> So kannst du User Stories im Product Backlog als Tabelle darstellen.
Das Product Goal Canvas
=> Lege dein Produktziel mit dem Product Goal Canvas fest.