Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In seinem Artikel → The Design Pyramid schreibt Philip Haine über die Frage, wie Forschung, Vision und Design zusammenpassen müssen, damit fundamental neue Produkte entstehen:
“How research, vision and design fit together to make breakthrough products”
Haine’s Designpyramide, die ebenfalls Gegenstand des Artikels ist, besteht aus mehreren aufeinander aufbauenden Phasen, beginnend bei der Phase „Understanding“, über die Phasen „Vision“ und „Requirements“ zum „Design“, wobei jede Vorgängerphase die Grundlage für die nächste Phase bildet.
In seinem Artikel geht er auch auf die Entwurfsmuster ein, die hinter jedem guten, und erfolgreichen Produkt stehen. Darum geht es mir heute.
…come from from breakthrough understanding.
Der Idee folgend ,daß „Understanding“ vor „Design“ kommt, liegt Haine’s Behauptung nicht fern, daß tolle, und bahnbrechende Produktideen (nur) aus dem tiefgreifenden Verständnis der Kundenanforderungen entstehen. Er bringt hierfür das Beispiel des – wie er selbst sagt – überstrapazierten iPod von Apple, und erzählt hierzu die Entstehungsgeschichte.
Da die Aussage recht interessant ist, gebe ich sie vollständig wieder, obwohl es dadurch ein langes Zitat wird:
Take, for example, the overused example of the iPod. Apple noticed that early batch of MP3 players played music well enough, but getting songs on the device was excruciatingly slow over the USB 1.0 interfaces common at the time. Plus, the quirky, proprietary music transfer software was hard to manage. This was a real problem. The solid-state devices of the day had such small capacity that unless you liked listening to the same three albums over and over again, you had to spend a lot of time transferring new music onto the device. Because of this cost, MP3 players often ended up gathering dust in a drawer. These were Apple’s core insights, at the Understanding level of the Pyramid.The iPod vision was sculpted to address these problems: make music management easy with great desktop software (iTunes); make transfers fast (using Firewire) and make transfers rarely necessary (with a high-capacity, hard-drive based player). Beyondthis, Apple understood that the that gadgets you are seen with in public are a reflection of your image, and that an MP3 player should look and feel cool.Their easy, fast, high-capacity, cool looking iPod was a breakthrough product that virtually owned the digital music market through its entire arc (until smartphones and pocketable computers like the iPod Touch relegated the single-purpose music player to niche product).
Man sollte vielleicht ergänzend erwähnen, daß die Ursprungsidee zu iTunes und iPod nicht von Apple selbst stammt, sondern von einem Mitarbeiter, der von einer anderen Firma dahin gewechselt hat. Er hatte sich in dieser Firma bereits mit dem Thema befasst, und Steve Jobs war kreativ genug, den guten Kern der Idee zu erkennen, als sie ihm vorgestellt wurde.
Was zeigt dies? Nun, es ist wichtig, daß
Die Haine’sche Designpyramide geht auf die Schritte zwischen Kundenbedarf und Design ein, und umfaßt die Phasen „Vision“ und „Requirement“, wie bereits weiter oben gesagt. Diese Pyramide behandelt daher im Grunde genommen die Frage, wie man sich ordentliche Produktanforderungen erarbeitet, und wie man zu einer guten Spezifikation kommt. Damit fehlt aber noch ein gutes Stück Anstrengung auf dem Weg zu einem guten Produkt.
An dieser Stelle fehlt meiner Meinung nach zwei Phasen, die man vielleicht „Prototyping“ und „SpecReview“ nennen könnte. Auch sollte man die Pyramide eher als einen Regelkreis verstehen, als eine Pyramide, die man von unten nach oben durchläuft.
Ein weiteres Thema, das die Designpyramide nicht abdeckt, ist die Frage der eigentlichen Umsetzung, die oft wieder einen Einfluß z.B. auf das Design hat. Hierfür sind Schritte notwendig, die sich an die Designphase anschliessen. Beispiele hierfür wären z.B. die anschiessende Qualitätsicherung, beginnend beim Review der Anforderung, bis zu entwicklungsbegleitenden Tests und Aktivitäten.
Normalerweise haben „Produktanforderungen“ das Problem, daß Kunden zwar etwas sagen, und die Entwicklung etwas anderes versteht. Sie entstehen daher zunächst als Featurewünsche.
Im Normalfall sind aber genau die Anforderungen interessant, die der Kunde zwar hat, die er aber nicht artikulieren kann, weil er die Lösungsmöglichkeiten nicht kennt. Dabei handelt es sich um die Anforderungen, die sich nicht aus konkreten Featurewünschen herleiten lassen.
Um mit diesem Problem umzugehen, sollte bereits sehr früh damit begonnen werden, sich Prototypen und Muster zu erstellen. Solche Prototypen helfen zum Beispiel im Kundengespräch dabei, um gemeinsam festzustellen, ob die Anforderungen, die man verstanden hat, auch diejenigen sind, die der Kunde hat. Man würde hiermit also zwischen dem oberen Punkt in der Pyramide (Design), und der unteren Phase (Anforderungen) hin und herspringen.
An anderer Stelle in meinem Blog habe ich über die Design-Thinking-Methode geschrieben, die genau diesen Ansatz auch methodisch kultiviert.
Zwei Fragen haben meiner Erfahrung nach immer wieder Einfluß auf ein Produktdesign, das oft unterschätzt wird:
Um diese Fragen beurteilen zu können, sollte man unbedingt ein Review von Anforderungen und Spezifikation durchführen. In diesem Review sollte man (auch) die Frage stellen, ob die „Anforderungen“ auch in einem größeren Zusammenhang überhaupt Sinn machen. Gut, bei der Entwicklung eines iPod hat man an dieser Stelle vielleicht wenig Spielraum. Bei geschäftskritischer Software ist diese Frage jedoch ungleich wichtiger.
Gerade bei größeren Entwicklungen sollte man dafür Sorge tragen, daß man den einmal angepeilten Weg auch konsequent verfolgt. Dieser Schritt kann aber beliebig komplex werden, insbesondere, wenn man sich auf Entwicklungen konzentriert, bei denen sich das Design im Projektverlauf ändern kann, z.B. weil man auf unerwartete Schwierigkeiten trifft.
Um hiermit umzugehen benötigt man Verfahren, die die Gesamtentwicklung in kleine Pakete einteilen, wie zum Beispiel die Scrum Methode. Man benötigt zudem Methoden, anhand derer man entscheiden kann, ob ein einzelnes Backlog Item erledigt ist, und inwieweit Änderungen im Gesamtkonzept notwendig sind. Üblicherweise benötigt man hierfür Done Kriterien, die man sowohl anwendet während man das Design entwickelt, als auch, während man das Design umsetzt.
In Haine’s Blog mit dem Titel →Steal This Idea finden Sie eine Fortsetzungsreihe zu der hier angerissenen Methode, und zu Themen im Umfeld.
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
