Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In der Softwareindustrie sind agile Entwicklungsmethoden inzwischen fest etabliert. Die Grundidee ist hierbei, Mitarbeiter unterschiedlicher Disziplinen zusammen an einen Tisch zu bekommen, um mit denen in endlicher Zeit und in einer iterierenden Vorgehensweise marktreife Lösungen zu entwickeln.
Unter dem Oberbegriff des „Design Sprints“ halten diese Methoden zunehmend Einzug in andere Arbeitsgebiete, wie das Design, wo die Problemstellungen ähnlich gelagert sind.
Komplexe Produkte entstehen selten linear und isoliert. Vielmehr treffen bei ihrer Entwicklung unterschiedliche Ideen und Produktanforderungen zusammen und müssen in einem geschlossenen Konzept vereint werden.
Dabei sind die Produktanforderungen selten klar formuliert, und es sind manche Ideen besser als andere. Über allem steht dabei der Anspruch, ein möglichst gutes Produkt zu entwickeln, daß sowohl Kunden begeistert, als auch gewinnbringend hergestellt werden kann.
Früher wurde der Entwicklungsprozess wie ein Wasserfall organisiert: Es gab Produktentwicklungsphasen, die nacheinander von unterschiedlichen Abteilungen durchlaufen wurden. Ganz am Ende stand dann ein fertiges Produkt, das dann kaum mehr zu ändern war – auch dann nicht, wenn seine Grundidee nicht optimal war.
Es hat sich gezeigt, daß die neueren agilen Methoden, wie die Scrum Methode, und, daß Vorgehensweisen wie das Design Thinking den Bedürfnissen komplexer Produkte viel besser gerecht wird, da sie iterierend statt sequentiell vorgehen. Dadurch können Ideen frühzeitig ausprobiert und verbessert werden, und es kann Kundenfeedback eingeholt werden, bevor es zu spät ist.
Im Design richtet sich der aktuelle Trend auf die Gestaltung herausragender Erlebniswelten für die Anwender. Diese Erlebniswelten zu entwerfen, ist ein ähnlich komplexer Vorgang, wie es die Entwicklung eines marktreifen Produktes ist.
Die Methode des „Design Sprints“ ist eine rasch wirksame Methode zur Entwicklung von Designprototypen, die auf ähnlichen agilen Prinzipen aufbaut, die man auch aus der Produktentwicklung kennt.
Die Vorgehensweise wurde im Jahr 2010 von den UX-Spezialisten Jake Knapp, John Zeratsky und Braden Kowitz bei Google Ventures entwickelt. Dabei steht die Abkürzung „UX“ für den Begriff der User Experience, bzw. das Nutzererlebnis.
In der ursprünglichen Konzeption läuft der Design Sprint über fünf Tage. In den ersten vier Tagen entstehen in Teamarbeit testfähige Prototypen von Produktdesigns. Am fünften Tag werden diese Produktdesigns zusammen mit Nutzern getestet. Dadurch kann nach Durchlaufen eines kompletten Zyklus am Ende der Woche schnell herausgefunden werden, ob ein neues oder verbessertes Design in die weitere Umsetzung gehen soll oder nicht.
Die Methode selbst entwickelt sich weiter. Die gegenwärtig gültige Version des Verfahrens ist die Version Design Sprint 2.0 (Stand: Mai 2018).
Der Begriff des „Sprints“ wurde mit der Scrum Methode eingeführt. Die ersten Anfänge dieser Methode lassen sich in die Jahre um 1995 zurückverfolgen. Ikujirō Nonaka, Hirotaka Takeuchi, Jeff Sutherland und Ken Schwaber gelten als ihre direkten oder indirekten Urheber.
Im Englischen, und damit dem Sprachraum, aus dem die agilen Methoden stammen, bezeichnet der Begriff des Sprints einen (Kurzstrecken-)lauf. Ähnlich wie bei einem Kurzstreckenlauf ist die Grundidee der Scrum Methode, einen festen Anfangs- und Endzeitpunkt zu setzen (üblicherweise zwei bis vier Wochen), um in diesem Zeitraum, die vereinbarten Sprintziele zu erreichen. Der Design Sprint hat sowohl diese Vorgehensweise als auch die Terminologie übernommen und orientiert sich inhaltlich auch an den Ideen des Design Thinking.
Ursprünglich dauern Design Sprints 5 Tage (Montag bis Freitag), es sind aber auch Abwandlungen möglich, wie 4 Tages Sprints. Das Verfahren hat mehrere Phasenschritte und Ergebnisobjekte (siehe hierzu und für weiterführendes Material auch die weiter unten angegebenen Website „The Design Sprint“ von Google Ventures).
Bevor es losgehen kann, findet eine „Set the Stage“ Phase statt. Auf der zitierten Website von Google Ventures finden Sie entsprechende Checklisten, wie die „Shopping list for sprint supplies“, oder auch weitere Links und Dokumente, die Sie benötigen, um die anderen Tage des Workshops auszugestalten.
Zu den wesentlichen Arbeitsmitteln zählen praktische Whiteboards zum Übersicht schaffen, oder auch Karten und Marker, die Sie unter dem weiter unten angegebenen Link „Büroausstattung für Design Sprints bei www.gaerner.ch“ beziehen können.
Die ursprüngliche Methode sieht vor, am ersten Tag zusammen mit der ganzen Gruppe das langfristige Ziel zu definieren, und hierzu entsprechende Experten zu befragen.
Eine mögliche Tagesgliederung könnte Themen wie die Definition der Herausforderungen, Expertenbefragungen, Gruppenarbeit, oder Demonstration von Beispielen beinhalten. Ziel ist es, Fragen zu beantworten wie „Wie könnten wir …?“ (HWMs = „How Might We“), um so strategische Szenarien zu definieren, die das Produktdesign erreichen soll.
Der nächste Tag konzentriert sich auf das Entwickeln von Lösungsideen. Dabei steht das Vorbereiten der „Lightning Demo“ im Vordergrund. Diese Demo zeigt die „Erleuchtung“, den Aha-Effekt, und macht deutlich, wie die jeweilige Lösung funktioniert. Hierbei ist es sinnvoll, die Lösung in 4 Teilen zu skizzieren:
An diesem Punkt liegen viele potentielle Lösungsideen vor. Man kann jedoch nicht zu jeder Idee einen Prototypen erstellen. Daher startet der Tag mit der Präsentation der Lösungen inclusive „Lightning Demo“. Hieran nimmt die gesamte Gruppe teil.
Es folgt eine Diskussion und und die Entscheidung, welcher Prototyp entwickelt werden soll. Diese Lösungen werden im Anschluss in das Storyboard für die Benutzer Tests integriert. Ein solches Storyboard zeigt den gesamten Kontext der Idee auf.
Am Vortag ist das Story Board einer konkreten Lösungsidee entstanden. Am Donnerstag geht es um die Entwicklung eines Prototypen, der dann am letzten Tag mit den potentiellen Nutzern getestet werden kann.
Gleichzeitig entstehen an diesem Tag Interviewfahrpläne und Skripte. Der Prototyp baut hierbei auf den Entscheidung des Vortages und den Lösungsskizzen auf.
In den Tagen bisher sind aus dem Nichts heraus, konkrete Lösungsideen und Prototypen entstanden, sowie Storyboards, die die beste Lösung realistisch und konkret beschreibt.
Der Freitag hat das Testen der entwickelten Funktionalitäten und Ideen zum Ziel, um so sicherzustellen, daß die Anforderungen potentieller Nutzer erfüllt werden.
Sollte es sich um ein Kundenprojekt handeln, kann in der letzten Phase gleichzeitig ein zusammenfassender Abschlussbericht erstellt werden, mit dem der Design Sprint dann formal abgeschlossen wird.
Prototyp und Abschlussbericht werden anschliessend dann an das Management des Auftraggebers übergeben.
Um gleichzeitig für die nächsten Design Sprints zu lernen, bietet es sich an, gemeinsam mit dem Team eine Retrospektive der Woche durchzuführen, ggfs. mit anschließendem Mittagessen.
Design Sprints sind teamorientierte Verfahren zum raschen Erstellen eines Designprototypen, der abschliessend von Nutzern getestet wird. Die Methode ist an das bewährte Scrum-Verfahren der agilen Softwareentwicklung angelehnt.
Die Dauer des Design Sprints beträgt vier Tage, und einen Tag für den abschliessenden Test des entwickelten Prototypen. In dieser Zeit lässt sich ermitteln, ob der Prototyp geeignet ist, um den vollen Entwicklungszyklus und eine Produktion geeignet ist.
In der heutigen Welt sich rasch verändernder Trends sind Design Sprints das passende Verfahren, rasch auf Änderungen im Markt und das Nutzerverhalten einzugehen. In kürzester Zeit lassen sich neue Produkte entwickeln. Mit Design Sprints verkürzen sich der Markteintritt (Time-to-Market) für neue nutzerorientierte Produkte beträchtlich.
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Folgeartikel zum Thema gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen.
Dieser Beitrag entstand mit/in einer Unterstützung/Zusammenarbeit. Er ist jedoch vollkommen ohne inhaltliche Vorgaben und eigenständig entstanden.
In der Online Version des Artikels finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
