Produktmanagement-Frameworks: welche sich lohnen und wo jedes scheitert

Die meisten Artikel über Produktmanagement-Frameworks sind Listen. Dreiundzwanzig Frameworks, je ein Diagramm, zu keinem eine Meinung. Sie sind auf dieselbe Weise nutzlos wie eine Speisekarte ohne Preise: Man sieht die Optionen und kann trotzdem nicht wählen.

Der Grund: Ein Framework ist kein Wissen, sondern eine Einschränkung für ein Gespräch. RICE sagt Ihnen nicht, was Sie bauen sollen; es zwingt vier Menschen, die sich uneinig sind, ihre Uneinigkeit explizit zu machen. Das ist der ganze Wert — und deshalb lautet die richtige Frage nie „welches Framework ist das beste”, sondern „welche Auseinandersetzung führt mein Team gerade nicht”.

Was ist ein Produktmanagement-Framework?

Ein Produktmanagement-Framework ist eine wiederholbare Struktur für eine bestimmte Klasse von Produktentscheidungen — was als Nächstes gebaut wird, welches Problem gelöst wird, wie Erfolg gemessen wird — sodass die Entscheidung zweimal auf dieselbe Weise fällt und jemandem erklärbar ist, der nicht dabei war.

Der letzte Halbsatz ist der entscheidende. Ein Framework, das Sie hinterher nicht erklären können, hat nichts strukturiert — es hat nur die Meinung einer Person durch eine Tabelle gewaschen.

Frameworks zerfallen in vier Aufgaben. Fast jeder Streit darüber, „welches Framework”, sind in Wahrheit zwei Personen, die zu Werkzeugen aus verschiedenen Zeilen dieser Tabelle greifen.

Die Aufgabe	Frameworks	Die Frage
Priorisierung	RICE, ICE, Kano, Cost of Delay, MoSCoW	Was davon zuerst?
Discovery	Opportunity Solution Tree, JTBD, Continuous Discovery	Lösen wir das richtige Problem?
Strategie	North Star, OKRs, Working Backwards, Produktvision	Wohin gehen wir und warum?
Umsetzung	Dual-Track, Shape Up, Now/Next/Later	Wie bewegt sich Arbeit wirklich?

Priorisierung

RICE

Reach × Impact × Confidence ÷ Effort. Das Arbeitspferd — und meist schon im Einsatz.

Wofür es wirklich gut ist: den Confidence-Term sichtbar zu machen. Die meisten Roadmap-Konflikte sind zwei Menschen mit unterschiedlicher Sicherheit über dieselbe Vermutung, und RICE ist das einzige verbreitete Framework, das diese Sicherheit aufzuschreiben zwingt.

Wo es scheitert: Impact ist eine erfundene Zahl — und sobald sie in einer Tabelle steht, sieht sie nicht mehr erfunden aus. Teams kalibrieren Reach und Effort sorgfältig und vergeben Impact nach Gefühl; der Score erbt dann die Autorität der Rechnung ohne deren Substanz. Außerdem unterbewertet RICE systematisch Arbeit mit kleiner Reichweite und enormer Tiefe — das Enterprise-Feature, das drei Accounts mit 40 % des Umsatzes freischaltet, schneidet miserabel ab.

Fazit: nutzen — und die Top fünf noch einmal bewerten lassen, mit einer anderen Person für Impact. Ändert sich die Reihenfolge, sind Ihre Impact-Zahlen Politik.

ICE

RICE ohne Reach. Schneller, gröber.

Wo es scheitert: Reach ist genau das, was man nicht weglassen sollte, weil es der einzige Term ist, den man meist messen kann. ICE sind drei Meinungen multipliziert.

Fazit: in Ordnung für einen ersten Durchgang durch eine lange Liste. Nie für die endgültige Entscheidung.

Kano

Sortiert Features in Basiserwartungen, Leistungsmerkmale und Begeisterungs­faktoren.

Wofür es wirklich gut ist: ein Team davon abzuhalten, Begeisterungsfaktoren zu polieren, während eine Basiserwartung kaputt ist. Es ist eine Diagnose, kein Ranking.

Wo es scheitert: Kategorien wandern. Der Begeisterungsfaktor von heute ist die Basiserwartung von übermorgen, und eine achtzehn Monate alte Kano-Analyse führt aktiv in die Irre. Ehrlich befüllen lässt sie sich nur mit echter Kundenforschung — genau der Schritt, den Teams überspringen.

