Читать книгу Inspired - Marty Cagan - Страница 17

Beginnen wir damit, die Ursachen für das Scheitern so vieler Produktvorhaben zu ergründen.

In den meisten Unternehmen, und zwar überall auf der Welt und egal welcher Größe, erkenne ich dieselben grundlegenden Arbeitsweisen und ich kann nicht umhin zu bemerken, dass diese nicht annähernd mit denen der besten Unternehmen vergleichbar sind.

Kleine Warnung vorab: Die folgende Darstellung kann ein bisschen deprimierend sein, besonders wenn Sie sich darin nur allzu gut wiederfinden. Also falls das der Fall sein sollte, möchte ich Sie bitten, einfach mit mir gemeinsam dranzubleiben.

Abbildung 6.1 beschreibt den Prozess, den die meisten Firmen nach wie vor nutzen, um Produkte zu schaffen. Ich möchte dieses Vorgehen noch nicht bewerten, sondern den Prozess zunächst einfach beschreiben:

Wie Sie sehen, fängt alles mit Ideen an. In den meisten Unternehmen kommen sie von innerhalb (durch die Geschäftsführung oder wichtige Stakeholder oder Firmeneigentümer) oder von außen (durch aktuelle oder potenzielle Kunden). Wo auch immer sie ihren Ursprung haben, es gibt stets eine ganze Reihe von Dingen, die verschiedene Bereiche des Unternehmens von uns erfordern.

Abbildung 6.1: Grundursachen gescheiterter Produktvorhaben

Die meisten Unternehmen möchten diese Ideen nach Prioritäten sortiert in einer Roadmap darstellen, und zwar aus zwei wesentlichen Gründen. Zum einen wollen sie, dass wir als Erstes an den wichtigsten Dingen arbeiten, und zum anderen wollen sie vorhersagen können, wann was fertig ist.

Dafür gibt es gewöhnlich irgendeine Form vierteljährlicher oder jährlicher Planungssitzungen, bei denen die Führungskräfte die Ideen begutachten und über eine Product Roadmap verhandeln. Aber um Prioritäten setzen zu können, brauchen sie zunächst für jeden Punkt irgendeine Art von Business Case.

Manche Firmen erstellen formelle Business Cases, andere eher informelle, aber in jedem Fall müssen über jede Idee zwei Dinge bekannt sein: (1) Wie viel Geld oder Wert bringt sie? Und: (2) Wie viel Geld oder Zeit kostet sie? Diese Informationen werden dann für die Erstellung der Roadmap genutzt, normalerweise für das nächste Quartal, aber manchmal auch bis zu einem Jahr im Voraus.

Durch diese Roadmap hat die Produkt- und Technologieorganisation nun ihren Marschbefehl und bearbeitet die Aufgaben nach Priorität.

Hat eine Idee es ganz nach oben auf die Liste geschafft, besteht die erste Aufgabe des Product Managers darin, mit den Stakeholdern zu sprechen, um die Idee auszugestalten und eine Reihe von »Anforderungen« zu formulieren.

Diese Anforderungen können User Stories oder irgendeine Form funktioneller Spezifikationen sein. Ihr Zweck ist es, den Designern und Programmierern zu verdeutlichen, was genau geschaffen werden muss.

Sind die Anforderungen zusammengetragen, wird das User-Experience-Designteam (vorausgesetzt, das Unternehmen verfügt über ein solches) mit dem Interaction Design, dem Visual Design und bei physischen Geräten mit dem Industrial Design beauftragt.

Schließlich werden die Anforderungen und die Design-Spezifikationen den Engineers vorgelegt. An dieser Stelle tritt für gewöhnlich Agile auf den Plan.

Die Programmierer werden die Arbeit typischerweise auf eine Reihe von Iterationen herunterbrechen – im Scrum-Prozess werden sie als »Sprints« bezeichnet. Es braucht also vielleicht ein bis drei Sprints, um die Idee auszugestalten.

