Competitor-to-PRD: Wie ich kompetitive Recherche in Stunden statt Wochen mache.

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.

Warum klassische Wettbewerbs-Analysen scheitern.

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?

Drei Anti-Pattern tauchen immer wieder auf:

1. 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.
2. 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.
3. 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.

Das eigentliche Problem ist nicht der Aufwand. Es ist der Output. Eine Wettbewerbs-Analyse, die nicht in einem Spec endet, ist nur Wissens-Sammelei.

Der Output, den ich will.

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 /superpowers:writing-plans.

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.

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.

Das System auf einen Blick.

Fünf Stages, drei Decision-Gates. Die Infografik oben zeigt die Topologie. Hier die Logik dahinter, Stage für Stage.

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.

Stage 0 — Discovery + Pruning.

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 curl und einem kleinen Parser. Output ist eine Liste mit typischerweise 200 bis 500 URLs, gruppiert nach Pfad-Präfix.

Was hier sichtbar wird, ist überraschend wertvoll. Die Sektionsverteilung zeigt, wo der Wettbewerber sein Gewicht hinlegt. 280 URLs im /wissen-*-Bereich heißt: Content-Marketing ist ein wesentlicher Akquise-Kanal. 12 URLs unter /funktionen und 18 unter /branche sagt: schlanker Funktionsumfang, breite Branchen-Aufstellung. Das ist eine Hypothese über die Go-to-Market-Strategie, bevor eine einzige Feature-Page extrahiert wurde.

Dann folgt der erste Gate.

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.

Stage 1 — Parallele Extraktion.

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.

Parallel läuft 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.

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.

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.

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 jq deterministisch zusammenführen. Markdown muss man parsen — und jeder Parser ist eine Fehlerquelle. Wer auf YAML/JSONL setzt, kriegt Stage 2 fast geschenkt.

Stage 2 — Deterministic Merge.

Stage 2 ist die einzige Stufe ohne LLM-Call. jq 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 research-master.yaml mit Statistiken und Pointern auf alles andere.

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.

Gate 2 — Der Gate, an dem 80 Prozent scheitern.

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:

1. Produktname. Klingt trivial. Ist es nicht. Wer hier blockiert, blockiert die ganze PRD-Synthese.
2. 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.
3. 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.
4. Differenzierung. Welche Achse? Preis, UX, Nische, Compliance, Integration, Geschwindigkeit? Eine Hauptachse, eine sekundäre, fertig. Wer drei Achsen will, gewinnt auf keiner.
5. 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.
6. 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.
7. 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.

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.

Wenn dieser Gate sauber durchgespielt ist, ist die eigentliche Produktarbeit getan. Der Rest ist Synthese.

Stage 3.5 — USP-Derivation, wenn man's ernst meint.

Optionaler Zwischenschritt, den ich für jedes Produkt empfehle, bei dem Differenzierung später eine Rolle spielt — also faktisch alle. 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.

Drei Kategorien:

• 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.
• 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.
• Emerging Moat. Features, die heute commodity-nahe sind, aber sich durch Setup-Tiefe oder Integration verteidigen lassen.

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.

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.

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.

Stage 4 — PRD-Synthese.

Letzter LLM-Schritt. 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.

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.

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.

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.

Output ist eine Markdown-Datei {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/Lagging, §9 Open Questions mit Owner-Spalte, §10 Timeline, §11 Next Steps, §12 Glossar.

Diese Markdown-Datei ist das Ende der Pipeline und der Anfang der Implementierungs-Planung.

Wann das System nicht funktioniert.

Damit das hier kein Pitch wird: das System hat klare Bruchstellen. Die wichtigsten:

• 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.
• JS-only-Sites. Single-Page-Apps, die ihren Content per Client-Side-Rendering liefern, geben einem WebFetch-Call wenig zurück. Da hilft nur Headless-Browser-Rendering oder eine andere Datenquelle (Wayback-Machine, Crunchbase, G2-Reviews).
• 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.
• 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.
• 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.

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.

Cross-Synthesis: wenn fünf Wettbewerber im Spiel sind.

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.

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.

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.

Das ist viel. Aber es ist die Art Analyse, die früher ein 30.000-Euro-McKinsey-Projekt war. Die Größenordnung ist anders.

Token-Budget — ehrlich.

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/off 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.

Erster gemessener Lauf: mocoapp.com, 08.05.2026 — 560.000 Harness-Tokens, ~7,50 Euro API-Kosten, 34 Minuten Wallclock inklusive Gates.

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.

Was ist das in Euro? Ohne --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.

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.

Dein Start-Paket.

Wenn du das System bei dir aufsetzen willst, brauchst du fünf Dinge:

1. Eine sitemap-fähige Wettbewerber-URL. Test: curl -s https://{domain}/robots.txt | grep -i sitemap. Wenn da was zurückkommt, ist Stage 0 möglich.
2. Ein klares Zielprodukt. Mindestens ein Arbeitsname. Ohne Name kein Anker für die PRD-Synthese.
3. 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.
4. Eine Differenzierungs-Achse. Preis, UX, Nische, Compliance, Geschwindigkeit, Integration. Eine. Nicht drei.
5. 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.

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.

Wenn du das im Team aufsetzen willst.

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.

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.

Das Konzept ist hier offen dokumentiert. Die Implementierung baut man am besten mit jemandem, der die Bruchstellen schon kennt.

Was als Nächstes kommt.

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 Portfolio-Bruttomarge-Essay), und ein Discovery-Framework, das bei Gate 2 ansetzt — also dort, wo die meisten Pipelines tatsächlich kippen.

Wenn du sehen willst, wie ich die PRDs danach in Implementierungs-Pläne überführe, hilft der INFORM-Case als Beispiel: Pricing-Reform plus AI-Feature in unter vier Monaten, mit den gleichen Decision-Gates auf der Roadmap-Seite.

Drei Wochen kompetitive Recherche werden nicht zurückkommen. Was kommt: bessere Decision-Gates. Genau dort, wo Produktarbeit eigentlich stattfindet.