Fazit: einmal im Jahr richtig machen, mit echten Umfragedaten. Nicht aus dem Gedächtnis im Workshop.

Cost of Delay

Was kostet es uns pro Woche, das nicht zu haben?

Wofür es wirklich gut ist: das mit Abstand am meisten unterschätzte Framework dieser Liste. Es verschiebt Priorisierung von Wert auf Dringlichkeit — die Dimension, die die meisten Roadmaps falsch behandeln. Und es ist das einzige, das nativ Finanzsprache spricht, was es außerhalb der Produktorganisation ungewöhnlich überzeugend macht.

Wo es scheitert: Es braucht Zahlen, die Sie vielleicht nicht haben, und ist auf Plattform- und Fundamentarbeit mit diffusem Nutzen kaum anwendbar.

Fazit: lernen. Es verändert, wie Sie vor einem CFO argumentieren.

MoSCoW

Must / Should / Could / Won’t.

Wo es scheitert: Alles wird ein Must. Ohne harte Obergrenze für die Must-Liste ist es ein Vokabular, kein Framework.

Fazit: nur mit vorab vereinbarter Grenze sinnvoll — „Musts dürfen 60 % der Kapazität nicht überschreiten”. Mit dieser Grenze ist es für den Zuschnitt eines einzelnen Releases richtig gut. Ohne sie: weglassen.

Discovery

Opportunity Solution Tree

Teresa Torres’ Struktur: Outcome an der Wurzel, davon abzweigend Opportunities, darunter Lösungen, darunter Experimente.

Wofür es wirklich gut ist: sichtbar zu machen, wenn ein Team direkt vom Outcome zur Lösung gesprungen ist, ohne Opportunity dazwischen — was, sobald man anfängt, diese Bäume zu zeichnen, der Normalfall ist.

Wo es scheitert: Es ist ein Denkwerkzeug, das als Dokumentationsartefakt behandelt wird. Ein Baum, den seit zwei Monaten niemand neu gezeichnet hat, ist Dekoration.

Fazit: das wertvollste Framework dieser Seite für ein Team, das kompetent liefert, aber nicht erklären kann, warum genau diese Dinge. Live zeichnen, wegwerfen, neu zeichnen.

Jobs to be Done

Menschen „stellen Produkte ein”, um in einer bestimmten Situation voranzukommen.

Wofür es wirklich gut ist: demografisches Denken aufzubrechen. Aus „unsere Nutzer sind Marketingleiter in mittelständischen B2B-Firmen” wird „jemand muss bis Donnerstag vor dem Board belegen, dass die Ausgaben des letzten Quartals gewirkt haben” — und der zweite Satz sagt Ihnen, was zu bauen ist.

Wo es scheitert: Es hat ein Dogmenproblem. Konkurrierende Schulen sind sich grundlegend uneinig, und Teams verlieren Wochen mit der Frage, ob ein Job Statement korrekt formuliert ist. Der Formalismus ist nicht der Wert — der Perspektivwechsel ist es.

Fazit: den Perspektivwechsel nehmen, die Orthodoxie lassen. Wenn Ihre Job Statements auf Syntax geprüft werden, ist etwas schiefgelaufen.

Continuous Discovery

Wöchentlicher Kundenkontakt durch das Trio, das das Produkt baut — statt einer Research-Phase.

Wo es scheitert: Es braucht einen echten, geschützten wöchentlichen Slot. Teams übernehmen die Sprache, machen es fünf Wochen und hören still auf, wenn eine Deadline kommt — schlimmer als nie anzufangen, weil die Organisation nun glaubt, es sei versucht worden.

Fazit: Die Gewohnheit ist das Framework. Wenn Sie den Slot nicht schützen können, nennen Sie es ehrlich periodische Forschung.

Strategie

North-Star-Metrik

Eine Zahl, die den gelieferten Wert erfasst, mit einigen Eingangsgrößen darunter.

Wo es scheitert: Sie wird nach Lesbarkeit statt nach Wahrheit gewählt. Wöchentlich aktive Nutzer sind ein North Star, der ein Board-Deck übersteht und fast nichts darüber sagt, ob jemand Wert hatte. Das Versagen ist leise — die Zahl steigt, das Geschäft nicht.

