[{"data":1,"prerenderedAt":822},["ShallowReactive",2],{"essay-warum-ich-aufgehoert-habe-roadmaps-zu-zeigen":3,"essays-others-warum-ich-aufgehoert-habe-roadmaps-zu-zeigen":133},{"id":4,"title":5,"body":6,"date":119,"description":112,"extension":120,"featured":121,"lang":122,"meta":123,"minutes":124,"navigation":121,"path":125,"seo":126,"stem":127,"tags":128,"teaser":15,"words":131,"__hash__":132},"essays\u002Fessays\u002Fwarum-ich-aufgehoert-habe-roadmaps-zu-zeigen.md","Warum ich aufgehört habe, Roadmaps zu zeigen.",{"type":7,"value":8,"toc":111},"minimark",[9,16,19,24,27,30,42,48,52,55,78,81,85,88,95,98,102,105,108],[10,11,12],"blockquote",{},[13,14,15],"p",{},"Eine Roadmap ist ein Versprechen an Menschen, die nicht dafür bezahlen. Ein OKR ist ein Versprechen an Menschen, die dafür bezahlen. Der Unterschied ist alles.",[13,17,18],{},"Vor drei Jahren war ich stolz auf meine Roadmaps. Miro-Boards mit Swimlanes, farblich nach Confidence codiert, quartalsweise aktualisiert. Ich zeigte sie in Board-Meetings, in Sales-Kickoffs, in All-Hands. Leute klatschten höflich. Dann gingen sie zurück an ihre Arbeit und nichts änderte sich.",[20,21,23],"h2",{"id":22},"die-roadmap-ist-das-falsche-artefakt","Die Roadmap ist das falsche Artefakt.",[13,25,26],{},"Ich habe angefangen zu beobachten, was Menschen mit Roadmaps machen. Engineering nickt und arbeitet weiter an dem, was sie für richtig halten. Sales verspricht den ersten drei Features dem nächsten Großkunden. Marketing plant Launches für Daten, die nicht existieren. Customer Success beruhigt Kunden über Dinge, die sich ändern werden.",[13,28,29],{},"Niemand trifft bessere Entscheidungen, weil sie die Roadmap gesehen haben. Sie treffen die gleichen Entscheidungen — nur mit mehr Kontext, um sie zu rechtfertigen.",[13,31,32,33,37,38,41],{},"Der zentrale Denkfehler: Eine Roadmap beschreibt ",[34,35,36],"em",{},"was wir bauen werden",". Aber das ist nicht die Information, die jemand braucht, um gute Entscheidungen zu treffen. Was sie brauchen, ist ",[34,39,40],{},"warum wir es bauen",".",[43,44,45],"callout",{},[13,46,47],{},"Eine gute Roadmap macht das Team effizient. Ein gutes Ziel macht das Team effektiv. Effektivität schlägt Effizienz jeden Tag.",[20,49,51],{"id":50},"was-ich-stattdessen-zeige","Was ich stattdessen zeige.",[13,53,54],{},"Drei Dinge, in dieser Reihenfolge:",[56,57,58,66,72],"ol",{},[59,60,61,65],"li",{},[62,63,64],"strong",{},"Die Frage, die wir beantworten."," Eine Frage pro Quartal. „Können wir die Bruttomarge auf 75 % heben, ohne ACV zu verlieren?\" Das ist eine Frage, die man beantworten kann. „Value-Based-Pricing einführen\" ist keine Frage — es ist eine Vorannahme der Antwort.",[59,67,68,71],{},[62,69,70],{},"Die Metrik, die die Antwort definiert."," Bruttomarge. ACV. Zwei Zahlen, beide öffentlich, beide wöchentlich aktualisiert. Jeder im Unternehmen kann jederzeit sehen, ob wir näher an der Antwort sind oder nicht.",[59,73,74,77],{},[62,75,76],{},"Die drei Hypothesen, die wir testen."," Nicht Features. Hypothesen. „Wenn wir Seat-Pricing abschaffen, steigt ACV.\" „Wenn wir Discount-Guardrails einführen, sinkt die Rabatt-Rate ohne Win-Rate-Verlust.\" Jede Hypothese wird zu einer Experiment-Serie, nicht zu einem Feature.",[13,79,80],{},"Das Dokument ist eine Seite. Es ändert sich zwei- bis dreimal pro Quartal. Niemand vermisst die Miro-Boards.",[20,82,84],{"id":83},"was-die-roadmap-wirklich-war","Was die Roadmap wirklich war.",[13,86,87],{},"Rückblickend war die Roadmap nie ein Kommunikations-Artefakt. Sie war ein Beruhigungs-Artefakt. Für mich.",[13,89,90,91,94],{},"Solange ich eine Roadmap hatte, fühlte ich mich wie ein PM mit Plan. Ich konnte sie im Meeting öffnen, auf ein Quadrat zeigen und sagen: „Das kommt in Q3.\" Ich fühlte mich vorbereitet. Niemand fragte die schwierige Frage — ",[34,92,93],{},"warum gerade dieses Quadrat und nicht ein anderes?"," — weil das Artefakt die Frage beantwortete zu haben schien.",[13,96,97],{},"Ohne Roadmap muss ich auf jede Feature-Anfrage antworten mit: „Okay, welche Frage beantwortet das? Welche Metrik bewegt das?\" Das ist unbequem. Es fühlt sich langsamer an. Es ist schneller.",[20,99,101],{"id":100},"was-ich-noch-nicht-weiß","Was ich noch nicht weiß.",[13,103,104],{},"Das funktioniert in einem Umfeld, in dem Quartale als Planungs-Einheit akzeptiert sind und ich Goodwill beim Leadership aufgebaut habe. Ob es bei einem Consumer-Produkt mit wöchentlichen Releases funktioniert — keine Ahnung. Ob es in einem Unternehmen mit 500+ Leuten und politischer Komplexität funktioniert — auch keine Ahnung.",[13,106,107],{},"Der Kern-Mechanismus scheint mir universeller: die Frage schlägt das Feature. Die Metrik schlägt die Deadline. Die Hypothese schlägt die Promise.",[13,109,110],{},"— PJ, April 2026",{"title":112,"searchDepth":113,"depth":113,"links":114},"",2,[115,116,117,118],{"id":22,"depth":113,"text":23},{"id":50,"depth":113,"text":51},{"id":83,"depth":113,"text":84},{"id":100,"depth":113,"text":101},"2026-04-18","md",true,"de",{},9,"\u002Fessays\u002Fwarum-ich-aufgehoert-habe-roadmaps-zu-zeigen",{"title":5,"description":112},"essays\u002Fwarum-ich-aufgehoert-habe-roadmaps-zu-zeigen",[129,130],"Produkt","Führung",1742,"E1VONh91sLlpfXktWv62Eze112flEGD2fCIXsatMqVY",[134,645],{"id":135,"title":136,"body":137,"date":629,"description":112,"extension":120,"featured":121,"lang":122,"meta":630,"minutes":631,"navigation":121,"path":632,"seo":633,"stem":634,"tags":635,"teaser":642,"words":643,"__hash__":644},"essays\u002Fessays\u002Fcompetitor-to-prd-system.md","Competitor-to-PRD: Wie ich kompetitive Recherche in Stunden statt Wochen mache.",{"type":7,"value":138,"toc":612},[139,144,151,155,158,161,181,184,188,195,198,201,205,208,211,215,222,237,240,248,251,255,258,265,268,271,278,282,292,295,299,302,346,349,352,356,363,366,387,390,393,401,404,408,415,418,421,424,431,434,438,441,477,480,484,487,490,493,496,500,503,506,509,516,519,523,526,562,565,569,572,575,578,589,593,601,609],[10,140,141],{},[13,142,143],{},"Vor zwei Jahren war kompetitive Recherche bei mir ein Drei-Wochen-Job: lesen, vergleichen, Confluence-Seiten füllen, in Reviews präsentieren. Am Ende lag eine Feature-Tabelle vor, die niemand mehr anfasste. Heute brauche ich für dieselbe Tiefe rund 34 Minuten Pipeline plus Gates — und am Ende liegt ein PRD, kein Friedhof.",[13,145,146],{},[147,148],"img",{"alt":149,"src":150},"Competitor-to-PRD-Pipeline mit fünf Stages, drei Decision-Gates und rund 500.000 billed Tokens Budget","\u002Finfographics\u002Fcompetitor-to-prd-pipeline.png",[20,152,154],{"id":153},"warum-klassische-wettbewerbs-analysen-scheitern","Warum klassische Wettbewerbs-Analysen scheitern.",[13,156,157],{},"Die meisten Analysen, die ich in den letzten Jahren gesehen habe, leiden am gleichen Problem: Sie produzieren Vergleichs-Tabellen statt Entscheidungen. 47 Features in Spalten gegen vier Wettbewerber. Hübsch sortiert. Komplett unbrauchbar für die Frage, die eigentlich beantwortet werden sollte: was bauen wir, was nicht, und warum?",[13,159,160],{},"Drei Anti-Pattern tauchen immer wieder auf:",[56,162,163,169,175],{},[59,164,165,168],{},[62,166,167],{},"Confluence-Friedhof."," Die Recherche wird in eine schöne Seite gegossen, das Team klickt einmal drauf, dann nie wieder. Nichts in dem Dokument zwingt zu einer Folgeentscheidung. Es ist ein Wissens-Artefakt, kein Entscheidungs-Artefakt.",[59,170,171,174],{},[62,172,173],{},"Feature-Bingo."," Jeder Wettbewerber kriegt Häkchen für seine Features. Daraus wird abgeleitet, was wir auch brauchen. Niemand fragt, ob das Feature beim Wettbewerber überhaupt funktioniert oder ob die Zielgruppe es nutzt.",[59,176,177,180],{},[62,178,179],{},"Buzzword-Diff."," \"Wir sind anders, weil wir KI machen.\" Andere Anbieter machen auch KI. Sechs Monate später ist KI commodity, und die behauptete Differenzierung ist verbrannt.",[13,182,183],{},"Das eigentliche Problem ist nicht der Aufwand. Es ist der Output. Eine Wettbewerbs-Analyse, die nicht in einem Spec endet, ist nur Wissens-Sammelei.",[20,185,187],{"id":186},"der-output-den-ich-will","Der Output, den ich will.",[13,189,190,191,41],{},"Wenn ich heute eine Recherche starte, ist das Zielartefakt ein PRD mit zwölf Sektionen: Problem, Personas, optionaler regulatorischer Rahmen, Scope mit expliziten Non-Goals, funktionale Anforderungen mit Reference-by-ID, nicht-funktionale Anforderungen, Metriken getrennt nach Leading und Lagging, Open Questions mit Owner-Spalte, Timeline. Das Spec ist deterministisch genug, dass eine Implementierungs-Planung direkt daran andocken kann — bei mir ist der Folgeschritt fast immer ",[192,193,194],"code",{},"\u002Fsuperpowers:writing-plans",[13,196,197],{},"Diese PRD-Struktur erzwingt Disziplin. Wer \"Scope\" schreiben muss, muss \"Non-Goals\" auch schreiben. Wer \"Metriken\" füllt, muss zwischen Leading und Lagging unterscheiden. Wer \"Open Questions\" listet, muss Owner zuweisen. Das ist die andere Hälfte des Outputs: nicht nur, was wir wissen, sondern was wir explizit nicht wissen — und wer es klären muss.",[13,199,200],{},"Damit ändert sich die Frage. Sie lautet nicht mehr \"wie analysiere ich Wettbewerber?\". Sie lautet \"wie komme ich von einer URL zu einem ausführbaren Spec?\". Und das ist eine Frage über Pipeline-Design.",[20,202,204],{"id":203},"das-system-auf-einen-blick","Das System auf einen Blick.",[13,206,207],{},"Fünf Stages, drei Decision-Gates. Die Infografik oben zeigt die Topologie. Hier die Logik dahinter, Stage für Stage.",[13,209,210],{},"Eingabe ist immer dasselbe Trio: eine Wettbewerber-URL, der Name meines geplanten Produkts, optional eine regulatorische Domain (steuer-de, finanz-eu, gesundheit-de — was immer relevant ist). Mehr nicht. Alle weiteren Entscheidungen fallen unterwegs an Gates.",[20,212,214],{"id":213},"stage-0-discovery-pruning","Stage 0 — Discovery + Pruning.",[13,216,217,218,221],{},"Erster Schritt ist deterministisch und fast kostenlos: robots.txt lesen, sitemap.xml fetchen, alle URLs nach Sektion kategorisieren, dedupen. Das passiert ohne LLM-Call, einfach mit ",[192,219,220],{},"curl"," und einem kleinen Parser. Output ist eine Liste mit typischerweise 200 bis 500 URLs, gruppiert nach Pfad-Präfix.",[13,223,224,225,228,229,232,233,236],{},"Was hier sichtbar wird, ist überraschend wertvoll. Die Sektionsverteilung zeigt, wo der Wettbewerber sein Gewicht hinlegt. 280 URLs im ",[192,226,227],{},"\u002Fwissen-*","-Bereich heißt: Content-Marketing ist ein wesentlicher Akquise-Kanal. 12 URLs unter ",[192,230,231],{},"\u002Ffunktionen"," und 18 unter ",[192,234,235],{},"\u002Fbranche"," sagt: schlanker Funktionsumfang, breite Branchen-Aufstellung. Das ist eine Hypothese über die Go-to-Market-Strategie, bevor eine einzige Feature-Page extrahiert wurde.",[13,238,239],{},"Dann folgt der erste Gate.",[43,241,242],{},[13,243,244,247],{},[62,245,246],{},"Gate 1 — User bestätigt Filter."," Welche Sektionen werden in Stage 1 extrahiert? Presse, Autoren, Legal, Cookies werden meist ausgeschlossen. Übrig bleiben oft nur 60 bis 100 URLs. Hier sitzt mein wichtigster Hebel auf das Token-Budget — und damit auf die Kosten der gesamten Analyse.",[13,249,250],{},"Wer Gate 1 überspringt, bezahlt das in Stage 1 mit dem Drei- bis Fünffachen an Token-Kosten. Schlimmer noch: das Modell muss sich durch hundert Pressemitteilungen kämpfen, die für das PRD nichts beitragen.",[20,252,254],{"id":253},"stage-1-parallele-extraktion","Stage 1 — Parallele Extraktion.",[13,256,257],{},"Jetzt wird teuer. Die approved URLs werden in Batches zu je etwa 15 Stück aufgeteilt und an parallele Subagents übergeben. Acht Sonnet-Subagents gleichzeitig, jeder fetcht seine Batch, strippt Boilerplate, extrahiert nach einem festen Schema: Feature-Name, Beschreibung, Trust-Signal, Integration, Pricing-Hinweis, regulatorische Referenz. Der Output ist JSONL, eine Zeile pro Page.",[13,259,260,261,264],{},"Parallel läuft ",[192,262,263],{},"competitor-research-brief",". Das Skill schaut sich gezielt die Schlüssel-URLs an: Homepage, Pricing-Seite, Integrations-Liste, API-Doku, Changelog, Reviews, gegebenenfalls GitHub-Org. Output ist eine YAML-Datei mit Pricing-Modell, Integrationen, USPs, Schwächen aus Reviews, Trust-Signalen.",[13,266,267],{},"Wenn die regulatorische Domain gesetzt ist, läuft zusätzlich ein dritter Strang: ein zielgerichteter Scan auf Compliance-, Legal- und Security-Seiten. GoBD, DSGVO, ISO 27001, EN 16931 — alles, was später im PRD als R-Sektion landet.",[13,269,270],{},"Drei Subskill-Stränge, alle parallel, alle deterministisch im Output-Schema. Token-Budget für diesen Schritt (Harness-billed, inkl. System-Prompt-Overhead): gemessen rund 360.000 für 88 URLs. Der größte Brocken der gesamten Pipeline. Und der Punkt, an dem ich nicht spare — weil die Qualität dieser Extraktion die Qualität jeder Folgestufe diktiert.",[13,272,273,274,277],{},"Warum YAML und JSONL statt Markdown? Weil Markdown für Menschen ist und alle Folgeschritte für Maschinen. JSONL ist append-safe, lässt sich pro Subagent batchen, lässt sich mit ",[192,275,276],{},"jq"," deterministisch zusammenführen. Markdown muss man parsen — und jeder Parser ist eine Fehlerquelle. Wer auf YAML\u002FJSONL setzt, kriegt Stage 2 fast geschenkt.",[20,279,281],{"id":280},"stage-2-deterministic-merge","Stage 2 — Deterministic Merge.",[13,283,284,285,287,288,291],{},"Stage 2 ist die einzige Stufe ohne LLM-Call. ",[192,286,276],{}," und Bash. Alle Batch-Files werden zu einer pages.jsonl konkateniert, eine Feature-Taxonomy aggregiert, Trust-Signals gerollt, ein Regulatorischer-Index gebaut. Output ist eine ",[192,289,290],{},"research-master.yaml"," mit Statistiken und Pointern auf alles andere.",[13,293,294],{},"Dieser Schritt kostet praktisch nichts — keine Tokens, keine API-Calls, läuft in Sekunden. Aber er gibt mir ein Artefakt, das ich auf dem nächsten Gate dem Auftraggeber vorlegen kann, ohne dass jemand 80 Pages lesen muss. Eine Tabelle mit \"Extracted: 88 Pages, 47 Features in 12 Modulen, 18 regulatorische Referenzen\" trägt mehr Information als die 80 Pages selbst.",[20,296,298],{"id":297},"gate-2-der-gate-an-dem-80-prozent-scheitern","Gate 2 — Der Gate, an dem 80 Prozent scheitern.",[13,300,301],{},"Hier kommt der Punkt, an dem die meisten Wettbewerbs-Analysen kippen. Nicht weil die Recherche schlecht ist, sondern weil die Folgefragen nicht beantwortet werden. Sieben Themen, die ich an diesem Gate immer durchgehe:",[56,303,304,310,316,322,328,334,340],{},[59,305,306,309],{},[62,307,308],{},"Produktname."," Klingt trivial. Ist es nicht. Wer hier blockiert, blockiert die ganze PRD-Synthese.",[59,311,312,315],{},[62,313,314],{},"Zielgruppe."," Konkret. Größe, Branche, Funktion. \"KMU\" ist keine Antwort. \"DACH-Steuerberater mit 1 bis 5 Mitarbeitern, primär selbstständig, Buchführungs-Background\" ist eine.",[59,317,318,321],{},[62,319,320],{},"Non-Goals."," Drei bis fünf Dinge, die explizit nicht gebaut werden. Ohne Non-Goals ist das PRD immer zu groß, weil Scope-Creep durch die Feature-Liste des Wettbewerbers droht.",[59,323,324,327],{},[62,325,326],{},"Differenzierung."," Welche Achse? Preis, UX, Nische, Compliance, Integration, Geschwindigkeit? Eine Hauptachse, eine sekundäre, fertig. Wer drei Achsen will, gewinnt auf keiner.",[59,329,330,333],{},[62,331,332],{},"Tech-Stack."," Frontend, Backend, DB, Hosting. Oft kommt das aus existierenden CLAUDE.md-Defaults; wenn nicht, muss es jetzt entschieden werden, weil es non-funktionale Anforderungen direkt beeinflusst.",[59,335,336,339],{},[62,337,338],{},"Compliance-Constraints."," Wenn die regulatorische Domain gesetzt war, listet die brief.yaml hier konkrete Regelwerke. Ich filtere auf das, was relevant ist, lasse den Rest weg.",[59,341,342,345],{},[62,343,344],{},"Erfolgs-Kriterien."," Fünf bis zehn Metriken, getrennt in Leading (1 bis 4 Wochen sichtbar) und Lagging (3 bis 6 Monate sichtbar). Wer das nicht trennt, optimiert auf Vanity-Metriken.",[13,347,348],{},"Plus: Owner für Open Questions. Wer entscheidet, wenn unterwegs etwas auftaucht, das nicht im Scope geklärt wurde? Engineering-Lead, Compliance-Partner, Sales — drei bis fünf Namen, mit Zuständigkeit.",[13,350,351],{},"Wenn dieser Gate sauber durchgespielt ist, ist die eigentliche Produktarbeit getan. Der Rest ist Synthese.",[20,353,355],{"id":354},"stage-35-usp-derivation-wenn-mans-ernst-meint","Stage 3.5 — USP-Derivation, wenn man's ernst meint.",[13,357,358,359,362],{},"Optionaler Zwischenschritt, den ich für jedes Produkt empfehle, bei dem Differenzierung später eine Rolle spielt — also faktisch alle. ",[192,360,361],{},"competitor-innovation-derive"," nimmt pages.jsonl und brief.yaml als Input und macht etwas, das mir manuell selten gelingt: es klassifiziert die USPs des Wettbewerbers nach Defensibility.",[13,364,365],{},"Drei Kategorien:",[367,368,369,375,381],"ul",{},[59,370,371,374],{},[62,372,373],{},"Commoditized by AI."," Features, die durch Foundation-Models in 12 bis 18 Monaten Standard werden. Auto-Kategorisierung, Text-Generierung, einfache Klassifikation. Wer hier ein USP aufbaut, baut auf Sand.",[59,376,377,380],{},[62,378,379],{},"Genuine Moat."," Features, die durch Daten-Zugang, Integrationen, Regulatorik oder Network-Effects geschützt sind. DACH-Banking-Anbindungen, GoBD-Auditierung, branchenspezifische Compliance-Bibliotheken. Diese Sachen kostet ein Wettbewerber Monate bis Jahre, nicht Wochen.",[59,382,383,386],{},[62,384,385],{},"Emerging Moat."," Features, die heute commodity-nahe sind, aber sich durch Setup-Tiefe oder Integration verteidigen lassen.",[13,388,389],{},"Dann läuft eine JTBD-Gap-Analyse: welche Jobs-to-be-done sind im Markt sichtbar, aber von niemandem ordentlich bedient? Plus Blue-Ocean ERRC: was eliminieren, reduzieren, erhöhen, neu schaffen? Plus AI-Native- und Mobile-Native-Lens-Scans.",[13,391,392],{},"Output ist eine innovation.yaml mit zwei bis vier USP-Kandidaten, jeder bewertet auf Spezifität, Defensibility, Implementierbarkeit-im-MVP, Kompatibilität-mit-Non-Goals, Trust-Fit, Post-AI-Durability. Dazu Dunford-Positioning-Statements für jeden Kandidaten — die \"For X who do Y, our product is Z that enables W, unlike ABC, we DEF\"-Variante.",[43,394,395],{},[13,396,397,400],{},[62,398,399],{},"Gate 2.5 — Top-USPs bestätigen."," Welche zwei bis drei USPs sollen die nächsten 18 Monate tragen? Das ist die Differenzierungs-Entscheidung. Sie geht in §5.3 des PRD und prägt jede Folge-Entscheidung über Features.",[13,402,403],{},"Dieser Schritt kostet 15.000 bis 20.000 Tokens. Verglichen mit dem Rest der Pipeline ist das billig. Verglichen mit der Wahrscheinlichkeit, ein \"Compliance-First\"-Produkt zu bauen, das in 12 Monaten von Foundation-Model-Updates eingeholt wird, ist es geschenkt.",[20,405,407],{"id":406},"stage-4-prd-synthese","Stage 4 — PRD-Synthese.",[13,409,410,411,414],{},"Letzter LLM-Schritt. ",[192,412,413],{},"prd-from-competitor"," liest pages.jsonl, brief.yaml und optional innovation.yaml, kombiniert das mit den User-Antworten aus Gate 2, und rendert das PRD nach einem festen Template.",[13,416,417],{},"Was ich besonders schätze: Reference-by-ID durchgängig. Statt dass das PRD 20 Mal \"siehe oben\" schreibt, hat jedes Element eine ID — D1 für ein Differenziator-Item, R2 für eine Regulierungs-Referenz, F4 für ein Funktional-Modul, U1 für einen USP. Die §6 Funktionale Anforderungen referenzieren §4 Regulatorischer Rahmen über die R-IDs, statt die Compliance-Anforderung dreimal zu wiederholen.",[13,419,420],{},"Effekt: Die PRD ist 30 bis 40 Prozent kürzer als eine konventionell geschriebene Variante derselben Tiefe. Und sie ist konsistenter, weil dieselbe Anforderung nicht zweimal in leicht unterschiedlichen Worten dasteht.",[13,422,423],{},"Token-Budget hier: 8.000 bis 20.000. Wenig, weil das Modell überwiegend strukturiert rendert, nicht synthetisiert. Die schwere Arbeit ist in Stage 1 und 3.5 passiert.",[13,425,426,427,430],{},"Output ist eine Markdown-Datei ",[192,428,429],{},"{date}-{produktname}.design.md"," mit §1 Preamble, §2 Problem Statement, §3 Personas, §4 Regulatorischer Rahmen R1 bis Rn, §5 Scope (In, Out, Differenzierung), §6 F1 bis Fn, §7 NF1 bis NF5, §8 Metrics Leading\u002FLagging, §9 Open Questions mit Owner-Spalte, §10 Timeline, §11 Next Steps, §12 Glossar.",[13,432,433],{},"Diese Markdown-Datei ist das Ende der Pipeline und der Anfang der Implementierungs-Planung.",[20,435,437],{"id":436},"wann-das-system-nicht-funktioniert","Wann das System nicht funktioniert.",[13,439,440],{},"Damit das hier kein Pitch wird: das System hat klare Bruchstellen. Die wichtigsten:",[367,442,443,449,459,465,471],{},[59,444,445,448],{},[62,446,447],{},"Keine sitemap.xml, kein robots.txt."," Stage 0 funktioniert nicht. Die meisten seriösen B2B-Wettbewerber haben beides; aber Stealth-Startups und Consumer-Apps oft nicht. Workaround ist manuelle URL-Listen-Erstellung; dann ist die Discovery-Stage manuell.",[59,450,451,454,455,458],{},[62,452,453],{},"JS-only-Sites."," Single-Page-Apps, die ihren Content per Client-Side-Rendering liefern, geben einem ",[192,456,457],{},"WebFetch","-Call wenig zurück. Da hilft nur Headless-Browser-Rendering oder eine andere Datenquelle (Wayback-Machine, Crunchbase, G2-Reviews).",[59,460,461,464],{},[62,462,463],{},"Regulierte Domain ohne Public-Compliance-Pages."," Wenn der Wettbewerber GoBD-konform ist, das aber nirgends auf seiner Website steht, kommt der Compliance-Strang leer zurück. Mitigation ist Sales-Enablement-Dokumente per Anfrage oder Reviews als Proxy.",[59,466,467,470],{},[62,468,469],{},"Wettbewerber-Vergleich, nicht Produkt-Bauen."," Wenn ich nur einen reinen Markt-Report brauche, ist die PRD-Synthese am Ende Overkill. Dann reicht Stage 0 bis 2 plus brief.yaml, und ich höre vor Gate 2 auf.",[59,472,473,476],{},[62,474,475],{},"Audience-Diskrepanz."," Wenn meine Zielgruppe deutlich anders ist als die des analysierten Wettbewerbers, sind dessen Features nur begrenzt aussagekräftig. Dann macht Cross-Synthesis mit drei bis fünf Wettbewerbern aus benachbarten Segmenten mehr Sinn.",[13,478,479],{},"Diese Liste ist nicht vollständig. Aber sie ist ehrlich. Ich habe in den letzten Monaten mindestens drei Pipeline-Läufe abgebrochen, weil eine dieser Bruchstellen zu früh sichtbar wurde — und das ist okay, der Pruning-Gate fängt das ab, bevor die teure Stage 1 anläuft.",[20,481,483],{"id":482},"cross-synthesis-wenn-fünf-wettbewerber-im-spiel-sind","Cross-Synthesis: wenn fünf Wettbewerber im Spiel sind.",[13,485,486],{},"Kurz erwähnt, weil es ein nächstes Playbook wert ist: Wenn ich nicht einen, sondern drei bis zehn Wettbewerber habe, gibt es eine Meta-Pipeline, die alle bestehenden brief.yaml-Dateien einließt und einen Markt-Index baut. Aus dem werden zwei bis vier Produkt-Kandidaten in unterschiedlichen Lenses generiert: Micro-Player, AI-native, Mobile-native, Compliance-Moat, Vertikal-Spezialist, Bundle-Plattform.",[13,488,489],{},"Jeder Kandidat zitiert mindestens zwei Wettbewerber als Beleg für Markt-Existenz und mindestens ein USP-Cluster als Differenzierungs-Anker. Output sind zwei bis vier zugespitzte Produkt-Optionen mit Dunford-Positioning, schnellster-Disproof-Test und impliziten Non-Goals.",[13,491,492],{},"Token-Budget für Cross-Synthesis allein: 70.000 bis 125.000. Plus ein PRD pro Winner, also typischerweise 400.000 bis 700.000 Tokens für ein vollständiges Markt-Mapping mit einem ausgearbeiteten PRD.",[13,494,495],{},"Das ist viel. Aber es ist die Art Analyse, die früher ein 30.000-Euro-McKinsey-Projekt war. Die Größenordnung ist anders.",[20,497,499],{"id":498},"token-budget-ehrlich","Token-Budget — ehrlich.",[13,501,502],{},"Als Test-Target für die erste vollständige Messung habe ich mocoapp.com gewählt. Mocoapp kenne ich aus mehr als drei Jahren aktivem Einsatz: in einer früheren Agentur eingeführt und im Tagesbetrieb gefahren, parallel als Selbstständiger on\u002Foff genutzt, und bei sipgate damals als Dev die CLINQ-Kontakte-Integration gegen die Mocoapp-API gebaut. Decision-Maker, User, Integrator — drei Perspektiven auf dasselbe Produkt. Genau deshalb ein guter Stress-Test für die Pipeline: ich konnte die Extraktions-Qualität sofort gegen mein eigenes Gedächtnis abgleichen, statt blind auf Pipeline-Output zu vertrauen.",[13,504,505],{},"Erster gemessener Lauf: mocoapp.com, 08.05.2026 — 560.000 Harness-Tokens, ~7,50 Euro API-Kosten, 34 Minuten Wallclock inklusive Gates.",[13,507,508],{},"Die Rohdaten: Ein Pipeline-Lauf ohne Innovation-Derivation kostet rund 150.000 bis 250.000 Content-Tokens — was der Wettbewerber tatsächlich verarbeitet. Was abgerechnet wird, sind rund 500.000 bis 600.000 Harness-Tokens: Jeder Subagent trägt seinen System-Prompt, seine Tool-Calls und WebFetch-Overhead mit sich. Bei regulierten Domains eher 600.000 bis 750.000. Cross-Synthesis plus ein PRD: 400.000 bis 700.000 Content-Tokens, billed rund 900.000 bis 1,5 Millionen.",[13,510,511,512,515],{},"Was ist das in Euro? Ohne ",[192,513,514],{},"--derive-innovation"," (kein Opus für strategische Stages): rund 2 bis 3 Euro. Mit Opus für USP-Derivation und PRD-Synthese: 6 bis 9 Euro. Eine Cross-Synthesis mit fünf Wettbewerbern und einer ausgearbeiteten PRD bei 30 bis 60 Euro. Vor zwei Jahren hätte dieselbe Tiefe drei Wochen Arbeit gekostet — bei einem Tagessatz, den jeder selbst ausrechnen kann.",[13,517,518],{},"Die Rechnung ist nicht \"AI macht Produktarbeit umsonst\". Sie ist \"AI verschiebt den Bottleneck weg von der Recherche\". Was übrig bleibt, sind die Decision-Gates: Filter, Scope, USPs. Genau die drei Stellen, an denen Produktentscheidungen passieren — und die menschliche Arbeit eigentlich hingehört.",[20,520,522],{"id":521},"dein-start-paket","Dein Start-Paket.",[13,524,525],{},"Wenn du das System bei dir aufsetzen willst, brauchst du fünf Dinge:",[56,527,528,538,544,550,556],{},[59,529,530,533,534,537],{},[62,531,532],{},"Eine sitemap-fähige Wettbewerber-URL."," Test: ",[192,535,536],{},"curl -s https:\u002F\u002F{domain}\u002Frobots.txt | grep -i sitemap",". Wenn da was zurückkommt, ist Stage 0 möglich.",[59,539,540,543],{},[62,541,542],{},"Ein klares Zielprodukt."," Mindestens ein Arbeitsname. Ohne Name kein Anker für die PRD-Synthese.",[59,545,546,549],{},[62,547,548],{},"Drei bis fünf explizite Non-Goals."," Was wirst du nicht bauen? Wenn du das nicht beantworten kannst, ist dein Scope zu groß und der zweite Gate scheitert.",[59,551,552,555],{},[62,553,554],{},"Eine Differenzierungs-Achse."," Preis, UX, Nische, Compliance, Geschwindigkeit, Integration. Eine. Nicht drei.",[59,557,558,561],{},[62,559,560],{},"Compliance-Klarheit, falls relevant."," Welche Regelwerke binden dich? Wenn du in Health, Finance oder Tax baust, kommst du um diese Frage nicht herum, und sie gehört in die PRD-Eingangsdaten.",[13,563,564],{},"Plus, weniger formal: 10 bis 20 Minuten konzentrierte Aufmerksamkeit an den drei Gates. Die Pipeline läuft asynchron, die Subagent-Stages sind nichts, wo du danebensitzen musst. Aber an Gate 1, Gate 2 und Gate 2.5 fallen die Entscheidungen, und die solltest du nicht schnell durchwinken — eine Stunde Vor-Denken über Non-Goals, Differenzierung und Erfolgs-Metriken zahlt sich an Gate 2 zehnfach aus. Das ist Vor-Arbeit, nicht Gate-Time.",[20,566,568],{"id":567},"wenn-du-das-im-team-aufsetzen-willst","Wenn du das im Team aufsetzen willst.",[13,570,571],{},"Ich habe das System über mehrere Monate aufgebaut, aus mehreren Skills, die einander aufrufen, mit klaren Schemas zwischen den Stages und einer Token-Buchhaltung, die mir nach jedem Lauf zeigt, wo das Geld geblieben ist. Das ist Skill-Engineering, nicht Magic — aber es ist Aufwand, der sich nicht jeder im Team leisten will, weil er nicht das eigentliche Produkt voranbringt.",[13,573,574],{},"Wenn du den Pipeline-Ansatz in deinem Team haben willst, ohne drei Monate eigene Setup-Zeit zu investieren: schreib mir. Ich erkläre, was funktioniert, wo die Bruchstellen sind, und wie du das auf deine eigenen Skill-Bibliotheken portierst. Ich habe das in zwei Beratungs-Engagements bereits gemacht; einmal brauchten wir zwei Wochen für die Anpassung an den firmenspezifischen Stack, einmal vier Tage. Beides hat sich beim ersten echten Pipeline-Lauf bezahlt gemacht.",[13,576,577],{},"Das Konzept ist hier offen dokumentiert. Die Implementierung baut man am besten mit jemandem, der die Bruchstellen schon kennt.",[43,579,580],{},[13,581,582,583,588],{},"Wenn du an einem ähnlichen Problem arbeitest — Wettbewerbs-Analyse, die in einem Spec endet statt im Confluence-Friedhof — ",[584,585,587],"a",{"href":586},"\u002Fcontact","schreib mir",". Erstes Gespräch kostet nichts.",[20,590,592],{"id":591},"was-als-nächstes-kommt","Was als Nächstes kommt.",[13,594,595,596,600],{},"Folge-Playbooks, an denen ich gerade arbeite: Cross-Synthesis im Detail (von fünf Wettbewerbern zu zwei Produkt-Kandidaten), das Pricing-Playbook (das Schwester-Stück zu meinem ",[584,597,599],{"href":598},"\u002Fessays\u002Fportfolio-bruttomarge-plus-17-punkte","Portfolio-Bruttomarge-Essay","), und ein Discovery-Framework, das bei Gate 2 ansetzt — also dort, wo die meisten Pipelines tatsächlich kippen.",[13,602,603,604,608],{},"Wenn du sehen willst, wie ich die PRDs danach in Implementierungs-Pläne überführe, hilft der ",[584,605,607],{"href":606},"\u002Fcases\u002Finform","INFORM-Case"," als Beispiel: Pricing-Reform plus AI-Feature in unter vier Monaten, mit den gleichen Decision-Gates auf der Roadmap-Seite.",[13,610,611],{},"Drei Wochen kompetitive Recherche werden nicht zurückkommen. Was kommt: bessere Decision-Gates. Genau dort, wo Produktarbeit eigentlich stattfindet.",{"title":112,"searchDepth":113,"depth":113,"links":613},[614,615,616,617,618,619,620,621,622,623,624,625,626,627,628],{"id":153,"depth":113,"text":154},{"id":186,"depth":113,"text":187},{"id":203,"depth":113,"text":204},{"id":213,"depth":113,"text":214},{"id":253,"depth":113,"text":254},{"id":280,"depth":113,"text":281},{"id":297,"depth":113,"text":298},{"id":354,"depth":113,"text":355},{"id":406,"depth":113,"text":407},{"id":436,"depth":113,"text":437},{"id":482,"depth":113,"text":483},{"id":498,"depth":113,"text":499},{"id":521,"depth":113,"text":522},{"id":567,"depth":113,"text":568},{"id":591,"depth":113,"text":592},"2026-05-08",{},12,"\u002Fessays\u002Fcompetitor-to-prd-system",{"title":136,"description":112},"essays\u002Fcompetitor-to-prd-system",[636,637,638,639,640,641],"Product","AI","Discovery","PRD","Competitive","Playbook","Das System, das ich nutze, um aus einer Wettbewerber-URL ein validiertes PRD zu bauen — fünf Stages, drei Decision-Gates, rund 500.000 billed Tokens. Inklusive der Stellen, an denen es bricht.",2750,"6cYirpyd0E36OrJRS9Ia7StnHRa2fjyJZw2urb2PHZY",{"id":646,"title":647,"body":648,"date":809,"description":112,"extension":120,"featured":121,"lang":122,"meta":810,"minutes":811,"navigation":121,"path":812,"seo":813,"stem":814,"tags":815,"teaser":654,"words":820,"__hash__":821},"essays\u002Fessays\u002Ffeature-freeze-fuehrungsakt.md","Feature Freeze als Führungsakt — warum die härteste Aufgabe eines Head of Product nicht das Bauen ist.",{"type":7,"value":649,"toc":801},[650,655,659,662,665,668,671,674,678,681,684,687,690,693,697,700,706,712,718,722,725,731,737,743,749,755,759,762,765,768,788,792,795,798],[10,651,652],{},[13,653,654],{},"Die meisten Head-of-Product-Jobs werden auf das Bauen geschrieben. In der Realität ist das Aufhören die schwerere Entscheidung. 14 FTE aus zwei EOL-Produkten in eine Wachstumsunit umzuziehen ist kein Delivery-Thema — es ist eine Organisationsentscheidung, die als Produktentscheidung verkleidet ist.",[20,656,658],{"id":657},"das-schweigen-über-feature-freeze","Das Schweigen über Feature Freeze",[13,660,661],{},"In Product-Management-Literatur gibt es viel über Discovery, Pricing, Roadmaps, Stakeholder-Management, OKRs. Feature Freeze — das explizite Aufhören, Neues an einem Produkt zu bauen — kommt kaum vor. Wenn es auftaucht, dann als operative Konsequenz: \"Produkt X geht EOL, also kein neues Feature mehr.\" Die Entscheidung dahinter wird nicht diskutiert.",[13,663,664],{},"Das ist auffällig. Weil genau diese Entscheidung in jeder reifen Produktorganisation die schwerste ist.",[13,666,667],{},"In der Wachstumsphase ist Produktarbeit ein Additions-Job. Man baut dazu. Man skaliert. Man nimmt Kunden mit, man nimmt Features mit. Alle Beteiligten sind in dieselbe Richtung motiviert — Engineering will bauen, Product will liefern, Sales will verkaufen, Kunden wollen mehr.",[13,669,670],{},"In der Portfolio-Reifephase ist Produktarbeit ein Subtraktionsjob. Man baut ab. Man konsolidiert. Man nimmt Kunden nicht immer mit — weil man eine Produktlinie schließt, von der sie abhängen. Alle Beteiligten sind in verschiedene Richtungen motiviert. Engineering liebt das alte Produkt, weil sie es gebaut haben. Product Management hat den Business-Case für den Abbau geschrieben und wird trotzdem im Meeting gefragt, ob das wirklich nötig ist. Sales will die Kunden nicht verlieren. Kunden wollen keine Migration.",[13,672,673],{},"Und mitten in dieses Spannungsfeld kommt die Führungskraft und sagt: Wir hören auf.",[20,675,677],{"id":676},"die-mathematik-dahinter-ist-simpel","Die Mathematik dahinter ist simpel",[13,679,680],{},"Bei d.velop gab es zwei Legacy-Produkte, die in ihrer Zielarchitektur nicht mehr zum strategischen Kurs passten. Sie liefen noch, sie hatten noch Kunden, sie waren noch profitabel in der Wartung. Aber sie waren nicht der Ort, an dem die Zukunft lag.",[13,682,683],{},"Die Zukunft lag in der d.velop postbox — der Plattform-Unit, die gleichzeitig die Mobile-Strategie, die Identity-Strategie und die Cross-Produkt-Kollaboration tragen sollte. Die Zielkapazität der postbox-Unit für 2025: 31,5 FTE, was 80 % der relevanten Gesamtkapazität entsprach.",[13,685,686],{},"Der Weg dorthin: 14 FTE aus den beiden Legacy-Produkten herausziehen und in die postbox-Unit umziehen. Nicht als HR-Aktion, sondern als Produktentscheidung mit HR-Konsequenz.",[13,688,689],{},"Die Mathematik dahinter ist simpel. Wenn du 14 FTE in ein wachsendes Produkt investierst, investierst du 14 FTE × 1,5 Jahre × durchschnittliche Projekt-Velocity — in neuer Technologie, in der richtigen Architektur, an der Schnittstelle, an der deine Kunden in fünf Jahren sein werden. Wenn du die 14 FTE in zwei Legacy-Produkten lässt, bekommst du Wartung. Wartung ist wichtig — Wartung ist nicht Zukunft.",[13,691,692],{},"Die Mathematik ist simpel. Die Entscheidung ist schwer.",[20,694,696],{"id":695},"warum-feature-freeze-härter-ist-als-feature-launch","Warum Feature Freeze härter ist als Feature-Launch",[13,698,699],{},"Drei Gründe.",[13,701,702,705],{},[62,703,704],{},"Erstens: Es gibt keinen Launch-Moment."," Bei einem Feature-Launch hast du einen Tag, an dem die Arbeit sichtbar wird. Alle klatschen, die Zahlen ziehen an, das Team hat ein Erfolgserlebnis. Bei einem Feature Freeze hast du einen Tag, an dem die Arbeit unsichtbar wird. Keiner klatscht. Die Zahlen passieren woanders. Das Team, das das alte Produkt gebaut hat, hat ein Abschieds-Erlebnis, kein Erfolgs-Erlebnis.",[13,707,708,711],{},[62,709,710],{},"Zweitens: Die Opposition ist rational."," Jemand, der gegen einen Feature-Launch argumentiert, hat meistens einen schwachen Punkt — fehlende Validierung, unklare Monetarisierung, zu viel Scope. Das ist produktiv, aber argumentierbar. Jemand, der gegen einen Feature Freeze argumentiert, hat meistens einen starken Punkt — das alte Produkt hat zahlende Kunden, das Team hat Expertise, der Umsatz ist real. Die Gegenargumente sind wahr. Sie sind nur nicht relevant, wenn man auf Portfolio-Ebene entscheidet.",[13,713,714,717],{},[62,715,716],{},"Drittens: Die persönliche Kosten-Seite ist asymmetrisch."," Ein erfolgreicher Feature-Launch verbessert den Ruf eines Head of Product. Ein erfolgreicher Feature Freeze verbessert ihn nicht — er verhindert im besten Fall, dass in 18 Monaten eine Organisation mit zu viel Ballast kippt. Das ist ein negativer Ergebnis-Raum: die Abwesenheit eines Schadens, nicht das Vorhandensein eines Gewinns. Menschen erinnern sich nicht an vermiedene Schäden.",[20,719,721],{"id":720},"die-mechanik-einer-guten-feature-freeze-entscheidung","Die Mechanik einer guten Feature-Freeze-Entscheidung",[13,723,724],{},"Wie trifft man sie gut?",[13,726,727,730],{},[62,728,729],{},"Erster Schritt: Die Entscheidung ist eine Kapazitätsentscheidung, keine Produktentscheidung."," Die Frage ist nicht \"Lohnt sich das alte Produkt noch?\" — die Frage ist \"Wo erzeugen 14 FTE in den nächsten 18 Monaten den höchsten Portfolio-Wert?\" Wer die erste Frage stellt, bekommt eine Debatte über Umsatz und Kundenbindung. Wer die zweite Frage stellt, bekommt eine Debatte über Kapazitäts-Allokation. Nur die zweite Debatte ist steuerbar.",[13,732,733,736],{},[62,734,735],{},"Zweiter Schritt: Der Feature Freeze ist nicht der EOL."," Das ist die wichtigste sprachliche Disziplin. Feature Freeze heißt: keine neuen Funktionen mehr, aber weiterhin Wartung, Security-Updates, Kunden-Support auf vertraglich zugesicherten Niveau. EOL heißt: das Produkt geht aus. Wer die beiden vermischt, erzeugt bei Kunden Panik und bei Sales Widerstand. Wer sie trennt, macht den Freeze zu einer operativen Neuigkeit, nicht zu einer Existenzkrise.",[13,738,739,742],{},[62,740,741],{},"Dritter Schritt: Der Team-Umzug braucht eine klare Heimat."," 14 FTE aus einem vertrauten Setup in eine unklare Struktur zu bewegen, erzeugt Attrition. Der Umzug funktioniert nur, wenn das Zielprodukt eine erkennbare Story, ein erkennbares Team und ein erkennbares Stück Arbeit hat, auf das die Menschen sich freuen können. Bei d.velop war das die postbox-Unit mit klarem strategischem Mandat, Plattform-Ambition und wachsendem Scope.",[13,744,745,748],{},[62,746,747],{},"Vierter Schritt: Kunden-Kommunikation erst nach interner Entscheidung."," Wer öffentlich macht, was noch nicht intern entschieden ist, verliert Verhandlungsspielraum. Wer intern die Entscheidung getroffen hat, kann Kunden sauber einordnen: was ändert sich, was nicht, bis wann.",[13,750,751,754],{},[62,752,753],{},"Fünfter Schritt: Die Cross-Training-Investition."," Zwei postbox-Consultants wurden seit Q4 2024 cross-trainiert, um Ressourcen-Bewegungen zwischen Produkten zu ermöglichen. Das ist kein operativer Overhead — das ist die Voraussetzung dafür, dass ein Feature Freeze nicht zu einer Kompetenz-Insel wird, die später wieder aufgetaut werden muss.",[20,756,758],{"id":757},"was-feature-freeze-über-head-of-product-arbeit-verrät","Was Feature Freeze über Head-of-Product-Arbeit verrät",[13,760,761],{},"Wenn ich mir die 2024er d.velop-mobile-services-Zeit anschaue, war Feature Freeze eine der drei härtesten Entscheidungen. Die anderen waren die Taskforce für einen kritischen Enterprise-Account und die Einführung des \"Operative Kühe\"-Prozesses für Querschnittsrisiken.",[13,763,764],{},"Alle drei haben das gleiche Muster. Sie bewegen Kapazität, nicht Features. Sie sind die Art Arbeit, für die in einem PM-Job-Profil selten ein eigener Abschnitt steht — und die trotzdem den Unterschied zwischen einer Produkt-Unit, die skaliert, und einer, die in die Breite läuft, entscheidet.",[13,766,767],{},"Drei Einsichten, die ich aus der Freeze-Arbeit mitnehme:",[56,769,770,776,782],{},[59,771,772,775],{},[62,773,774],{},"Die Frage \"Was bauen wir als Nächstes?\" ist interessanter. Die Frage \"Was hören wir auf zu bauen?\" ist wichtiger."," Nicht jedem Head of Product liegt die zweite Frage. Manche Rollen brauchen explizit die Erlaubnis, sie zu stellen. Wenn die Erlaubnis nicht kommt, kommt auch das Ergebnis nicht.",[59,777,778,781],{},[62,779,780],{},"Roadmap-Diskussionen kaschieren häufig fehlende Kapazitätsdiskussionen."," Wer eine Roadmap mit 12 Features vorstellt, die auf 4 FTE geplant sind, stellt keine Roadmap vor — der stellt eine Wunschliste vor. Eine ehrliche Roadmap beginnt mit der Kapazitätszahl und endet bei dem, was sie erlaubt. Feature Freeze ist die Vorbereitung dafür, dass die Kapazitätszahl überhaupt in Bewegung kommt.",[59,783,784,787],{},[62,785,786],{},"Die Bewertung eines Head of Product sollte den vermiedenen Schaden einschließen."," Eine Organisation, die in 18 Monaten 14 FTE auf Legacy-Wartung hat, die in die falsche Richtung läuft, ist eine Organisation mit einem 14-FTE-Problem. Wenn der Head of Product es rechtzeitig bewegt, sieht man das Problem nie. Das ist eine Leistung, die schwer sichtbar zu machen ist — und die trotzdem die wichtigste ist.",[20,789,791],{"id":790},"zurück-zur-eingangsfrage","Zurück zur Eingangsfrage",[13,793,794],{},"Feature Freeze ist kein operatives Nebenthema. Feature Freeze ist der Führungsakt, der eine Produktorganisation vom Addieren zum Komponieren bewegt. Wer Head of Product ist und nie einen Feature Freeze entschieden hat, hat entweder Glück gehabt — oder die Portfolio-Ebene nie betreten.",[13,796,797],{},"Die 14 FTE bei d.velop sind mittlerweile in der postbox-Unit angekommen. Die beiden Legacy-Produkte laufen im Wartungsmodus, ihre Kunden sind informiert, ihre Rolle im Portfolio ist klar. Die Wachstumsunit hat die Kapazität, die sie für 2025\u002F2026 braucht.",[13,799,800],{},"Das ist, was nach einem guten Feature Freeze zurückbleibt: eine Organisation, die an der richtigen Stelle arbeitet. Still, aber entscheidend.",{"title":112,"searchDepth":113,"depth":113,"links":802},[803,804,805,806,807,808],{"id":657,"depth":113,"text":658},{"id":676,"depth":113,"text":677},{"id":695,"depth":113,"text":696},{"id":720,"depth":113,"text":721},{"id":757,"depth":113,"text":758},{"id":790,"depth":113,"text":791},"2026-04-24",{},10,"\u002Fessays\u002Ffeature-freeze-fuehrungsakt",{"title":647,"description":112},"essays\u002Ffeature-freeze-fuehrungsakt",[816,817,818,819],"Leadership","Portfolio","Kapazität","EOL",1480,"zl8e31Xk_g2E49_OLx6wkg6u7D9uIvLbQM9V_DJdya8",1778755788016]