Diese Woche hatte ich ein interessantes Gespräch mit einem meiner Product Owner. Es ging darum, wie wir mit den Anforderungen unserer Nutzer umgehen – und wie leicht man der Versuchung verfällt, diese einfach 1:1 umzusetzen, ohne den eigentlichen Mehrwert wirklich zu hinterfragen.
Es gibt ein Beispiel, das ich in solchen Gesprächen immer wieder bringe. Es ist schon eine Weile her, aber es illustriert das Thema so schön greifbar.
Ein Anwender hatte damals den Wunsch geäußert, in einem Excel-Export eine weitere Spalte zu bekommen – die Umsatzsteuer zur jeweiligen Rechnung. Klingt nach einer einfachen Anforderung, oder? Eine zusätzliche Spalte im Excel, sollte schnell gemacht sein.
Und genau das ist passiert: Das Excel wurde erweitert. Anforderung erfüllt, Haken dran.
Was wir dabei nicht gemacht haben: Nachfragen. Warum brauchst Du diese Spalte eigentlich? Was willst Du damit machen?
Hätten wir das getan, hätten wir herausgefunden, dass der Anwender eigentlich gar kein Excel mit einer zusätzlichen Spalte wollte. Er wollte wissen, bei welchen Rechnungen die Umsatzsteuer vom Rechnungssteller fehlerhaft berechnet wurde. Das war sein eigentliches Problem.
Die Lösung war also nicht, das Excel zu erweitern. Die Lösung war ein Warnmechanismus, der solche Fehler frühzeitig erkennt, die Verarbeitung verhindert und meldet.
Zwei völlig unterschiedliche Lösungsansätze für dasselbe ursprüngliche Problem.
Zurück zu dieser Woche. Im Gespräch mit meinem PO ging es genau darum: Diesen Blick zu schärfen. Nicht nur die Anforderung entgegenzunehmen, sondern dahinter zu schauen.
Meine Aussage war sinngemäß: “Hinterfrage immer die Anforderungen und versuche den tatsächlichen Mehrwert zu finden.”
Ich denke dabei oft an das Value Proposition Canvas und die Kategorien, die dort verwendet werden: Pain Relievers und Gain Creators. Was ist der eigentliche Schmerz, den wir lindern? Oder welchen Gewinn wollen wir schaffen?
Im Excel-Beispiel war der Schmerz nicht “Ich habe zu wenig Spalten in meinem Excel”. Der Schmerz war: “Ich erkenne fehlerhafte Rechnungen zu spät oder gar nicht, und das verursacht Mehraufwand und Ärger.”
Lustigerweise bin ich kurz nach diesem Gespräch über ein altes Video mit Steve Jobs gestolpert. Er spricht dort darüber, wie man Produkte entwickeln sollte – und eine Aussage ist mir besonders hängen geblieben:
“You’ve gotta start with the customer experience and work backwards to the technology.”
Das ist im Grunde genau das, worüber wir gesprochen hatten. Nicht von der Technologie oder der oberflächlichen Anforderung ausgehen, sondern vom Erlebnis des Kunden, von seinem Problem.
Und wenn man es so betrachtet: Was ist die “Customer Experience” im Excel-Fall? Es ist nicht “Ich möchte eine Spalte im Excel sehen”. Es ist “Ich möchte fehlerhafte Rechnungen schnell und zuverlässig erkennen, ohne dass ich mir einen Wolf suchen muss.”
Von dort ausgehend landet man dann bei ganz anderen Lösungen als bei einer zusätzlichen Excel-Spalte.
Wie das meinen Blick verändert
Was sich für mich geändert hat, seit ich öfter mit dieser Perspektive arbeite: Ich stelle mehr Fragen. “Warum brauchst Du das?” “Was willst Du damit erreichen?” “Was ist das eigentliche Problem?”
Das fühlt sich anfangs vielleicht wie mehr Aufwand an – ein weiteres Meeting, noch eine Rückfrage. Aber in der Praxis spart es oft massiv Zeit und Energie, weil man nicht die falsche Lösung baut.
Und manchmal – nicht immer, aber manchmal – stellt man fest, dass die ursprüngliche Anforderung genau richtig war. Aber selbst dann hat man etwas gewonnen: Man versteht den Kontext und kann die Lösung entsprechend gestalten.