Sie treten unter verschiedenen Namen auf… Projektpläne, Roadmaps… Sie nutzen verschiedene Formen… zum Beispiel Gantt Charts. Die Projektleitung, das Management, Stakeholder… Alle lieben sie… Vor allem aus einem Grund… Sie geben Sicherheit!

Doch der Schein trügt…

Wir bewegen uns in der sogenannten VUCA World, unser Umfeld ist "volatility" ("Volatilität"), "uncertainty" ("Unsicherheit"), "complexity" ("Komplexität") und "ambiguity" ("Mehrdeutigkeit"). Wir Agilisten sprechen auch gerne von einem komplexen Umfeld, ein Umfeld mit vielen Wechselwirkungen, in welchem Zusammenhänge oft erst im Nachhinein erkannt und verstanden werden können.

Roadmaps setzen voraus, dass es ein Ziel „B“ gibt und einen klaren Weg wie ich vom aktuellen Zustand „A“ nach „B“ komme. Dieser „eine“ „klare“ Weg kann aus folgenden Gründen einen negativen Einfluss auf den Produkterfolg, insbesondere auf die Innovationskraft der Produktentwicklung haben:

  • Schätzungen sind willkürlich: Es ist fast unmöglich, große Teile der Arbeit abzuschätzen, ohne die Funktionen zu planen und zu durchdenken, was wir nicht tun, wenn wir Roadmaps so weit im Voraus planen.
  • Es wird keine Zeit für Research und Validierung eingeplant: Wenn Unternehmen abschätzen, wie lange ein Produkt dauern wird, berücksichtigen sie in der Regel nicht die Zeit für Research und Validierung, sondern nur für Wireframing, Design usw. Das führt dazu, dass wir Produkte entwickeln, die die Probleme der Kunden nicht lösen.
  • Kein Spielraum für Änderungen: 100 % der geschätzten Kapazität wird für die kommenden Monate zugewiesen, was keinen Raum lässt, um Erkenntnisse aus Kundenfeedback und Marktdynamik einzubeziehen.
  • Nicht problemorientiert: Normalerweise konzentrieren sich Produkt-Roadmaps auf Lösungen und vernachlässigen den Punkt, dass Funktionen gebaut werden, um Probleme unserer Kunden zu lösen.
  • Output-gesteuert: Oft werden Roadmaps zu einer Feature-Wunschliste von verschiedenen Interessengruppen und konzentrieren sich nicht auf die gewünschten Outcomes.

Zeit für ein Umdenken bei Roadmaps - Trennung von Problemen und Lösungen

Eine klassische Produkt-Roadmap trennt normalerweise nicht zwischen Kundenproblemen und Lösungen. Stattdessen wird davon ausgegangen, dass das nächste Feature auf der Liste das Problem lösen wird. Wie wir wissen, gibt es nicht nur einen Weg, ein Problem zu lösen, sondern viele... Manchmal kann die beste Lösung auch darin bestehen, KEIN neues Feature zu entwickeln, sondern ein bestehendes Feature zu optimieren oder sogar zu entfernen.

Eine problemorientierte Produkt-Roadmap trennt Kundenprobleme von möglichen Lösungen.

Jedes agile Produkt-Team arbeitet an einem Problem, das innerhalb dieses Zeitraums gelöst werden soll. Das Problem wird in Form eines OKR (Objective & Key Results) formuliert. Für jedes Quartal und jedes Team können ein oder mehrere OKRs definiert werden. Ihr Ziel ist es, das Problem bestmöglich zu lösen und die geplanten Key Results zu erreichen.

In der Discovery-Phase konzentrieren sich die Teams auf User Research und die Validierung der Existenz des Kundenproblems. Teams bauen Prototypen, führen User Experience Labs durch, machen A/B-Tests und andere Experimente. Alle bekannten Discovery-Methoden und -Tools sind hier willkommen. Wenn die Teams genug Wissen gesammelt haben, können sie dieses in das Delivery Backlog übertragen und in der Delivery-Phase mit der Erstellung der Features als MVPs (Minimum Viable Product) oder MMPs (Minimum Marketable Product) beginnen.

In der Delivery-Phase konzentrieren sich die Teams auf Minimallösungen zur Behebung der wichtigsten Kundenprobleme. Die Teams sollten häufig releasen, um schnelles Kundenfeedback zu erhalten. Die Erkenntnisse aus diesem Feedback fließen zurück in die strategischen Themen und das Discovery Backlog. Dies ist ein kontinuierlicher Feedback- und Lernzyklus.

Es ist sehr wichtig, Optionen auf der Roadmap zu behalten und Discovery die Entscheidungen über die zu entwickelnden Features treffen zu lassen.

Sebastian Straube

Business Agility Enablement Senior Manager

ABONNEMENT-CENTER
Melden Sie sich bei unserem Accenture's IES ASG Newsletter an! Melden Sie sich bei unserem Accenture's IES ASG Newsletter an!