Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Neulich habe ich über eine Designausstellung in Hamburg geschrieben, bei der es um designorientierte Firmen, wie Braun Elektrogeräte, Wega, oder Apple geht.
Kürzlich habe in einen Blogartikel gelesen, der für die Vereinfachung der Kommunikation und Präsentation wirbt, und sich im Grunde genommen die Frage stellt, warum einfache Präsentationen oft die Besten sind.
Da gute „designorientierte“ Produkte sich ebenfalls durch diese Einfachheit auszeichnen, will ich heute beide Themen verbinden, und mich der Frage stellen, wie man einfache Produkte erschafft.
Im Presentation Zen Blog ist kürzlich ein Artikel mit dem Titel →Progress and the intentional selection of less erschienen, der sich der Frage widmet, ob ein „Mehr“ auch automatisch immer zu einem „Besser“ führt. Der Autor bezieht sich hierbei auf sein eigentliches Kerngebiet, die Präsentationstechnik, und kommt hier zu dem Ergebnis, daß dort „Mehr“ eben nicht automatisch „Besser“ ist.
Er zitiert den folgenden Satz eines japanischen Filmemachers, der verdeutlicht, wie sinnvoll es ist, in Vorträgen an das Vereinfachen zu denken.
A blind march toward progress that’s based on distraction, temptation, and consumption may not bring happiness.“ — Eiji Han Shimizu
Ich denke, daß der Zusammenhang „je einfacher, desto besser“ nicht nur in der Kommunikation gilt, sondern eben auch auf anderen Gebieten, wie zum Beispiel der Produktentwicklung. Daher habe ich mit Interesse gelesen, daß der Blogautor konkrete Vorschläge macht, wie man bei der Umsetzung vorgehen könnte:
Questions to consider
- How can you apply the „intentional selection of less“ to your work?
- What elements or activities in your field serve more to distract than to engage?
- How can you remove the distractions?
- In what ways, in your field, is more actually less (and vice versa)?
- How can you increase clarity and impact by resisting the call to add more?
Meine Antworten aus Produktmanagement-Sicht stammen aus der Praxis.
Der Ansatz des bewussten Verzichts läßt sich eigentlich immer gut anwenden, gerade, wenn man ein neues Produkt entwickelt. Oft wird man in der Praxis getrieben, immer mehr Features zu liefern und immer weitere Spezialfälle abzudecken. Am Ende ist das Releasedatum nah und die Software ist komplex, oder schwer zu bedienen.
Dies zeigt: Wenn man nicht aufpasst, denkt man leider nur zu spät daran, wie sinnvoll es sein kann, Features auch mal wegzunehmen, wenn man hierdurch andere Vorteile beibehält, wie die leichtere Bedienbarkeit, das konsistentere Konzept, etc.
Ich habe die besten Erfahrungen damit gemacht, daß ich jede Produktspezifikation vor der Fertigstellung noch einmal prüfe und vereinfache, solange bis ein weiteres Wegnehmen das Konzept zum Kippen bringt. Das ist dann genau der Punkt, an dem der funktionale Umfang „genau richtig“ ist.
Im Softwarebereich führen „zuviel“ Anforderungen quasi zwangsläufig zu Produkten, die sich kaum noch bedienen, oder durchschauen lassen. (Zu) Komplexe Produkte machen keinen Spass, und halten den Anwender erfahrungsgemäß von seiner eigentlichen Aufgabe ab.
Wenn man nicht aufpasst, entsteht das gleiche Problem auch dann, wenn man Produkte „nach und nach“ erweitert, und am Ende „eiermilchlegende Wollmilchsäue“ hat.
Um mit Komplexität umzugehen, sollte man sich als Produktowner nicht nur auf die Featuremenge konzentrieren, sondern man sollte vielmehr darauf achten, daß man die richtigen Features findet. Das setzt natürlich voraus, daß man genau versteht, welche Anwendungsszenarien den Kunden wichtig sind. Dies widerum bedingt, daß man seine Kunden kennt, und sie befragt.
Unerfahrene Produktmanager(innen) tendieren dazu, sich beim Einsammeln von Kundenanforderungen zu sehr und zu eng an den Kunden zu orientieren.
Diese vermeintlich „kundenorientierte“ Vorgehensweise hat den Nachteil, daß man u.U auch die Anforderungen erhebt, die dem Anwender eigentlich nur dazu dienen, kurzfristige Probleme zu lösen. Wenn man solche problemlösenden Anforderungen allzu willig aufnimmt, läuft man in die Gefahr, „zu komplexe“ Produkte zu entwickeln. Dasselbe passiert, wenn man sich in einen Feuerwehrmodus drängen läßt, und Dringlichkeit vor Güte kommt.
Meiner Erfahrung nach ist es sinnvoller, Kundenanforderungen generell zu hinterfragen, und sich auch zu überlegen, ob wirklich jeder Featurewunsch Einzug in das Produkt halten muss. Auf jedem Fall ist es aus Entwicklungssicht sinnvoll, wenn sich der Productowner darauf konzentiert, einen durchdachten Backlog bereitzustellen.
Im Internet finden Sie weiterführende Artikel:
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
