Produktentwicklung auf die schlanke Art

Wie viele von den Funktionalitäten, die wir in Software einbauen, bringt unseren Anwendern wirklich einen Nutzen? Zu häufig wird diese Frage gar nicht gestellt. Woran liegt das?
Häufig scheint die Überzeugung zu sein, das viel auch viel hilft. Eine endlose Feature-Liste erscheint attraktiv. Genauer betrachtet stellen Features, die den Anwendern keinen echten Mehrwert liefern, eher einen Kostenpunkt dar. Sie müssen gewartet werden und erhöhen die Komplexität einer Software-Anwendung sowohl für die Anwender, als auch die Betreiber.

Der überzeugte Lean Startup-Anwender und Buchautor Ash Maurya berichtet in einem Blogpost darüber, wie er selbst vorgeht, um nur Features in seiner Software bereitzustellen, die auch wirklich einen Nutzen für einen Großteil der Anwender erzielen.

Sein „Framework“ hierfür besteht aus mehreren Elementen. Zu jeder Zeit wählt er einen zentralen Zielwert, der angestrebt werden soll. Beispielsweise die Quote von Neu-Anwendern, die für eine dauerhafte Nutzung der Software aktiviert werden kann. Zu jeder Zeit gibt es nur eine zentrale Zielsetzung, die mit den Feature-Entwicklungsbemühungen erreicht werden soll.

Auf dem Weg von Entwicklung bis dauerhafter Aufnahme einer Funktionalität in den Produktumfang durchläuft sie vier zentrale Schritte.
Die erste Stufe beginnt mit der Priorisierung des Backlogs. Da es einen zentralen Zielwert gibt, kann die Priorisierung nach dem Beitrag für diesen Zielwert, im Verhältnis zu den für die Realisierung anfallenden Kosten, erstellt werden.
Wenn die Priorisierung geklärt ist, wird als nächstes das Top-Item genommen und durch Kunden-Interviews abgeklärt, wo genau das dahinter liegende Problem liegt. Es geht an dieser Stelle nicht darum, was die Kunden wünschen. Vielmehr geht es darum, warum sie etwas wünschen. Ausgehend von den Rückmeldungen der Kunden wird dann entschieden, ob etwas gemacht wird oder der Feature-Wunsch verworfen wird.

In der zweiten Stufe wird dann entschieden, wie das Feature umgesetzt werden soll. Es werfen hierfür erste Screens gestaltet und dann mit den Kunden, die auch interviewed wurden, dazu befragt. Es werden dann üblicherweise mehrere Iterationen durchlaufen, bevor eine Umsetzung angedacht wird.

Die Funktionalität wird dann in einem Continous Deployment-Prozess realisiert. Mit Hilfe eines Feature Flipper Systems kann dafür gesorgt werden, dass die Features auf das Live-System eingespielt werden, ohne dass sie den Anwendern zugänglich sind, bis sie fertig sind. Nach Fertigstellung wird die Funktionalität einer selektierten Kundengruppe zur Verfügung gestellt und von denen ein qualitatives Feedback eingeholt. Wenn dabei Fehler auftreten oder das Feedback negativ ausfällt, können noch vor einem größeren Roll-out Korrekturen vorgenommen werden.

Es folgt die vierte Stufe, wenn das qualitative Feedback zufriedenstellend war bzw. Nachbesserungen erfolgt sind. Die Funktionalität wird allen Anwendern zur Verfügung gestellt und quantitative Metriken gesammelt. Während die Messungen laufen, wird mit der Arbeit an der nächsten Funktionalität gestartet, denn meist dauert die Erhebung der metriken etwas. Dann folgt eine Auswertung der Zahlen.
Die Kombination von qualitativem Feedback und quantitativen Metriken sorgt für eine gute Entscheidungsgrundlage. Nur, wenn die Funktionalität sich als förderlich für den zentralen Zielwert herausstellt, wird es dauerhaft in der Anwendung belassen. Ansonsten fliegt es konsequent raus.

Die folgende Präsentation stellt das Vorgehen von Ash Maurya dar:

How We Build Features

View more presentations from ashmaurya

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

Anwenderbetreuung mit den richtigen Tools unterstützen

Anwenderbetreuung Für Internetportale, die es mit einer breiten Nutzerschaft zu tun haben, stellt sich die Frage, wie sie die Anwenderbetreuung optimal organisieren. Es gibt eine Reihe von Tools, die dabei unterstützen können, diese Prozesse effektiv und effizient abzubilden. Eine Auswahl davon stelle ich in einem aktuellen Beitrag „Fünf Tools für Nutzerbetreuung“ bei Gründerszene vor: CoTweet zur gemeinsamen Verwaltung von Twitter-Accounts, UserVoice für die Sammlung und Bewertung von Feature-Wünschen durch die Anwender, SnapEngage für Live-Chats mit Website-Besuchern, MailChimp für den Versand von Newslettern und OTRS für die strukturierte Verarbeitung von Mail-Anfragen.

