Vor kurzem habe ich einen neuen Blogeintrag von Marty Cagan gelesen, dem Experten für Produktmanagement. Seine Beobachtung entsprechen so sehr meinen, dass ich mich entschieden habe seinen Post zu übersetzen. Mit seiner freundlichen Erlaubnis, die deutsche Übersetzung des Posts (http://www.svpg.com/product-fail):

­­


Produkt Fail

Ich sehe die gleiche fundamentale Arbeitsweise bei der Mehrheit der Unternehmen. Und für mich ist es offensichtlich, dass diese Arbeitsweise nicht im Geringsten der Arbeitsweise von wirklich erfolgreichen Unternehmen entspricht.

Ich muss Sie warnen, diese Diskussion kann ein wenig deprimierend sein, vor allem, wenn viele Punkte stark auf ihr Unternehmen zutreffen. Falls das der Fall ist, möchte ich Sie bitten trotzdem weiterzulesen.

Wir beginnen mit einem Spaziergang durch die Grundlagen dieses Prozesses, der noch heute von einer großen Mehrheit der Unternehmen zur Produktentwicklung angewendet wird. Ich werde versuchen sachlich zu bleiben und zunächst kurz nur den Prozess beschreiben:

Alles beginnt mit Ideen. In den meisten Unternehmen kommen diese von Führungskräften oder von wichtigen Stakeholdern oder Anteilseignern oder von (potentiellen) Großkunden. Auf jedem Fall gibt es immer eine ganze Reihe von solchen Ideen, die wir, die Produktorganisation, in verschiedenen Bereichen tun müssen.

Die meisten Unternehmen wollen diese Ideen in einer Roadmap priorisieren und dies tun sie aus zwei Gründen. Erstens, sie wollen das zuerst an den wertvollsten Dingen gearbeitet wird. Und zweitens, wollen sie in der Lage sein, vorherzusagen wann bestimmte Dinge fertig sein werden.

Um dies zu tun, gibt es fast immer eine Quartals- oder Jahresplanungssitzung, wo die Unternehmensführung die Ideen beurteilt und die Prioritäten in der Produkt-Roadmap verhandelt. Aber um zu priorisieren, braucht die Führung zuerst einen Business-Case für jede Idee.

Einige Unternehmen haben formelle Business-Cases und andere informelle, aber so oder so geht es um die Notwendigkeit, zwei Dinge über jede Idee herauszufinden: 1) wie viel Geld wird sie einbringen? und 2) wie viel Geld oder Zeit wird sie kosten? Diese Informationen werden dann verwendet, um die Roadmap zu erstellen, in der Regel für das nächste Quartal, aber manchmal auch für ein ganzes Jahr.

An diesem Punkt erhält die Produkt- und Technologie-Organisation ihren Marschbefehl. Und in der Regel werden die Elemente mit der höchsten Priorität der Reihe nach abgearbeitet.

Sobald eine Idee es an die Spitze der Liste schafft, ist der erste Schritt des Produkt-Managers, die beteiligten Stakeholder zu kontaktieren, die Idee auszuarbeiten und eine Liste von Nutzer-Anforderungen zu erstellen. Diese können als gewünschte Benutzererfahrungen oder eine Art funktionale Spezifikation oder in anderen Formate formalisiert werden. Ihr Zweck ist es, den Designern und Entwicklern mitzuteilen, was hergestellt werden soll.

Sobald die Anforderungen gesammelt sind, wird das UX-Team (angenommen, das Unternehmen hat ein solches Team) aufgefordert, das Interaktionsdesign, das visuelle Design und bei physischen Produkten, das Industrie-Design, herzustellen. Im Anschluss werden diese Anforderungen und Design-Spezifikationen an die Entwickler weitergeleitet. In der Regel kommt erst hier Agilität ins Spiel.

Im Scrum-Prozess teilen die Entwickler in der Regel die Arbeit in eine Reihe von Iterationen auf – diese werden „Sprints“ genannt. Es kann typischerweise 1-3 Sprints dauern, bis eine Idee ausgearbeitet ist.

