Discovery-Sprint: Von vagen Zielen zu einer Roadmap, die Engineering nicht sofort ignoriert
Wie ihr in wenigen Wochen Problem, Nutzer, Constraints und Priorit├ñten sch├ñrft ÔÇö mit Artefakten, die sich in Backlogs und Architekturentscheide ├╝bersetzen lassen.
8. Januar 2025 · Abbattista
Roadmaps scheitern oft nicht an fehlender Vision, sondern an fehlender ├£bersetzung: Produkt spricht Outcomes, Engineering h├Ârt ÔÇ×noch mehr FeaturesÔÇ£, Finance h├Ârt ÔÇ×noch mehr KostenÔÇ£.
Woche 1: Problem und Kontext
- Stakeholder-Interviews (kurz, strukturiert).
- Ist-Prozesse und Schmerzpunkte dokumentieren.
- Erste Hypothesen: für wen, warum jetzt, was passiert ohne Veränderung.
Woche 2: Nutzer und Wettbewerb
- Nutzer- oder Kundensegmente sch├ñrfen (auch B2B hat ÔÇ×Jobs to be doneÔÇ£).
- Wettbewerb und Alternativen ÔÇö inklusive ÔÇ×Excel und E-MailÔÇ£.
- Risiko- und Compliance-Checkliste (Daten, Verträge, SLA).
Woche 3: L├Âsungsoptionen und Schnitte
- 2ÔÇô3 Architektur- oder Produktpfade skizzieren (nicht zehn).
- Value vs. Aufwand grob sch├ñtzen ÔÇö mit ehrlicher Unsicherheit.
- Entscheidungskriterien festhalten (Time-to-Market, Risiko, strategische Passung).
Artefakte, die bleiben sollen
Ein einseitiges Zielbild, eine priorisierte Liste (Now / Next / Later) und eine offene Fragenliste. Alles andere ist Unterlage ÔÇö nicht das Dokument selbst.
Fazit
Discovery ist kein Luxus-Workshop, sondern Risikomanagement. Teams, die diese Phase ├╝berspringen, zahlen mit Rework und frustrierten Releases.
Passt zu: So arbeiten wir, FAQ und ÔÇö wenn ihr aus Klarheit in Umsetzung wollt ÔÇö Strategie & Beratung.
Teilen