Zu diesen Sprints gehört hoffentlich auch das QA Testing. Wenn nicht, wird das QA-Team dies nachholen und einige Tests vornehmen, um sicherzustellen, dass die neue Idee wie angekündigt funktioniert und nicht für weitere Probleme sorgt (die als Regressionen bekannt sind).

Sobald die QA grünes Licht gegeben hat, kann die neue Idee endlich bei echten Kunden zum Einsatz kommen.

Die Mehrheit der Unternehmen, ob groß oder klein, denen ich erstmals begegne, arbeiten im Wesentlichen genauso und tun das schon seit vielen Jahren. Doch diese Unternehmen klagen auch fortwährend über den Innovationsmangel und die sehr lange Dauer des Weges der Idee zum Kunden.

Ihnen ist vielleicht aufgefallen, dass ich zwar Agile erwähnt habe und dass so ziemlich jeder heute Agile für sich beansprucht, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess. Um den Programmierern Gerechtigkeit widerfahren zu lassen, muss gesagt sein, dass sie im Rahmen des größeren Wasserfall-Kontextes im Allgemeinen so viel Agile wie möglich anwenden.

Die meisten Teams werden vermutlich so arbeiten. Aber warum sollte das der Grund für so viele Probleme sein? Ziehen wir jetzt einmal die Verbindungslinien, damit wir genau erkennen können, warum diese weit verbreitete Arbeitsmethode für die meisten gescheiterten Produktvorhaben verantwortlich ist.

In der folgenden Liste führe ich auf, was ich für die zehn größten Probleme bei dieser Vorgehensweise halte. Denken Sie daran, dass jedes dieser zehn Probleme eine sehr ernste Angelegenheit ist, die allein schon ein ganzes Team ins Schleudern bringen kann. Viele Unternehmen haben jedoch mehr als eins oder sogar alle diese Probleme.

Zwar beansprucht so ziemlich jeder heute Agile für sich, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess.

1 Beginnen wir ganz oben – bei der Quelle der Ideen. Dieses Modell führt zu verkaufsgesteuerten Besonderheiten und zu stakeholdergesteuerten Produkten. Es gibt zu diesem zentralen Thema noch sehr viel mehr zu sagen, aber fürs Erste nur so viel: Das ist nicht die Quelle unserer besten Produktideen. Eine weitere Folge dieser Vorgehensweise ist die mangelnde Beteiligung der Teammitglieder. In diesem Modell haben sie nichts weiter zu tun, als zu implementieren – sie sind nichts als Söldner.

2 Als Nächstes wollen wir über den fatalen Irrtum bei diesen Business Cases sprechen. Um das klarzustellen, ich persönlich bin ein großer Befürworter von Business Cases, zumindest für Ideen, die eine größere Investition brauchen. Aber die Art und Weise, wie die meisten Unternehmen sie in diesem Stadium erstellen, um eine nach Prioritäten geordnete Roadmap zu erhalten, ist wirklich lächerlich, und zwar aus folgendem Grund. Erinnern Sie sich an die beiden wichtigsten Vorüberlegungen für jeden Business Case? Wie viel Geld Sie verdienen werden und wie viel es kosten wird? Also, die nackte, schonungslose Wahrheit lautet: In dieser Phase haben wir von beidem nicht die leiseste Ahnung. Genau genommen können wir das gar nicht wissen.Wir können nicht wissen, wie viel Geld wir verdienen, weil das komplett davon abhängt, als wie gut die Lösung sich erweist. Wenn das Team gute Arbeit leistet, könnte die Sache äußerst erfolgreich sein und wahrhaftig den Kurs des Unternehmens ändern. Die Wahrheit ist jedoch, dass viele Produktideen am Ende überhaupt nichts einbringen. Und das ist keine effekthascherische Übertreibung. Wirklich überhaupt nichts (das wissen wir aus A/B-Tests).Auf alle Fälle lautet eine der wichtigsten Lektionen beim Produktmarketing, zu wissen, was wir nicht wissen können, und wir können zu diesem Zeitpunkt einfach nicht wissen, wie viel Geld wir verdienen werden.Ebenso wenig Ahnung haben wir davon, wie hoch die Erstellungskosten sein werden. Ohne die eigentliche Lösung zu kennen, ist das für die Technik extrem schwer vorauszusagen. Die meisten erfahrenen Programmierer dürften es ablehnen, in diesem Stadium eine Schätzung vorzunehmen, aber manche werden zu einem T-Shirt-Größen-Kompromiss gedrängt – uns einfach zu sagen, ob es »S, M, L oder XL ausfällt«.Aber Unternehmen wollen diese nach Prioritäten geordneten Roadmaps unbedingt haben, und um einen zu erstellen, brauchen sie irgendein System zur Bewertung der Ideen. Also spielen die Leute das Business-Case-Spiel.

