Nutzer involvieren

Nutzer involvieren

Im gerade stattfindenden Product Owner Barcamp hat ein Teilnehmer die Frage aufgeworfen, ob und wie Nutzer stärker in die Entwicklung von Produkten involviert werden können. “Review 4 Real – in touch with true customers” war der Titel. Aufhänger war das Scrum Review Meeting und die Frage, ob und wie Nutzer einbezogen werden.

Nach einer kurzen gemeinsamen Herleitung, was Stakeholder in einem Vorhaben sind und dass es einen Unterschied zwischen dem Kunden (Zahler) und dem Nutzer (intern und extern) gibt, haben wir unterschiedliche Ideen gesammelt, die für eine hohe Einbeziehung des Nutzers sorgen können.

Wichtige Erkenntnis für mich auch hier: Individuen und Interaktionen sind wichtiger als Prozesse und Tools. Der Berg kommt nicht zum Propheten. Dass wir den Nutzer einbeziehen wollen, ist unser Interesse um ein möglichst erfolgreiches Produkt zu haben und einen wirklichen Mehrwert zu stiften. Wir versuchen Probleme von Nutzer zu lösen, manchmal welche, die Nutzer noch gar nicht formulieren können. Wir müssen Nutzern einen Mehrwert bieten (und das kann auch das Privileg sein, zu einer Gruppe zu hören, die das Produkt vor anderen bekommt), damit sie sich einbringen. Außerdem müssen wir zu den Kunden gehen und können/brauchen gerade im Business to Consumer Geschäft nicht erwarten, dass die Kunden zu uns in ein zweiwöchiges Reviewmeeting gehen.

Machen

Aus meiner eigenen Sicht scheitert es nicht an guten Ideen und Formaten – weiter unten führe ich ein paar Ideen auf, die in der Session des Barcamps vorgestellt wurden. Es scheitert häufig schlicht am “Machen” aus Angst, man könne einen Nutzer verprellen, oder man bekäme nicht ausreichend oder “richtiges” Feedback. Manchmal werden auch mögliche Kosten gescheut oder es fehlt an Ideen, wie man Nutzern einen Mehrwert für ihren Einsatz bieten kann. 

Wie heißt es so schön: Es gibt immer Gründe, etwas nicht zu tun. Oder: All sagten, das gehe nicht, bis einer kam, der das nicht wusste und der hat es dann gemacht. 

Was sind die Gründe, wieso ihr bei euch den Nutzer nicht aktiv einbezieht?

Echtes Verproben statt Testen

Häufig überlegen sich viele schlaue Menschen, wie sie Nutzer dazu bekommen können, ein neues Produkt, eine Erweiterung oder Veränderung zu testen. Der Beste weg dafür sind keine künstlich hergestellten Testszenarien, sondern ein Verproben im echten Betrieb. Dabei ist es eine Voraussetzung, dass die Verprobung für den Nutzer und den Unternehmer sicher abläuft. Auf einer solchen Grundlage sollte es das Ziel sein, das Produkt früh und regelmäßig in der echten Benutzung zu verproben und gute Feedback-Kanäle aufzubauen, über die Rückmeldungen wieder in die Weiterentwicklung fließen können.

Ein paar Ideen

Eine (nicht vollständige) Sammlung der Ideen aus der Session des Barcamps fasse ich hier mit ein paar Erklärungen zusammen. 

Hausmänner und -frauen-Test

Gerade bei Produkten für die “gesamte Bevölkerung” können Mitarbeiter innerhalb des Unternehmens als Nutzer einbezogen werden. Sie können in offene Vorstellungen des aktuellen Produktstandes frühzeitig eingebunden werden. 

Help Desk

Häufig gibt es für Produkte oder Anwendungen einen Kundendienst oder Help-Desk, der im täglichen Kontakt zum Kunden steht. Er kann direkt aus seinen Erfahrungen mit den Kunden berichten und viel Feedback unterschiedlicher Kunden konsolidieren.

Pizza-Testing

Menschen können über (zum Beispiel) soziale Netzwerke eingeladen werden, an Pizza-Testing Events teilzunehmen. Hier wird der aktuelle Stand eines Produkts an einem Abend vorgestellt und Kunden können das Produkt bei lockerer Atmosphäre ausprobieren und direkt Rückmeldung geben.

Beta-User

Beta-User lassen sich auf verschiedene Arten und Weisen einbeziehen. Idee ist einfach, eine eingeschränkt Nutzergruppe einzubeziehen – zum Beispiel indem man bei einer neuen Website nur einen Teil des Traffics auf eine neue Site zu lenken. Alternativ kann man eine Gruppe von Beta-Testern definieren und über einen geschützten Bereich das Produkt zur Nutzung anbieten.

100 Sekunden Video

Die wichtigen Änderungen an einem Produkt können in einem kurzen Video zusammengefasst und vorgestellt werden. Hier kann man auch Veränderungen vorstellen, die es noch nicht gibt um zu überprüfen, wie diese Veränderung von den Nutzern angenommen würde.

Beobachtung

Man kann das Verhalten von Nutzern auch beobachten in der Benutzung von Produkten – dazu muss man entweder zum Kunden gehen oder kann online Daten analysieren. Dabei ist es wichtig, die Beobachtungen immer im möglichst großen Gesamtkontext zu betrachten. 

Und wo bleibt das Team?

Bitte beim Ausprobieren obiger Ideen das Team nicht vergessen!

Sehr positiv habe ich erlebt, wenn die Menschen, die ein Produkt bauen, auch selbst in den Kontakt zum Nutzer ihres Produkts kommen. Dieser Austausch soll in Scrum durch das offene Review-Meeting gewährleistet werden. Nutzer lassen sich aber oft nicht in einen Sprint-Zyklus Prozess einzwängen.

Alle obigen Ideen lassen sich so anbieten und umsetzen, dass auch das für die Produktentwicklung verantwortliche Team involviert wird.

Vielen Dank an Daniel Benic, für die spannende Session im Product Owner Barcamp (Twitter-Feed), organisiert von Mayflower und ausgerichtet von der DB Systel GmbH unterstützt durch das Agile Enabler Team und dem Agile Roundtable

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert