Personas im Produktmanagement

Author
Foto von Sohrab Salimi
Sohrab Salimi

Lesezeit
6 Minuten

Beim Produktmanagement geht es um Entscheidungen. Entscheidungen darüber, welche Gelegenheiten man ergreifen sollte, welche Probleme es wert sind, gelöst zu werden, welche Features den meisten Wert liefern werden, was die besten Kompromisse im Hinblick auf die Markteinführungszeit sind und welche Kunden die wichtigsten sind. Auch wenn man nie zu 100% die richtigen Entscheidungen treffen wird, sollte man bei den meisten Entscheidungen aber richtig liegen, damit das Produkt ein Erfolg werden kann.

Personas (User Profiles) als Tool

Eines meiner Lieblingstools bei schweren Entscheidungen sind Personas (auch User Profiles genannt). Für alle, die nicht wissen was Personas sind: eine Technik, um die wichtigsten Erkenntnisse aus Nutzer- und Kundeninterviews festzuhalten, zu identifizieren und zu verstehen, wer die verschiedenen Leute sind, die unser Produkt nutzen werden. Personas beschreiben einen imaginären aber äußerst plausiblen Nutzer und seine Merkmale – im Besonderen seine Verhaltensweisen, seine Ansichten und Überzeugungen sowie seine Ziele.

Dieses Tool wurde erstmalig 1998 in einem meiner Lieblingsbücher The Inmates are Running the Asylum von Alan Cooper erwähnt. Wenn Sie dieses Buch noch nicht gelesen haben, sollten Sie das nachholen. Es ist ein Klassiker für auf Produktmanager, Designer und Entwickler.

Personas in verschiedenen Bereichen

Es ist gut möglich, dass Ihre Designer bereits Personas in ihrem Designprozess verwenden. Die Design Community scheint diese Technik übernommen zu haben, da die meisten Designteams, die ich kennengelernt habe, mit diesem Tool arbeiten. Jedes Team hat seine eigenen Vorstellungen, was gute Personas ausmacht und wie förmlich man bei der Erstellung vorgehen sollte, aber das ist meiner Meinung nach auch vollkommen in Ordnung.

Vielleicht arbeitet sogar schon Ihre Marketingabteilung mit Personas. Die Verwendung von Personas ist in beiden Fällen sehr ähnlich und sie sind beide sinnvoll, aber auch nicht vollkommen identisch, da sie für zwei ganz unterschiedliche Zwecke genutzt werden. Das Marketingteam möchte herausfinden, wie sie die Zielgruppe am besten erreichen und deren unterschwellige Emotionen ansprechen können. Die Designer interessieren sich eher für die Ziele der Nutzer und deren Online-Verhalten.

Für einen Produktmanager dürfte das besonders hilfreich sein.

Die richtige Nutzung von Personas

Aber obwohl dies ein sehr starkes Tool ist, werden Personas oft erst viel zu spät im Produktdefinierungs-/Discovery-Prozess eingesetzt, denn häufig sind es die Designer, die das alles vorantreiben, sie werden aber meistens viel zu spät in den Prozess einbezogen.

Um das wahre Potenzial von Personas nutzen zu können, müssen die Produktmanager stark in die Erstellung und Priorisierung der Personas und besonders auch in die dafür notwendigen Nutzerinterviews und Recherchearbeiten involviert sein. Die Erstellung der Personas sollte in Zusammenarbeit zwischen dem Produktmanager und dem Interaction Designer geschehen – und wenn Sie in der glücklichen Situation sind, eines zu haben – auch mit Ihrem User Research Team. Aber was Sie auch immer tun, delegieren Sie diese Aufgabe nicht. Aus dem gleichen Grund, aus dem der Produktmanager bei jedem Usability Test dabei sein muss, muss er auch bei jedem User Interview dabei sein. Der Produktmanager braucht nämlich ein tiefes Verständnis für die Zielgruppe, welches erst entsteht, wenn er mit so vielen Nutzern und Kunden wie möglich spricht.

Daher versuche ich, die Produktmanager dazu zu bringen, sich aktiv an der Erstellung der Personas zu beteiligen und sicherzustellen, dass sie so früh wie möglich im Laufe des Prozesses damit fertig werden.

Die Design Community hat schon so viel über Personas geschrieben, dass ich hier nicht alles wiederholen möchte. Jedoch möchte ich einige bestimmte Punkte erwähnen, da sie für Produktmanager besonders relevant sind.

