Sechs Mythen der Produktentwicklung

Kunstwerk: Ricky Allman, Undertable, 2011, Acryl auf Leinwand, 72″ x 48″

Die meisten Produktentwicklungsmanager haben ständig damit zu kämpfen, Projekte pünktlich und innerhalb des Budgets abzuschließen. Sie haben nie genug Ressourcen, um den Job zu erledigen, und ihre Chefs verlangen vorhersehbare Zeitpläne und Ergebnisse. Also drängen die Manager ihre Teams, sparsamer zu sein, detailliertere Pläne zu schreiben und Terminabweichungen und Verschwendung zu minimieren. Aber dieser Ansatz, der vielleicht gut funktioniert, wenn es darum geht, unterdurchschnittliche Fabriken umzukrempeln, kann der Produktentwicklung tatsächlich schaden.

Obwohl viele Unternehmen die Produktentwicklung so behandeln, als wäre sie mit der Fertigung vergleichbar, unterscheiden sich die beiden grundlegend. In der Welt der Fertigung von physischen Objekten sind die Aufgaben repetitiv, die Aktivitäten sind einigermaßen vorhersehbar und die herzustellenden Gegenstände können sich nur an einem Ort zur gleichen Zeit befinden. In der Produktentwicklung sind viele Aufgaben einmalig, die Projektanforderungen ändern sich ständig, und das Ergebnis – zum Teil dank des weit verbreiteten Einsatzes von fortschrittlicher computergestützter Konstruktion und Simulation und der Einbindung von Software in physische Produkte – sind Informationen, die sich an mehreren Orten gleichzeitig befinden können.

Die Nichtbeachtung dieser kritischen Unterschiede hat zu mehreren Irrtümern geführt, die die Planung, Durchführung und Bewertung von Produktentwicklungsprojekten untergraben. Gemeinsam haben wir mehr als 50 Jahre damit verbracht, Unternehmen bei der Produktentwicklung zu untersuchen und zu beraten, und wir sind diesen Irrtümern – wie auch anderen, die aus unterschiedlichen Gründen entstehen – in einer Vielzahl von Branchen begegnet, darunter Halbleiter, Autos, Unterhaltungselektronik, medizinische Geräte, Software und Finanzdienstleistungen. In diesem Artikel werden wir sie aufdecken und Wege aufzeigen, wie man die Probleme, die sie verursachen, überwinden kann.

Trugschluss 1: Eine hohe Auslastung der Ressourcen wird die Leistung verbessern.

Wir haben sowohl in unserer Forschung als auch in unserer Beratungstätigkeit festgestellt, dass die große Mehrheit der Unternehmen bestrebt ist, ihre Ressourcen für die Produktentwicklung voll auszulasten. (Einer von uns, Donald, hat durch Umfragen in Führungskursen am California Institute of Technology herausgefunden, dass der durchschnittliche Produktentwicklungsleiter die Auslastung bei über 98 % hält.) Die Logik scheint offensichtlich: Projekte dauern länger, wenn die Mitarbeiter nicht zu 100 % ausgelastet sind – und deshalb wird eine gut ausgelastete Entwicklungsorganisation schneller und effizienter sein als eine, die ihre Mitarbeiter nicht so gut auslastet.

Aber in der Praxis hält diese Logik nicht stand. Wir haben gesehen, dass die Geschwindigkeit, Effizienz und Qualität von Projekten unweigerlich abnimmt, wenn Manager die Teller ihrer Produktentwicklungsmitarbeiter komplett füllen – egal wie gut diese Manager auch sein mögen. Eine hohe Auslastung hat schwerwiegende negative Nebenwirkungen, die Manager aus drei Gründen unterschätzen:

Sie berücksichtigen nicht die inhärente Variabilität der Entwicklungsarbeit.

Viele Aspekte der Produktentwicklung sind unvorhersehbar: wann Projekte ankommen, welche individuellen Aufgaben sie erfordern und wie lange Mitarbeiter, die solche Aufgaben noch nie zuvor angepackt haben, dafür brauchen. Unternehmen sind jedoch am meisten mit sich wiederholenden Prozessen wie der Fertigung und der Transaktionsverarbeitung vertraut, bei denen sich die Arbeit nicht viel ändert und Überraschungen selten sind. Solche Prozesse verhalten sich geordnet, wenn die Auslastung der Ressourcen steigt. Fügen Sie 5 % mehr Arbeit hinzu, und es wird 5 % mehr Zeit für die Fertigstellung benötigt.