Es ist zu hoffen, dass QA-Tests Teil dieser Sprints ist. Aber falls das nicht der Fall ist, wird das QA-Team im Anschluss einige Tests durchführen, um sicherzustellen, dass die neue Idee so funktioniert, wie sie spezifiziert wurde und auch sonst keine neuen anderen Probleme entstanden sind – Regressionstests.

Sobald das grüne Licht von QA kommt, wird die neue Idee endlich an den Kunden ausgeliefert

 

Bei der Mehrheit der Unternehmen, die ich neu kennenlerne, groß und klein, ist dies die wesentliche Vorgehensweise, nach der schon seit vielen Jahren gearbeitet wird. Jedoch beschweren sich genau diese Unternehmen konsequent über den Mangel an Innovation und über die sehr lange Dauer, bis eine Idee in den Händen der Kunden ankommt.

Sie haben vielleicht festgestellt, dass ich Agilität erwähnt habe. Während heutzutage fast jeder behauptet agil zu sein, ist der Vorgang, den ich gerade beschrieben habe, eher ein Wasserfall-Prozess. In Fairness zu den Entwicklern, diese sind in der Regel, so agil, wie sie es, angesichts des breiten Wasserfall-Kontexts, nur sein können.

OK, das mag vielleicht das Konzept sein, nach dem so viele Teams arbeiten, aber warum ist das der Grund für so viele Probleme?

Ich möchte Ihnen jetzt zeigen, warum diese Art der Arbeitsweise für die meisten gescheiterten Produkte verantwortlich ist. Ich könnte buchstäblich den ganzen Tag lang über die Probleme mit diesem Prozess sprechen, aber ich denke es ist besser Ihnen die „Top 10“  der größten Probleme mit dieser Arbeitsweise aufzulisten. Um klarzustellen, ich behaupte, dass alle dieser zehn sehr ernsthafte Probleme sind, von denen jedes einzelne ein Team entgleisen könnte. Viele Unternehmen haben aber tatsächlich alle oder sogar noch mehr dieser Probleme.

1. Beginnen wir an der Spitze – die Quelle der Ideen. Das obige Modell führt zu verkaufsangetriebenen oder von Interessengruppen angeleiteten Produkten. Im Weiteren kommt noch viel mehr zu diesem Punkt. An dieser Stelle möchte ich nur sagen, dass dies nicht die Quelle unserer besten Produktideen ist. Eine weitere Folge dieser Vorgehensweise ist die mangelnde Einbindung des Teams – in diesem Modell ist das Team nur da um zu implementieren. Söldner.

2. Lassen Sie uns als nächstes über die fatalen Fehler in den Business-Cases sprechen. Nur um klarzustellen, ich bin sogar ein Fan von Business-Cases, zumindest für Ideen, die eine größere Investition benötigen. Aber die Art und Weise, wie die meisten Unternehmen diese Business-Cases in dieser Phase handhaben, um eine priorisierte Roadmap zu erstellen, ist wirklich lächerlich. Hier sind die Gründe. Erinnern Sie sich an die beiden Schlüsselfragen zu jedem Business-Case? Wie viel Geld sie verdienen werden und wie viel es kosten wird? Die kalte Wahrheit ist, dass wir zu diesem Zeitpunkt keine Ahnung haben und es auch nicht wissen können.

Wir können nicht wissen, wie viel Geld die Idee einbringen wird, denn das hängt enorm davon ab, wie gut die Lösung am Ende ist. Wenn das Team eine ausgezeichnete Arbeit vollbringt, könnte es extrem erfolgreich sein und damit buchstäblich den Kurs des Unternehmens verändern. Aber auf der anderen Seite bewirken viele Produktideen am Ende überhaupt nichts. Buchstäblich nichts. Auf jeden Fall ist eines der wichtigsten Dinge im Produktmanagement, zu wissen, was wir nicht wissen können. Und wir können zu diesem Zeitpunkt einfach nicht wissen, wie viel Geld wir einnehmen werden.

Ebenso haben wir keine Ahnung, was es kosten wird. Ohne die eigentliche Lösung zu kennen, ist dies extrem hart für Entwickler vorherzusagen. Die meisten erfahrenen Entwickler werden sich sogar weigern, zu diesem Zeitpunkt eine Aussage zu Kosten abzugeben. Aber einige werden durch die veraltete Aufforderung eine „T-Shirt-Size“ abzugeben, unter Druck gesetzt – „Sagen Sie uns einfach wie groß es ist: Small, Medium, Large oder Extra Large?“.