Personas als Tool für das Produktmanagement haben einige Vorteile:

  •  Personas helfen einem, zu priorisieren, was wichtig ist. Wenn man sich beispielsweise dafür entschieden hat, „Mary” zum Ziel für dieses Release zu machen, und ein bestimmtes Feature für „Mary” wichtig ist, dann sollten sie es auch umsetzen. Wenn das Feature aber für „Sam” wäre, dann wird es nicht umgesetzt. Wie Sie sehen, ist es nicht nur wichtig, zu entscheiden, für wen dieses Release gedacht ist, sondern auch für wen es eben nicht gedacht ist. Es ist ein weit verbreiteter Fehler, mit einem Produkt alle und jeden zufriedenstellen zu wollen und am Ende niemanden zufriedenzustellen. Dieser Prozess kann helfen, genau das zu vermeiden.

  • Einer der häufigsten Fehler von Produktteams ist es, sich mit den Kunden zu verwechseln. Über dieses Thema habe ich bereits geschrieben, aber was ich an Personas wirklich gut finde, ist die Tatsache, dass sie uns helfen, dieses weit verbreitete Problem in Angriff zu nehmen.

  • Die meisten Produkte haben verschiedenste Nutzer – unterschiedliche Endnutzer, Manager, Administratoren usw. und schnell geht man davon aus, dass man einfach nur für all diese Personen ein paar Features umsetzen muss, was aber nur wieder in einem riesigen Durcheinander endet. Zum Teil ist das ein Designproblem, Personas können einem aber auch dabei helfen, die Wichtigkeit dieser verschiedenen Nutzer zu priorisieren und herauszufinden, an welcher Stelle man vielleicht eine separate User Experience benötigt.

  • Personas sind wirklich gut dafür geeignet, dem gesamten Produktteam zu erklären, für wen das Produkt gedacht ist, wie diese Nutzer das Produkt nutzen werden und warum es ihnen wichtig ist.

  • Ganz grundsätzlich haben Personas (wie die Manifest- /Produktprinzipien) den großen Vorteil, das Team um eine gemeinsame Vision herum zu versammeln. Es gibt im wahrsten Sinne des Wortes tausende Details, die auf dem Weg zum Produkt Release geklärt werden müssen. Der Produktmanager (oder Designer) kann unmöglich alle davon umsetzen. Wenn alle Manager, Designer, Entwickler, Tester usw. die Produktprinzipien und Personas wirklich verinnerlicht haben, können sie viel eher die richtige Entscheidung treffen, wenn sie mit einer offenen Frage konfrontiert werden.

Tücken bei Personas, auf die man achten sollte

  • Einige Teams erstellen zwar Personas, machen aber nicht den nächsten Schritt, nämlich die schwere Entscheidung zu treffen, welche Personas Priorität haben. Es ist nicht gut, zu sagen, dass ein Produkt für alle gedacht ist. Damit machen Sie sich selbst etwas vor. Auch wenn das für die meisten Produktmanager extrem schwer ist, versuche ich wirklich, die Produktmanager dazu zu bewegen, jedes Release auf eine einzige Persona auszurichten. Es ist nicht so als könne dieses Release nicht auch anderen Leuten einen Nutzen bringen, Ihr Fokus sollte aber eine gute Arbeit für diesen einen speziellen Typ von Nutzer sein.

  • Manchmal erstellen Teams Personas aufgrund von Annahmen und Stereotypen bezüglich der Nutzer, nehmen sich aber nicht die Zeit, sich mit echten Nutzern zu unterhalten und zu verifizieren, ob diese theoretischen Nutzer tatsächlich existieren. Ich habe dabei schon oft eine Überraschung erlebt. Und zwar so oft, dass ich gelernt habe, dass ich meine ersten Eindrücke lediglich als Theorie nehmen sollte und mir erst eine richtige Meinung bilden sollte, wenn ich tatsächlich mit den Nutzern gesprochen habe.

  • Eine häufige Frage ist, ob man seine Prototypen nur von den Hauptpersonas testen lassen sollte. Natürlich sollten Sie sicherstellen, dass Ihr Produkt ein großartiges Produkt für diejenigen ist, für die es gedacht ist. Allerdings sollten Sie auch einige Leute außerhalb der wichtigsten Personas testen lassen, da Sie wahrscheinlich nicht das Glück haben werden, dass nur genau diese Leute Ihr Produkt nutzen werden. Für das Testen von Prototypen sollten Sie also immer eine ganze Reihe von möglichen Nutzern zur Verfügung haben.

Wenn Sie es nicht schon getan haben, sollten Sie darüber nachdenken, eine Persona zu erstellen, die einen typischen Nutzer Ihrer Hauptzielgruppe für Ihr nächstes Release beschreibt, und dann überlegen, ob Ihnen dieses Tool nicht vielleicht helfen kann, all die schwierigen Entscheidungen zu fällen.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.

Nichtfunktionale Anforderungen

=> Wie setzt du nichtfunktionale Anforderungen als User Stories um?

Wettbewerbsvorteil Zeit

=> Wie verschafft dir Scrum einen Wettbewerbsvorteil?

Product Owner Rolle & Zertifizierung

Erfahre mehr über die Rolle vom Product Owner und lass dich zertifizieren