Prozesse mit hoher Variabilität verhalten sich ganz anders. Mit zunehmender Auslastung verlängern sich die Verzögerungen dramatisch. (Siehe das Exponat „Hohe Auslastung führt zu Verzögerungen“.) Fügen Sie 5 % mehr Arbeit hinzu, und die Fertigstellung kann 100 % länger dauern. Aber nur wenige Menschen verstehen diesen Effekt. In unserer Erfahrung mit Hunderten von Produktentwicklungsteams haben wir festgestellt, dass die meisten deutlich überlastet waren. Um alle Projekte pünktlich und innerhalb des Budgets abzuschließen, hätten einige Organisationen, mit denen wir gearbeitet haben, mindestens 50 % mehr Ressourcen benötigt, als sie hatten.

Es stimmt, dass ein Teil der Variabilität das Ergebnis mangelnder Disziplin ist und dass einige Produktentwicklungsaufgaben (wie die Konstruktion von Komponenten für einen Flugzeugprototyp oder die Durchführung klinischer Studien) mehr sich wiederholende Arbeit beinhalten. Aber selbst wenn ein Teil der Arbeit vorhersehbar ist, kommt es zu Warteschlangenproblemen, wenn sie mit anderen unvorhersehbaren Arbeiten kombiniert werden.

Sie verstehen nicht, wie sich Warteschlangen auf die wirtschaftliche Leistung auswirken.

Eine hohe Auslastung der Ressourcen führt unweigerlich zu Warteschlangen von Projekten. Wenn teilweise abgeschlossene Arbeiten untätig herumliegen und darauf warten, dass Kapazitäten frei werden, verlängert sich die Dauer des gesamten Projekts. Warteschlangen verzögern auch das Feedback, was dazu führt, dass die Entwickler länger unproduktive Wege gehen. Sie machen es Unternehmen schwer, sich an die sich verändernden Marktanforderungen anzupassen und Schwachstellen in ihrem Produkt zu erkennen, bevor es zu spät ist. Ironischerweise sind das genau die Probleme, von denen Manager denken, dass eine hohe Auslastung ihren Teams erlaubt, sie zu vermeiden.

Selbst wenn Manager wissen, dass sie Warteschlangen erzeugen, erkennen sie selten die wirtschaftlichen Kosten. Obwohl diese Kosten quantifiziert werden können, haben wir festgestellt, dass die überwiegende Mehrheit der Unternehmen sie nicht berechnet. Manager müssen die Kosten für Warteschlangen gegen die Kosten für nicht ausgelastete Kapazitäten abwägen, um das richtige Gleichgewicht zu finden.

In der Produktentwicklung ist der Bestand an unfertigen Erzeugnissen überwiegend unsichtbar.

Fertigungswarteschlangen bestehen aus physischen Dingen, und wenn sich der Bestand in einer Fabrik verdoppelt, ist das offensichtlich. Das ist in der Produktentwicklung nicht der Fall, wo der Bestand größtenteils aus Informationen besteht, wie z. B. Konstruktionsunterlagen, Testverfahren und -ergebnisse sowie Anweisungen für den Bau von Prototypen. Wenn sich der Bestand in einem Entwicklungsprozess verdoppelt, gibt es keine physischen Anzeichen. Da die meisten R&D-Bestände nach den Rechnungslegungsstandards mit einem Wert von Null angesetzt werden müssen, geben die Jahresabschlüsse zudem keinen Hinweis auf ernsthafte Bestandsüberschüsse in der Produktentwicklung.

Es ist sehr schwierig, ein Problem zu bekämpfen, das man nicht sehen oder messen kann. Betrachten Sie die Situation bei einem großen Pharmaunternehmen. Vor einigen Jahren stand der neu ernannte Leiter der Medikamentenentwicklung vor einem Management-Dilemma. Wie andere Führungskräfte, die große F&D-Organisationen leiten, versuchte er, Wege zu finden, seine Wissenschaftler innovativer zu machen. Er wollte, dass sie mehr mit neuen chemischen Verbindungen experimentieren, die vielversprechende neue Medikamente hervorbringen könnten, und dass sie gleichzeitig vielversprechende Kandidaten so früh wie möglich ausschließen. Für Experimente mit lebenden Organismen war jedoch die Tierversuchsabteilung zuständig, die nicht unter seiner Kontrolle stand und als Kostenstelle geführt wurde. Sie wurde danach bewertet, wie effizient sie die Testressourcen einsetzte, was natürlich zu einer hohen Auslastung führte. Folglich mussten die Wissenschaftler in der Medikamentenentwicklung drei bis vier Monate auf die Ergebnisse von Tests warten, deren Durchführung etwas mehr als eine Woche dauerte. Die „gut geführte“ Testorganisation behinderte den Fortschritt der Forschungsabteilung.

