Probe, Sense, Respond – Mit Rapid Prototyping zum digitalen Produkt

Digitalisierung schafft Chancen. Neue Kundenbedürfnisse entstehen, Märkte öffnen und verändern sich. Gleichzeitig konfrontiert sie Produktmanager mit zunehmender Komplexität und vielen Unbekannten. In diesem Artikel beleuchte ich, welche Rolle Rapid Prototyping als Werkzeug bei der Entwicklung innovativer, digitaler Produkte spielen kann und was es beim Aufbau von Rapid-Prototyping-Kapazitäten zu beachten gilt.

Was hat sich verändert?

In den meisten Unternehmen – Software-Produzenten ausgeschlossen –  ist Software immer primär dazu eingesetzt worden, Geschäftsprozesse zu unterstützen. Entsprechend ist die interne IT ausgeprägt worden: Plantreue, Verlässlichkeit und Kosteneffizienz waren die dominierenden Erfolgsfaktoren. Der von Nicholas G. Carr 2003 im Harvard Business Report veröffentlichte Artikel “IT doesn’t matter” beschreibt die Situation deutlich: IT-Kapazitäten sollten wie jedes andere Infrastruktur-Thema behandelt werden: als nicht-strategische Handelsware.

Knapp neun Jahre später – für eine große Konzern-IT kein langer Zeitraum – sieht die Welt schon fundamental anders aus. Marc Andreessen schreibt im Wall Street Journal unter dem Titel “Why Software is Eating the World” über eine Welt, in der jedes Unternehmen zwangsläufig zu einem Software-Unternehmen werden wird.

Heute – noch einmal sechs Jahre später – zweifelt niemand mehr daran, dass digitalen und software-intensiven Produkten die Zukunft gehört. Das stellt Produktmanager vor große Herausforderungen:

Zum einen haben sich Märkte und Marktteilnehmer verändert. Digitale Kanäle und Produkte erlauben es, neue Zielgruppen zu erschließen und alte Probleme auf ganz neue Weise zu lösen. Das bedeutet aber gleichzeitig, dass das über lange Zeit angeeignete Expertenwissen plötzlich an seine Grenzen stößt. Unbekannte Wirkmechanismen müssen neu erforscht, veränderte Kundenbedürfnisse identifiziert werden. Exponentiell wachsende technische Möglichkeiten und die zunehmend unscharfen Grenzen zwischen Produktkategorien erzeugen zusätzliche Komplexität.

Zum anderen ist der Lebenszyklus digitaler Produkte im Vergleich zu ihren traditionellen Vorgängern um ein Vielfaches schneller. Hybride Produkte erhalten durch Software-Updates ganz neue Funktionen, ohne dass die Hardware-Plattform ausgetauscht werden muss. Reine Software-Produkte können gar mehrfach täglich aktualisiert werden. Dieser Geschwindigkeit kann sich kein Produktmanager auf Dauer verweigern: Die “digital natives” unter den Mitbewerbern haben sie längst für sich als Wettbewerbsvorteil erkannt.

Es entstehen zwei gravierende Verschiebungen: Zum einen stellen neue Produktgenerationen nicht länger eine evolutionäre Weiterentwicklung dar. Stattdessen muss das Produkt von Grund auf neu erfunden werden. Eine solche Neuausrichtung bedeutet aber auch, dass wir im Produktmanagement den komplizierten Problemraum, in dem analytisches, auf Fachwissen basierendes Vorgehen die beste Lösungsstrategie darstellt, verlassen. Immer häufiger finden wir uns im komplexen Problemraum wieder: Kausale Zusammenhänge sind nicht mehr a priori sichtbar, sondern müssen durch gezielte Experimente erst neu identifiziert werden.

Gleichzeitig zwingen uns deutlich kürzere Produktlebenszyklen dazu, diese frühe Phase der Produktentwicklung immer häufiger zu durchlaufen. In Summe bedeutet das, dass Produktmanager digitaler Produkte ihren Werkzeugkoffer an eine Situation anpassen müssen, in der Komplexität und die damit verbundene Unvorhersehbarkeit zum Alltag gehören. Ein mögliches Hilfsmittel dafür möchte ich im Folgenden detaillierter vorstellen.

Prototyping als Handlungsstrategie

Betrachtet man erfolgreiche Handlungsstrategien in komplexen Problemsituationen, so zeigen sich bestimmte Gemeinsamkeiten. An die Stelle von auf Analyseergebnissen fußendem Handeln tritt das vorsichtige Herantasten durch Ausprobieren und Beobachten. Dave Snowden’s Cynefin-Framework fasst dies sehr treffend zusammen: An die Stelle von Erkennen-Analysieren-Reagieren tritt Probieren-Erkennen-Reagieren (“Probe-Sense-Respond”). Prototyping, also die Fertigung von auf den Zweck der Informationsgewinnung ausgelegten Modellen und Testversionen eines Produkts, ist ein Vertreter dieser Handlungsstrategie.

Entsprechend sind heute Low-Fidelity-Prototypen fester Bestandteil der Produktentwicklung. Zusammen mit Interviews und anderen, dem User-Centered Design entstammenden Techniken nutzen wir sie regelmäßig, um Kundenbedürfnisse zu identifizieren und Lösungskonzepte zu validieren. Sie sind einfach, schnell und ohne besondere technische Fähigkeiten herzustellen und damit eine Methode des sogenannten Rapid Prototypings – der durch geeignete Verfahren und Reduzierung auf das Wesentliche stark beschleunigten Modellentwicklung. Damit sind sie ein wertvolles Werkzeug, solange wir mit ihnen dieses Wesentliche unserer Produktidee ausdrücken und erproben können.

Nun verändern sich aber wie bereits geschildert Problem- und Lösungsräume mit zunehmender Digitalisierung erheblich. Im Internet of Things rücken Software und Hardware wieder stärker zusammen. Die Einbindung von und Vernetzung mit bestehenden digitalen Produkten – das Stichwort hier ist API-Ökonomie – ermöglicht bisher undenkbare Funktionsvielfalt. Virtual- und Augmented-Reality-Lösungen rücken mit Projekten wie Google Tango in greifbare Nähe. Sprachbasierte Benutzerschnittstellen wie Amazon Alexa oder Chat-basierte Dienste wie WeChat stellen herkömmliche digitale Mensch-Maschine-Schnittstellen gleich ganz in Frage. Zuletzt machen künstliche Intelligenz und maschinelles Lernen menschliches Eingreifen an vielen Stellen vollständig unnötig.

Es ist leicht ersichtlich, dass Low-Fidelity-Prototyping – so nützlich es bisher gewesen sein mag – schnell an seine Grenzen gerät, wenn das Innovative – und vielleicht Disruptive – unserer Produktidee gerade in der Nutzung dieser neuen technischen Möglichkeiten liegt. Dadurch entsteht eine mit herkömmlichen Methoden schwierig zu schließende Lücke im Produktentwicklungsprozess: Wir können das Problem und seine Wichtigkeit feststellen, also unsere Produktidee theoretisch validieren. Wir haben aber keine einfache Möglichkeit zur Hand, herauszufinden, wie ein marktgängiges Produkt zur Lösung des identifizierten Problems beschaffen sein muss, können also auch nicht mit vertretbaren Risiken mit der Entwicklung einer ersten Produktversion beginnen.

Ansätze wie die Entwicklung eines MVP , also einer ersten, bedingt marktgängigen, nutzbaren Produktversion mit dem minimal erforderlichen Funktionsumfang, helfen zwar, sind in der Praxis aber häufig nur erfolgreich durchzuführen, wenn klar ist, welche Lösung “viable”, also praktikabel aus Entwickler- und Kundensicht ist. Solange wir hier nur auf Hypothesen setzen, sind kostspielige Fehlleistungen vorprogrammiert.

Wenn an dieser Stelle von einem MVP die Rede ist, dann beziehe ich mich hier auf die engere Definition, die ich in der Praxis am häufigsten antreffe: Eine erste Version eines Produkts, die in ihrer Beschaffenheit dem finalen Produkt nahe kommt. Beispiele für diese Art des MVP sind das erste iPhone oder der Tesla Roadster. Beide sind auf die wesentliche Komponente des späteren Produkts reduzierte Versionen, aber keineswegs “halbfertig” und einfach herzustellen.

Dem gegenüber steht die weitere Definition von MVP, die Eric Ries mit seiner Lean-Startup-Methode etabliert hat und deren Fokus der Informationsgewinn ist. Wie man sich dieses Werkzeug als Produktmanager nutzbar machen kann, beschreibt mein Kollege Jan Hölter in seinem Softwerker-Artikel “Do Things That Don’t Scale”.

Rapid High-Fidelity-Prototyping mit Software

