Ein KI-Feature kann in der Demo überzeugen und trotzdem jeden Monat Geld verlieren. Der Pilot läuft mit wenigen Nutzern und kurzen Dokumenten; im Betrieb kommen lange Kontexte, Wiederholungen und Eskalationen auf teurere Modelle hinzu, und für keinen dieser Posten hat jemand eine Reserve eingeplant.
Diese Rechnung landet heute bei Produktmanagern. Bei klassischer Software reichte es meist, Markt, Zielgruppe, Wertversprechen, Wettbewerb, Preis und Funnel-Kennzahlen zu verstehen. Bei KI-Produkten kommen vier Dinge hinzu. Die Kosten wachsen mit der Nutzung. Die Qualität schwankt: Ein Ergebnis ist oft nützlich, aber nie garantiert. Daten werden zu einem wichtigen Vermögen. Und vom Wettbewerb hebt man sich erst ab, wenn Daten, Modelle, die Steuerung der Abläufe und die Qualitätsprüfung gut zusammenspielen.
Wer ein KI-Produkt als „intelligenteres Feature“ behandelt, übersieht, dass es ein wirtschaftliches System ist. Es trägt nur, wenn strategische Relevanz, technische Machbarkeit, Experimentierrhythmus, Governance und Finanzlogik zueinander passen.
Damit verschiebt sich auch der Qualitätsbegriff. Modelle driften, Kontexte werden missverstanden, die Dokumentensuche (Retrieval) bleibt unvollständig, Kosten steigen unter Last, und eine kleine Änderung am Prompt kann die ganze Nutzererfahrung kippen.
Die Frage, ob Nutzer etwas wollen, genügt deshalb nicht. Ein PM muss auch klären, ob das System robust genug, sicher genug und unter realer Nutzung wirtschaftlich ist. Fehlt diese Prüfung, entstehen beeindruckende Demos und selten tragfähige Produkte.
Erst das Problem, dann das Modell
Viele KI-Initiativen reden zu früh über Technik. Großes oder kleines Modell, RAG oder Fine-Tuning, Copilot oder Agent: Diese Fragen sind berechtigt, aber sie kommen an zweiter Stelle. Wer mit dem Modell beginnt, sucht anschließend ein Problem, das dazu passt, und findet meist eines, das zu selten auftritt oder zu wenig wert ist.
Produktmanager sollten deshalb zuerst die Arten von Problemen finden, bei denen KI klar im Vorteil ist. Dazu gehört, große Mengen an Fällen einzuordnen oder vorherzusagen. Dazu gehören freie Texte, Bilder und Dokumente, aufwendige Recherche und Zusammenfassungen, persönliche Empfehlungen für sehr viele Nutzer und Abläufe, die so vielfältig sind, dass feste Regeln nicht reichen. Auch Fälle zählen dazu, in denen schon eine etwas bessere Schätzung Geld wert ist.
Dass ein Problem „gut zu KI passt“, reicht allerdings nicht. Es braucht drei Bedingungen: Häufigkeit, Wirkung und brauchbare Daten.
Wie schnell die erste Bedingung entscheidet, zeigt eine kleine Rechnung. Angenommen, eine Rechtsabteilung prüft 200 Lieferantenverträge im Monat, jede Prüfung dauert 45 Minuten, die Stunde kostet intern 90 Euro. Spart ein KI-Assistent die Hälfte der Zeit, sind das 75 Stunden oder 6.750 Euro im Monat. Ein Support-Team mit 20.000 Tickets, bei denen ein Copilot je drei Minuten spart, kommt auf 1.000 Stunden und 50.000 Euro, wenn die Stunde 50 Euro kostet.
Beide Fälle sind technisch spannend. Nur einer trägt ohne Weiteres ein eigenes Produktteam, solange der Vertragsfall keinen zweiten Werthebel hat.
Die dritte Bedingung wird am häufigsten überschätzt. „Wir haben viele Daten“ heißt selten, dass es markierte Beispiele für genau die Entscheidung gibt, die das Modell treffen soll, also Fälle, bei denen jemand die richtige Antwort eingetragen hat. Ein Support-Team mit fünf Jahren Ticket-Historie hat zwar Hunderttausende Texte, aber oft keine verlässliche Markierung, welche Antwort das Problem tatsächlich gelöst hat.
Bevor ein Anwendungsfall in die Roadmap kommt, lohnt deshalb ein Tag Stichprobe: 100 zufällige Fälle ziehen und zählen, wie viele sich ohne Rückfrage bewerten lassen. Liegt der Anteil unter der Hälfte, beginnt das Projekt mit Datenarbeit.
Hier zeigt sich gute PM-Arbeit. Statt zu fragen, wo sich KI „einbauen“ ließe, sucht man die Stellen, an denen sie einen Arbeitsablauf messbar besser macht: niedrigere Kosten, gesparte Zeit, höhere Genauigkeit, früher erkannte Risiken oder eine Nutzererfahrung, die ohne KI nicht denkbar wäre. Welche dieser Formen im konkreten Produkt zählt, muss früh feststehen, denn daraus folgen später Metriken, Preis und Roadmap.
Welchen Wert die KI liefert, entscheidet über Metrik und Preis
Viele Teams beschreiben KI-Wert zu allgemein: Die Lösung sei „intelligenter“, „schneller“, „personalisierter“. Damit lässt sich nichts modellieren. Erst wenn klar ist, welche Form von Wert entsteht, wird aus einer technischen Möglichkeit eine Fähigkeit, die man in Euro ausdrücken kann.
In der Praxis gibt es sechs Wertpfade. KI senkt direkte Kosten, wenn sie manuelle Arbeit ersetzt oder verdichtet. Sie beschleunigt Prozesse und erhöht den Durchsatz, ohne dass zwingend weniger Personal nötig ist. Sie verbessert die Genauigkeit und senkt damit Fehler, Rückfragen und Eskalationen.
Sie erkennt Risiken früher, was in Compliance, Betrugsprävention oder Qualitätssicherung große Summen bewegt. Sie macht Oberflächen kontextsensitiver und hilfreicher. Und sie schafft neue Nutzungsmuster wie Copilots, dialogische Oberflächen oder Assistenten, die mehrere Schritte selbst ausführen.
Kaum ein Produkt braucht alle sechs gleich stark. Ein Assistent für Vertragsprüfung verdient sein Geld mit Risikoreduktion; ob er zwei Minuten schneller ist, interessiert die Rechtsabteilung wenig. Ein Support-Copilot lebt von der Zeitersparnis pro Ticket, dort zählt jede Sekunde.
Aus dem primären Hebel folgt alles Weitere. Liegt der Wert in Zeitersparnis, misst man Bearbeitungszeit und Durchsatz und rechnet den Preis gegen Personalkosten. Liegt er in Risikoreduktion, misst man vermiedene Fehler und deren Kosten, und der Preis orientiert sich am Schaden, der nicht eintritt. Liegt er in einer neuen Nutzungsform, muss sich das Pricing an Fähigkeit und Ergebnis orientieren, weil es keinen alten Prozess gibt, gegen den man rechnen könnte.
Eine einfache Regel hilft bei der Entscheidung: Können Kunde und Anbieter den Wert in derselben Einheit zählen, etwa erledigte Tickets oder geprüfte Verträge, taugt diese Einheit als Preismetrik. Lässt sich der Wert nur schätzen, etwa „bessere Entscheidungen“, gehört er in die Verkaufsargumentation, aber nicht auf die Rechnung.
Der Burggraben entsteht im System rund um das Modell
Was hält Wettbewerber davon ab, denselben Wert nachzubauen? Die Modellwahl kaum. Foundation-Modelle, APIs und Standardfähigkeiten werden schnell austauschbar, und ein Vorsprung, der auf einem bestimmten Modell beruht, hält bis zum nächsten Release des Anbieters.
Der eigentliche Modellcode ist nur ein kleiner Teil eines laufenden Systems. Der Rest ist Daten sammeln und aufbereiten, Einstellungen, Überwachung und die Technik, die Antworten an Nutzer ausliefert. Genau dort entsteht der Vorsprung, den andere nicht über Nacht kopieren.
Für die Strategie heißt das: Schwer zu kopieren wird ein KI-Produkt durch sorgfältig gepflegte Daten, aufbereitetes Fachwissen, eine gute Suche in den eigenen Dokumenten, tiefe Einbindung in die Arbeitsabläufe der Kunden und eine Technik für schnelle Tests und verlässliche Qualitätsprüfung. Ein Unternehmen, das Daten, Technik, Produkt und Lernen schneller verbindet als die Konkurrenz, ist schwerer zu kopieren als eines mit dem besten Modell.
Wer ein solches System bewusst bauen will, braucht eine Landkarte der nötigen Fähigkeiten, und sie hat vier Schichten. Auf der Datenschicht geht es darum, wie Daten fließen, gespeichert, für die Suche aufbereitet und von Menschen markiert werden. Auf der Modellschicht stehen Basismodelle, angepasste Modelle, die Anbindung eigener Dokumente (RAG) und die Qualitätstests.
Die Steuerungsschicht umfasst Prompts, Abläufe mit mehreren selbstständigen Schritten, die Wahl des passenden Modells je Anfrage und Notlösungen, wenn etwas schiefgeht. Die Experience-Schicht enthält, was Nutzer sehen: Copilots, Automatisierungsstrecken, Dashboards, Empfehlungen oder Dialogoberflächen.
Die Landkarte zwingt dazu, jede Fähigkeit mit vier Fragen zu verknüpfen. Welchen Nutzwert erzeugt sie? Welche technischen Grenzen bringt sie mit? Welche laufenden Kosten verursacht sie? Welche Anforderungen an Evaluation und Governance folgen daraus?
An dieser Stelle werden Zielkonflikte sichtbar. RAG oder Fine-Tuning? Ein kleineres Modell mit guter Orchestrierung oder mehr Modelltiefe? Caching oder dynamische Inferenz? Ein Szenariomodell rechnet diese Varianten mit realistischen Volumina durch. Entscheiden muss am Ende der PM.
Priorisiert werden Fähigkeiten
Mit der Landkarte ändert sich die Frage, was zuerst gebaut wird. Klassische Produktarbeit priorisiert Features. In KI-Produkten sitzt der Engpass meist eine Ebene tiefer. Eine Oberfläche ist schnell skizziert, aber wenn Datengrundlage, Evaluation oder Fallback nicht reif sind, bleibt jede Feature-Idee wirtschaftlich und operativ schwach.
Priorisiert werden deshalb Fähigkeiten statt Funktionen. Gefragt wird: Passen Problem und Modell zusammen? Reichen die Daten? Wie schnell und wie genau muss es sein? Wie viele Abhängigkeiten gibt es? Welche Risiken entstehen? Und geht die Rechnung auf? Die Leitfrage verschiebt sich von „Was liefern wir als Nächstes aus?“ zu „Welche Fähigkeit müssen wir aufbauen, damit wir wiederholbar Wert schaffen?“
Das hat handfeste Folgen für die Roadmap. Bessere Qualitätstests, eine stabilere Notlösung oder eine sauberer aufbereitete Suche sieht im nächsten Release niemand. Sie werden aber in jedem weiteren Anwendungsfall wiederverwendet und beschleunigen jede folgende Iteration.
Ein Beispiel: Baut ein Team einmal einen Evaluationsdatensatz mit 500 geprüften Fällen, kann es jeden Modellwechsel in Stunden statt Wochen bewerten. Ein Produkt mit weniger sichtbaren Funktionen, aber sauberen Daten, guter Evaluation und stabilen Kosten steht wirtschaftlich oft besser da als eines mit vielen Experimenten auf schwacher Basis.
Wie das in einer echten Abwägung aussieht, zeigt eine typische Quartalsplanung. Ein Team hat ein Quartal und zwei Kandidaten: einen neuen Zusammenfassungs-Button, den der Vertrieb sich wünscht, und den Evaluationsdatensatz. Der Button bringt vielleicht drei Prozent mehr Nutzung in einem Segment. Der Datensatz bringt keine sichtbare Änderung, verkürzt aber jeden der vier geplanten Modellwechsel des nächsten Jahres von drei Wochen auf drei Tage. Das sind knapp 50 eingesparte Arbeitstage, die in Features fließen können.
Wer nur Features vergleicht, wählt den Button. Wer Fähigkeiten vergleicht, sieht, dass der Datensatz den Button im Folgequartal mitfinanziert.
Nutzer- und Modellmetriken gehören in dieselbe Auswertung
Ob eine Fähigkeit Wert schafft, zeigt erst die Messung, und sie muss bei KI zwei Datenwelten verbinden. Aktivierung, Nutzungstiefe, Aufgabenabschluss, Zeitersparnis und Retention bleiben unverzichtbar, erzählen aber nur die halbe Geschichte. Die andere Hälfte ist das Verhalten des Modells: Wie oft liegt es richtig, wie viel findet es, wie passend sind die Antworten, wie oft erfindet es etwas, wie lange dauern Antworten, was kostet jede Anfrage und wird es mit der Zeit schlechter?
Beide Ebenen beeinflussen sich, oft mit Verzögerung. Sinkende Relevanz zeigt sich in der Retention manchmal erst Wochen später. Zu viele Halluzinationen zerstören Vertrauen. Steigende Inferenzkosten machen ein Segment unwirtschaftlich, das in den Engagement-Kennzahlen gesund aussieht.
Und Latenz kostet direkt Umsatz: Jede zusätzliche Wartezeit vor einer Antwort senkt die Wahrscheinlichkeit, dass Nutzer den Schritt abschließen. Ein größeres Modell, das offline besser abschneidet, kann online also verlieren, weil es langsamer ist.
Dazu kommt der Funnel. KI wirkt selten auf ein einzelnes Feature, meist auf Onboarding, Personalisierung, Upsell, Churn-Prävention und Monetarisierung zugleich. Die Instrumentierung muss deshalb den ganzen Funnel abdecken. Ein System, das das Onboarding verbessert und später die Kosten explodieren lässt, hat das Problem nur nach unten verschoben, wo es teurer wird.
Praktisch heißt das: Jedes KI-Ereignis im Tracking trägt neben der Nutzer-ID auch Modellversion, Tokenzahl und Latenz. Erst dann lässt sich fragen, unter welchen Modellbedingungen Nutzer bleiben.
Mit diesen Feldern wird eine Auswertung möglich, die sonst fehlt: Inferenzkosten pro aktivem Nutzer, aufgeteilt nach Segment und gegen den Umsatz pro Nutzer gestellt. Häufig zeigt sich dabei ein kleines Segment, etwa Nutzer, die ganze Dokumentenarchive hochladen, das ein Vielfaches des Durchschnitts kostet und im Engagement-Dashboard als besonders loyal glänzt.
Ob man diese Nutzer in einen höheren Tarif lenkt, ein Kontingent einführt oder ihr Verhalten bewusst subventioniert, ist eine Produktentscheidung. Treffen kann man sie nur, wenn beide Zahlen in derselben Tabelle stehen.
Ein KI-Experiment prüft das ganze System
Ein Test, welche Variante Nutzer lieber mögen, reicht bei KI nicht. Die zweite Frage ist, ob das System mit dieser Variante auch im Alltag trägt. Tests mit alten Daten sortieren schwache Kandidaten schnell aus. Erst Tests mit echten Nutzern zeigen reale Nutzung, Qualitätsverlust über die Zeit, typische Fehler und Kosten.
Viele KI-Teams kennen den Befund aus eigener Erfahrung: Bessere Offline-Metriken führen nicht verlässlich zu besseren Geschäftsergebnissen. Ohne Online-Test bleibt ein Benchmark-Erfolg eine Hypothese.
Ein valider Test betrachtet deshalb gleichzeitig das Ergebnis für den Nutzer, die Modellgüte, Sicherheitsmetriken, Systemlast, Latenz und Kosten. Darin unterscheiden sich KI-Experimente von vielen klassischen A/B-Tests, bei denen eine Konversionsrate genügt.
Eine brauchbare Entscheidungsregel für den Rollout sieht so aus: Die neue Variante gewinnt, wenn die Hauptmetrik steigt, die Kosten pro erledigter Aufgabe um nicht mehr als zehn Prozent zunehmen und die Latenz im 95. Perzentil unter der vorher festgelegten Grenze bleibt. Die Schwellen legt jedes Team vor dem Start selbst fest.
Dazu gehören Leitplanken. Produktmanager legen fest, wie viel Halluzination akzeptabel ist, welche Inhaltstypen ausgeschlossen sind, welche Fehlerschwellen gelten und wann ein Fallback greift. Ein Fallback, der bei unsicheren Antworten auf ein kleineres Modell oder eine Regel umschaltet, kostet fast immer weniger als die Schadensbegrenzung danach.
Für Produkte im europäischen Markt kommen die Pflichten aus dem EU AI Act hinzu, die je nach Risikoklasse gestaffelt greifen. Leitplanken, Protokollierung und menschliche Aufsicht gehören deshalb auch in die Kostenrechnung.
Ein System, das in Extremsituationen teuer, unsicher oder unkontrollierbar wird, ist kein belastbares Geschäftsmodell, so gut es im Test auch abschneidet.
Die Finanzlogik entscheidet, ob das Produkt trägt
Die Kosten, die jedes Experiment mitmisst, führen zum größten Unterschied zu traditionellem SaaS. KI bringt variable Kosten ins Zentrum des Produktmodells, und die Bruttomarge eines KI-Produkts erreicht deshalb selten das Niveau klassischer Software.
Inferenzkosten hängen von Modellgröße, Kontextlänge, Tokenvolumen, Anfragefrequenz und Caching ab. Verlangt ein Feature längere Kontexte oder eine tiefere Denkstufe des Modells (Reasoning), können sich die Bereitstellungskosten pro Kunde (Cost-to-Serve) abrupt verschieben.
Was ein KI-Workflow im Monat wirklich kostet
Die folgenden Zahlen sind frei gewählte Annahmen und keine Benchmark-Werte. Sie zeigen nur, wie schnell Aufschläge die reale Cost-to-Serve über den Listenpreis treiben.
Angenommen, ein Enterprise-Kunde löst 20.000 KI-Aktionen pro Monat aus, im Schnitt 8.000 Input- und 1.500 Output-Tokens je Aktion. Bei angenommenen 5 € pro Million Input- und 15 € pro Million Output-Tokens kostet eine Aktion 8.000 / 1.000.000 × 5 € + 1.500 / 1.000.000 × 15 € = 0,04 € + 0,0225 € = 0,0625 €. Das ergibt einen nominalen Modellpreis von 20.000 × 0,0625 € = 1.250 € pro Monat.
Jetzt die realistischen Aufschläge: Werden 12 Prozent der Aufrufe einmal wiederholt, kommen 0,12 × 1.250 € = 150 € hinzu. Eskalieren 5 Prozent auf ein rund dreimal teureres Modell, sind das 0,05 × 1.250 € × 2 = 125 €.
Auf die bisherigen Modellkosten von 1.525 € seien für Retrieval, Vektor-Lookup, Logging und Monitoring pauschal 20 Prozent veranschlagt, also rund 305 €. Die Cost-to-Serve liegt damit bei etwa 1.250 € + 150 € + 125 € + 305 € = 1.830 €, also 46,4 Prozent über den zunächst berechneten Modellkosten.
Die wirksamen Hebel sind Wiederholungsquote, Eskalationsrate und Kontextlänge. Der Listenpreis gehört nicht dazu. Verdoppelt der Kunde sein Volumen oder steigt der Modellpreis, kippt die Marge genau an den Stellen, die in der ersten Kalkulation fehlten.
Der Hebel Kontextlänge lässt sich im selben Beispiel beziffern. Angenommen, 6.000 der 8.000 Input-Tokens sind stabiler Systemprompt und Wissenskontext. Große Anbieter rechnen Cache-Treffer deutlich unter dem normalen Input-Preis ab; angenommen sei ein Zehntel, während das Schreiben in den Cache etwas mehr kostet als eine normale Anfrage.
Bei hoher Trefferquote sinken die Input-Kosten je Aktion von 0,04 € auf etwa 0,013 € (2.000 Tokens zum vollen Preis, 6.000 zum Zehntel), die Aktion kostet dann rund 0,036 € statt 0,0625 €. Das sind gut 40 Prozent weniger, ohne dass Nutzer etwas merken.
Ein zweiter Hebel betrifft Aufgaben, die nicht sofort fertig sein müssen: Stapelverarbeitung, bei der das Ergebnis bis zu einen Tag dauern darf, rechnen die Anbieter deutlich günstiger ab als Echtzeitanfragen. Nächtliche Berichte und Massenklassifikation gehören dorthin, nicht in den teuren Echtzeitpfad.
Hinzu kommen laufende Kosten für Pflege und Nachtrainieren. Daten aufbereiten und markieren, Modelle anpassen, Qualität prüfen, alte Fehler erneut testen, die Technik ausbauen und das Modell überwachen: Das alles läuft dauerhaft, in einer Form, die klassisches SaaS nicht kennt.
Viele Teams unterschätzen diese Ebene, weil sie sich auf den ersten Build konzentrieren. Oft wird erst der langfristige Modellbetrieb zur eigentlichen wirtschaftlichen Herausforderung.
Beim Pricing stehen mehrere Grundmuster offen: nutzungsbasiert, stufenbasiert, wertbasiert oder hybrid. Welches passt, hängt von Wertlogik und Kostenstruktur ab. Wer hohe verbrauchsabhängige Kosten trägt, denkt eher nutzungsbasiert oder hybrid. Wer ein klar zählbares Ergebnis liefert, kann wertbasiert argumentieren.
Für den Kunden aus dem Rechenbeispiel heißt das konkret: Liegt der Vertragspreis bei 4.000 Euro im Monat, bleiben nach 1.830 Euro Cost-to-Serve gut 54 Prozent Bruttomarge, weit unter dem, was klassisches SaaS gewohnt ist. Verdoppelt der Kunde sein Volumen bei Festpreis, fällt die Marge auf etwa 8,5 Prozent. Ein Kontingent mit Preis für Mehrverbrauch verhindert das.
ROI-Modelle brauchen ebenfalls mehrere Szenarien. Automatisierung, weniger manueller Aufwand, bessere Entscheidungen, geringeres Risiko oder neue Umsätze sind valide Treiber, ihr Effekt bleibt aber eine Annahme. Ein erwarteter, ein optimistischer und ein pessimistischer Fall genügen oft. Die Annahmen darin muss der PM selbst vertreten können.
Wann sich die ganze Modellierung nicht lohnt
Gegen diesen Aufwand scheint das Tempo zu sprechen, mit dem Modellpreise fallen: Jede Kostenrechnung ist in sechs Monaten veraltet. Warum also nicht einfach bauen, wachsen und den Preisverfall die Marge reparieren lassen?
Für einen Teil der Fälle stimmt das. Ein internes Werkzeug mit ein paar hundert Nutzern, dessen Inferenzkosten unter fünf Prozent des Budgets liegen, braucht keine Cost-to-Serve-Rechnung auf drei Nachkommastellen. Ein früher Prototyp, der erst Nachfrage beweisen muss, auch nicht. Dort ist Geschwindigkeit wichtiger als Präzision.
Das Argument hat aber drei Lücken. Erstens wächst die Nutzung oft schneller, als die Preise fallen, und neue Funktionen greifen zu größeren Modellen und längeren Kontexten. Zweitens hängen Wiederholungsquote, Eskalationsrate und Lebenszykluskosten gar nicht am Listenpreis. Drittens werden Preise gegenüber Kunden einmal festgelegt und lassen sich schwer nach oben korrigieren.
Im Rechenbeispiel lässt sich das nachprüfen. Halbiert sich der Modellpreis, während der Kunde sein Volumen verdoppelt, bleibt die Cost-to-Serve bei rund 1.830 Euro, denn Wiederholungen, Eskalationen und Infrastruktur wachsen mit. Die Marge des Festpreisvertrags wird dadurch um keinen Prozentpunkt besser.
Die Faustregel daraus: Sobald ein KI-Feature extern verkauft wird oder seine Inferenzkosten zehn Prozent des Umsatzes übersteigen, gehört die Rechnung auf den Tisch.
Zwei Blätter: Schichten und Cost-to-Serve
Ein KI-Produkt scheitert erstaunlich oft an der Nahtstelle zwischen Produkt, Data Science, Engineering, Governance und Betrieb. Ein praktischer Einstieg braucht trotzdem nur zwei Blätter Papier.
Auf das erste kommen die vier Schichten aus der Fähigkeitslandkarte (Daten, Modell, Steuerung, Experience), jeweils mit einer ehrlichen Einschätzung, wie belastbar sie im eigenen Produkt heute sind. In vielen Teams liegt die Schwäche gar nicht in der Experience-Schicht, an der die Roadmap gerade arbeitet; häufiger hapert es an Evaluation, Fallback oder Datenqualität.
Auf das zweite Blatt gehört eine Cost-to-Serve-Rechnung nach dem Muster oben, mit den echten Wiederholungs- und Eskalationsquoten und der tatsächlichen Kontextlänge.
Aus beiden Blättern ergibt sich die Priorität fast von selbst. Ist die schwächste Schicht zugleich der größte Kostentreiber, gehört ihr Ausbau vor jedes neue Feature, auch wenn er im nächsten Release unsichtbar bleibt. Ist sie es nicht, lohnt zuerst ein Experiment, das Nutzer- und Modellmetriken gemeinsam misst, bevor Budget in den Umbau fließt.
Die Zahlen auf dem zweiten Blatt bleiben dabei nicht stehen. Wiederholungs- und Eskalationsquoten verschieben sich mit jedem Modellwechsel und jeder Verlängerung des Kontexts, und ein Feature, das im Pilot profitabel wirkte, kann danach Geld kosten, ohne dass sich an der Oberfläche etwas ändert. Wer beide Blätter jedes Quartal und nach jedem Modellwechsel neu ausfüllt, sieht das, bevor es die Quartalszahlen zeigen.