Die naheliegende Lösung für solche Probleme ist die Bereitstellung eines Kapazitätspuffers in Prozessen, die stark variabel sind. Einige Unternehmen haben das schon lange verstanden. 3M hat jahrzehntelang Produktentwickler mit 85 % ihrer Kapazität eingeplant. Und Google ist berühmt für seine „20%-Zeit“ (die es Ingenieuren erlaubt, einen Tag in der Woche an allem zu arbeiten, was sie wollen – eine Praxis, die bedeutet, dass zusätzliche Kapazität verfügbar ist, wenn ein Projekt hinter dem Zeitplan zurückbleibt). Unserer Erfahrung nach ist diese Art von Lösung jedoch ziemlich schwer zu implementieren. Wie wir noch besprechen werden, können nur wenige Organisationen der Versuchung widerstehen, jedes letzte bisschen an verfügbarer Kapazität zu nutzen. Manager fangen reflexartig mehr Arbeit an, wenn sie Leerlauf sehen.

Aber es gibt auch andere praktikable Lösungen:

Ändern Sie die Management-Kontrollsysteme.

Für das pharmazeutische Unternehmen könnte dies bedeuten, dass es Schritte unternimmt, um die Ziele der Tierversuchsabteilung mit denen der Forschungsabteilung abzustimmen. Das Unternehmen könnte zum Beispiel die Tierversuchsabteilung für prompte Antworten belohnen (Messung der Zeit von der Anfrage bis zum Abschluss des Tests) und nicht für die Auslastung der Ressourcen.

Kapazitäten gezielt erhöhen.

Die Aufstockung der Ressourcen in den Bereichen, in denen die Auslastung bei 70 % oder höher liegt, kann die Wartezeit deutlich reduzieren. Würde das Pharmaunternehmen dies bei Tierversuchen tun, bekäme es viel schneller Rückmeldung über neue chemische Verbindungen. In Bereichen, in denen Tests mit Computermodellierung und -simulation durchgeführt werden, ist eine Kapazitätserweiterung oft relativ kostengünstig, da sie nur den Kauf zusätzlicher Computerausrüstung und Softwarelizenzen erfordert.

Begrenzen Sie die Anzahl der aktiven Projekte.

Wenn die Pharmafirma die Kapazität der Tierversuche nicht erhöhen kann, könnte sie die Auslastung immer noch senken, indem sie die Anzahl der aktiven Projekte zur Erforschung neuer chemischer Verbindungen reduziert. Die Disziplin, eine harte Grenze für die Produktentwicklungspipeline zu setzen, führt oft zu einem schärferen Fokus und klareren Prioritäten.

Machen Sie den Bestand an unfertigen Erzeugnissen übersichtlicher.

Eine Methode ist die Verwendung visueller Kontrolltafeln. Diese können verschiedene Formen annehmen, aber der Schlüssel ist, dass eine Art physisches Zeichen, wie z.B. ein Post-it-Zettel, die Entwicklungsarbeit repräsentiert (siehe die Abbildung „Typisches Work-in-Process Control Board“). Eine Kontrolltafel sollte alle aktiven Arbeiten anzeigen und angeben, in welchem Zustand sich jeder Teil des Projekts befindet. Es sollte im Zentrum des Management-Prozesses des Teams stehen. Teams können täglich 15-minütige Besprechungen um solche Tafeln herum abhalten, um die Bemühungen zu koordinieren und die Arbeit in Gang zu halten.

Trugschluss 2: Die Verarbeitung von Arbeit in großen Chargen verbessert die Wirtschaftlichkeit des Entwicklungsprozesses.

Eine zweite Ursache für Warteschlangen in der Produktentwicklung ist die Chargengröße. Nehmen wir an, ein neues Produkt besteht aus 200 Komponenten. Sie könnten sich dafür entscheiden, alle 200 Teile zu entwerfen und zu bauen, bevor Sie eines davon testen. Wenn Sie stattdessen nur 20 Komponenten entwerfen und bauen würden, bevor Sie mit dem Testen beginnen, wäre die Losgröße 90 % kleiner. Das hätte einen tiefgreifenden Effekt auf die Wartezeit, denn die durchschnittliche Wartezeit in einem Prozess ist direkt proportional zur Losgröße.

Die Reduzierung der Losgrößen ist ein entscheidendes Prinzip der schlanken Fertigung. Kleine Chargen ermöglichen es Herstellern, die Arbeit im Prozess zu reduzieren und die Rückmeldung zu beschleunigen, was wiederum die Zykluszeiten, die Qualität und die Effizienz verbessert. In der Produktentwicklung sind kleine Losgrößen sogar noch nützlicher, aber nur wenige Entwickler erkennen die Möglichkeiten dieser Methode.

Ein Grund dafür ist die Art ihres Arbeitsablaufs. Da die Informationen, die sie produzieren, für sie meist unsichtbar sind, sind es auch die Losgrößen. Zweitens scheinen Entwickler eine inhärente Neigung zu haben, große Chargen zu verwenden – möglicherweise weil sie fälschlicherweise glauben, dass große Chargen Skaleneffekte erzeugen.

In einem gut geführten Prozess wird die Chargengröße die Transaktions- und Haltekosten ausgleichen (siehe die Abbildung „Wie man die optimale Chargengröße bestimmt“). Es ist ähnlich wie beim Kauf von Eiern im Supermarkt. Wenn Sie einen 12-Monats-Vorrat auf einmal kaufen, sind die Transaktionskosten niedrig, aber die meisten Eier werden verderben, was die Lagerkosten erhöht. Wenn Sie einen Tagesvorrat auf einmal kaufen, ist der Verderb gering, aber Ihre Transaktionskosten sind hoch. Intuitiv versucht man, ein Gleichgewicht zwischen den beiden zu finden.

Die Unternehmen, die verstanden haben, wie das funktioniert, haben IT-Fortschritte ausgenutzt, um die Losgrößen zu reduzieren, oft mit erstaunlichen Ergebnissen. Einige Software-Firmen, die früher alle 90 Tage große Chargen von Code getestet haben, testen jetzt viel kleinere Chargen mehrmals am Tag. Ein Hersteller von Computer-Peripheriegeräten, der einen ähnlichen Ansatz mit seiner Softwaregruppe verfolgte, reduzierte die Zykluszeit beim Softwaretest um 95 % (von 48 Monaten auf 2,5 Monate), verbesserte die Effizienz um 220 % und verringerte die Fehlerquote um 33 %. Die Kosteneinsparungen waren doppelt so hoch, wie das Unternehmen erwartet hatte. Obwohl diese Ergebnisse außergewöhnlich waren, haben wir festgestellt, dass die Reduzierung der Chargengröße die meisten Entwicklungsprojekte deutlich verbessert. In ähnlicher Weise haben computergestützte Modellierungs- und Simulationstools die optimale Losgröße für Experimente und Tests in Unternehmen, die physische Produkte entwickeln, drastisch gesenkt.

Trugschluss 3: Unser Entwicklungsplan ist großartig; wir müssen uns nur daran halten.

In unserer gesamten Beratungs- und Forschungsarbeit sind wir noch nie auf ein einziges Produktentwicklungsprojekt gestoßen, dessen Anforderungen während des gesamten Entwicklungsprozesses stabil blieben. Dennoch setzen viele Unternehmen ein übermäßiges Vertrauen in ihre Pläne. Sie führen jede Abweichung auf schlechtes Management und schlechte Ausführung zurück und verfolgen, um sie zu minimieren, sorgfältig jeden Schritt anhand von Zwischenzielen und Meilensteinen. Eine solche Denkweise ist gut für sich stark wiederholende Aktivitäten in etablierten Fertigungsprozessen. Aber es kann zu schlechten Ergebnissen bei Produktinnovationen führen, wo täglich neue Erkenntnisse generiert werden und sich die Bedingungen ständig ändern.

Eine klassische Studie zur technischen Problemlösung von Thomas Allen vom MIT verdeutlicht die fließende Natur der Entwicklungsarbeit. Er fand heraus, dass Ingenieure, die ein Subsystem für die Luft- und Raumfahrt entwickelten, eine Reihe von Designalternativen erdachten und bewerteten, bevor sie eine auswählten, die sie als die beste ansahen. Auf dem Weg dorthin änderten sich ihre Präferenzen häufig, da sie konkurrierende technische Lösungen testeten und verfeinerten. Dies ist typisch für Innovationsprojekte: Testen und Experimentieren offenbaren, was funktioniert und was nicht, und anfängliche Annahmen über Kosten und Wert können widerlegt werden.

Die Bedürfnisse der Kunden zu definieren, kann zu Beginn eines Produktentwicklungsprojekts ebenfalls schwierig sein. Wenn man darüber nachdenkt, ist das nicht überraschend: Es ist nicht einfach für Kunden, ihre Bedürfnisse für Lösungen, die noch nicht existieren, genau zu spezifizieren. Tatsächlich kann die Vertrautheit mit bestehenden Produkteigenschaften die Fähigkeit einer Person beeinträchtigen, ihre Bedürfnisse für ein neues Produkt zu äußern. Die Präferenzen der Kunden können sich im Laufe eines Entwicklungsprojekts auch abrupt ändern, wenn Wettbewerber neue Angebote einführen und neue Trends auftauchen.

Aus all diesen Gründen kann das Festhalten am ursprünglichen Plan – egal wie exzellent seine Konzeption und wie geschickt seine Ausführung ist – ein Rezept für ein Desaster sein. Das soll nicht heißen, dass wir nicht an die Planung glauben. Die Produktentwicklung ist eine Reihe komplexer Aktivitäten, die eine sorgfältige Koordination und Aufmerksamkeit bis ins kleinste Detail erfordern. Der Plan sollte jedoch als eine anfängliche Hypothese behandelt werden, die ständig überarbeitet wird, wenn sich die Beweise entfalten, sich die wirtschaftlichen Annahmen ändern und die Gelegenheit neu bewertet wird. (Siehe „The Value Captor’s Process“, von Rita Gunther McGrath und Thomas Keil, HBR Mai 2007.)

Irrtum 4: Je früher das Projekt begonnen wird, desto früher wird es fertig sein.

Wie wir bereits besprochen haben, ist Leerlaufzeit für Manager ein Gräuel. Sie neigen dazu, jede Ausfallzeit auszunutzen, indem sie ein neues Projekt starten. Selbst wenn die Aufgabe nicht abgeschlossen werden kann, weil die Mitarbeiter zu einem anderen Projekt zurückkehren müssen, argumentieren Manager, dass alles, was in dem neuen Projekt erledigt wird, Arbeit ist, die später nicht mehr erledigt werden muss. Solches Denken führt dazu, dass Unternehmen mehr Projekte starten, als sie mit Nachdruck verfolgen können, was die Ressourcen verwässert.

Diese Verwässerung ist gefährlich. Wenn ein Unternehmen ein Projekt in Angriff nimmt, bevor es die Ressourcen hat, um es voranzutreiben, wird es langsam durch den Entwicklungsprozess stolpern. Das ist problematisch, weil die Arbeit in der Produktentwicklung sehr verderblich ist: Annahmen über Technologien und den Markt können schnell veraltet sein. Je langsamer ein Projekt voranschreitet, desto größer ist die Wahrscheinlichkeit, dass es neu ausgerichtet werden muss. Tatsächlich hat eine Militärbehörde herausgefunden, dass die Kosten- und Terminüberschreitungen exponentiell proportional (zur vierten Potenz) zur Dauer eines Projekts sind. Mit anderen Worten: Wenn sich der ursprüngliche Zeitplan eines Projekts verdoppelte, stiegen die Kosten- und Terminüberschreitungen um den Faktor 16.

Die Bedeutung der Reduzierung der in Arbeit befindlichen Arbeit wird deutlich, wenn wir uns eine der klassischen Formeln der Warteschlangentheorie ansehen: Das Little’sche Gesetz. Es besagt einfach, dass die Durchlaufzeit im Durchschnitt proportional zur Größe der Warteschlange geteilt durch die Bearbeitungsrate ist. Wenn also 20 Personen vor Ihnen in der Schlange bei Starbucks stehen und der Barista fünf Personen pro Minute bedient, werden Sie in vier Minuten bedient. Sie können die Zykluszeit verkürzen, indem Sie die Verarbeitungsrate erhöhen oder die Anzahl der laufenden Aufträge reduzieren. In den meisten Einstellungen ist Letzteres die einzige praktische Wahl.

Für einige Produktentwickler besteht die Lösung darin, die Rate, mit der sie die Arbeit beginnen, rigoros zu kontrollieren. Sie passen es an das Tempo an, mit dem die Arbeit tatsächlich abgeschlossen wird; sie verwalten sorgfältig die Anzahl der laufenden Projekte; sie stellen sicher, dass ein Projekt, sobald es einmal begonnen wurde, bis zu seiner Fertigstellung angemessen besetzt ist; und sie widerstehen der Versuchung, Ressourcen aus einem laufenden Projekt zu stehlen, um neue hineinzupressen.

Trugschluss 5: Je mehr Funktionen wir in ein Produkt einbauen, desto mehr Kunden werden es mögen.

Produktentwicklungsteams scheinen zu glauben, dass das Hinzufügen von Funktionen einen Wert für die Kunden schafft und das Weglassen von Funktionen den Wert zerstört. Diese Einstellung erklärt, warum Produkte so kompliziert sind: Fernbedienungen scheinen unmöglich zu bedienen zu sein, Computer brauchen Stunden, um eingerichtet zu werden, Autos haben so viele Schalter und Knöpfe, dass sie Flugzeugcockpits ähneln, und selbst der bescheidene Toaster wird mittlerweile mit einer Bedienungsanleitung und LCD-Anzeigen geliefert.

Unternehmen, die den Glauben, dass mehr besser ist, in Frage stellen, schaffen Produkte, die in ihrer Einfachheit elegant sind. Bang & Olufsen, der dänische Hersteller von Audioprodukten, Fernsehern und Telefonen, hat verstanden, dass Kunden nicht unbedingt mit dem Equalizer, der Balance und anderen Reglern herumfummeln wollen, um die optimale Kombination von Einstellungen für den Musikgenuss zu finden. Die High-End-Lautsprecher nehmen automatisch die notwendigen Einstellungen vor, um einen Song so originalgetreu wie möglich wiederzugeben. Alles, was der Benutzer noch einstellen muss, ist die Lautstärke.

Unternehmen dazu zu bringen, das Prinzip, dass weniger mehr sein kann, zu übernehmen und umzusetzen, ist schwierig, weil es zusätzlichen Aufwand in zwei Bereichen der Produktentwicklung erfordert:

Das Problem definieren.

Das Problem zu formulieren, das die Entwickler zu lösen versuchen, ist der am meisten unterschätzte Teil des Innovationsprozesses. Zu viele Unternehmen widmen ihm viel zu wenig Zeit. Aber diese Phase ist wichtig, denn hier entwickeln die Teams ein klares Verständnis ihrer Ziele und generieren Hypothesen, die durch Experimente getestet und verfeinert werden können. Die Qualität einer Problemstellung macht den Unterschied in der Fähigkeit eines Teams aus, sich auf die wenigen Funktionen zu konzentrieren, die wirklich wichtig sind.

Als Walt Disney Disneyland plante, wollte er nicht in aller Eile mehr Funktionen (Fahrgeschäfte, Essensarten, Anzahl der Parkplätze) hinzufügen als andere Vergnügungsparks hatten. Vielmehr begann er damit, eine viel größere Frage zu stellen: Wie könnte Disneyland den Besuchern ein magisches Kundenerlebnis bieten? Sicherlich kam die Antwort nicht über Nacht; sie erforderte akribisch detaillierte Forschung, ständiges Experimentieren und tiefe Einblicke in das, was „magisch“ für Disney und seine Kunden bedeutet. IDEO und andere Unternehmen haben spezielle Phasen, in denen sie vollständig in den Kontext eintauchen, in dem das anvisierte Produkt oder die Dienstleistung genutzt werden soll. Ihre Entwickler lesen alles Interessante über die Märkte, beobachten und befragen zukünftige Nutzer, recherchieren Angebote, die mit dem neuen Produkt konkurrieren werden, und fassen alles, was sie gelernt haben, in Bildern, Modellen und Diagrammen zusammen. Das Ergebnis sind tiefe Einblicke in die Kunden, die im Laufe des iterativen Entwicklungsprozesses getestet, verbessert oder verworfen werden.

Bestimmen, was versteckt oder weggelassen werden soll.

Teams sind oft versucht, damit anzugeben, indem sie brillante technische Lösungen produzieren, die ihre Kollegen und das Management verblüffen. Aber oft würden Kunden ein Produkt bevorzugen, das einfach mühelos funktioniert. Aus Kundensicht lösen die besten Lösungen ein Problem auf die einfachste Art und Weise und verbergen die Arbeit, auf die die Entwickler so stolz sind.

Ein Unternehmen, das dies verstanden hat, ist Apple. Es ist für viele Dinge bekannt – innovative Produkte, stilvolles Design und geschicktes Marketing – aber seine vielleicht größte Stärke ist seine Fähigkeit, ein Problem auf den Punkt zu bringen. (Siehe „The Real Leadership Lessons of Steve Jobs“, von Walter Isaacson, in unserer April-Ausgabe). Wie der verstorbene Steve Jobs einmal erklärte: „Wenn man sich ein Problem ansieht und es wirklich einfach erscheint, versteht man die Komplexität des Problems nicht wirklich. Und Ihre Lösungen sind viel zu stark vereinfacht. Dann steigt man in das Problem ein und sieht, dass es wirklich kompliziert ist. Und man kommt mit all diesen verworrenen Lösungen an….Da hören die meisten Leute auf.“ Nicht Apple. Es macht einfach weiter. „Die wirklich großartigen Leute machen weiter“, sagte Jobs, „und finden … das grundlegende Prinzip des Problems und kommen mit einer schönen, eleganten Lösung, die funktioniert.“

Die Entscheidung, welche Funktionen weggelassen werden sollen, ist genauso wichtig wie – und vielleicht noch wichtiger als – herauszufinden, welche man einbauen soll. Leider werfen viele Unternehmen im Bestreben, innovativ zu sein, alle möglichen Funktionen in die Waagschale, ohne wichtige Faktoren wie den Wert für den Kunden und die Benutzerfreundlichkeit vollständig zu berücksichtigen. Wenn solche Unternehmen eine geplante Funktionalität weglassen, dann in der Regel, weil sie Kosten einsparen müssen oder hinter den Zeitplan zurückgefallen sind oder weil das Team auf andere Weise versagt hat.

Manager sollten sich stattdessen darauf konzentrieren, herauszufinden, ob die Streichung einer vorgeschlagenen Funktion ein bestimmtes Produkt verbessern könnte und es dem Team ermöglichen würde, sich auf Dinge zu konzentrieren, die das allgemeine Kundenerlebnis wirklich verbessern. Dies lässt sich herausfinden, indem man jede vermeintliche Anforderung als Hypothese behandelt und sie in kleinen, schnellen Experimenten mit potenziellen Kunden testet.

Entwicklungsteams gehen oft davon aus, dass ihre Produkte fertig sind, wenn keine weiteren Funktionen mehr hinzugefügt werden können. Vielleicht sollte ihre Logik genau umgekehrt sein: Produkte nähern sich der Perfektion, wenn keine Features mehr eliminiert werden können. Wie Leonardo da Vinci einst sagte: „Einfachheit ist die höchste Stufe der Raffinesse.“

Trugschluss 6: Wir werden erfolgreicher sein, wenn wir es beim ersten Mal richtig machen.

Viele Produktentwicklungsprojekte verfehlen ihre Ziele hinsichtlich Budget, Zeitplan und technischer Leistung. Zweifelsohne spielen schlechte Planung, starre Prozesse und schwache Führung eine Rolle. Aber eine weitere Ursache, die oft übersehen wird, ist die Forderung von Managern, dass ihre Teams es „gleich beim ersten Mal richtig machen“. Die Forderung nach einem Erfolg beim ersten Durchgang führt dazu, dass die Teams sich für die am wenigsten riskanten Lösungen entscheiden, selbst wenn die Kunden diese nicht als große Verbesserung gegenüber dem Vorhandenen ansehen.

Um Fehler zu vermeiden, folgen Teams einem linearen Prozess, in dem jede Phase (spezifizieren, entwerfen, bauen, testen, skalieren, einführen) sorgfältig an „Gates“ überwacht wird. Die Arbeit an der nächsten Phase kann erst beginnen, wenn das Projekt das Tor passiert hat. Je weiter das Projekt voranschreitet, desto mehr Verpflichtungen werden eingegangen, und die Kosten, um auf neue Erkenntnisse zu reagieren, steigen um Größenordnungen. Erfolgreiche Tests in späten Phasen werden gefeiert, und Überraschungen, egal wie wertvoll sie sind, werden als Rückschläge betrachtet. Leider kann ein solcher linearer Prozessablauf zu Projektüberschreitungen führen, weil das Test-Feedback verzögert wird, Teams länger als nötig an schlechten Ideen festhalten und Probleme erst dann aufgedeckt werden, wenn es teuer ist, sie zu lösen.

Eine Toleranz gegenüber „Fehlern beim ersten Mal“ kann die bessere Strategie sein, solange die Leute schnell und häufig iterieren und schnell aus ihren Fehlern lernen. Fortschritte in der Simulation und Rapid-Prototyping-Technologien haben das Arbeiten auf diese Weise wesentlich einfacher und kostengünstiger gemacht.

