Personas sind für Personalization ungeeignet

Personas sind (nach IREB-Glossar) „fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.“ Die Verwendung von Personas gerade im Agilen Projektmanagement zur Ableitung der Anforderungen und zur Formulierung und Bewertung von User Stories ist populär. Dabei hatte ich allerdings auch schon in einem früheren Blogbeitrag auf auf Tücken dieser Vorgehenseise hingewiesen: Die Falle bei den Anforderungen.

Darüber hinaus hatte auch Frank Piller die Verwendung von Personas für die Hybride Wettbewerbsstrategie Mass Customization als nicht geeignet angesehen, da „A “persona of one” is turning the persona idea to its opposite“. Siehe dazu ausführlicher: Ist die Verwendung von Persona das Gegenteil von Mass Customization?

Neben dem Agilen Projektmanagement und Mass Customization haben sich auch Autoren mit Personas in Bezug zum Megatrend Mass Personalization befasst. Auch hier sieht man die Verwendung von Personas kritisch:

„Seit einiger Zeit „menschelt“ es in den Marketingabteilungen verstärkt. Anstelle von unanschaulichen Excel-Files mit ihren Tabellen und Diagrammen werden bei Präsentationen so genannte Personas zum Leben erweckt. Auch User Personas genannt. Einfach ausgedrückt dienen sie dazu, einen Zielkunden darzustellen.

Was Personas sind, darüber gehen die Meinungen in der Fachwelt auseinander. Die einen sprechen von fiktiven, aber realitätsnahen Nutzern, die anderen von prototypischen Kunden ihres Angebots – oder von archetypischen Nutzern. Zwar unterschiedlich bezeichnet, dienen sie einem einheitlichen Zweck: Sie repräsentieren Bedürfnisse einer Zielgruppe und machen es möglich, (mehr oder weniger) fundierte Entscheidungen bei der Entwicklung nutzerfreundlicher Produkte zu treffen. Von Beginn an.

Mass Personalization kann nicht realisiert werden, ohne die individuellen Nutzerbedürfnisse zu berücksichtigen. Die schlechte Nachricht: Personas sind nicht zu 100 Prozent zielführend und helfen bei personalisierten Produkten nicht weiter. Sie bieten nur eine Typisierung der Nutzer für Entwicklungszwecke und keine Personalisierung für die Produktion. Stattdessen wird ein parametrisiertes Profil benötigt, das mit dem individualisierten Fertigungsplan gematcht werden kann“ (Briehm/Dangelmeyer, in Krieg/Groß/Bauernhansl (2024) (Hrsg.)).

Es ist nicht ganz leicht, die feinen Unterschiede zu erkennen und daraus die richtigen Schlussfolgerungen zu ziehen. Daher ist es wichtig, sich zu informieren, und das aus erster Hand.

Im September 2026 haben Sie dazu auf der 12. MCP 2026 zu Mass Customization und Personalization die Möglichkeit. Die internationale Konferenz findet diesmal in Balatonfüred, Ungarn statt. Sprechen Sie mich bei Fragen bitte direkt an. Als Initiator der Konferenzreihe kann ich Ihnen gerne weitere Informationen geben.

Ist die Verwendung von Persona das Gegenteil von Mass Customization?

Gerade im Agilen Projektmanagement werden Anforderungen häufig für Persona formuliert. Diese sind nach dem IREB (International Requirements Engineering Board) fiktive Charaktere, mit deren Hilfe Werte für die User geschaffen werden sollen. Dieses Vorgehen erinnert an eine Art Segmentierung aus dem traditionellen Marketing.

Mass Customization auf der anderen Seite ist eine hybride Wettbewerbsstrategie, die individuelle Produkte und Dienstleistungen für jeden Abnehmer – also massenhaft – anbietet, bei Preisen, die denen der massenhaft produzierten Standardprodukten ähneln. Dabei ist der Konfigurator ein wichtiges Element, das passende Produkt in einem Fixed Solution Space (Definierter Lösungsraum) zu erstellen. Die dahinterliegende Idee eines „Market of One“ passt nicht so recht mit der Persona-Idee zusammen. Dazu habe ich folgendes gefunden:

