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