Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Die Güte von Software hängt sehr stark davon ab, daß sie die Anforderungen von realen Menschen in konkreten Situationen abdeckt. Das klassiche Marketing verwendet einen Ansatz, der uns bei der Entwicklung von Software oder auch Webanwendungen nicht weiterbringt.
Deshalb ist es notwendig, Mittel zu suchen, damit wir diese Menschen im gesamten Entwicklungsprozess stets vor Augen haben.
Reicht die klassische Martkforschung aus?
In der klassischen Marktforschung teilen wir den Markt in unterschiedliche Zielgruppen ein. Anschließend bedienen wir uns zwei- oder mehrdimensionaler Modelle, die die einzelnen Verbraucher nach definierten Kriterien gruppieren (Eine typische Klassifizierung basiert auf einer Einteilung der Verbraucher nach demografischen Merkmalen).
Wir verwenden diese Kategorien, weitere Marktforschungsdaten und Angaben über unsere einen Produktkategorien, um unsere Software/Webseite zu gestalten. Eigentlich haben wir dann alles gemacht, wie im Lehrbuch beschrieben.
Leider ist das Ergebnis einer solchen Vorgehensweise oft eine Lösung, die inside-outside getrieben ist.
Da unsere realen Nutzer oft nicht unsere Kategorien im Kopf haben, oder weil sie sich nur selten reinen Zielgruppen zuordnen lassen, passiert es sehr schnell, daß wir eine Software erstellen, in der die Nutzer sich nicht zurechtfinden.
Kunden können im Internet mit einem click zum Wettbewerb wechseln, wenn wir sie in einer Webanwendung durch einen unklaren Informationsaufbau abschrecken. Gleichzeitig verlangen die Nutzer einer nicht-web basierten Software eine Ergonomie, wie sie sie von Webapplikationen gewohnt sind. Da diese Usability einer Anwendung immer wichtig wird, kann der falsche Aufbau einer Lösung sehr schnell zu Umsatzeinbußen führen. Eine Lösung, die wir für reale Menschen entwickeln ist deshalb auch aus ökonomischer Sicht sinnvoll.
Hierfür benötigen wir andere Informationen, als sie uns das klassische Marketing bereitstellt. User Personas, Use Cases und Demand Scapes geben uns diesen notwendigen Überblick, an dem wir unsere Anwendungen ausrichten können.
Mit User Personas steht die Person des Nutzers im Mittelpunkt.
Die Technik der User Personas animiert uns dazu, uns sehr intensiv mit unseren eigentlichen Nutzern zu beschäftigen und die konkreten Aufgabenstellungen für die diese Personen unsere Anwendung verwenden.
Im Gegensatz zu abstarkten statistischen Beschreibungen handelt es sich bei User Personas um Beschreibungen von konkreten Personen. Diese Beschreibungen sind so detailliert, dass sie uns helfen, uns unmittelbar und direkt in diese Nutzer hineinzuversetzen.
User Personas eignen sich umso mehr, je inhomogener die Anforderungen sind, die an unsere Software gestellt werden. Dies ist zum Beispiel der Fall, wenn die Einstellungen und Vorlieben unserer Nutzer eine Rolle spielen. In Systemen oder Prozessen in denen der Nutzer sehr stark geführt wird, oder in monolitischen Anwendungen, existieren nur wenige Freiheitsgrade. Hier sind User Personas hingegen nicht in dem Maße hilfreich.
User Personas sind auch nützlich, wenn wir in einer größeren Organisation an einem gemeinsamen Produkt arbeiten. In solchen Fällen wollen wir sicherstellen, daß der Time-To-Market, d.h. die Zeitdauer bis zur Freigabe des Produktes möglichst minimal ist. Dies wird dadurch begünstigt, dass wir parallel arbeiten. Personas helfen uns dabei, Arbeiten zu parallelisieren, ohne das gemeinsame Leitbild aus den Augen zu verlieren. So können wir zum Beispiel Marketingunterlagen und die eigentliche Software gleichzeitig erstellen, und aneinander ausrichten.
3 bis 5 User Personas reichen
Für eine typische Softwareanwendung benötigt man zwischen 3 bis 5 unterschiedliche User Personas. Wenn man zu wenige Personas erarbeitet, würde jede Einzelne sehr davon sehr generisch ausfallen. Zu viele User Personas verwässern und individualisieren die Anforderungen an unsere Anwendung, und sind deshalb ebenfalls nicht sinnvoll.
Beim Erstellen der User Persona sollten wir darauf achten, daß sie einer typischen Nutzerperson entspricht. Um die Personen besser kennenzulernen, sollten wir Daten aus unterschiedlichen Quellen verwenden, wie zum Beispiel Daten aus Nutzerportalen, aus Verkäufen, vom Customer Care, etc. Zusätzlich hat es sich bewährt, Onlinebefragungen z.B. auf unserer Homepage durchzuführen. Online Befragungen erlauben es uns, mit wenigen gezielten Fragen, die Nutzer unserer Webseiten und ihre Anforderungen näher kennenzulernen. Weiterhin ist es sinnvoll, Onlineforen zu durchforsten, nach typischen Nutzern, und deren Meinungen. Um uns besser später im Softwareentwurfsprozess besser in die Persona hineindenken zu können, sollten wir sie nicht nur detailliert beschreiben, sondern ihr auch einen konkreten Namen geben. Zur verbesserten Identifizierbarkeit kann man User Personas auch ausgeschmücken mit persönlichen Photos, typischen Gegenständen aus dem Umfeld, etc.
Darf ich vorstellen. Dies ist Marlene, unsere vereinfachte Beispielpersona
Darf ich vorstellen. Dies ist Marlene, unsere vereinfachte Beispielpersona. Wir entwickeln ein Software für ein Reiseportal. Hier Marlene’s Kurzpersona für unser Entwicklungsprojekt:
| Daten | Marlene, 25 Jahre, 2 Kinder, verheiratet. Lebt in einer Kleinstadt. Sie verfügt über keinen Breitband-Internetanschluss |
| Bildung | Abitur und Ausbildung als Einzelhandelskauffrau |
| Arbeit | Tätig im Kundendienst bei einer kleinen Internetagentur. Ist gewohnt Computer und Internet zu nutzen |
| Typische Nutzung | Marlene benutzt Reiseportale in der Mittagspause, um a) sich zu informieren über mögliche Reiseziele, und b) sich Angebote zu besorgen für preiswerte Hotels. Manchmal, wenn die Kinder schlafen, sucht sie im Internet nach begleitenden Reiseinformationen, oder Film-/ Videomaterialen, die ihre Reiseziele näher beschreiben. |
| Internetnutzung | Marlene kauft regelmäßig im Internet ein, wie zum Beispiel Elektrogeräte oder Konsumartikel. Sie hat in mehreren Portalen eigene Accounts, und ist mit Zahlvorgängen vertraut. Im Internet benutzt sie gerne die Suchfunktion |
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