Fazit: lohnt sich. Prüfen Sie den Kandidaten mit: Wenn sich diese Zahl verdoppelte und sonst nichts, wäre das Geschäft dann wirklich doppelt so gesund? Die meisten Kandidaten sterben an dieser Frage.

OKRs

Ziele mit messbaren Schlüsselergebnissen.

Wo es scheitert: OKRs sind ein Kommunikations-Framework, das Organisationen als Leistungsbeurteilungs-Framework installieren. Sobald sie an Vergütung hängen, setzt jeder Ziele, die er sicher erreicht — und Sie haben eine teure Tiefstapelmaschine gebaut.

Fazit: gut für Abstimmung zwischen Teams, die nicht täglich sprechen. Aktiv schädlich, wenn an Gehalt gekoppelt.

Working Backwards

Pressemitteilung und FAQ schreiben, bevor gebaut wird.

Wofür es wirklich gut ist: Es macht Unschärfe unmöglich. Man kann keine Pressemitteilung für etwas schreiben, das man nicht beschreiben kann — und das Scheitern beim Schreiben ist das Ergebnis.

Wo es scheitert: Es belohnt Schreibfähigkeit. Der bestgeschriebene Vorschlag gewinnt, nicht der beste. Wo diese Dynamik real ist, konzentriert es Entscheidungsmacht still bei den guten Schreibern.

Fazit: hervorragend für große, unumkehrbare Wetten. Darunter überdimensioniert.

Umsetzung

Dual-Track — Discovery und Delivery parallel im selben Team — ist der verteidigenswerte Standard. Sein Fehlermodus: Der Discovery-Track wird zu einem PM, der allein arbeitet, während „das Team” liefert. Das ist Single-Track mit zusätzlichem Vokabular.

Shape Up — feste sechswöchige Appetite, variabler Scope, kein Backlog — tauscht Planbarkeit gegen Fokus. Es funktioniert in Organisationen, die sechs Wochen lang wirklich Nein zu Unterbrechungen sagen können; das dürften weniger sein, als es einführen.

Now / Next / Later ist kein Framework, sondern ein Roadmap-Format. Aber es ist der richtige Standard, weil es als einziges verbreitetes Format keine Termine suggeriert, die es nicht halten kann.

Wie Sie wählen

Diagnostizieren Sie die Auseinandersetzung, die nicht stattfindet:

• Ihr Team liefert stetig und kann nicht sagen, warum genau das → Opportunity Solution Tree.
• Jeder Stakeholder hält sein Thema für das nächste → RICE, mit der Impact-Spalte in der Hand von jemandem ohne Eigeninteresse.
• Die Führung kippt Entscheidungen immer wieder → Working Backwards oder ein echter North Star. Das ist ein Strategievakuum, kein Priorisierungsproblem.
• Die Roadmap ist eine Warteschlange von Wünschen der Lautesten → kein Framework hilft. Das ist ein Verantwortungsproblem und braucht eine strukturelle Antwort statt eines Bewertungsmodells.

Beim letzten Punkt lohnt es sich zu verweilen. In den meisten stockenden Produktorganisationen fehlt das Framework nicht — es gibt eine RICE-Tabelle, nur darf niemand nach ihrem Ergebnis handeln. Ein zweites Framework auf einen Priorisierungsprozess ohne Autorität zu setzen erzeugt zwei ignorierte Artefakte statt einem.

Der Teil, der nicht das Framework ist

Die unbequeme Erkenntnis nach zwölf Jahren: Teams scheitern fast nie daran, das falsche Framework gewählt zu haben. Sie scheitern daran, dass niemand das Ergebnis verantwortet, dass Scores nach der Entscheidung nie wieder angefasst werden, oder dass das Framework als Workshop-Ritual läuft und danach still auf dem Flur überstimmt wird.

Frameworks sind billig einzuführen und teuer zu betreiben. Der Betriebsteil — wem gehören die Zahlen, was passiert, wenn das Ergebnis unpopulär ist, wie wird eine Entscheidung revidiert, ohne alles neu aufzurollen — ist die eigentliche Arbeit. Und er ist das Meiste, was ich im Coaching mit Produktmanagern mache, die all das oben längst wissen und trotzdem keine Entscheidung festzurren können.

Wenn Sie sich auf Fragen dazu im Vorstellungsgespräch vorbereiten: Die Fragen, die tatsächlich gestellt werden, zielen weniger auf Definitionen als auf eine Situation, in der Sie eines angewendet haben und es schiefging.