Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In dem folgenden Artikel geht es darum, welche Taktiken neue Firmen anwenden können, um tolle Produkte zu bauen: →7 tactics lean startups need to build great products.
Darunter sind ein paar sehr brauchbare Tipps. Jedoch fehlt der eine oder andere Aspekt. Andere Vorschläge aus dem Artikel würde ich so nicht nutzen wollen.
Bevor ich zu weitern Vorschlägen komme, will ich zunächst meine Erfahrungen mit den vorgeschlagenen Taktiken beisteuern.
Die folgenden Taktiken werden im Artikel angesprochen:
Der Vorschlag, Modelle zu benutzen (mit oder ohne Daten), klappt meiner Erfahrung nach sehr gut. Ich würde allerdings nicht so weit gehen, zu fordern, daß die Modelle, die man Kunden vorlegt, immer funktionsfähig sein müssen – insbesondere dann, wenn die Modellerzeugung viel Arbeit erzeugen würde.
Um grobe Konzepte mit Kunden zu besprechen, reichen oft sogenannte „Papiercomputer“, also Skizzen, Ablaufmodelle, und einfache Beispiele. Diese umgehen auch das generelle Problem eines komplexeren Models: man kann sie einfach wegwerfen, wenn sie nichts taugen.
Wenn man allerdings Software besitzt, die einem dabei hilft, mit einfachen Mitteln Modelle zu programmieren, ist dagegen natürlich nichts zu einzuwenden, wenn man etwas mehr Zeit investiert, und ein besseres Modell dafür erhält.
Neulich habe ich mir zum Beispiel die iPad App Adobe Proto näher angesehen. Mit Hilfe dieser App kann man Wire Frames mit der Hand zeichnen, und das Ergebnis anschließend in ein lesbares Format umwandeln. Zusammen mit Adobe Dreamweaver kann man hieraus sogar relativ schnell Prototypen von Webseiten erstellen.
Kundeninterviews und auch Kurzbefragungen sind eigentlich unabdingbar. Allerdings sollte man meiner Meinung nach in diesen Befragungen nicht den Fehler machen, daß man versucht, Kunden konkret zu fragen, wie sie sich eine bestimmte Applikation vorstellen.
Oft wissen Kunden wirklich nicht was sie wollen, und zudem engt man sich gedanklich zu vorschnell ein (die optimale Lösung könnte ja auch ganz anders aussehen, als die Vorstellung des Kunden).
Vielmehr sollten solche Interviews eher dazu dienen, daß man versteht, wie ein Kunde arbeitet und warum er genau so arbeitet, wie er es tut. Das User-Story Mapping ist eine Methode, die diese Sicht unterstützt.
Ob die Idee mit den Fake Doors (Testfunktionen im Produkt) immer funktioniert, wage ich zu bezweifeln. Es mag Einzelfälle geben wo diese Methode, unfertige Funktionen einzubauen, sinnvoll ist, um mit diesen die eigentlichen Erwartungen der Nutzer festzustellen.
Wenn man unfertige Produkte ausliefert, hat man jedoch normalerweise eher das Problem, daß Kunden deshalb unzufrieden werden, weil ein Produkt nicht das tut was es soll, d.h. die Methode kann auch auf das Entwicklungsteam zurückfallen.
Wenn überhaupt, würde ich Ihnen dazu raten, die Methode der Fake Doors nur dann zu verwenden, wenn die Kunden wissen, daß es sich um ein unfertiges Beta-Produkt handelt.
Ich persönlich halte nicht viel davon, daß man sich allzu intensiv mit Wettbewerberprodukten beschäftigt.
Auf der einen Seite könnten wettbewerbsrechtliche Regeln dagegen sprechen. Und, was noch viel schwerer wiegt, man könnte sich viel zu früh auf eine „schlechte“ Lösung versteifen.
Dies bedeutet nicht, dass Wettbewerberprodukte generell schlecht sind. Aber, man sollte sich immer vor Augen halten, dass es sich ja hierbei auch nur um die Interpretation der Kundenbedürfnisse geht, auf die man es eigentlich abgesehen hat.
Sinnvoller ist es, direkt zu verstehen, wie der Kunde arbeitet und warum, d.h. sich genau anders herum an die Lösung heranzutasten, als über das Wettbewerbsprodukt.
Ich rate Ihnen daher: Sprechen Sie mit realen Kunden über reale Aufgaben, statt sich zu lange am Wettbewerb aufzuhalten.
Kundenbesuche sind ebenfalls unabdingbar, um eine vernünftige Software entwickeln zu können. Oft muss ein Entwicklungsteam einfach vor Ort sehen, wie Nutzer arbeiten, und sollte nicht aus falschverstandenem Ehrgeiz versuchen, die Kosten hierfür zu sparen.
Man sollte sich allerdings auch gleich klarmachen, daß Kundenbesuche Arbeit erfordern, und Zeit kosten.
Meiner Meinung nach fehlen in den Artikel mindestens zwei Methoden, die relativ gute Ergebnisse liefern:
Das Design Thinking ist eine komplette Methode, die ein Entwicklungsprojekt über alle Entwurfsphasen zwischen „Verstehen des Problems“ und „Implementation der Lösung“ begleitet.
Es würde jetzt zu weit führen, diese Methode im Detail zu besprechen. Wenn Sie mehr über die Methode wissen wollen, empfehle ich Ihnen einige meiner früheren Artikel zu lesen, oder sich generell die Literatur zum Thema zu beschaffen.
Mit folgenden Elementen innerhalb der Methode habe ich gute Erfahrungen gemacht.
In dieser Phase ist es u.a. sinnvoll, sich besonders extreme Nutzer zu suchen. Das sind solche Nutzer, die besonders komplizierte Anforderungen haben, und sogar schon dazu übergegangen sind, vorhandene Lösungen zu „customizen“ (Zum Beispiel wurde das Mountainbike ursprünglich von solchen extremen Usern entwickelt, und erst später industriell umgesetzt).
In dieser Phase habe ich besonders gute Erfahrungen mit Persona-Beschreibungen gemacht, sowie mit Storyboards und Storytelling als Methoden.
Personas sind idealisierte Nutzer, unter denen sich jeder etwas vorstellen kann. Storyboards, und Storytelling funktionieren wie die Märchen in der Kinderzeit; man nutzt allgemeinverständliche Geschichten, die beschreiben, welche Anwendungsszenarien einen Kunden bewegen.
Die bisher verwendet wurden Methoden funktionieren gut, um eine Lösung neu zu entwickeln. Sobald man eine erste Version ausgeliefert hat, muss man das Produkt weiterentwickeln und pflegen. Dies sollte man rechtzeitig vorbereiten.
Das Specification by Example ist eine Methode, die versucht, eine Klammer herzustellen zwischen den Geschäftszielen eines Nutzers und der endgültigen softwaretechnischen Umsetzung der Lösung in Form von Coding und Tests.
Üblicherweise beginnt man mit den Geschäftszielen, beschreibt dann User Stories und Use Cases. Hieraus leitet man sich Schlüsselbeispiele ab, und dokumentiert diese Szenarien in geeigneter Form. Die Beispiele werden dann in eine Lösung umgesetzt und, was besonders wichtig ist, man erstellt hierfür Unit Tests, die testen, inwieweit die erstellte Software funktioniert.
Beispiele, Implementation und Tests ermöglichen es einem dann mit Beginn der nächsten Erweiterungstufe das Acceptance Test Driven Development zu nutzen. Hierbei formuliert man für die nächste Erweiterung neue Akzeptanzkriterien, und entwickelt dann die Lösung, die hierzu passt.
Im Internet finden Sie weiterführende Artikel:
In meinem Blog finden Sie ebenfalls weiterführende Artikel:
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