Betrachten Sie, was wir in einer Studie von 391 Teams, die kundenspezifische integrierte Schaltungen entwickelten, herausgefunden haben. Teams, die einen iterativen Ansatz verfolgten und frühe und häufige Tests durchführten, machten auf dem Weg dorthin mehr Fehler. Da sie jedoch kostengünstige Prototyping-Technologien verwendeten, waren sie (in Bezug auf den Zeit- und Arbeitsaufwand) besser als Teams, die versuchten, ihr Design gleich beim ersten Mal richtig zu machen. Die Teams, die hohe Prototyping-Kosten hatten, investierten mehr Aufwand in die Spezifikation, Entwicklung und Verifizierung. Und weil sie ihre Iterationen später im Prozess durchführten – und viel weniger davon – verzögerten sie die Entdeckung kritischer Probleme.

Das Experimentieren mit vielen verschiedenen Ideen ist entscheidend für Innovationsprojekte. Wenn Menschen schnell und häufig experimentieren, werden natürlich viele neue Konzepte scheitern. Aber solche frühen Misserfolge können wünschenswert sein, weil sie es den Teams ermöglichen, schlechte Optionen schnell zu eliminieren und sich auf vielversprechendere Alternativen zu konzentrieren. Ein Crashtest, der zeigt, dass ein Autodesign unsicher ist, ein Medikamentenkandidat, der sich als giftig erweist, oder eine Software-Benutzeroberfläche, die Kunden verwirrt, können alles wünschenswerte Ergebnisse sein – vorausgesetzt, sie treten früh in einem Prozess auf, wenn nur wenige Ressourcen gebunden wurden, Designs noch sehr flexibel sind und andere Lösungen ausprobiert werden können.

Ein klassisches Beispiel für die Vorteile des „Fail early, fail often“-Ansatzes ist der überraschende Sieg des neuseeländischen Teams beim America’s Cup 1995. Um Ideen zur Verbesserung des Kieldesigns zu testen, setzte das Team zwei nahezu identische Boote ein: ein Boot, das im Laufe des Projekts modifiziert wurde, und ein „Kontrollboot“, das nicht modifiziert wurde. Täglich simulierte das Team Hypothesen auf einer lokalen Grafik-Workstation, wendete diejenigen, die vielversprechend aussahen, auf das eine Boot an, ließ es gegen das Kontrollboot antreten und analysierte die Ergebnisse. Im Gegensatz dazu führte der Konkurrent, das Team Dennis Conner, das Zugang zu leistungsfähigeren Computern (Supercomputer bei Boeing) hatte, alle paar Wochen große Stapel von Simulationen durch und testete dann mögliche Lösungen an einem Boot. Das Ergebnis: Das Team New Zealand absolvierte viel mehr Lernzyklen, eliminierte aussichtslose Ideen schneller und schlug am Ende das Boot Young America des Teams Dennis Conner.

Was sich mittlerweile hoffentlich herumgesprochen hat, ist, dass Experimente, die zu Misserfolgen führen, nicht unbedingt gescheiterte Experimente sind. Sie generieren neue Informationen, die ein Innovator nicht vorhersehen konnte. Je schneller der Experimentierzyklus abläuft, desto mehr Feedback kann gesammelt werden und in neue Experimentierrunden mit neuen und potenziell riskanten Ideen einfließen. In einem solchen Umfeld neigen Mitarbeiter dazu, in schwierigen Zeiten durchzuhalten, sich auf anspruchsvollere Aufgaben einzulassen und ihre risikoscheuen Kollegen zu übertreffen.

Ein solches Umfeld zu schaffen, ist jedoch nicht einfach – ein Thema, das Amy C. Edmondson von der Harvard Business School in „Strategies for Learning from Failure“ (HBR April 2011) untersucht hat. Misserfolge können zu Peinlichkeiten führen und Wissenslücken aufdecken, die das Selbstwertgefühl und das Ansehen des Einzelnen im Unternehmen untergraben können. Denn wie oft werden Manager befördert und Teams belohnt, wenn sie frühzeitig Fehler aufdecken, die zum Abbruch eines Projekts führen – obwohl die frühe Umschichtung wertvoller Ressourcen dem Unternehmen zugute kommt? Dies gilt besonders in Organisationen, die eine „Null-Toleranz für Fehler“ oder eine „fehlerfreie“ (Six Sigma) Umgebung aufgebaut haben.

Dieser Artikel erscheint auch in: