Produktmanagement Lesetipps: Freemium-Modell, gegen Featuritis, Verwendung von abgeschlossenen Tickets

glasses

Die Lesetipps von heute fassen mal wieder ganz kompakt ein paar Blogartikel über wesentliche Themen des Produktmanagements von Internetanwendungen zusammen, deren Lektüre lohnenswert ist.

Wie ein Freemium-Modell nicht aufgezogen werden sollte

Auf dem Blog Rogueleaderr gibt es eine interessante Analyse zum Thema „Freemium“. Der Autor kommt zu dem Schluss, dass die meisten Freemium-Angebote falsch gestrickt sind.

„But in a surprising number of cases, I’m not upgrading because the startup is using a freemium model that just doesn’t make sense.

My basic contention in this post is that in many freemium startups, the free product is the real product and the “pro” product is just a bunch of random tacked-on features that might appeal to power users. Instead, startups should remember that the premium product is the real product, and the free version is just a conduit to make people aware that paying money will actually solve their problem.“

You’re Doing Freemium Wrong

Gegen die Featuritis

Im Blog von Kissmetrics gibt es einen kleinen Reminder daran, dass mehr Features nicht zu einem erfolgreicheren Produkt führen, sondern ein gut gemachtes Produkt, das einen klar erkennbaren Nutzen stiftet.

„Your product is designed to solve a problem. If you’re adding a feature that doesn’t contribute to the solution, you may be wasting your time and worsening your product in the process.“

Als gutes Beispiel dafür wird Dropbox angeführt, dass an seinem Kern-Produkt keine großen Veränderungen vorgenommen bzw. keine großen unnötigen Features realisiert hat. Weitere Beispiele umfassen Twitter, Instagramm und Foursquare. Ganz kompakt rübergebracht wird es in dem Satz:

„Randomly adding features without focus, direction, or vision is a recipe for failure.“

> Why More Features Doesn’t Mean More Success

Was tun mit erledigten Tickets?

Scrum- und Kanban-Teams arbeiten häufig mit analogen Boards, über die sie Papier-Tickets wandern lassen. Dabei fallen haufenweise Zettelchen an, die nach Abschluss der Arbeiten … ja was eigentlich? Arne Roock hat in einem Blogpost fünf Verwendungen für die abgeschlossenen Tickets dargelegt.

Darunter sind sehr wertvolle Ansätze wie die Verwendung zur Erstellung von Charts, wie etwa einem Burn-Down-Chart.

5 Ideas what to to with your done tickets

Foto: 0xMatheus

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz am 7. November 2013 in Wiesbaden

Produktmanagement Lesetipps: Gründen ohne technischen Co-Founder, Design Thinking, Reflective Thinking, Peer Reviews

Eine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um’s Gründen ohne technischen Co-Founder, um den Ansatz „Design Thinking“, etwas Zeit zum Reflektieren, sowie die Kraft von Peer Reviews. Viel Spaß beim Lesen!

  • Why you should stop looking for a technical co-founder – at least for now von Andreas Kwiatkowski kann all denjenigen Nicht-Techies Mut machen, die denken, ohne das Erlernen einer Programmiersprache oder einen technisch versierten Co-Founder ließe sich die eigene Idee nicht realisieren. Die ersten Artikel auf seinem Blog Kwiat.com sind sehr vielversprechend und machen ihn zu einem Lesetipp für alle Internet-Produktmanager.
  • Ahmet Emre Acar stellt bei Gründerszene in seinem Artikel „Die Welt des Design-Thinking“ die Grundlagen des Design Thinking-Ansatzes dar. Dieser Innovationsansatz stellt in den Vordergrund, Dinge mit dem Menschen im Fokus neu zu erschaffen.
  • Don’t be Too Busy to Do Some Reflective Thinking – Wer sich täglich einem Information Overload aussetzt, sollte von Zeit zu Zeit ganz bewusst zurücktreten und sich die Zeit für etwas Reflektion nehmen. Marty Zwilling gibt uns ein paar Tipps, wie wir dabei vorgehen können, ohne auf der anderen Seite in ein „over-thinking“ zu verfallen.
  • Sebastian Schneider betont in seinem Beitrag zu „Peer Reviews“ die Bedeutung einer frühen Feedbackschleife durch die direkten Kollegen, die sehr kostengünstig ist und eine zeitnahe Qualitätssicherung ermöglicht, die spätere teure Korrekturen meidet.

