Hinter dem neunten Türchen des Agilen Adventskalenders verbirgt sich ein Thema, in dem es einzig und allein um das Produkt geht. Die heutige Frage lautet:
Gibt es Best Practices, wie sich Product Discovery und Product Delivery anteilsmäßig verteilen?
Product Discovery & Product Delivery
Product Discovery bezeichnet den Weg, “das richtige Produkt” zu finden – also einen passenden Problem/Solution/Market Fit herzustellen. Bei der Product Delivery geht es darum, dieses “richtige Produkt” als Software umzusetzen.
Während es vor vielen Jahren den typischen Weg gab, die Product Discovery zeitlich versetzt als parallelen Strang vor die Delivery-Iterationen zu legen, hat sich dies bis heute rasant und radikal verändert.
Das große Ganze
Product Discovery und Delivery sind zu einem großen Ganzen verschmolzen bzw. miteinander verwoben. Beides findet also gleichzeitig statt. Das hat immense Vorteile:
Dadurch wird die Time-to-Market verkürzt. Aufwändige Vorstudien oder Tests, die vorab stattfinden, fallen weg. Wesentlich für diese Vorgehensweise ist, den Nutzer mit seiner realistischen Nutzungsintention zu „beobachten“.
Dies erfordert ein entsprechendes Analytics-Tooling oder auch die Option, Produktabfragen nach einer durchgeführten Aktion zu tätigen. Damit wird ein schnelles Lernen ermöglicht. Empfehlen möchte ich Euch hierzu auch das Validated Learning Board aus Lean Startup. Diese Prinzipien kann man auch bei „reifen Produkten“ anwenden, um eine „Fire-&_Forget“-Mentalität zu vermeiden.
Der oftmals vorgefundene Weg, die Discovery zeitlich mit einem halben oder ganzen Sprint “Versatz” (Dual Track Agile) als iterativen Mechanismus leicht vor die Delivery zu versetzen, ist nicht mehr zeitgemäß.
Cross-funkionale Entwicklungsteams als Lösung
Möglich macht dies ein passend zusammengestelltes cross-funktionales Entwicklungsteam. Mit einem starken, befähigten Product Owner, der über die notwendigen Skills in puncto Produktstrategie und die Kenntnisse in puncto Problem/Solution und Solution/Market Fit verfügt. Mit T-/Pi-shaped Entwicklern, die kleine prototypische Lösungen bauen können, die sich schnell verproben lassen. Immer vorausgesetzt, dass auch UX-Know-How im Entwicklungsteam existiert – ob nun beim Product Owner direkt oder bei den Software-Entwicklern mit UX-Ausprägung.
Durch ein befähigtes und bevollmächtigtes Team wird autonomes Arbeiten ermöglicht. Dies reduziert Übergaben von Informationen und Aufgaben, bei denen ein unvermeidlicher Reibungsverlust entsteht. Gleichzeitig hat dies einen positiven Einfluss auf die Time-to-Market.
Das Wissen aus der “Marktforschung” wird direkt im Produktentwicklungsteam generiert und ist damit schnell und direkt verfügbar. Erkenntnisse, die daraus gezogen werden, können direkt in das Product Backlog und damit in die Entwicklung fließen.
Die schnelle Weiterentwicklung von Technologien und Werkzeugen, die hier zur Verfügung stehen, führte zusätzlich dazu, dass Discovery und Delivery miteinander verschmelzen.
Die Kombination macht’s!
Die Aussage “x % Discovery, y % Delivery” ist also nicht mehr opportun. Discovery ist eine fortlaufende Aufgabe, die uns durch den gesamten Produktentwicklungs-Zyklus begleitet. Moderne Produktentwicklungsteams profitieren daher von der direkten Wertschöpfung, die eine Kombination aus Discovery und Delivery bieten.
Du suchst einen tatkräftigen Entwicklungs-Partner und möchtest mit uns Dein Software-Vorhaben diskutieren? Dann melde Dich gerne bei kontakt@mayflower.deOder schau Dir unser Training “Become a Product Leader” an, mit dem Du das nächste Level der Product Ownership erklimmst. Unsere Interims Product Owner helfen Euch auch direkt im Maschinenraum.
[smartblock id=11351]
Schreibe einen Kommentar