Frameworks sind Gerüste, keine Antworten

Intuition

Einsteiger sammeln Frameworks wie Sammelkarten und versuchen, bei jedem Case eine auszuspielen. Aber Frameworks sind Gerüste, die temporäre Struktur um ein Gebäude im Bau. Das Gerüst hilft dir, an die Arbeit heranzukommen, und hält dich geordnet, doch niemand verwechselt es mit dem Gebäude selbst. Das Gebäude ist dein maßgeschneidertes Denken über das konkrete Problem dieses Kunden. Starke Kandidaten nutzen das Gerüst leicht und bauen es ab, sobald es im Weg ist.

Das Paradox dieses ganzen Moduls: Du hast die Frameworks gelernt, damit du aufhören kannst, dich auf sie zu stützen.

Das Framework

So hältst du Frameworks richtig:

• Starte beim Ziel, nicht beim Framework. Frag, welcher Entscheidung der Case dient, und bau darauf hin; leih dir Framework-Bausteine nur dort, wo sie passen.
• Schneid gnadenlos zu. Behalte die Äste, die für dieses Problem zählen; lass die weg, die es nicht tun. Ein halb genutztes Framework, das passt, schlägt ein vollständiges, das nicht passt.
• Nenn nie den Namen. Sag „Ich würde mir die Kundennachfrage, unsere Lieferfähigkeit und die Reaktion der Konkurrenz ansehen“, nicht „Ich nehme die 3 Cs“.
• Erfinde, wenn nichts passt. Die meisten echten Aufgaben brauchen einen eigenen Baum. Frameworks sind ein Vokabular, kein Drehbuch.

Durchgerechnetes Beispiel

Aufgabe: „Ein Sinfonieorchester verliert sein Publikum. Was sollte es tun?“ Ein schwacher Kandidat zwingt Porters Five Forces auf eine gemeinnützige Organisation und strauchelt. Ein starker baut von Grund auf: „Ich würde mir ansehen, wer geht (das verlorene Publikum segmentieren), warum (Ersatzangebote, Preis, Relevanz) und was wir glaubwürdig bieten können (Programm, Erlebnis im Konzertsaal, digitaler Zugang).“ Diese Struktur nutzt still Kunden- und Wettbewerbsdenken, ist aber auf ein Orchester zugeschnitten, nicht aus dem Regal gezogen. Der Interviewer sieht Denken, nicht Abrufen.

Noch eins, in einem operativen Umfeld: „Eine Notaufnahme hat Wartezeiten von 4 Stunden.“ Der schwache Kandidat tastet nach einem Business-Framework, das es dafür nicht gibt. Der starke baut aus der Physik des Problems: Nachfrage (Ankünfte, sagen wir 10 Patienten/Stunde in der Spitze), Kapazität (Durchsatz, 8 Patienten/Stunde über die besetzten Behandlungsplätze), Prozess (Verzögerungen bei Triage und Übergabe zwischen beiden). Wenn die Ankünfte den Durchsatz um 2 Patienten pro Stunde übersteigen, wächst die Schlange zwangsläufig, und jeder Ast zeigt auf eine andere Lösung. Kein Framework-Name der Welt war nötig; nur das Ziel, zerlegt.

Im Interview

Der erste Satz deiner Struktur ist der Ort, an dem diese Lektion lebt oder stirbt. Sag: „Da das Ziel ist, den Besucherrückgang umzukehren, würde ich mir ansehen, wen wir verlieren, warum sie gehen und was wir glaubwürdig ändern können.“ Sag nie: „Ich wende hier die 3 Cs an.“ Dasselbe Denken dahinter, entgegengesetztes Signal. Wenn ein Framework wirklich passt, nutz seinen Inhalt und lass seinen Namen weg: „Ich würde verstehen wollen, ob diese Branche überhaupt gesunde Margen tragen kann: Wer hat die Macht über den Preis?“ Das sind die Five Forces inkognito. Und wenn deine Struktur mitten im Case nicht mehr passt, bau laut um: „Die Daten deuten darauf hin, dass das ein operatives Problem ist, kein Nachfrageproblem, ich strukturiere neu.“ Sichtbar anzupassen ist ein Stärkesignal, kein Geständnis. Der Interviewer bewertet Eigenständigkeit: ob die Struktur klingt, als wäre sie für diesen Kunden gebaut oder von einer Lernkarte abgerufen.

Typische Fehler

• Zuerst das Framework wählen und dann das Problem passend biegen.
• Framework-Namen aufsagen, statt maßgeschneiderte Äste zu bauen.
• Sich weigern, ein Framework aufzugeben, obwohl es eindeutig nicht zum Case vor dir passt.