Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
In →Iterations: The Harsh Realities Of iOS App Distribution spricht Semil Shah das Problem von Produkten an, die sich im Longtail befinden, und benutzt hierfür den Apple App Shop als Beispiel.
Er stellt sich eine Frage, die anscheinend viele Entwickler betrifft – es gibt inzwischen teilweise mehrere relativ ähnliche Lösungen (Apps) für einzelne Probleme, wie schafft man es trotzdem, als einzelner Anbieter, auf größere Downloadzahlen zu kommen?
Letztendlich stellt er sich die Frage: Welche Strategien helfen, wenn sich mein Produkt im Longtail befindet?
Auch ich werde – wie dieser Autor – die Frage nicht abschliessend klären. Zusammen mit den Überlegungen im obigen Artikel wird das Bild aber ggfs. etwas runder.
Doch zunächst zur Definition des Begriffs.
Wikipedia (siehe Weiterführende Informationen am Artikelende) verdeutlicht den Begriff mit folgendem Beispiel, und zeigt dabei eine Kurve, die sich schnell abflacht:
„The Long Tail“, hier gelb eingefärbt, ähnelt einem langen Schwanz. Auf der Y-Achse ist die Anzahl der Verkäufe und auf der X-Achse sind die Produkte nach Reihenfolge ihrer Verkaufsstatistik aufgelistet. Beide Flächen sind gleich groß.
Der Begriff des Longtail taucht ursprünglich als Strategie auf (siehe Weiterführende Informationen am Artikelende) – manche (techniklastige) Geschäftsmodelle funktionieren dadurch, daß man viele Produkte anbietet, jedoch immer nur sehr wenige aus der einzelnen Reihe verkauft. Man arbeitet also bewußt in dem Bereich rechts in der Kurve.
Diese Strategie funktioniert dort, wo es keine/geringe Kosten gibt, die durch einen zusätzliche Verkauf entstehen (z.B. sind die Kosten aus Verkäufersicht für den Musikdownload unabhängig von der Menge, d.h ein Lied 100 mal verkaufen, kostet dasselbe, wie 100 Lieder ein mal).
Der obige Autor beschreibt sein Problem wie folgt, und benennt das Verteilungs- und Reichweitenproblem als das größte Problem:
Over the past few months, I’ve been exposed to and tested many exciting mobile concepts, and on the few occasions where I saw a product and could envision a long future with it living on my phone, I got tripped up on one recurring question: “Great, but how can this app imprint on millions of phones, not just a few hundred thousand? And if it does breakout, what’s the plan to have the app provide value on a daily basis, or close to it?” What was most frustrating is that, in these few cases I could easily envision a future where nearly every iOS customer would use these apps and they would provide great value, but it was both sad and scary to think that the first hurdle — distribution — may be the highest.
Hinter einem Markt, wie ihn der App Store bildet, steht sicher mehr als ein Geschäftsmodell – mann kann daher nicht davon ausgehen, daß es „die“ Strategie gibt.
Beispielsweise gibt es Firmen, die eine App als Ergänzung zu einem Produkt anbieten, und andere, für die die App das Hauptgeschäft darstellen. Aus Anwenderperspektive beobachte ich immer mal wieder Optimierungspotential gerade bei der letztgenannten Gruppe.
Manche Anwendung ist zu wenig fokussiert. Es fällt schwer, herauszufinden, was die App macht, und was sie nicht leistet, ohne, daß man diese Anwendung installiert, und testet.
Selbst wenn man sich als Anwender zunächst einmal im Netz auf die Informationssuche begibt, findet man nur wenige Informationen, die einem den Test ersparen würden.
Diese Art von Problemen lassen sich dadurch angehen, daß man sich als Entwickler nicht nur um die Entwicklung kümmert, sondern eben auch um die Bereitstellung von Informationen zu der Problemlösung.
Auch ist hilfreich, daß man die Anwendung funktional so fokussiert, daß sie dem Nutzer als konkrete Problemlösung zu einer realen Aufgabe erscheint.
Anwender nehmen sich, wenn überhaupt, Zeit, eine Anwendung zu testen, wenn die Anwendung mindestens die folgenden Anforderungen erfüllt:
Um hier zu optimieren, sollte man alles dafür tun, daß die Anwendung immer mal wieder in den Fokus gerät. Beliebt hierbei sind zum Beispiel Änderungen beim Preis, oder regelmäßige Blogbeiträge, einfach, um den Aggregatoren von Nachrichten einen Trigger zu geben.
Eine weitere Möglichkeit ist es kostenlose Varianten anzubieten, und eine kostenpflichtige Version, die mehr leistet.
Wenn Erfahrungen aus den Zugriffszahlen zu meinen Blogs allgemeingültig sind, zeigen diese, daß man nicht erwarten sollte, daß Zugriffszahlen sprunghaft steigen. Vielmehr muß man regelmäßig aktiv sein, um mit kontinuierlich wachsenden Nutzerzahlen belohnt zu werden.
Als Entwickler sollte man sich eine längere Zeitspanne nehmen über die man die Bekanntheit steigert, und man sollte hierfür auch die Kapazität haben, dies zu tun. Dies bedeutet natürlich auch, daß man sein Entwicklungsprojekt entsprechend plant.
Unterstützend, könnte man auch die App eine zeitlang verschenken, nur, um an Nutzer zu kommen, und erst später auf ein Bezahlmodell umschwenken.
Jede Anwendung erzeugt Daten, und je mehr Daten man erfaßt hat, desto unflexibler wird man, und desto weniger ist es sinnvoll, die App zu wechseln (und umgekehrt).
Um hier sein Angebot zu fokussieren, kann man entweder selbst offene Clouddienste anbieten, die man mit unterschiedlichen Anwendungen nutzen kann, oder man hängt sich an eine bestehende Cloud an, und nutzt deren Schnittstelle.
In der Cloud werden die Daten zentral abgelegt, und der Nutzer kann diese Daten auch dann weiternutzen, wenn er die Anwendung wechselt. So vorbereitet kann es einem zumindest theoretisch überhaupt erst gelingen, Anwender zum Wechsel zu bewegen.
Nur wenige Anwender nutzen eine App aus Spass. Vielmehr soll eine App eine konkrete Aufgabenstellung lösen.
Es gibt Anwendungen, bei denen man erkennt, daß der Entwickler verstanden hat, welche Aufgabe sich dem Nutzer stellt. Es gibt aber auch Anwendungen, wo dies nicht der Fall ist.
Anwendungen der ersten Kategorie verteilen sich einfacher, als die letztgenannten Anwendungen. User Centric Development ist die richtige Antwort, um hier zu optimieren.
Eine App sobald entwickelt und publiziert, läßt sich ohne großen Mehraufwand verteilen. Dabei ist es (relativ) egal ob 100 oder 1000 fach.
Dies bedeutet, daß man die Anwendung möglichst konkret für den Anwendungsfall gestalten sollte und ggfs auf unterschiedlichen Plattformen anbieten.
Für einen neuen Anwendungsfall würde man eher eine zweite App anbieten, als die erste zu erweitern. Oder man nutzt neue Programmiermodelle wie z.B. HTML5, daß sich (ohne App) mit jedem Browser öffnen läßt.
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:
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
