tderoussel/competitive-teardown

Wettbewerbsanalyse (Competitive Teardown)

Das Ergebnis ist eine Entscheidung, kein Feature-Inventar. Jede Lücke erhält eine Bewertung, eine Aufwandsschätzung und ein „Bauen-oder-Ignorieren“-Urteil.

Methode

1. Recherchiere den aktuellen Stand des Wettbewerbers — Preise, Positionierung, was in den letzten 6 Monaten ausgeliefert wurde, worüber sich ihre Nutzer beschweren. Datumsangabe für jede Behauptung; die meisten Kategorien bewegen sich schneller, als die Analyse Bestand hat.

2. Prüfe dein eigenes Repo auf bereits vorhandene Funktionen. Dies ist der Schritt, der die Antwort ändert. Immer wieder entpuppen sich die scheinbar wertvollsten „Lücken“ als ruhende Gerüste im Codebestand ohne Aufrufer oder als eine Funktion, die hinter einem Flag ausgeliefert wurde, das niemand aktiviert hat. Grep, bevor du zu dem Schluss kommst, dass etwas fehlt.

3. Filtere durch den tatsächlichen Nutzer. Nenne, wem dein Produkt konkret dient, und beurteile jede Lücke anhand dieser Person. Eine Funktion, die in einer Enterprise-Demo beeindruckt, kann für einen Einzelanwender wertlos sein und umgekehrt. Gib an, wem jede Lücke dient – wenn die Antwort „jemand, an den wir nicht verkaufen“ lautet, dann ist das das Urteil.

4. Bewerte nach dem Wert für diesen Nutzer, mit einer groben Aufwandsschätzung und dem Grund, warum die Umsetzung günstig oder teuer ist.

Struktur

# <Wettbewerber> vs <Wir> — Wettbewerbslücken-Analyse (JJJJ-MM-TT)

<Eine Zeile, die den verwendeten Forschungsmodus benennt.>

## Überschrift
<Was ihr wirklicher Vorteil ist – normalerweise nicht das, was sie vermarkten.>

## Bewertete Lücken
1. **<Lücke>** (~Aufwand) — Beleg aus dem Repo, warum sie für unseren Nutzer wichtig ist, was gebaut werden soll.

## Explizit nicht nachahmenswert
<Benannt, mit Gründen.>

## Strategische Erkenntnis
<Die dauerhafte Lektion, getrennt von der Feature-Liste.>

Der Abschnitt „Nicht nachahmenswert“ ist Pflicht

Dieser Abschnitt hält das Backlog ehrlich. Ohne ihn ist eine Wettbewerbsanalyse eine Liste von Arbeiten, bei denen du dich jetzt im Rückstand fühlst.

Funktionen, die in Demos gut aussehen und oft niemandem wirklich dienen: benutzerdefinierte Objekte, visuelle Workflow-Canvas, Kanban-Boards, Kollaborationsoberflächen bei Einzelspieler-Produkten und Anreicherungen, die auf einen Käufer abzielen, an den du nicht verkaufst. Lehne sie namentlich mit Begründung ab, damit die nächste Analyse sie nicht erneut vorschlägt.

Verteilung schlägt Funktionen

Wenn der Wettbewerber größer ist, liegt die Bedrohung normalerweise darin, wie sie den Nutzer erreichen – Bündelung, eine Standardintegration, eine etablierte Beziehung – nicht in ihrem Funktionsumfang. Wäge das explizit ab. Eine Analyse, die nur Funktionen vergleicht, wird die falsche Arbeit empfehlen.

Bestehende Einschränkungen

Führe eine kurze Liste früherer Entscheidungen mit, damit die Analyse bereits getroffene Entscheidungen nicht wieder aufrollt: Dinge, deren Entwicklung die Führung bereits abgelehnt hat, Positionierungsaussagen, die ausgeschlossen wurden, und strukturelle Wetten, die nicht zur Debatte stehen. Ergänze sie, sobald Urteile gefällt werden.

Halte sie in einer eigenen Kopie dieses Skills im Projekt fest – der Punkt ist, dass die Tatsache, dass ein Wettbewerber etwas tut, für sich genommen kein Argument ist, eine Entscheidung rückgängig zu machen.

Vergleichsseiten

Falls die Aufgabe Marketingtexte umfasst, verwende das bereits vorhandene Hausmuster, anstatt ein eigenes zu erfinden. Halte jede Tatsachenbehauptung über den Wettbewerber datiert und belegt – diese Seiten sind öffentlich, und eine veraltete Behauptung ist eine Haftung.

Belasse sie als Entwürfe. Veröffentliche keine Vergleichsseite ohne ausdrückliche Genehmigung eines Menschen.

Ausgabe

Schreibe die Analyse dort, wo das Projekt seine Forschung aufbewahrt. Wenn die Wettbewerbsanalyse die Strategie ändert, füge einen datierten Abschnitt zum entsprechenden Hub oder Plan hinzu – überschreibe nicht stillschweigend ein früheres Urteil.