Wenn über Produktrisiken gesprochen wird, hört man meist die Begriffe Value, Usability oder Viability. Unternehmen investieren viel Zeit in Interviews und Experimente, um herauszufinden, ob ein Produkt wertvoll (Value) für Kund:innen ist. UX- und UI-Designer optimieren kleinste Details für eine bessere Nutzererfahrung (Usability). Viability wiederum ist eine durchdachte, strategische Entscheidung des Unternehmens.
Für diese drei Produktrisiken gibt es Literatur, Austausch und jede Menge Erfahrungswerte in der Produktwelt. Doch Marty Cagan, Produkt-Vordenker und Autor, schreibt u.a. in seinem Blog, von einer weiteren wichtigen Risikoart: Feasibility Risk, also der Frage, ob ein Projekt in der gewünschten Zeit umsetzbar ist. Das vierte große Produktrisiko. Oft wird dieses Risiko allein den Entwickler:innen überlassen. Das kann dazu führen, dass Umsetzungsprobleme zu spät erkannt werden und selbst das beste UX-Design nicht rechtzeitig umgesetzt werden kann. Dann bleibt das Projekt womöglich hinter den Erwartungen und kalkulierten Zielen zurück.
Wie wäre es, wenn POs auch hier agil Erkenntnisse sammeln und so helfen könnten, Meilensteine verlässlich zu erreichen? Genau darum geht es in diesem Beitrag: Wir erklären unser Konzept eines technischen Durchstichs und wie POs gemeinsam mit dem Team Feasibility Risk frühzeitig adressieren können.
Worum geht es bei Feasibility Risk und warum ist das für POs wichtig?
Feasibility bedeutet die Machbarkeit eines Produkts: Haben die Beteiligten die nötigen Fähigkeiten und Ressourcen, um es zu realisieren? Besonders für POs ohne technischen Hintergrund ist das schwer einzuschätzen. Sie müssen sich auf das Team verlassen und können vielleicht nur hoffen, dass alle Kompetenzen abgedeckt sind, um das Produkt rechtzeitig fertigzustellen.
Kein Wunder, wenn es manche POs verleitet zu detaillierte Vorgaben zu machen oder sich auf enge Schätzungen zu verlassen. Doch Risiken lassen sich nicht einfach wegplanen. Selbst wenn die Umsetzungsschritte klar erscheinen, können sich Anforderungen und Bedingungen jederzeit ändern.
Wie bei anderen Produktrisiken gilt auch hier: Je früher Annahmen getestet und Erkenntnisse gewonnen werden, desto besser. Durch regelmäßige Überprüfung kann sichergestellt werden, dass das Produkt wie geplant realisierbar ist.
Da POs für gesamte Produkte verantwortlich sind, sollte Feasibility eine ebenso hohe Priorität haben wie Value, Usability und Viability – und zwar bereits vor der Umsetzungsphase.
Wie können POs Feasibility frühzeitig bewerten?
Im agilen Kontext sind POs für das Backlog-Management und die Maximierung des Produktwerts verantwortlich (siehe hierzu z.B. Scrum Guide). Doch wie geht man mit technischem Risiko um, besonders in frühen Entwicklungsphasen?
Hier hilft eine enge Zusammenarbeit mit dem Entwicklungsteam. POs sollten nicht nur das Backlog priorisieren, sondern auch gemeinsam mit dem Team identifizieren, welche technischen Risiken früh adressiert werden müssen.
POs können über gezielte Fragen mit dem Team in die Diskussion zum Feasibility Risk einsteigen:
- Wie passt das Produkt in die Unternehmensstrategie? Welche übergeordneten Ziele verfolgt es?
- Wie fügt sich das Produkt in die bestehende Systemlandschaft ein? Welche Schnittstellen sind relevant?
- Wo liegen die größten Unsicherheiten in der technischen Umsetzung?
Gerade die Abhängigkeit von anderen Systemen birgt oft unerwartete Risiken. Wenn ein Produkt technisch perfekt gebaut ist, aber kritische Daten fehlen oder nicht wie erwartet konsumiert werden können, entstehen Verzögerungen.
Warum diese Fragen?
1. Wie passt das Produkt in die Unternehmensstrategie?
Bevor sich POs mit Feasibility beschäftigen, sollte mit dem Team geklärt werden, warum das Produkt für das Unternehmen strategisch wichtig ist. Geht es um Kostensenkung, Effizienzsteigerung oder Marktwachstum? Diese Klarheit hilft dem Team, Entscheidungen zu treffen, die auf den Unternehmenszielen basieren. Denn oft gibt es nicht nur eine technisch richtige Lösung, sondern unterschiedliche Wege mit variierenden Kosten und Aufwänden. POs sollten den Anspruch an das Entwicklungsteam stellen Verantwortung zu übernehmen, indem sie technische Entscheidungen auf Basis der Unternehmensstrategie und -ziele treffen (siehe unseren Blog zum Thema Die Rolle der Softwareentwicklung: Von Technik zur Produktentwicklung).
2. Wie fügt sich das Produkt in die bestehende Systemlandschaft ein?
Als PO ist man es gewohnt auf das Produkt zu gucken und selten auf andere Systeme, von denen man betroffen ist. Häufig liegt hier allerdings das größte Feasibility Risk. Ein Produkt kann perfekt gestaltet sein, aber wenn Daten nicht wie erwartet verfügbar sind oder Schnittstellen unzuverlässig arbeiten, kommt es zu Verzögerungen oder sogar zum Scheitern.
Deshalb sollten POs gemeinsam mit dem Team klären, wie sich das Produkt in die bestehende Systemlandschaft einordnet:
- An welche Systeme muss es angebunden werden?
- Welche Daten werden benötigt, wo kommen sie her und wie werden sie weiterverarbeitet?
Ein Abhängigkeitsdiagramm, das relevante Systeme und Schnittstellen aufzeigt hilft hier enorm.
3. Wo liegen die größten Unsicherheiten in der technischen Umsetzung?
Sind Unternehmensziele und Systemlandschaft geklärt, geht es darum, die größten Unsicherheiten zu identifizieren. Welche Abhängigkeiten sind erfolgskritisch? Wo sind die Schnittstellen noch am wenigsten klar? Hier hilft ein iterativer Ansatz, um die zentralen technischen Herausforderungen so früh wie möglich zu testen.
Mit klaren Zielen, einem guten Verständnis wovon das Produkt abhängt und einer Einschätzung des Umsetzungsrisikos kann gerade in frühen Phasen des Produkts das Backlog so priorisiert werden, dass neben Value, Usability und Viability auch Feasibility Schritt für Schritt sicherer wird.
Warum MVP, Meilensteine und Schätzungen nicht ausreichen
Viele POs setzen auf MVPs, Meilensteine und Schätzungen, um die Umsetzung zu strukturieren. Diese Ansätze haben alle ihren Zweck, doch wenn es um Feasibility geht, greifen diese Methoden oft zu kurz:
- MVP: Definiert den Mindestfunktionsumfang, der Monate in der Umsetzung dauern kann.
- Meilensteine: Sollen Fortschritte sichtbar machen, die trotzdem noch zu groß und unflexibel sein können, wenn es um Risikominimierung geht.
- Schätzungen: Vermitteln Planbarkeit, basieren aber auf Annahmen und bergen Unsicherheiten.
- Proof of Concept (PoC): Technische Machbarkeitsstudien sind hilfreich, allerdings meistens nicht auf produktive Software ausgelegt.
Nachdem POs diese wichtigen MVP- und Meilensteinplanungen gemacht und mit dem Team Schätzungen durchgeführt haben, bleibt eigentlich nur noch von der Seite zuzuschauen und regelmäßig zu fragen ob noch alles im Plan läuft.
Deshalb braucht es einen ergänzenden Ansatz, mit dem Feasibility kontinuierlich überprüft werden kann.
Die Lösung: Ein technischer Durchstich
Ein technischer Durchstich ist die einfachste funktionsfähige Verbindung aller kritischen Systemkomponenten. Er testet die realen Herausforderungen frühzeitig und hilft, Unsicherheiten schnell zu eliminieren.
Beispiele:
- Ein Analyse-Tool ist nutzlos, wenn es keine validen Daten erhält.
- Eine Datenaufbereitungssoftware ohne stabilen Output bringt keinen Mehrwert.
- Ein Onlineshop ohne Echtzeit-Produktdaten kann die Nutzererwartungen nicht erfüllen.
POs können hier sehr wertvolle Arbeit leisten, indem mit dem Team die folgenden Schritte zum funktionierenden technischen Durchstich geplant und durchgeführt werden:
Schritt 1. Kernfunktionen, von denen das Produkt abhängt, identifizieren
Schritt 2. Die risikoreichsten Komponenten und Schnittstellen im Backlog priorisieren
Schritt 3. Einen funktionierenden Durchstich als ersten Meilenstein setzen – am besten nach spätestens drei Monaten
Schritt 4. Das Produkt schrittweise basierend auf den gewonnenen Erkenntnissen erweitern
Ein Durchstich besteht aus funktionierender Software, die den kritischsten Feasibility Risiken begegnet. Anders als ein PoC ist er nicht nur ein Test, sondern bereits ein realer Baustein des späteren Produkts.
Alle Vorteile auf einem Blick: Warum ein Durchstich wichtig ist
Viele Entwicklungsprojekte scheitern nicht an fehlendem Wert oder schlechter Usability, sondern an ungeahnten technischen Hürden. Ein Durchstich sorgt dafür, dass diese früh sichtbar werden.
Vorteile:
- Frühzeitige Klärung von Abhängigkeiten und technischen Herausforderungen.
- Reduzierung von Unsicherheiten durch funktionierende Software.
- Schnellere Lernkurve für das Team, da Annahmen direkt überprüft werden.
- Flexibilität in der Weiterentwicklung, da der Durchstich schrittweise erweitert werden kann.
- Erhöhtes Verständnis für das Produkt und Verantwortungsbewusstsein im Team, durch die starke Einbindung des Entwicklungsteams Risiken zu bewerten und zu minimieren.
Fazit: POs sollten Feasibility aktiv steuern
Als PO übernimmt man Verantwortung für Value, Usability und Viability – aber auch für Feasibility. POs sollten nicht passiv darauf warten, ob Entwickler:innen alle Tickets abarbeiten, nur um am Ende festzustellen, dass sich alles verzögert.
Stattdessen können POs aktiv mit dem Team an einem Umsetzungsplan arbeiten, der technische Risiken frühzeitig aufdeckt. Ein technischer Durchstich liefert früh funktionierende Software, die die größten Feasibility-Fragen klärt und so dazu beiträgt, dass das Produkt termingerecht und erfolgreich umgesetzt wird.