Foto: 0xMatheus

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

Produktmanagement Lesetipps: Architekturvision in Scrum, Top 10 Startup-Erfolgsregeln, Kundenfeedback, Kostenplanung in agilen Projekten

Die Produktmanagement Lesetipps enthalten diesmal eine Mischung aus Beiträgen zu agiler Softwareentwicklung, Startup-Vermarktung und der Nutzung von Kunden-Feedback. Viel Spaß dabei! Falls Ihr in letzter Zeit einen spannenden Artikel aus diesem Themenbereich gefunden habt, teilt es doch über einen Kommentar mit.

Die Architekturvision in Scrum

Auch wenn ein Team nach den Leitsätzen und Prinzipien der agilen Softwareentwicklung arbeitet, ist eine initiale Architekturvorstellung wichtig, um nicht ständig alles umbauen zu müssen. Sie muss aber Raum lassen, um inkrementell von Sprint zu Sprint weiterentwickelt werden zu können.
Stefan Roock und Roman Pichler stellen in einem Artikel das Konzept der Architekturvision vor und beschreiben Kriterien und Techniken für ihre Erstellung: „Die Architekturvision in Scrum: Vorausplanung und emergentes Design balancieren“. Er kann als PDF heruntergeladen werden.

Richtig groß rauskommen

Reid Hoffman, Co-Founder und Vorsitzender von LinkedIn hat auf Greylockvc.com 10 Regeln für Gründer veröffentlicht, zu denen er beim diesjährigen South by Southwest vorgetragen hat.
t3n hat diese 10 Regeln wie man richtig groß rauskommt auf deutsch übersetzt. In seiner 10. Regel stellt Hoffman selbst klar, dass solche Regeln nicht als Naturgesetz, sondern als Richtlinie verstanden werden sollten. Wenn man den Erfolg von Hoffman bedenkt, der neben der Mit-Gründung von LinkedIn und PayPal auch in Facebook, Flickr und Zynga investiert hat, lohnt es sich, sich ein paar Minuten Zeit für seine Erkenntnisse zu nehmen.

Warum Kundenfeedback wichtig ist

Evan Hamilton, Community Manager des Kunden Engagement Tools Uservoice, stellt seine Präsentation vom Online Community Meetup in San Francisco zur Verfügung.
Darin präsentiert er, warum Kundenfeedback so wichtig ist, wie es erhalten und gesammelt werden kann. Er gibt auch einen kleinen Einblick, wie am besten mit Kundenwünschen umgegangen wird, gegen deren Umsetzung sich das Unternehmen entscheiden hat.

Kostenplanung in agilen Projekten

Bei Scrumology schreibt Kane über die Kostenplanung in agilen Projekten. Sein zentraler Punkt: Kostenplanung wird durch agile Softwareentwicklung unglaublich viel einfacher.

There are two important facts about Agile projects that I need to make clear before I continue.

  • Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.
  • Agile teams are dedicated for the duration of the project. At the risk of repeating myself, this means that everyone (Analysts, Developers, Testers etc) are 100% allocated to the project for the entire duration of the project.
    • Given these two ideas, it should now be obvious how to cost an Agile project. We have static team compositions and the team is dedicated 100% of the time, so there is a fixed cost for the team per day.

Mit einer Beschätzung durch das Team und das Abschätzen der benötigten Sprints kann somit eine wesentlich bessere Schätzung abgegeben werden als in Projekten, bei denen zahlreiche Übergabepunkte mit einem Wechsel der beteiligten Personen bestehen.

Weitere Ausgaben der Produktmanagement Lesetipps:

%d Bloggern gefällt das: