Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In einem typischen Softwareprodukt werden viele Funktionen kaum benutzt. Ein Produkt mit weniger Features zu haben, wäre hier von Vorteil, sowohl was die Komplexität betrifft, als auch die Wartung der Software, und die Kosten.
Heute geht’s um des „minimal viable scope“ eines Produktes, als eine Möglichkeit, genau das zu entwickeln, was für den Markterfolg notwendig ist (und nicht mehr).
Oft ist das Problem, daß eine Software mehr kann, als sie eigentlich müßte, um die Anforderungen eines normalen Nutzers abzudecken. Viele Produkte (gerade die „gewachsenen“ großen Softwarepakete) bilden ein Sammelsurium von Features, die oft nicht einmal konsistent zusammenpassen.
Sehr viele Features werden nicht von jedem Nutzer gebraucht, und kosten demnach überflüssiges Geld, oder bedingen unnötige Komplexitäten. In Ihrem Artikel →Cut Features; Add-Value sagt Joy Beatty hierzu:
„Yet 65 percent of features in software aren’t used (according to a Standish Group survey), and those unused and rarely used features are everywhere you look. Product managers and business analysts are in the unique position of being able to drastically cut scope to deliver more usable products faster and for less cost.”
Man soll nach Beatty ein Produkt so zusammenbauen, daß es die Bedeutung der Features für die Nutzer in Betracht zieht.
Die Bedeutung, die ein einzelnes Features für das Produkt hat, ergibt sich aus dem Wert den das Feature für die einzelnen User in den unterschiedlichen Nutzergruppen hat. Beatty meint, um diesen Wert zu bestimmen, solle man für jedes Produktmerkmal ermitteln, wieviele Nutzer das Gerät unter der Annahme kaufen würden, daß es das eine betrachtete Feature gibt.
Der Artikel macht diesen Entscheidungsprozess an einem Musikspieler für Sportler fest, der bestimmte Anforderungen erfüllen soll, wie zum Beispiel:
Sie nutzt diese Angaben zu den Anforderungen, um nun festzustellen, wie kaufentscheidend die einzelnen Features sind.
Den Ansatz halte ich für gut. Meiner Erfahrung nach sind jedoch die Zahlen, die hierfür notwendig sind, nicht immer einfach zu erheben. Auch sollte man die einzelnen Nutzer besser in Zielgruppen einteilen. Ein Ausweg aus diesem Datenproblem bieten meiner Meinung nach die folgenden Ansätze:
Beatty schlägt weiterhin vor, darüber nachzudenken, wie der Nutzer Schritt für Schritt die Funktionalität erschliesst („Process Flow“). Der Process Flow kann für die einzelnen Nutzer unterschiedlich sein, und zeigt die zentralsten Aspekte auf, die ein Produkt für diese Nutzer abdecken sollte.
Sie schlägt hierfür eine relativ komplexe „Requirements Mapping Matrix“ vor, die dafür sorgen soll, ein komplettes Bild zu erhalten, und, um die einzelnen Anforderungen nachzuvollziehen.
Der Artikel zeigt hierfür eine sehr detaillierte Tabelle mit den Spaltenüberschriften die sich aus ihrem Beispiel ergeben, und Zeilen, die den einzelnen Nutzungsszenarien entsprechen (hier nur ein Szenario wiedergegeben):
Gerade auf dem gezeigten Level der Information, und bei komplexeren Produkten ist die vorgeschlagene Matrix meiner Meinung nach viel zu detailliert, und auch erst einmal garnicht notwendig, solange man nicht das Gesamtprodukt strukturiert hat.
Insbesondere ist es sehr aufwendig, bis dahin zu kommen, daß man genaue Anforderungen aufschreiben kann. Ich würde stattdessen eher eine Matrix verwenden, die sich auf die folgenden Informationen konzentriert:
Mit diesen Daten kann man viel einfacher Anforderungen angleichen, und Nutzergruppen identifizieren, die zu viel Komplexität erfordern.
Die Grafik ganz oben zeigt eine Tabelle, die genau diese Daten zusammenfasst (Clicken zum Öffnen). Dort sieht man, daß es drei Personas gibt, wovon eine Persona (Zielgruppe) sehr viel Komplexität ergänzt. Man kann das Produkt sehr viel einfacher machen, indem man sich zunächst auf die einfachen Anwendungsfälle konzentriert.
Um dort hinzukommen beschreibt man die neben den Szenarien, die Anforderungen der Nutzer. Hierfür hat es sich bewährt, die einzelnen Gruppen (in dieser Phase) an einen Tisch zu holen, um so dafür zu sorgen, daß sich die die Anforderungen angleichen.
Im Internet finden Sie weiterführende Artikel, in denen Sie mehr Informationen über die vorgestellten Konzepte:
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema Innovationsmanagement generell:
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
