Agilität in der Entwicklung ist kein Rezept für erfolgreiche Produkte. Sie ist eine Zutat, mit der Produkte besser entwickelt werden können. Aber ob diese Produkte am Markt erfolgreich sind, entscheiden andere Faktoren.
Wie sieht eine agile Organisation, die ein Produkt entwickelt, in der Praxis oft aus? Es gibt ein Umsetzungsteam, oft auch als „Entwickler:innen“ bezeichnet. Dazu gibt es noch eine/n Product Owner:in und wenn das Unternehmen es mit der Agilität erst meint, auch eine/n Scrum Master:in. Dieses ganze Scrum-Team arbeitet in Intervallen, meist in zweiwöchigen Sprints. Am Anfang jedes Sprints wird geplant, am Ende gibt es ein Review mit dem/der PO und den Stakeholdern. Dann geht es weiter, der nächste Sprint. Dazwischen gibt es Releases des Produkts, die ihren Weg zu den Kunden finden.
So wird Monat für Monat ein Produkt agil weiterentwickelt. Bis es eingestellt wird, weil die Kunden es nicht annehmen. Was ist denn falsch gelaufen?
Kundenzentrierung ist ein weiter Begriff, oft ohne Wirkung
PO und Stakeholder betonen immer wieder, wie wichtig Kundenzentrierung ist und dass agiles Arbeiten ein frühzeitiges Nachsteuern und Umplanen ermöglicht. Im Gegensatz zum klassischen Wasserfallprojekt. Damit man nicht ein Produkt entwickelt, das die Kunden nicht wollen. Und jetzt wollen die Kunden das Produkt doch nicht. Warum?
Kundenorientierung ist die Lösung! Kunden so früh wie möglich in die Entwicklung einbeziehen, um nicht am Markt vorbei zu entwickeln. Stories durch Feedback verändern oder neu priorisieren. Was in der Theorie gut klingt, sieht in der Praxis anders aus. Oft wird ein MVP über Wochen oder gar Monate auf Basis der Vorstellungen der Stakeholder, nicht selten des Managements, entwickelt. Dann wird das MVP, eigentlich die Version 1.0, den Kunden präsentiert. Manchmal hat man Glück und die Kunden lieben das Produkt. Und manchmal können die Kunden mit dem Produkt nichts anfangen, zumindest würden sie nicht dafür bezahlen.
Die Gründe für das Scheitern des Produktes sind vielfältig. Gerne wird von der ersten Idee direkt zur Umsetzung übergegangen. Man weiß nicht, ob das Produkt wirklich die Probleme der Kunden löst. Man hat eine Vermutung, die sich aber selten bestätigt. Und wenn die Annahme des Problems nicht ganz falsch war, kann sich die mögliche Lösung als Fehlentscheidung herausstellen. Sich als Team in den Kunden „hineinzuversetzen“, ohne tatsächlich Kontakt gehabt zu haben, ist keine Kundenzentrierung. Und ein kundenzentriertes Team bedeutet nicht, dass nur der PO und die Stakeholder Kundenkontakt haben. Alle Mitglieder des Teams müssen das Problem des Kunden lösen wollen. Sie müssen das Arbeiten an der Lösung einfordert, die in der Praxis einen nachweisbaren Mehrwert bringt.
Aber bringt die Agilität nicht genau diesen Austausch, den früheren Kontakt zum Kunden? Nicht automatisch. Wenn sich ein Unternehmen nur mit „klassischer Agilität“ beschäftigt, ist noch nicht viel gewonnen. Die Welt hat sich weitergedreht und seit dem Agilen Manifest sind neue Konzepte wie Lean Startup von Eric Ries oder Hypothesis Driven Development von Alex Cowan entstanden. Was sie gemeinsam haben: Beschäftige dich länger mit dem Problem, bevor du zur Lösungsfindung übergehst. Validiere deine Hypothesen mit einfachen Methoden, bevor du mit der Entwicklung beginnst. Lass die Leute kollaborativ an der Produktentwicklung arbeiten, nicht im Wasserfall.
Diese Ansätze sind nicht mehr neu, für viele Start-ups gehören sie zum Alltag. In größeren Organisationen stehen der Umsetzung einige Hürden im Weg: Die Trennung in Silos (Einkauf, Marketing, Entwicklung, Design etc.) lässt keine wirkliche Zusammenarbeit zu, Arbeitsergebnisse werden von einer Abteilung zur nächsten weitergereicht. Auch die Einstellung, Ideen zu validieren und in Problemräumen zu denken, ist nicht weit verbreitet. Ob und wie sich das Produkt am Markt durchsetzt, ist den Verantwortlichen oft nicht wichtig genug. Sie haben ihr Budget, setzen das Projekt um und gehen weiter auf ihrem Karriereweg. Wer aber länger im Geschäft bleiben will und vom Erfolg des Produktes abhängt, der will auch alles dafür tun, dass die Kunden das Produkt haben wollen.
Verliebe dich in das Problem, nicht die Lösung
Wir wären alle schon viel weiter, wenn wir uns mehr mit den Problemen unserer Kunden beschäftigen würden als mit unseren Lösungen. Wir sollten nicht Features implementieren, sondern Probleme lösen. Das ist ein langer Weg, aber wir sollten heute in den Unternehmen den Lernprozess einleiten, um auch morgen gute Produkte anbieten zu können.
Heute legen die Teams zu viel Wert auf ihren Output. Das heißt, die Anzahl der Artefakte, die sie in einem bestimmten Zeitraum veröffentlichen. Oder wie gut sie das Backlog abgearbeitet haben und wie viele Epics der Stakeholder im Release fertiggestellt wurden. Sie werden auch vom Management am Output gemessen. Ob die umgesetzte Arbeit dem Kunden tatsächlich den erwarteten Mehrwert gebracht hat, steht auf einem anderen Blatt. Welche Auswirkungen die geleistete Arbeit auf die Nutzung des Produkts beim Kunden hatte, wird, wenn überhaupt, nur indirekt und zeitverzögert sichtbar.
Deshalb ist es so wichtig, dass die intensive Auseinandersetzung mit dem Problem im Selbstverständnis der Produktentwicklung verankert ist. So erreichen wir die viel beschworene Kundenorientierung. Und woher weiß man welche Probleme Kunden lösen wollen? Genau da kommt Product Discovery ins Spiel.