Glücklicherweise sind nicht nur die Herausforderungen gewachsen. Sowohl methodisch als auch technisch hat sich im Bereich der Software-Entwicklung viel getan. Agile Methoden, allen voran Scrum, sind im Mainstream angekommen und zeigen, wie man Software ohne schwergewichtige Prozesse in kurzen Entwicklungszyklen entwickeln und ausliefern kann. Entwicklungsframeworks, API- und Komponenten-Ökosysteme sowie Platform-as-a-Service-Angebote mit umfangreichen, leicht nutzbaren Diensten liefern Entwicklungsteams die nötige Produktivität. Damit besitzen wir letztlich alle Zutaten, um das alte Argument gegen High-Fidelity-Prototypen, langwierige und komplizierte Entwicklung, außer Kraft zu setzen.

Hier liegt für Produktmanager digitaler Produkte eine große Chance. Nehmen wir einmal an, es wäre heute möglich, funktionsfähige Prototypen für Produktideen in einer Geschwindigkeit zu entwickeln, die bisher Papier-Prototypen und anderen Low-Fidelity-Methoden vorbehalten war. In diesem Fall könnten wir die oben beschriebene Lücke schließen: Sobald das Problem identifiziert und erste Hypothesen bezüglich des notwendigen Funktionsumfangs einer Lösung aufgestellt sind, können wir die Hypothesen mit gezielten, realistischen Experimenten validieren und auf diese Weise den notwendigen Funktionsumfang – aber auch das Lösungsdesign – für unser MVP empirisch ermitteln, ohne auf die sich heute bietenden technischen Möglichkeiten verzichten zu müssen.

Für innovative, digitale Produkten ist das ein unschätzbarer Vorteil: Ihre Wirkweise und Tauglichkeit ist im buchstäblichen Sinne aufgrund der neu entstandenen technischen und kombinatorischen Möglichkeiten nicht vorstellbar. Wir wissen im Voraus nicht, und können es uns auch ohne es auszuprobieren (“probe”) nicht erschließen, ob unsere Augmented-Reality-App, die dem Servicepersonal die Bestellhistorie der Restaurantgäste anzeigt, tatsächlich zu besserem Service und in Folge besserer Kundenbindung führt – und wie genau solch ein System ausgeprägt sein muss, um in dem spezifischen Nutzungskontext zu funktionieren.

Könnten wir die wichtigsten Aspekte dieser Idee kostengünstig aber realistisch in einem Modellversuch – also mittels eines Prototyps – erproben, könnten wir schnell Risiken identifizieren und in der Praxis nicht tragfähige Ideen verwerfen, bevor wir sie in die potentiell kostspielige und langwierige Entwicklung eines funktional eingeschränkten aber qualitativ hochwertigen MVP überführen.

Das Rapid-Prototyping-Team

Wenn wir davon überzeugt sind, dass Rapid Prototyping in Form von Software für uns ein wertvolles Produktmanagement-Werkzeug sein kann, stellt sich die Frage, wie wir die entsprechenden Kapazitäten aufbauen können. IT-Organisationen sind, wie in der Einleitung angedeutet, üblicherweise nicht auf diese Art von Software-Entwicklung ausgerichtet. Ihre Aufgabe ist, verlässlich qualitativ hochwertige und langlebige Systeme zu entwickeln, häufig nach einem mehr oder weniger stabilen Plan. Wir benötigen eine andere Art von Team: Ein Team, das Software nicht als Endergebnis sieht, sondern als ein sehr spezielles Mittel zum Einholen von Feedback. Entsprechend müssen sich die Optimierungsziele dieses Team verschieben. Es lässt sich argumentieren, dass – sobald es einmal gelungen ist, den Feedback-Zyklus zu schließen, also Prototypen tatsächlich bis zur Testgruppe auszuliefern – nur noch die Minimierung der Zeit und Kosten zwischen Idee und Umsetzung wichtig ist. Im besten Fall möchte ich als Produktmanager die Entstehung und Beschaffenheit des Prototyps unmittelbar – also ohne zwischengelagerte Rituale oder Prozesse – beeinflussen können.

Wenn ich auf die Erfahrung zurückblicke, die ich beim Aufbau eines solchen Teams sammeln konnte, zeichnen sich einige Faktoren ab, die für die erfolgreiche Erbringung von Rapid-Prototyping-Dienstleistungen essentiell sind:

Stabiles, funktionsübergreifendes Team

In der Entwicklung innovativer, digitaler Produkte ist Geschwindigkeit essentiell. Im klassischen, auf Projektarbeit optimierten IT-Organisationen ist es nicht unüblich, Teams gezielt für ein Projekt zusammenzustellen und am Ende des Projekts wieder aufzulösen. Unter dem Gesichtspunkt der Auslastung ist das sinnvoll. Wollen wir aber auf Taktzeit optimieren, können wir es uns nicht leisten, darauf zu warten, dass ein Team sich zusammenfindet und seine internen Abläufe erfindet und optimiert. Entsprechend sollte ein Rapid-Prototyping-Team stabil sein: Einmal ins Leben gerufen, bleibt es über einen langen Zeitraum zusammen. Die Zeit zwischen Einsätzen wird genutzt, um die Werkzeuge und die interne Zusammenarbeit zu verbessern.

Bei der initialen Zusammenstellung müssen wir darauf achten, alle relevanten Rollen abzudecken, ohne das Team unnötig groß werden zu lassen. Neben den offensichtlichen Software-Entwicklungskenntnissen in den relevanten Domänen sind Fähigkeiten in UX- und UI-Design und IT-Operations unerlässlich, um die nötige Autonomie herzustellen. Hat keines der Teammitglieder Erfahrungen im Bereich der Prozessoptimierung, kann ein externer Coach sinnvoll sein.

Stabile, produktivitätssteigernde Werkzeuge

Was für das Team gilt, muss auch für die verwendeten Werkzeuge gelten. Der Schlüssel zu erfolgreichem Prototyping liegt meiner Erfahrung nach darin, einen möglichst flexibel einsetzbaren und gleichzeitig genügend stabilen Satz von Entwicklungswerkzeugen zu wählen und über die Lebenszeit des Teams in diese Werkzeuge zu investieren, anstatt für jeden Prototyp auf spezialisierte und neue Tools zu setzen. Ziel ist es, durch Automatisierung und Extraktion wiederverwendbarer Komponenten den eigentlichen Programmieraufwand immer weiter zu reduzieren und gleichzeitig technische Risiken zu minimieren.

Welche Werkzeuge konkret in Frage kommen, hängt zu stark vom Kontext ab, in dem Produkte prototypisiert werden sollen. Allerdings ist es sinnvoll, nach bestimmten Kriterien auszuwählen:

• Wie groß ist das Ökosystem an fertigen Komponenten?
• Wie einfach ist es, eigene Komponenten herzustellen und wiederzuverwenden?
• Wie gut kann das Werkzeug automatisiert werden?
• Wie einfach ist der Betrieb von mit den entsprechenden Werkzeugen realisierten Anwendungen?

Wichtig bei dieser Entscheidung: Ob die verwendeten Werkzeuge später für die Entwicklung des echten Produkts in Frage kommen, ist nachrangig. Die Aufgabe des Prototyping-Teams ist nicht, Software zu entwickeln, sondern Ideen zu validieren.

Autonomie

Die durch stabile Besetzung und die richtigen Werkzeuge gewonnene Produktivität kann sich nicht in schnellen Taktzeiten niederschlagen, wenn das Team auf externe Zuarbeit warten muss. Die notwendige Autonomie hat viele Facetten: Zum einen spiegelt sie sich in der schon erwähnten, funktionsübergreifenden Besetzung des Teams wieder. Selbstverständlich fällt darunter auch eine intensive und kontinuierliche Zusammenarbeit mit dem verantwortlichen Produktmanager. Zum anderen ist technische Autonomie erforderlich. Konkret bedeutet das, das Team zu befähigen, alle benötigten Werkzeuge selbst auszuwählen, anzuschaffen und zu betreiben. Einige konkrete Beispiele aus meiner Erfahrung sind:

• Das Team konnte von Linux-basierten Entwickler-Rechnern auf macOS umsteigen, um für alle mobilen Plattformen Apps prototypisieren zu können.
• Das Team konnte eigenständig Abonnements für die benötigten Dienste (Laufzeitumgebungen, Continuous-Delivery-Infrastruktur, App Stores, etc.) abschließen.
• Das Team kann Hardware für Prototypen (IoT-Geräte, mobile Endgeräte, etc.) eigenständig bestellen.
• Das Team hat vollständige Kontrolle über den eigenen Entwicklungsprozess.

Schlanke Prozesse

Wenn ein Team auf Taktzeit optimieren muss, ergibt sich fast zwangsläufig eine Reduzierung des Umlaufbestandes, also der gleichzeitig bearbeiteten Aufgaben. Soll der Entwicklungsprozess außerdem kontinuierlich verbessert werden, ist eine Messung und Visualisierung von Taktzeiten und Bestand unerlässlich. Meiner Erfahrung nach eignen sich daher Kanban-Systeme mit strikten Work-In-Progress-Beschränkungen am besten. Auf Zeremonien sollte weitestgehend verzichtet werden. Treten unerwünschte Abweichungen auf, sollte sofort reflektiert und reagiert werden. Auch hier wieder ein paar konkrete Beispiele aus der Praxis:

• Für komplizierte, häufig auftretende und nicht technisch automatisierbare Tätigkeiten hat das Team Protokolle und Checklisten entworfen.
• Treten unerwünschte Variationen im Prozess auf, werden diese umgehend in einem eigens eingerichteten Chat-Kanal gesammelt. Am Ende jedes Tages wird über die Variationen reflektiert und entschieden, ob ein Eingreifen nötig ist.
• Treten Probleme auf, die ein Teammitglied daran hindern, effektiv zu arbeiten, wird der ganze Prozess sofort gestoppt, die Ursache ermittelt und behoben (“Stop the Line” ).
• Arbeitsgegenstände werden einzeln durch den gesamten Prozess geführt: Eine vom Produktmanager eingebrachte Idee wird sofort analysiert. Es wird eine Lösung entworfen, realisiert, ausgeliefert und validiert, bevor die nächste Idee angegangen wird.

Was bekommen wir dafür?

Ein Team, das konsequent darauf optimiert, wird mittelfristig in der Lage sein, für den Produktmanager mehrfach täglich und ohne nennenswerte Rüstzeiten Ideen in Form prototypischer Software umzusetzen und damit die Grenze zwischen Low- und High-Fidelity-Prototyping zu verwischen. Die Produktmanagement-Organisation kann diese Kapazitäten anschließend in ganz unterschiedlichen Szenarien einsetzen und erhält so ein insbesondere vor dem Hintergrund der Digitalisierung wertvolles Werkzeug:

• Unterstützung des Portfolio-Managements durch Validierung kritischer Hypothesen
• Erprobung unterschiedlicher Lösungsvarianten bei der Herstellung neuer oder der Ergänzung bestehender Produkte
• Unterstützung bei Machbarkeitsstudien
• Erstellung von Prototypen zu Demonstrationszwecken (Messen, interne Präsentationen, etc.)
• Einbindung in die Designphasen herkömmlich arbeitender Teams als Ersatz oder Ergänzung für Low-Fidelity-Prototyping

Ergänzend zu den aufgezählten Szenarien ist durchaus denkbar, Software-MVP und kleinere finale Produkte auch direkt durch ein solches Rapid-Prototyping-Team entwickeln zu lassen. Beispielsweise ließe sich das von Jan Hölter in seinem Artikel “Do Things That Don’t Scale” geschilderte Piecemeal MVP, das bestehende Services ohne eigenen Aufwand nur kombiniert, in einem Rapid-Prototyping-Team aufgrund ähnlicher Ansätze leicht zu einem echten Produkt weiterentwickeln.

In jedem Fall sollte aber Sorge getragen werden, dass die langfristige Weiterentwicklung und der Betrieb gesichert sind. Mein Kollege Harald Schlüter beschreibt entsprechende Maßnahmen in seinem Softwerker-Artikel “Wartungshölle? Nein, danke!”.

Fazit

In dem komplexen Umfeld der Entwicklung innovativer, digitaler Produkte müssen Produktmanager neue Handlungsstrategien finden. Probe-Sense-Respond – beispielsweise in Form des Prototypings – hilft uns, Produktideen zu validieren und geeignete Lösungen zu entdecken. Mit den heute verfügbaren Mitteln ist es möglich geworden, diese Prototypen direkt in Form von Software herzustellen und damit auch komplizierte und technisch anspruchsvolle Produktideen schnell und belastbar zu validieren.

Allerdings ist es unwahrscheinlich, dass entsprechende Kapazitäten über die bestehende IT-Organisation abgebildet werden können, da die Anforderungen deutlich von denen des üblicherweise praktizierten Projektgeschäfts abweichen. Mit der entsprechenden Planung und Disziplin ist es aber durchaus möglich, ein Team aufzubauen, das uns zukünftig die Entdeckung und Entwicklung digitaler Produkte erheblich vereinfachen wird.

Dieser Blog-Post ist erstmalig im Softwerker Spezial: Digitalisierung erschienen. Hier können Sie sich den Artikel auch als PDF herunterladen.

Den Softwerker kostenlos abonnieren

Für weitere Infos zu unserem Angebot schauen Sie bitte auf unserer Seite Digitization Labs.
Kontaktieren Sie uns für einen kostenlosen Workshop!