3 Ein sogar noch größeres Problem ist, zu sagen, was als Nächstes kommt, und an dieser Stelle sind die Unternehmen wirklich begeistert von ihren Product Roadmaps. Im Laufe der Jahre habe ich zahllose Roadmaps gesehen und die meisten davon sind im Wesentlichen Listen von Funktionen und Projekten. Das Marketing braucht diese Funktion für eine Werbekampagne. Der Verkauf braucht jene Funktion für einen neuen Kunden. Jemand möchte eine PayPal-Verknüpfung. Sie wissen schon, worauf ich hinauswill.Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird.Aber jetzt kommt das Problem – vielleicht das größte von allen. Es ist das, was ich als die beiden unbequemen Wahrheiten über Produkte bezeichne.Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird. Es gibt viele Gründe, warum eine Idee nicht umsetzbar ist. Der häufigste ist, dass die Kunden diese Idee einfach nicht so fantastisch finden wie wir. Also entscheiden sie sich, das Produkt nicht zu verwenden. Manchmal probieren sie es zwar aus, aber dann erweist es sich als so kompliziert, dass sich der Aufwand einfach nicht lohnt und die Kunden keinen zweiten Versuch unternehmen. Manchmal besteht das Problem darin, dass die Nutzer das Produkt zwar toll fänden, aber es stellt sich heraus, dass die Herstellung viel mehr erfordert, als wir gedacht haben, weshalb wir einfach nicht die notwendige Zeit und das Geld aufbringen können, um es anzubieten.Ich kann Ihnen garantieren, dass mindestens die Hälfte der Ideen in Ihrer Roadmap nicht das von Ihnen erhoffte Resultat bringen wird. (Übrigens, wirklich gute Teams schätzen, dass mindestens drei Viertel der Ideen nicht so laufen wie erhofft.)Als wäre das noch nicht schlimm genug, lautet die zweite unbequeme Wahrheit, dass selbst für die Ideen, die Potenzial beweisen, typischerweise etliche Iterationen notwendig sind, bis die Realisierung dieser Idee zu einem Punkt gelangt, an dem sie den notwendigen Geschäftswert erbringt. Wir nennen das Time to Money.Eines der wichtigsten Dinge, die ich über das Product Management gelernt habe, ist, dass diese unbequemen Wahrheiten sich einfach nicht umgehen lassen, egal wie clever Sie auch sein mögen. Und ich hatte das Glück, mit vielen wirklich außergewöhnlichen Produktteams zusammenzuarbeiten. Der tatsächliche Unterschied liegt darin, wie man mit diesen Wahrheiten umgeht.

4 Lassen Sie uns als Nächstes die Rolle des Product Managements in diesem Modell betrachten. Eigentlich sollten wir es gar nicht als Product Management bezeichnen– es ist genau genommen eine Form des Project Managements. In diesem Modell geht es mehr darum, Anforderungen zusammenzutragen und sie für die Programmierer zu dokumentieren. Lassen Sie mich an dieser Stelle nur sagen, dass dies um 180 Grad von der Realität des modernen Tech Product Managements abweicht.

5 Ganz Ähnliches gilt für die Rolle des Designs. Die Sache ist schon viel zu weit vorangeschritten, um dem Design zu seinem tatsächlichen Wert zu verhelfen, und was hier geschieht, sind in erster Linie »kosmetische Maßnahmen«. Der Schaden ist bereits angerichtet und wir versuchen jetzt bloß, eine Schicht Farbe darüberzupinseln. Die UX-Designer wissen, dass das nicht gut ist, aber sie geben sich Mühe, es so nett und stimmig wie möglich aussehen zu lassen.

6 Die vielleicht größte verpasste Chance in diesem Modell ist die Tatsache, dass die technische Seite viel zu spät ins Spiel gebracht wird. Wir sagen, wenn Sie Ihre Programmierer nur zum Coden einsetzen, nutzen Sie nur ungefähr die Hälfte ihres Wertes. Das kleine Geheimnis der Produkterstellung lautet, dass Programmierer typischerweise die beste Innovationsquelle sind; trotzdem werden sie bei diesem Prozess nicht mal zur Party eingeladen.

7 Nicht nur das Engineering wird viel zu spät eingebracht, sondern auch die Prinzipien und wichtigsten Vorzüge von Agile treten viel zu spät auf den Plan. Teams, die Agile auf diese Weise nutzen, schöpfen vielleicht 20 Prozent des tatsächlichen Wertes und Potenzials der Agile-Methoden aus. Was man hier wirklich sieht, sind Agile-Methoden bei der Delivery, aber der Rest der Organisation und des Kontextes ist alles andere als agil.

8 Dieser gesamte Prozess ist sehr projektlastig. Das Unternehmen finanziert Projekte, stellt Personal für Projekte ab, drückt Projekte durch und führt schließlich Projekte aus. Leider sind Projekte aber Output und beim Produkt geht es in erster Linie um Resultate. Dieser Prozess führt vorhersehbar zu verwaisten Projekten. Irgendetwas wird am Ende schon dabei herauskommen, aber es erfüllt die Erwartungen nicht. Also worum ging es bei der ganzen Sache eigentlich? Auf jeden Fall ist das ein ernst zu nehmendes Problem und hat nichts damit zu tun, wie wir Produkte erstellen sollten.

9 Der größte Schwachpunkt des guten alten Wasserfallprozesses war schon immer und bleibt auch weiterhin, dass das gesamte Risiko am Ende liegt, und das bedeutet, dass die Kundenvalidierung viel zu spät erfolgt.Das Grundprinzip von Lean-Methoden ist die Reduzierung von Überflüssigem und eine der entscheidendsten Formen des Überflüssigen ist es, eine Funktion oder ein Produkt zu gestalten, zu schaffen, zu testen und einzuführen, nur um festzustellen, dass es nicht das ist, was benötigt wird. Die Ironie an der Sache ist, dass viele Teams glauben, sie würden Lean-Prinzipien anwenden; stattdessen folgen sie aber nur den grundlegenden Prozessen, die ich gerade beschrieben habe. Dann erkläre ich ihnen, dass sie Ideen auf eine der teuersten und langsamsten Arten ausprobieren, die uns bekannt ist.

10 Und während wir mit diesem Prozess beschäftigt sind und Zeit und Geld vergeuden, zeigt sich am Ende für gewöhnlich der größte Verlust von allen, nämlich in Form der Opportunitätskosten dessen, was die Organisation stattdessen hätte tun können und sollen. Wir können uns diese Zeit und dieses Geld nicht zurückholen.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen. Ich habe Sie gewarnt, dass das Ganze ein bisschen deprimierend werden könnte. Aber Sie sollten genau verstehen, warum Ihr Unternehmen seine Arbeitsweise ändern muss, vorausgesetzt natürlich, dass es tatsächlich auf diese Weise arbeitet.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen.

Die gute Nachricht ist: Ich verspreche Ihnen, dass die besten Teams überhaupt nicht so vorgehen, wie ich es gerade geschildert habe.