„In many ways, a persona is the opposite of mass customization. It’s more traditional marketing thinking about how to deal with a larger number of segments. A “persona of one” is turning the persona idea to its opposite“ Piller, Frank T. and Euchner, James, Mass Customization in the Age of AI (June 07, 2024). Research-Technology Management, volume 67, issue 4, 2024 [10.1080/08956308.2024.2350919], Available at SSRN: https://ssrn.com/abstract=4887846.

In Zeiten von Künstlicher Intelligenz wird es immer mehr Möglichkeiten geben, Produkte und Dienstleistungen massenhaft zu individualisieren und zu personalisieren. Ob die Verwendung von Persona in solchen eher agil durchzuführenden Projekten dann noch angemessen ist, scheint fraglich zu sein. Siehe dazu auch 

Society 5.0 und Mass Customization

Freund, R. (2009): Kundenindividuelle Massenproduktion (Mass Customization). RKW Kompetenzzentrum, Faktenblatt 5/2009.

Wir sind dabei: 20 Jahre MCP-CE vom 24.-27.09.2024

Agiles Projektmanagement: Die Falle bei den Anforderungen

Gerade im agilen Umfeld geht es oft um den Begriff „Value“. Beim Agilen Projektmanagement, beispielsweise nach Scrum, werden die Anforderungen oft als User Stories aus der Perspektive fiktiver Charaktere (Persona) formuliert. Dabei kann es vorkommen, dass dabei nicht nur User, sondern auch weitere Stakeholder beachtet werden sollen. Das kann wiederum dazu führen, dass das Projekt mehr in Richtung des Wertes für interne Stakeholder „abdriftet“.

„Bei der agilen Herangehensweise an die Softwareentwicklung liegt das Hauptaugenmerk auf der Werthaltigkeit, welche die Lösung den Benutzern bieten soll („User Story“). Daher wird der Benutzer eines interaktiven Systems als primärer Stakeholder betrachtet. Dennoch besteht, vor allem in großen Organisationen, das Risiko, dass agile Teams oder Product Owner nicht mit den echten Nutzern in Kontakt sind. Die Personas werden hier möglicherweise von jemandem erdacht, der nur vorgibt, die Benutzer zu kennen! In einem solchen Kontext sind die Stakeholder der Organisation (Manager, Fachbereiche, Rechtsabteilungen, Marketing usw.) wesentlich präsenter und dominanter als der externe Endbenutzer. Seien Sie sich über diese Falle im Klaren: Bestehen Sie darauf, dass ein direkter Zugang zu Endbenutzern besteht, um eine angemessene Nutzerforschung durchführen und nach der Sprint-Lieferung direktes Feedback einholen zu können. Nur so können Sie Ihre Benutzer und deren Bedürfnisse wirklich kennenlernen“ (Brand et al. 2024).

Siehe dazu auch

Agiles Projektmanagement: Anforderungen auf verschiedenen Granularitätsebenen

Agiles Projektmanagement: Was zeichnet ein gutes Product Backlog aus, und wie kann man es steuern?

Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.

Planning Poker beim relativen Schätzen nutzen – analog oder auch online

In dem von uns entwickelten Blended Learning Lehrgang Projektmanager/in Agil (IHK) geht es selbstverständlich auch um das Scrum-Framework. Um dabei ein priorisiertes Backlog mit den Anforderungen zu erhalten, werden u.a. aus der Perspektive von fiktiven Charakteren (Personas) User Stories formuliert.

Diese werden dann relativ (nicht absolut) geschätzt. Relativ bedeutet hier, dass eine User Story als Referenz festgelegt wird.

Mit Hilfe der modifizierten Fibonacci-Reihe schätzen die Developer den jeweiligen Aufwand der verschiedenen User Stories ab, die für den nächsten Sprint vorgesehen sind – das geschieht im Sprint Planning in Abstimmung mit dem Product Owner und dem Scrum Master, bzw. auch mit anderen Stakeholdern.

Dieses Schätzen kann mit Planning Poker unterstützt werden. Wir haben uns dazu ein Kartenspiel mit unserem Logo herstellen lassen (siehe Abbildung). Der Aufwand der einzelnen User Stories kann dann mit Hilfe des Kartenspiels ermittelt werden. Darüber hinaus kann Planning Poker auf dieser Seite auch online gespielt werden.

Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen, die wir an verschiedenen Standorten anbieten. Informationen zu unseren Blended Learning Lehrgängen und zu aktuellen Terminen finden Sie auf unserer Lernplattform.