Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In der New York Times ist am Wochende ein Artikel zu einer Vorlesung/Übung erschienen, die an der Stanford Universität stattgefunden hat.
In dieser Übung sollten Studenten in relativ kurzer Zeit Apps für mobile Geräte erstellen, diese in den Apple Store einstellen, und so die App erfolgreich vermarkten. Aus diesem Versuch sind verschiedene neue Unternehmen entstanden, und eine neue Art, eine Unternehmensgründung zu organisieren (siehe →The Class That Built Apps, and Fortunes).
Kann dieser Ansatz generell funktionieren, und, wenn ja, wo liegen die Einschränkungen? Heute möchte ich Ihnen meine Erfahrungen zu diesen beiden Fragen vermitteln, und nehme bewußt die Rolle eines Produktmanagers für eine etablierte Softwarelösung ein.
Die übliche Lehrmeinung geht davon aus, daß man Software zunächst spezifiziert, dann ein Design erstellt, und ggfs einen Prototypen, um dann sehr viel später in die eigentliche Produktentwicklung einzusteigen. Je nach Softwaresystem kann ein solcher Zyklus schon einmal mehrere Jahre dauern. Der oben erwähnte Artikel beschreibt diverse Facetten der besagten Vorlesung in Stanford. Hier gehe ich kurz auf die wesentlichsten Inhalte ein.
Alles startet mit der Aufgabenstellung an die Studenten, eine App zu entwickeln, und über den App Store an die Nutzer zu bringen:
„ALL right, class, here’s your homework assignment: Devise an app. Get people to use it. Repeat. That was the task for some Stanford students in the fall of 2007, in what became known here as the “Facebook Class.”
Neben der Information, daß daraus neue Unternehmen entstanden sind, finde ich den neuen Ansatz interessant, den man hierbei entwickelt hat. Der besteht daraus, schnörkellose, und einfache Apps zu entwickeln, die schnell unter die Leute gebracht werden, um die Anwendungen später nach und nach zu optimieren (ganz anders als der bisherige Standard).
But by teaching students to build no-frills apps, distribute them quickly and worry about perfecting them later, the Facebook Class stumbled upon what has become standard operating procedure for a new generation of entrepreneurs and investors in Silicon Valley and beyond. For many, the long trek from idea to product to company has turned into a sprint.
Inzwischen hat dieser Rapid-Prototyping-Ansatz das Gründungsgeschehen für junge Unternehmen verändert, und hat zu einer neuen Innovationswelle geführt. Manche Nennen diesen Ansatz allerdings auch einen Bubble, und fürchten, daß der Ansatz irgendwann platzen wird:
Start-ups once required a lot of money, time and people. But over the past decade, free, open-source software and “cloud” services have brought costs down, while ad networks help bring in revenue quickly.
The app phenomenon has accentuated the trend and helped unleash what some call a new wave of technology innovation — and what others call a bubble.
Einige der Teilnehmer an diesem App-Gold-Rush haben ihr Glück gefunden. Insofern kann man feststellen, daß die Methode damals geklappt hat, und vermutlich auch in Zukunft Chancen hätte.
Der Rapid Prototying Ansatz besteht daraus, daß man gleich zu Beginn seines Entwicklungsprojektes damit beginnt, lauffähige (funktionell eingeschränkte) Modelle der späteren Software zu erstellen. Bei vielen Methoden stellen Modelle ein ergänzendes Element dar. Wie sie wissen, bilden Modelle sogar einen festen Bestandteil der Design Thinking Methode, und sind dort fest integriert.
Modelle, bzw einfache Prototypen haben diverse Vorteile. Unter anderem kann man mit ihnen Thesen prüfen, auf die man seine Entwicklung gründen will. Oder man kann über ein einfaches Modell die Bedienung und die Nutzbarkeit eines Systems verifizieren. Auch erleichtern Modelle die Kommunikation mit Kunden, oder sonstigen Teilnehmern im Entwurfsprozess.
Modelle, und Entwurfsmethoden, die Modelle verwenden sind daher mächtige Werkzeuge beim Entwurf komplexer Systeme, und dort auch nicht wegzudenken. In diesem Zusammenhang habe ich sie als ein wertvolles Hilfsmittel kennengelernt.
Neu an dem Stanford Experiment ist, daß man die Rapid Prototyping Methode nicht nur innerhalb des Entwicklungsprojektes verwendet, sondern, daß man diese Zwischenstände an Kunden ausliefert.
Eine solche Vorgehensweise kann sehr wohl Vorteile haben. So bekommt man auf diesem Wege sicher relativ direktes Feedback von seinen Nutzern, in welche Richtung die Entwicklung weitergehen soll. Auch kann man es damit schaffen, die Nutzung einer Applikation zu forcieren, zumindest, solange man die ersten Prototypen der Software kostenlos abgibt. Nicht zu vergessen ist, daß der Geschwindigkeitsvorteil bei manchen Anwendungen sinnvoll ist, z.B, wenn es darum geht eine neue Produktkategorie zu schaffen.
Eine solche Methode kann aber auch Nachteile haben, bzw sie ist an das Vorhandensein ganz bestimmter Vorbedingungen geknüpft. Darum geht es mir im folgenden Teil.
Es kann passieren, daß man das Ziel der „einfache Anwendung“ verwechselt mit „unprofessionell“. Damit will ich sagen, daß die Gefahr besteht, daß man nicht nur an der Funktionalität der ersten Versionen spart, sondern auch an deren Qualität, und somit den Nutzer nicht nur als Ideenlieferanten, sondern auch als billigen Betatester versteht.
Eine solche Vorgehensweise ist bei jedem Produkt überaus gefährlich, da es heute oft sehr viele Alternativen gibt, und Nutzer schlechte Qualität normalerweise unmittelbar abstrafen. Inzwischen haben sich auch der Apple Store, oder Googles App Store so weit von den Ursprüngen fortentwickelt, daß ich nicht glaube, daß eine qualitativ schwache Anwendung dort lange überleben kann.
Fazit: In Ihrem Stanford Projekt sollten Sie keine Abstriche bei der Qualität erlauben. Sie sollten Ihre Entwicklungszyklen und -methoden so gestalten, daß sie lang genug sind, um Qualität zu entwickeln.
Es ist eine Sache, wenn man über eine Entwicklungsmannschaft verfügt, aber eine Entwicklungsmethode verwendet mit der man inkrementelle Verbesserungen einer Software ausliefern kann (z.B. Scrum Methode). Eine andere Sache ist, wenn man den Stanford Ansatz verwenden muß, um darüber hinwegzutäuschen, daß das eigentliche Projekt zu groß ist für das zur Verfügung stehende Team.
Bereits im Artikel wird das Beispiel eines Studenten erwähnt, der eine gefragte Anwendung entwickelt hat, aber dann doch aussteigen mußte, weil er zeitlich nicht in der Lage war, die Anwendung weiterzuentwickeln. In Fällen, in denen die eigenen Kapazitäten nicht ausreichen, besteht die Gefahr, daß die Wettbewerber Ihre Idee übernehmen. Schlimmer noch. Es könnte vorkommen, daß Ihre mangelnde Lieferfähigkeit Kunden verärgert.
Fazit: Planen Sie Ihren Kapazitätsbedarf trotz flexiblem Ansatz längerfristig, um so sicherzustellen, daß Sie in der Lage sind, den sich ergebenden Bedarf zu befriedigen.
Der Stanford Ansatz kann nur unter bestimmten Bedingungen funktionieren. Meiner Meinung nach ist es wichtig, daß Sie innerhalb eines Framework entwickeln, der Ihnen viel Drumherum abnimmt. Die App Stores unterstützen Sie bei der Entwicklung Ihres Produktes, und sie helfen Ihnen bei der Vermarktung. Auch sind die Produkte hinsichtlich des Funktionsumfangs relativ überschaubar, der dort angeboten wird.
Die Stanford Methode findet meiner Erfahrung nach ihre Grenzen bei Entwicklungsprojekten, die Sie ohne eine unterstützende Plattform durchführen müssen. Dies liegt einmal daran, daß Sie sich dort selbst die jeweiligen Voraussetzungen aneignen müssen. Viel wichtiger ist noch, daß Sie sich selbst erst Reputation erwerben müssen, die Ihnen woanders mitgeliefert wird.
Fazit: Die Stanford Methode ist prädestiniert für Produkte, die Sie innerhalb einer bestehenden Plattform entwickeln. Sie ereignet sich weniger für vollständig eigenständige Stand-Alone Produkte.
Die üblichen Apps für mobile Geräte sind normalerweise relativ kostengünstig. Demgegenüber sind ausgewachsene Softwarepakete relativ teuer. Kunden mögen es bei überschaubaren Kosten akzeptieren, einfache, unfertige Produkte zu erhalten. Ein ausgewachsenes Softwareprodukt würden ebendiese Kunden sicherlich nicht so gelassen beurteilen, alleine, da es sehr viel teurer ist.
Fazit: Die Stanford Methode ist gut anwendbar bei relativ preisgünstigen Produkten. Bei ausgewachsenen Softwareprodukten ist es besser, den Rapid Prototyping Ansatz nur firmenintern zu verwenden.
Der Stanford Ansatz kann eine sinnvolle Vorgehensweise bei der Neuentwicklung von Produkten sein. Um zu funktionieren, benötigt er allerdings auch Rahmenbedingungen. Mindestens sollte die Qualität stimmen, und das Produkt hinreichend günstig sein. Darüberhinaus sollten Entwicklungsvorhaben und Ihre Entwicklungskapazitäten im Einklang stehen. Auch benötigt das Modell Unterstützungen durch das Angebot eines größeren Herstellers, z.B. in Form einer Plattform auf der Sie entwickeln und vermarkten können.
Wenn Sie weiter über die Stanford Entwicklungsmethoden nachdenken, fallen Ihnen sicher noch weitere Anwendungsgebiete und Voraussetzungen ein. Die Vorteile erscheinen mir jedoch so eindeutig zu sein, daß ich Ihnen uneingeschränkt empfehlen kann, diese Methode einmal auszuprobieren.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version 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
