gilt als das erste und wichtigste Prinzip der Product Discovery: Unsere Kunden und unsere Stakeholder sind nicht in der Lage dazu, uns zu sagen, was gebaut wird.
Und zwar nicht, weil unsere Kunden oder Stakeholder nicht klug oder sachkundig genug wären. Sondern aus zwei anderen Gründen:
Erstens wissen Kunden und Stakeholder nicht, was zum jetzigen Zeitpunkt gerade technisch möglich ist – sie sind keine Technologie-Experten, also können sie auch nicht wissen, wie das jeweilige Problem am besten gelöst werden kann oder ob es überhaupt gelöst werden kann. Oft lösen echte Innovationen Probleme auf eine Art und Weise, die Kunden oder Stakeholder nie für möglich gehalten hätten.
Zweitens ist bei Technologieprodukten sehr schwer vorherzusagen, welche Lösungen funktionieren. Es gibt viele Gründe, warum Produktideen nicht zu den erhofften Ergebnissen führen. Allzu oft sind wir begeistert von einer Idee, aber unsere Kunden sind es nicht – also werden sie das Produkt entgegen unserer Erwartung auch nicht kaufen. Oder die Idee bringt Probleme hinsichtlich Datenschutz oder Sicherheit mit sich. Oder die Verwirklichung der Idee würde viel länger brauchen, als irgendjemand erwartet hätte.
Product Teams mit Empowerment verstehen diese inhärenten Herausforderungen, und bei der Product Discovery geht es um die Entdeckung einer Lösung, die unsere Kunden lieben und die gleichzeitig für unser Business funktioniert.
Wir bezeichnen dies als »Product Discovery«, um deutlich zu machen, dass wir vieles nicht vorher wissen können, und um zu unterstreichen, dass unsere Aufgabe darin besteht, eine Lösung zu entdecken, die valuable (nutzbringend), usable (bedienbar), feasible (umsetzbar) und viable (existenzfähig) ist.
Anmerkungen
1 1 Eine unverblümte Kritik der Politik dieser Unternehmen bieten die Schriften von Professor Scott Galloway (www.profgalloway.com).
2 2 Natürlich tragen der Designer und der technische Leiter viel mehr bei, als nur die Nutzerfreundlichkeit bzw. technische Durchführbarkeit sicherzustellen; worauf ich mich hier beziehe, ist, wer jeweils verantwortlich und rechenschaftspflichtig für das jeweilige Risiko ist.
3 3 Es gibt tatsächlich eine dritte Art von Technologie-Team, die als Delivery Team (oder »Scrum Team« bzw. »DEV-Team«) bezeichnet wird. Ein Delivery Team gibt noch nicht einmal vor, ein echtes Product Team zu sein. Es ist nicht funktionsübergreifend, und es besitzt keine Eigenverantwortung. Es gibt einen Product Owner (verantwortlich für die Verwaltung des Product Backlogs) und eine Reihe von Entwicklern. Es geht rein um den Output (Code and Ship, also das Programmieren und Ausliefern von Software-Projekten). Wenn Sie in einem Prozess wie SAFe involviert sind, dann betrifft Sie dies leider, und ehrlicherweise habe ich keine Ahnung, warum Sie dieses Buch lesen wollen würden, denn was ich hier beschreibe, ist das genaue Gegenteil davon, sowohl was die Unternehmensphilosophie als auch was die unternehmerische Praxis angeht.
2 Die Rolle der Technologie
Ich verspreche, dass dieses Buch sehr praxisnah ist, und Sie werden alles, was hier behandelt wird, direkt anwenden können. Aber in diesem einen Kapitel müssen wir ein kleines bisschen philosophisch werden.
Es ist leicht, die Unterschiede zwischen Feature Teams und Product Teams mit Empowerment zu erkennen.
Es ist leicht zu erkennen, ob Unternehmen es als die Aufgabe von Teams verstehen, dem Business zu dienen, oder ob die Aufgabe ist, dem Kunden zu dienen und damit auch dem Business.
Es ist leicht zu erkennen, ob ein Unternehmen nur versucht, so viele Stakeholder wie möglich zufriedenzustellen, oder ob ein Unternehmen eine klare und bewusste Produktstrategie hat.
Diese Unterschiede mögen leicht erkennbar sein, doch erklärt das nicht, warum diese Unterschiede existieren.
Wenn wir die Lücke zwischen den besten Unternehmen und dem Rest schließen wollen, müssen wir ein wenig Ursachenforschung betreiben.
Ungefähr vor einem Jahrzehnt veröffentlichte Marc Andreessen einen Aufsatz, den ich für einen der wichtigsten unserer Zeit halte: »Why Software is eating the World«.1 Er beschrieb darin, warum er glaubte, dass Technologie dabei sei, große Disruptionen in nahezu jeder Branche zu verursachen. Er brachte genau das zum Ausdruck, was ich bei meiner eigenen Arbeit beobachten konnte – in erster Linie bei den Disruptoren, aber gelegentlich auch bei jenen, die von Disruption bedroht waren.
Zehn Jahre später ist klar, dass er bemerkenswert vorausschauend war.
Trotzdem scheinen die meisten Unternehmen diese Warnungen noch nicht wirklich begriffen zu haben.
Ja, sie alle geben inzwischen Geld für Software aus.
Ja, sie haben sich (zumeist) hin zu agilen Methoden bewegt.
Aber die meisten haben sich nicht auf irgendeine sinnvolle Art und Weise transformiert, und insbesondere sehen die meisten von ihnen die Technologie immer noch nicht als den Business Enabler, der sie ist.
Beispiele dafür finden sich leider überall.
Eines der deutlichsten und ungeheuerlichsten Beispiele aus jüngerer Zeit ist sicherlich die absolute Unfähigkeit der Unternehmensleitung von Boeing im Umgang mit der Software, welche die schockierende Krise der Flugzeuge 737 MAX auslöste.2
Der fundamentale Fehler von Boeing war, diese Software lediglich als notwendigen Kostenfaktor zu begreifen statt als die Kernkompetenz, die es dem Unternehmen erlaubt, die sichersten, benzinsparendsten und rentabelsten Flugzeuge zu bauen, die es gibt.
Statt ein Product Team mit Empowerment zusammenzustellen – das fortlaufend daran gearbeitet hätte, die sicherste, benzinsparendste, überlebenswichtige Steuerungssoftware bereitzustellen –, beschloss die Unternehmensführung bei Boeing, ausgerechnet diese Technologie auszulagern. Man dachte, durch Outsourcen könne man vielleicht ein paar Dollar sparen.
Das betrifft nicht nur die Luftfahrtbranche. Die Automobilbranche hat unter dieser Denkweise jahrzehntelang gelitten3, bis Tesla daherkam und bewies, was eigentlich alles möglich ist, wenn die Fahrzeugentwicklung Technologie wirklich ins Zentrum stellt und nicht nur als notwendigen Kostenfaktor behandelt. Indem die Technologie im Tesla weit über Navigation und Unterhaltungssysteme hinausgeht und die technologischen Möglichkeiten zum Beispiel mit Over-the-Air-Updates (Softwareaktualisierung über eine Funkschnittstelle) voll ausnutzt, verbessert ein Tesla sich im Laufe der Zeit eher, als dass er an Wert verliert. Es lohnt sich, darüber einen Moment lang nachzudenken.
Pixar hat der Filmbranche gezeigt, was eigentlich alles möglich ist, wenn die Produktion von animierten Spielfilmen Technologie in den Mittelpunkt stellt, anstatt sie nur als notwendigen Kostenfaktor zu sehen. Pixar verwendet Technologie auf eine Art und Weise, die weit über das traditionelle Filmemachen hinausgeht, und die Technologie-Teams werden genauso wertgeschätzt wie die Kreativ-Teams.
Wie Sie vielleicht wissen,
