Zurück zum Playbook
Define & DesignDD-05
Mit MoSCoW priorisieren
Trennt im Gespräch unverzichtbare Lieferung von verhandelbarem Umfang; Won’t heisst dieses Mal, nicht für immer.
ProduktstatusVerfügbar
Input4 benötigte InputsAnforderungskandidaten · Zentrale User Journey und Kapazitätsgrenzen · Abhängigkeiten
SkillsFacilitate MoSCoW scope · Prepare task context · Review an artifact against agreed criteriaProduct Manager + Product Manager Agent
ErgebnisMoSCoW-Umfang: Release-Grenze, Gruppen Must, Should, Could und Won’t mit Begründung, Abhängigkeiten und offene Entscheide.Artefakt: MoSCoW-Umfang
Owner
Product Manager
Mensch + Agent
Beteiligte · Agents
EngineerHead of ProductProduct Manager Agent
Auslöser
Anforderungskandidaten übersteigen ein Release oder einen Planungshorizont.
Benötigter Kontext
JiraAnforderungskandidatenProduct BrainZentrale User Journey und KapazitätsgrenzenCodeAbhängigkeitenProduct BrainFokus der Initiative und freigegebene Product-Brain-Leitlinien
Optionaler Kontext
FilesKlassifikationen der Stakeholder
Skills
Facilitate MoSCoW scopePrepare task contextReview an artifact against agreed criteria
Vorgeschlagener Gesprächsbogen
- 1Die Release-Grenze setzenDie User Journey, die funktionieren muss, den Release-Horizont und die Einschränkungen vereinbaren, bevor Anforderungen sortiert werden.Skills: Prepare task context
- 2MoSCoW-Gruppen vorschlagenAlle Kandidaten sammeln und Must, Should, Could und Won’t-this-time mit Begründung vorschlagen. Abhängigkeiten offenlegen, statt sie in einer Gruppe zu verstecken.Skills: Facilitate MoSCoW scope
- 3Jedes Must hinterfragenFragen, was scheitert, wenn ein Must fehlt. Dissens der Stakeholder vergleichen und verhandelbaren Wert als Should oder Could behalten, wenn die zentrale Journey trotzdem funktioniert.
- 4Umfang und Ausschlüsse bestätigenMachbarkeit und abhängige Anforderungen prüfen; Won’t-this-time-Elemente und die Bedingungen für eine Neubewertung des Umfangs explizit bestätigen.Skills: Review an artifact against agreed criteria
Ergebnis
MoSCoW-Umfang: Release-Grenze, Gruppen Must, Should, Could und Won’t mit Begründung, Abhängigkeiten und offene Entscheide.
Artefakte
Erstellt: MoSCoW-Umfang
So sieht gut aus
- Alle Kandidaten stehen in einer expliziten Gruppe oder einem offenen Abschnitt.
- Jedes Must hat eine konkrete Begründung seiner Notwendigkeit.
- Ein machbarer Umfang wird nicht ohne Belege zu Abhängigkeiten und Kapazität versprochen.
Freigabe
Der Product Manager bestätigt den Umfang, die Ausschlüsse und wann sie neu bewertet werden dürfen.
Ziel
JiraConfluence
Meist als Nächstes
Menschen und Agents arbeiten mit demselben Product Brain. Der Owner bleibt verantwortlich. Zugewiesene Agents bereiten vor und prüfen. Ein benannter Mensch gibt an der Freigabe frei.
Vertiefung im AI PM Lab
Beiträge, die das Denken hinter dieser Activity erklären.
- Graph Engineering: Multi-Agenten-Workflows statt Chat-Ketten
- Die Anatomie eines Jira-Tickets für KI-Product-Management im Agentic Engineering
- Warum Spotifys Product-Management-Modell für euer Unternehmen nicht funktioniert – mit KI-Agenten erst recht
- PM, Data Scientist, ML Engineer: Wer macht was im KI-Produktteam?
Wähl den Einstieg, der zu deiner Rolle passt.
Leg mit uns die Product-AI-Richtung fest oder teste das gemeinsame Product Brain mit Jira und Code an echter Arbeit.