Zum Artikel bei Gründerszene

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: tyle_r

Die Nutzerloyalität auf einfache Weise ermitteln

Einfachheit ist vielfach Trumpf. „Einfache Pläne, die ausgeführt werden, sind besser als komplexe Pläne, die noch in Planung sind“, sagt Chris Brogan. So ähnlich verhält es sich meines Erachtens auch bei der Ermittlung von Kennzahlen für Startups. Kennzahlen zu erheben und die eigenen Entscheidungen durch Zahlen zu unterstützen ist wichtig und richtig. Kleine Unternehmen verfügen (meist) aber nicht über eigene Fachkräfte, die sich mit der Erhebung komplexer Kennzahlen beschäftigen können, noch über die finanziellen Ressourcen, diese Leistung einzukaufen.
Bei Deutsche Startups habe ich in einem Artikel vorgestellt, wie Startups mit Hilfe des Net Promoter Scores auf einfache Art und Weise eine Kennzahl für den entscheidenden Performance Indicator Nutzerloyalität erheben können.

Zum Artikel bei Deutsche Startups

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Photo: Joe Pemberton

Userstories: Volle Konzentration auf den Kundennutzen

Ein zentraler Vorteil der Verwendung von Userstories für die Beschreibung von Anforderungen ist es, den Kundennutzen stark in den Vordergrund zu stellen. Wofür wird eine Funktion eigentlich entwickelt? Das sollte allen Beteiligten stets präsent sein.

Ein weiterer Vorteil von Userstories ist, dass Stories schreiben eine Übungssache ist und sich von jeder Person erlernen lässt. Vereinfacht wird der Einstieg in das Schreiben von Userstories durch Vorlagen für den Satzbau.
Bisher habe ich meist diese sehr gebräuchliche und verbreitete Vorlage für das Schreiben von Nutzerstories verwendet:

Als (Anwendertyp) möchte ich (folgende Aktion durchführen), um (dieses Ziel zu erreichen).

Für diesen Aufbau einer Userstory finden sich verschiedene Referenzen. Ich habe auch sehr gute Erfahrungen damit gemacht. Der große Fortschritt gegenüber vorher von uns verwendeten Arten der Anforderungsbeschreibung ist u.a. darin zu sehen, dass die Stories für jeden verständlich sind und der Kundennutzen klar ausgedrückt werden muss.

Aus einem Gespräch mit einem Kollegen und ScrumMaster habe ich lernen dürfen, dass eine leichte Modifikation des Aufbaus der Userstory dabei hilft, den Kundennutzen noch stärker in den Fokus zu rücken. Das sieht dann wie folgt aus:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Den Fokus auf den Kundennutzen zu richten ist wichtig und richtig. Daher werde ich zukünftig auch diese Vorlage verwenden.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: CannedTuna

User Stories: Anforderungen aus Nutzersicht dokumentieren

User Stories Für das Blog von //SEIBERT/MEDIA habe ich einen Artikel über User Stories geschrieben: User Stories: Anforderungen aus Nutzersicht dokumentieren.
Der Artikel erklärt, warum User Stories als Werkzeug zur Beschreibung von Anforderungen sinnvoll sind, mit welchem Gerüst sich User Stories einfach schreiben lassen, welche Kriterien eine gute User Story erfüllen muss und auch, was eine Story Card ist.

Zum Artikel im //SEIBERT/MEDIA Blog

 

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von psd

Gastbeitrag bei deutsche-startups: Wie Start-ups Nutzer zu aktivem Feedback motivieren können

NutzerintegrationFür Startups ist das Feedback der Nutzer unheimlich wichtig für die Produktentwicklung. Aber wie motiviert man die Nutzer dazu, auch wirklich Feedback zu geben? Zu dieser Fragestellung ist heute ein Gastbeitrag von mir bei deutsche-startups erschienen. Er basiert (wie auch mein letzter Gastbeitrag bei Gründerszene) auf unseren Erfahrungen aus der Entwicklung von TwentyFeet.

Zum Artikel bei deutsche-startups

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von hikingartist

Wie können Personas das Produktmanagement unterstützen?

Personas sind eine verhältnismäßig einfache Möglichkeit, um die Nutzer einer Internetanwendung im Entwicklungsprozess der Software im Fokus zu halten. Sie helfen dabei, die heterogene Zielgruppe gedanklich zu strukturieren. Für die verschiedenen Nutzergruppen werden Prototypen gebildet, deren Einstellungen, Fähigkeiten und Ziele in Entscheidungen einfließen kann.

Die brainmates aus Australien haben jetzt eine Präsentation und ein Whitepaper herausgegeben, die auf die Frage eingehen, wie Personas das Produktmanagement unterstützen können.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: