10 Gründe für erfolgreiche Produktentwicklung
Vor genau einem Jahr wurde ich zur Craft Conference in Budapest eingeladen und sprach dort über die 10 Hauptgründe für das Scheitern von Produktteams. Ich sprach damals hauptsächlich darüber, warum viele Teams so ineffektiv sind, und allen gegenteiligen Behauptungen zum Trotz sind die meisten Organisationen immer noch nicht wirklich „agil”, da sie immer noch nach dem Wasserfall-Prinzip arbeiten. Also wurde ich dieses Jahr wieder zu der Konferenz eingeladen, um darüber zu sprechen, wie die besten mir bekannten Teams arbeiten. Dieser Artikel ist eine Zusammenfassung meiner Rede.
Nach meiner ersten Rede kontaktierten mich einige Leute und baten mich um mehr Informationen. Abgesehen davon, dass ich ihnen riet, mein Buch zu lesen oder einen Workshop mitzumachen, hatte ich nicht das Gefühl, ihnen eine zufriedenstellende Antwort geben zu können. Das hat mich dazu inspiriert, etwas genauer über die wichtigsten Eigenschaften extrem starker Produktteams nachzudenken. Also erarbeitete ich meine persönliche Top 10.
Continuous Discovery und Delivery
Ebenso wie ich die zehn größten Probleme mit dem Wasserfall-Modell beschrieben habe, habe ich auch die zehn Merkmale erfolgreicher Teams im Bezug auf Continuous Discovery und Delivery beschrieben (auch Dual Track Agile, Discovery Sprints oder Delivery Sprints genannt). Was sind also die Erfolgsfaktoren für erfolgreiche Produktentwicklung?
1. Bevollmächtigte Produktteams
Der wichtigste Faktor ist das absolut grundlegende Konzept starker Produktteams. Aber was genau bedeutet das eigentlich?
Zuerst einmal ist es wichtig, dass das Team längerfristig in dieser Konstellation existiert und die Teammitglieder nicht wie Schachfiguren herumgeschoben werden. Wenn Teams innovativ sein sollen, brauchen sie Zeit, um mehr über sich, die Technologie, die Kunden und den Geschäftskontext zu erfahren.
Zweitens ist auch die Chemie unter den Teammitgliedern ausschlaggebend. Das heißt, dass sie sich gut genug kennen und auch respektieren sollten, damit sich jedes Mitglied des Teams wohl genug fühlt und sich traut, Dinge vorzuschlagen sowie sich selbst und andere immer wieder zu besseren Leistungen zu motivieren.
Drittens sollte ein Team über eine gewisse Vielfalt an Fähigkeiten verfügen, die normalerweise aus Produktmanagement, User Experience Design und der Entwicklung besteht. Oft gehören auch Datenanalyse und Nutzerforschung dazu.
Und zu guter Letzt ist es vorteilhaft, wenn alle Teammitglieder an ein und demselben Ort zusammenarbeiten – auch wenn dies für viele Firmen kein einfaches Thema ist. Produktmanager, Produktdesigner und die Entwickler (oder zumindest der Leiter des Entwicklungsteams) sollten ihre Schreibtische nebeneinander stehen haben. Leider ist das nicht immer umsetzbar, aber man kann es zumindest versuchen. Und nur um das klarzustellen, es sind nicht einzelne Teams an verschiedenen Orten, die ein Problem darstellen. Es hat negative Auswirkungen auf die Velocity und vor allem auf die Innovation, wenn die Mitglieder desselben Teams örtlich voneinander getrennt sind.
2. Produktvision und -strategie
Um wirklich bevollmächtigte und autonome Produktteams zu bekommen, müssen die Teammitglieder ein gutes Verständnis des Geschäftskontextes haben. Das beginnt mit einer klaren und überzeugenden Produktvision und dem Weg dorthin: der Produktstrategie.
Die Produktvision beschreibt die Welt, die wir in den nächsten zwei bis fünf Jahren erschaffen möchten (bei Hardware meistens etwas länger).
Die Produktvision muss inspirierend sein. Eine gute Produktvision ist eines unserer effektivsten Recruiting-Werkzeuge und motiviert die Leute tagtäglich, zur Arbeit zu kommen. Eine inspirierende Vision zieht gute Fachkräfte an, denn sie möchten an etwas Bedeutsamem beteiligt sein.
Die Produktstrategie ist die Reihenfolge der Produkte, die wir auf dem Weg zur Realisierung der Vision liefern wollen. Es wäre eine schlechte Strategie, mit nur einem einzigen Release alle Beteiligten zufriedenstellen zu wollen. Stattdessen haben wir eine priorisierte Liste von Märkten, Geographien oder Personas und konzentrieren uns darauf, dass das Produkt und der jeweilige Markt zusammenpassen.
Je mehr Produktteams man hat, umso wichtiger sind eine einheitliche Vision und Strategie, damit jedes einzelne Team die richtigen Entscheidungen treffen kann.
Das Wichtigste ist aber, dass die Produktvision inspirierend ist und dass die Produktstrategie bewusst getroffen wird.
3. Business Outcome
Der zweite Teil des Geschäftskontextes, den ein bevollmächtigtes und autonomes Team benötigt, um gute Entscheidungen treffen zu können, ist eine Reihe von priorisierten Geschäftszielen. Das OKR-System (Objectives and Key Results) ist genau dafür gedacht.
Die OKR spiegeln eine Liste bestimmter Geschäftsprobleme wider, die das Team lösen soll. Dies sind jedoch keine Features. Features sind nur potenzielle Lösungen für Probleme. Ein Feature fertig zu bekommen, macht ein Team nicht erfolgreich; sondern die Lösung des eigentlichen Problems.
Die zwei Prinzipien hinter diesen Methoden für das Leistungsmanagement sind:
1) Teams bringen bessere Leistungen, wenn man ihnen Probleme gibt, die sie selbst lösen sollen, statt ihnen die Lösungen vorzugeben.
2) Das Team wird anhand von Resultaten gemessen, nicht an Output. Features auf einer Roadmap zu liefern ist Output; ein Geschäftsproblem zu lösen ist ein Resultat.
4. Ein kompetenter Produktmanager
Leider hatten die meisten Entwickler noch nie die Gelegenheit mit einem fähigen Produktmanager zusammenarbeiten zu dürfen. Diejenigen, bei denen das doch der Fall ist, sind auch diejenigen, die darauf bestehen, immer eine solche Person im Team zu haben. Und noch schlimmer ist die Tatsache, dass viele Entwickler nicht einmal genau wissen, was der Produktmanager eigentlich zum Team beitragen soll.
Stellen Sie sich das alles folgendermaßen vor: Damit ein Produktteam echte Geschäftsprobleme lösen kann, reicht es nicht, dass eine Lösung lediglich technisch funktioniert oder der Kunde die Lösung toll findet. Die Lösung muss auch für Ihr Geschäft funktionieren – und das ist oft das Schwierigste daran.
Denken Sie darüber nach, was das bedeutet. Stellen Sie sich vor, Sie arbeiten für Uber oder AirBnB und Sie müssen sich um die komplexen Gesetze, Arbeitgebergruppen und Gewerkschaften kümmern. Oder nehmen Sie eBay, wo man mit gehörigen Beschränkungen zu kämpfen hatte, um als Marktplatz statt als E-Commerce-Seite eingestuft zu werden. Oder Tesla, wo es Haftungsfragen bezüglich des Autopiloten zu klären galt. Jedes Unternehmen hat eine ganz eigene Liste solcher Hindernisse zu überwinden:
Rechtliche, finanzielle, vertriebs- und preisbezogene sowie marken- und marketingbezogene Hindernisse, Datenschutz, Sicherheit, Kooperationsbedingungen usw.
Unglücklicherweise ist die einzige Person, die das alles versteht, der Geschäftsführer, und in diesem Fall kann man nachvollziehen, warum er sich so schwer damit tut, das Team zu bevollmächtigen, selbst die richtigen Entscheidungen zu treffen.
Es gibt drei Möglichkeiten, wie ein Team arbeiten kann. Eine ist, dass der Geschäftsführer oder ein anderer Vorgesetzter alles entscheidet. Die zweite ist, dass ein Produktmanager ein großes Meeting einberuft und alles mit der gesamten Geschäftsführung ausdiskutiert („Design By Committee”), was in der Regel schlechte Ergebnisse hervorbringt. Die dritte Möglichkeit ist, dass der Produktmanager seinen Job macht, sich mit den Hindernissen auseinandersetzt und sie an die Teammitglieder weitergibt, damit sie die Lösung für das Problem selbst erarbeiten können.
Kombinieren Sie das mit einem guten Verständnis der Technologie und fundierten Kenntnissen über die Nutzer und Kunden, dann können Sie hoffentlich erkennen, warum das ein harter aber auch absolut essenzieller Job für ein Produktteam ist, besonders wenn das Team ein sinnvolles Maß an Autonomie genießen soll.
5. Lösungen durch Zusammenarbeit
„Zusammenarbeit” soll hier kein Schlagwort sein. Ich meine damit nur, dass die drei Bereiche Produkt, Design und Entwicklung zusammenarbeiten sollten, um ein Problem zu lösen, statt dass der Produktmanager „Anforderungen” weiterreicht, der Designer alles schön verpackt und die Entwickler den Code schreiben, der von ihnen verlangt wird. Der Grund dafür ist die Tatsache, dass sich Technologie und Funktionalität bei guten Lösungen gegenseitig vorantreiben. Die Technologie macht bestimmte Design-Optionen erst möglich, ebenso wie das Design die Auswahl der Technologie beeinflusst. Und die Design-Entscheidungen beeinflussen die Funktionalität – und andersherum.
Technologie, User Experience Design und Funktionalität sind miteinander verflochten. Gute Lösungen entstehen durch ein konstantes Hin und Zurück, ein permanentes Geben und Nehmen zwischen den drei Bereichen.
Das ist auch der Hauptgrund dafür, warum Teams, die an ein und demselben Ort zusammenarbeiten, im Grunde genommen immer besser sind als Teams, bei denen das nicht der Fall ist.
6. Product Discovery: Schnelles Lernen
Großartige Produkte haben viel mit der Fähigkeit eines Teams zu tun, schnell viele Ideen auszuprobieren. Wir wollen schnellstmöglich die guten von den schlechten Ideen trennen. Product Discovery umfasst eine ganze Reihe von Techniken, die uns dabei helfen, schnell herauszufinden, welche Ideen super und welche nicht ganz so toll sind. Einige Ideen sind wirklich großartig und andere weniger. Manche sind riskant und manche sind kostspielig. Manchmal brauchen wir Beweise dafür, andere Male nur Indizien.
Leute beschreiben das auf die unterschiedlichste Weise. Einige halten sich an das Sprichwort „fake it before you make it”, was so viel bedeutet wie „so tun als ob, bis es funktioniert”. Andere Leute betonen, dass man Dinge bauen sollte, die nicht skalierbar sind. Hauptsache wir lernen schnell dazu und minimieren Waste (dt. Verschwendung).
Ein Entwicklungsteam ein echtes Produkt bauen und auf den Markt bringen zu lassen, um eine Idee zu testen, ist so ziemlich die langsamste und teuerste Methode, etwas zu lernen.
7. Auf die Hauptrisiken konzentrieren
Bei der Product Discovery gibt es einige wichtige Punkte, die man beachten sollte.
Als Erstes müssen wir uns auf die vier Hauptrisiken konzentrieren:
Wert – würde irgendjemand dieses Produkt kaufen oder es nutzen wollen?
Benutzerfreundlichkeit – würden die Kunden verstehen, wie man es benutzt?
Umsetzbarkeit – können unsere Entwickler das Produkt mit der ihnen zur Verfügung stehenden Technologie, Zeit und den Fähigkeiten des Teams bauen?
Stakeholder – sind alle Beteiligten im Unternehmen mit der vorgeschlagenen Lösung einverstanden?
Product Discovery ist die Suche nach guten Antworten auf diese vier Fragen. Wenn wir sie gefunden haben, haben wir die nötigen Beweise und sind zuversichtlich, dass das Entwicklungsteam eine qualitative und skalierbare Lösung umsetzen und liefern kann.
8. Die Rolle des MVP
Das Konzept des Minimum Viable Products ist eines der wichtigsten Konzepte bei der Produktentwicklung und dennoch ist es auch eines der am häufigsten falsch genutzten und missverstandenen Konzepte.
Zu generalisieren ist immer gefährlich, aber ich lehne mich jetzt mal aus dem Fenster und behaupte, dass ein MVP niemals ein Produkt sein sollte. Jedes Mal, wenn ich auf ein Team traf, das mit viel Zeit und Geld ein MVP gebaut hatte, konnte ich diesem Team danach zeigen, wie sie den gleichen Lerneffekt mit viel geringeren Kosten und viel weniger Verschwendung hätten haben können.
Ein MVP ist also ein Experiment – ein Test. Normalerweise ist es eine Art Prototyp. Oft ist es ein Prototyp für den Nutzer, manchmal aber auch ein Live-Daten-Prototyp oder er wird für Machbarkeitsstudien genutzt. Und manchmal ist es eine Mischung aus diesen Dingen. In jedem Fall ist es immer nur ein kleiner Teil der Entwicklung eines tatsächlichen Produkts.
9. Product Delivery: Keine Kompromisse beim Release
Hierbei geht es mir nicht darum, den Entwicklern zu sagen, wie sie Software entwickeln und releasen sollen. Im Gegenteil. Ein Problem, das entsteht, wenn ein Entwicklungsteam das MVP entwickeln muss, ist, dass das Entwicklungsteam sich oft gezwungen fühlt, Software zu releasen, von der sie nicht überzeugt sind. Sie stehen nicht wirklich voll und ganz dahinter. Vielleicht gibt es Probleme mit der Verlässlichkeit, der Skalierung oder der Performance, aber der Produktmanager sagt einfach immer wieder: „Es ist doch nur ein MVP, entspannt euch!”
Ich sage einfach nur, dass man keine Kompromisse machen sollte, wenn es um Software geht, auf die die Kunden für die Aufrechterhaltung ihres Geschäfts angewiesen sind. Es gibt viele gute Product Discovery Techniken für das Testen von MVPs, durch die unsere Kunden, unser Umsatz, unser Ruf und unsere Mitarbeiter geschützt werden.
Nutzen Sie also Ihre Best Practices und releasen Sie nur Produkte, wenn Sie vollstes Vertrauen in dieses Release haben.
10. Vom Kunden besessen sein
Dieser letzte Punkt geht in eine etwas andere Richtung. Bei fast jedem Unternehmen, zu dem ich komme, sagt man mir, wie sehr man die Kunden liebt. Das ist meistens ein Teil der Wertvorstellungen oder des Leitbildes des Unternehmens. Das zu sagen ist einfach, aber auch wirklich so zu handeln, ist schon wesentlich schwieriger.
Das merke ich immer ziemlich schnell, wenn ich mich mit einem Team unterhalte. Wie geht das Team damit um, wenn ein Problem mit dem Kunden auftritt? Wie dringend ist das? Tritt das Team mit dem Kunden in Kontakt, um ihn, falls nötig, besser verstehen zu können? Kennen die Teammitglieder die Kunden mit Namen? Welche Beziehung haben sie zu den Kunden? Gehen ihnen die Kunden eher auf die Nerven oder sind sie für die Teammitglieder vielleicht sogar eher wie Kollegen?
Die beste Möglichkeit, wahre Empathie und Einsatzbereitschaft für den Kunden zu wecken, ist, dass sich die Teammitglieder (vor allem die Entwickler) direkt mit dem Kunden in Verbindung setzen.
Ich hoffe, das hilft Ihnen, ein besseres Gefühl dafür zu entwickeln, was großartige Produktteams ausmacht.
Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.
Outcome vs. Output
=> Das Minimum Viable Product (MVP) verstehen
Product Owner Training
=> Werde zertifizierter Product Owner