Und Unternehmen wollen diese priorisierten Roadmaps und um eine zu bekommen, benötigen sie eine Art von System, um die Ideen zu bewerten. Und so kommt es zum Business-Case-Spiel.

3. Als nächstes kommt ein noch größeres Problem. Unternehmen freuen sich sehr über ihre Roadmaps. Ich habe unzählige Roadmaps gesehen und die überwiegende Mehrheit sind im Wesentlichen priorisierte Listen von Features. Das Marketing braucht diese Funktion um Kampagnen zu planen. Der Vertrieb braucht diese Funktion um sie Kunden versprechen zu können. Jemand anders will eine PayPal-Integration. Sie wissen was ich meine.

Aber hier ist das Problem und es ist vielleicht das größte Problem von allen. Ich nenne es „die zwei unbequemen Wahrheiten über das Produkt.“

Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen einfach nicht funktionieren werden. Es gibt viele Gründe, warum eine Idee nicht funktioniert. Der häufigste Grund ist, dass die Kunden einfach nicht so begeistert von dieser Idee sind, wie wir und sie deshalb einfach nicht beachten. Manchmal beachten unsere Kunden die Idee, aber nach dem Ausprobieren stellen sie fest, dass es zu kompliziert ist. Das führt dann am Ende zum gleichen Ergebnis – der Benutzer entscheidet sich gegen einen Kauf. Manchmal ist das Problem, dass die Kunden Interesse zeigen, aber sich später herausstellt, dass die Umsetzung viel schwerer ist, als wir dachten. Und so entscheiden wir, dass sich die Implementierung nicht lohnt.

Gehen sie davon aus, dass mindestens die Hälfte der Ideen auf Ihrer Roadmap nicht das liefern, was Sie sich erhoffen. Nur nebenbei bemerkt, die wirklich guten Teams gehen davon aus, dass mindestens drei Viertel der Ideen, nicht das liefern werden, was wir sie sich erhoffen.

Und als sei das nicht schon schlimm genug, ist die zweite unbequeme Wahrheit, dass auch Ideen mit Potenzial, in der Regel mehrere Iterationen brauchen, ehe an dem Punkt ankommen, wo sie tatsächlich den notwendigen Unternehmenswert liefern. Wir nennen das „time to money“.

Eines der wichtigsten Dinge, die ich über Produkte gelernt habe ist, dass man diesen Wahrheiten einfach nicht entkommen kann. Egal wie intelligent man ist. Und ich hatte das Glück, mit vielen wirklich außergewöhnlichen Produktteams zusammenzuarbeiten. Der große Unterschied zwischen Teams ist, wie sie mit diesen Wahrheiten umgehen.

4. Lassen Sie uns als nächstes über die Rolle des Produktmanagements in diesem Modell sprechen. Ich würde soweit gehen zu sagen, dass wir nicht einmal wirklich von einem Produktmanagement sprechen. Es ist eher eine Form von Projektmanagement. In diesem Modell geht es viel mehr um das Sammeln von Anforderungen und deren Dokumentation für die Entwickler. Um mich kurz zu fassen, möchte ich nur sagen, dass wir damit das Gegenteil von dem machen, was unter modernem Produktmanagement verstanden wird.

5. Ähnlich verhält es sich mit der Rolle des Designs. Dieses kommt viel zu spät ins Spiel, um einen realen Wert beitragen zu können. Was nun nur noch gemacht werden kann, nennen wir das “lipstick on the pig“. Der Schaden ist bereits angerichtet und jetzt versuchen wir nur noch, dem Durcheinander einen neuen Anstrich zu verpassen. Die UX-Designer wissen, dass das nicht gut ist, aber sie versuchen, das Ergebnis so schön und konsequent, wie möglich aussehen zu lassen.

6. Die vielleicht größte verpasste Chance in diesem Modell ist die Tatsache, dass die Entwickler viel zu spät mit einbezogen werden. Wir behaupten, dass wenn Sie Ihre Entwickler nur zum Programmieren verwenden, Sie nur etwa die Hälfte des Wertes rauskriegen. Das kleine Geheimnis guter Produkte ist, dass Entwickler in der Regel die besten Innovationen liefern. Jedoch werden sie hier noch nicht einmal zum Ideenprozess hinzugezogen.

7. Entwickler werden nicht nur zu spät mit einbezogen, sondern auch die Grundsätze und die wichtigsten Vorteile der Agilität kommen viel zu spät ins Spiel. Teams die Agilität auf diese Weise verwenden, realisieren so vielleicht 20% des Wertes und des Potenzials von Agilität. Was Sie wirklich sehen, ist Agilität in der Lieferung des Produkts, aber der Rest der Organisation und der Kontext ist alles andere als agil.

8. Dieser gesamte Prozess ist sehr projektzentriert. Das Unternehmen fördert in der Regel Projekte, versorgt Projekte und schiebt Projekte an und liefert Projekte an Kunden aus. Leider sind die Projekte Output und bei Produkten geht es um Outcomes – Erreichung von Unternehmenszielen. Diese Vorgehensweise führt erwartungsgemäß zu verwaisten Projekten. Ja, es wurde endlich etwas geliefert, aber es erreicht nicht die gesetzten Ziele. Warum haben wir also gemacht? Auf jeden Fall ist das Denken in Projekten ein ernstes Problem und hat nichts mit dem zu tun, was wir brauchen um erfolgreiche Produkte herzustellen.

9. Das größte Problem beim alten Wasserfallprozess war schon immer, dass alle Risiken aufs Ende verschoben werden. Validierung der Idee mit dem Kunden geschieht viel zu spät.

Sie haben hoffentlich bereits von Lean-Startup Methoden. Diese bilden natürlich den Kern der Alternative zum vorgestellen Prozess. Das  Grundprinzip ist, Waste (wertvernichtende Tätigketen) zu reduzieren und eine der größten Arten von Waste ist, ein Produkt zu planen, bauen, testen und dann nach dem Launch festzustellen, dass das Produkt keiner braucht. Die Ironie ist, dass viele Teams glauben, dass sie Lean-Prinzipien anwenden. Im Kern folgen sie aber dem Prozess, welchen ich oben beschrieben habe. Dann weise ich sie normalerweise darauf hin, dass sie ihre Ideen auf eine der teuersten, langsamsten Weise, die uns bekannt ist, austesteen.

10. Und schließlich, während wir mit diesem Prozess beschäftigt sind und unsere Zeit und unser Geld verschwenden, sind die größten Verluste in der Regel, die Opportunitätskosten. Was hätte unsere Organisation stattdessen machen können? Wir können diese Zeit oder dieses Geld nicht zurückgewinnen.

Für mich ist es kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür bekommen. Ich habe Sie gewarnt, dass dies deprimierend sein könnte.

Die gute Nachricht ist, dass die besten Teams nicht im Geringsten so arbeiten, wie ich es oben beschrieben habe.

Ich habe viele Artikel über die verschiedenen Aspekte davon, wie die besten Teams arbeiten, geschrieben. Product-Discovery ist, wie wir funktionierende Lösungen für die Probleme, die wir angreifen, finden. Die Product-Discovery ist eine aktive und kontinuierliche Zusammenarbeit zwischen Produktteam, UX-Design und Entwicklern. Kontinuierliche Product-Discovery und kontinuierliche Produktentwicklung finden parallel statt. Features auf Roadmaps (Ergebnisse) werden durch Geschäftszielen (Outcomes), die erreicht werden müssen, ersetzt. Das ultimative Ziel der Entwicklung von neuen Produkten ist der Product-Market-Fit.

Wenn Ihr Unternehmen noch nach obigen längst veralteten Verfahren läuft, dann lade ich Sie ein, ein Licht auf diese alten Verfahren zu werfen und mit dem Übergang in die Zukunft beginnen. Und hoffentlich tun Sie dies, bevor ein ernsthafter Wettbewerber am Markt entsteht, der in der Lage ist, viel schneller und effektiver zu arbeiten, als Sie es können.