Offizieller Skill · Produkt

Teardown eines Konkurrenzprodukts

Schreibt aus öffentlichen Seiten oder Testnotizen ein Teardown eines Wettbewerbers: Onboarding-Schritte, Preise, Core Loop, Stärken, Lücken, was ihr übernehmt oder nicht, Ungeprüftes markiert.

Funktioniert in Claude, ChatGPT und Coding-Agents. In Team und Business aktualisiert sich der offizielle Skill in deinem Pod von selbst, wenn wir ihn verbessern.

Wann du ihn nutzt

Was du ihm gibst

Was du bekommst

Ein Teardown mit Onboarding-Tabelle, Preistabelle, Core Loop, Stärken, Lücken, Übernehmen/Nicht übernehmen/Abheben und einer Liste zum Prüfen.

So funktioniert er

  1. Markiere die Quelle jeder Aussage Jede Tatsache bekommt „geprüft“ (in den Testnotizen gesehen oder als Seitentext zitiert, mit Datum) oder „ungeprüft“ (aus dem Gedächtnis, von einer Bewertungsseite oder abgeleitet). Preise und Tarifgrenzen ändern sich oft; nenne nie einen Preis, den du nicht in der Eingabe gesehen hast, schreib „[prüfen: aktueller Preis]“.
  2. Bilde das Onboarding Schritt für Schritt ab Von der ersten Seite bis zum ersten Moment, in dem das Produkt Nutzen bringt: jeder Bildschirm, was er abfragt, wie viele Felder, ob eine Kreditkarte nötig ist und, falls notiert, wie lange es dauert. Zähl die Schritte. Markiere, wo jemand Neues hängen bleiben könnte.
  3. Stell Preise und Pakete dar Tarife, welche Grenzen sie trennen (Lizenzen, Nutzung, Funktionen), der kostenlose Tarif oder die Testphase und der Upgrade-Auslöser: der Moment, in dem das Produkt nach Geld fragt. Nur aus der Eingabe.
  4. Beschreib den Core Loop Welche Aktion wiederholt jemand, was bekommt er zurück, und was bringt ihn zurück (E-Mails, Benachrichtigungen, geteilte Arbeit)? Ein kurzer Absatz.
  5. Liste Stärken und Lücken auf Nutze die 10 Usability-Heuristiken von NN/g als Brille, wo es hilft: Systemstatus, verständliche Sprache, Umgang mit Fehlern, Hilfe. Stärken sind Dinge, die jemand vermissen würde, wenn sie fehlten. Lücken sind Stellen, an denen Leute hängen bleiben, zahlen, bevor sie Nutzen sehen, oder Hilfe brauchen.
  6. Entscheide, was ihr übernehmt, was nicht und wo ihr euch abhebt Der Rat von NN/g zu Wettbewerbsanalysen: nach Stärken, Trends, einzigartigen Lösungen und Lücken suchen und die Ergebnisse in Empfehlungen für das eigene Produkt übersetzen. Übernimm nur, was zu euren Nutzern passt; sag bei jedem Punkt, warum. „Nicht übernehmen“ umfasst Dinge, die beim Wettbewerber wegen seiner Größe, Marke oder Zielgruppe funktionieren.
  7. Liste auf, was als Nächstes zu prüfen ist Jede ungeprüfte Aussage, die für eine Entscheidung zählt, wird zu einer Prüfung: für die Testversion registrieren, die Preisseite lesen, einen Kunden fragen, der gewechselt hat.

Die SKILL.md

Die ganze Datei, so wie deine KI sie liest. Herunterladen

---
name: product-teardown
description: Schreibt ein Teardown eines Konkurrenzprodukts aus öffentlichen Seiten, einer kostenlosen Testversion, in Text beschriebenen Screenshots oder den Testnotizen der Nutzerin oder des Nutzers – mit Onboarding-Schritten, Preisen und Paketen, Core Loop, Stärken, Lücken und was ihr übernehmt und was nicht, jede Aussage als geprüft oder ungeprüft markiert. Nutze ihn, wenn jemand nach einem Teardown eines Wettbewerbers, einer Wettbewerbsanalyse eines Produkts, „Wie macht X das Onboarding?“, „Wie bepreist X?“ fragt oder wissen will, was man vom Produkt eines Konkurrenten lernen kann.
---

# Produkt-Teardown

Ein Teardown ist nützlich, wenn es deinem Team sagt, was es ab Montag anders macht. Beschreib anhand von Belegen Schritt für Schritt, was das Produkt tatsächlich tut; trenne, was du gesehen hast, von dem, was du vermutest; und schließ mit einer kurzen Liste, was ihr übernehmt, was ihr meidet und wo ihr euch abhebt. Das Ziel ist, den Wettbewerber zu schlagen, nicht ihn zu kopieren.

## Wann du sie nutzt

- Bevor ihr Onboarding, Preise oder eine Funktion entwerft, die ein Wettbewerber schon hat.
- Wenn Vertrieb oder Geschäftsführung über einen Konkurrenten fragt: „Wie machen die das?“
- Nachdem jemand die Testversion eines Wettbewerbers durchlaufen hat und Notizen hat.
- Nicht für eine Battlecard für den Vertrieb mit Einwandbehandlung: Dafür gibt es competitor-battlecard. Nicht, um einen Anbieter zum Kauf auszuwählen: Dafür gibt es vendor-comparison.

## Was du brauchst

- Den Namen des Wettbewerbers und die Belege: Text öffentlicher Seiten, Text der Preisseite, Hilfedokumente, Testnotizen oder beschriebene Screenshots, jeweils mit dem Datum, an dem sie gesehen wurden.
- Was dein Team lernen will (Onboarding, Preise, eine Funktion). Fehlt das, frag einmal; sonst deck alle Abschnitte ab.
- Optional: das Gegenstück in eurem eigenen Produkt, zum Vergleich.

## Schritte

1. **Markiere die Quelle jeder Aussage.** Jede Tatsache bekommt „geprüft“ (in den Testnotizen gesehen oder als Seitentext zitiert, mit Datum) oder „ungeprüft“ (aus dem Gedächtnis, von einer Bewertungsseite oder abgeleitet). Preise und Tarifgrenzen ändern sich oft; nenne nie einen Preis, den du nicht in der Eingabe gesehen hast, schreib „[prüfen: aktueller Preis]“.
2. **Bilde das Onboarding Schritt für Schritt ab.** Von der ersten Seite bis zum ersten Moment, in dem das Produkt Nutzen bringt: jeder Bildschirm, was er abfragt, wie viele Felder, ob eine Kreditkarte nötig ist und, falls notiert, wie lange es dauert. Zähl die Schritte. Markiere, wo jemand Neues hängen bleiben könnte.
3. **Stell Preise und Pakete dar.** Tarife, welche Grenzen sie trennen (Lizenzen, Nutzung, Funktionen), der kostenlose Tarif oder die Testphase und der Upgrade-Auslöser: der Moment, in dem das Produkt nach Geld fragt. Nur aus der Eingabe.
4. **Beschreib den Core Loop.** Welche Aktion wiederholt jemand, was bekommt er zurück, und was bringt ihn zurück (E-Mails, Benachrichtigungen, geteilte Arbeit)? Ein kurzer Absatz.
5. **Liste Stärken und Lücken auf.** Nutze die 10 Usability-Heuristiken von NN/g als Brille, wo es hilft: Systemstatus, verständliche Sprache, Umgang mit Fehlern, Hilfe. Stärken sind Dinge, die jemand vermissen würde, wenn sie fehlten. Lücken sind Stellen, an denen Leute hängen bleiben, zahlen, bevor sie Nutzen sehen, oder Hilfe brauchen.
6. **Entscheide, was ihr übernehmt, was nicht und wo ihr euch abhebt.** Der Rat von NN/g zu Wettbewerbsanalysen: nach Stärken, Trends, einzigartigen Lösungen und Lücken suchen und die Ergebnisse in Empfehlungen für das eigene Produkt übersetzen. Übernimm nur, was zu euren Nutzern passt; sag bei jedem Punkt, warum. „Nicht übernehmen“ umfasst Dinge, die beim Wettbewerber wegen seiner Größe, Marke oder Zielgruppe funktionieren.
7. **Liste auf, was als Nächstes zu prüfen ist.** Jede ungeprüfte Aussage, die für eine Entscheidung zählt, wird zu einer Prüfung: für die Testversion registrieren, die Preisseite lesen, einen Kunden fragen, der gewechselt hat.

## Ausgabeformat

```markdown
# Teardown: [Wettbewerber] — [Schwerpunkt]

**Belege:** [Quellen und Datum, an dem sie gesehen wurden] · **Erstellt:** [Datum]

## Zusammenfassung
- [3 Punkte: das Wichtigste, was das Team wissen sollte]

## Onboarding
| # | Bildschirm / Schritt | Was abgefragt wird | Hinweise | Quelle |
|---|---|---|---|---|
| 1 | [Schritt] | [Felder oder Auswahl] | [Reibung oder Stärke] | geprüft [Datum] / ungeprüft |

**Schritte bis zum ersten Nutzen:** [n] · **Karte nötig:** [ja / nein / ungeprüft]

## Preise und Pakete
| Tarif | Preis | Wichtige Grenzen | Quelle |
|---|---|---|---|
| [Tarif] | [wie gesehen oder prüfen] | [Grenzen] | geprüft [Datum] / ungeprüft |

**Upgrade-Auslöser:** [wann das Produkt nach Geld fragt]

## Core Loop
[Ein Absatz.]

## Stärken
- [Stärke] — [Beleg]

## Lücken
- [Lücke] — [Beleg]

## Für uns
- **Übernehmen:** [was] — [warum es zu unseren Nutzern passt]
- **Nicht übernehmen:** [was] — [warum es nicht passt]
- **Abheben:** [wo wir klar besser sein können]

## Zu prüfen
- [ungeprüfte Aussage] — [wie wir es prüfen]
```

## Beispiel

**Eingabe (Testnotizen, 2. Mai):** „Bei Ledgerly registriert. Schritt 1: E-Mail + Passwort. Schritt 2: Dropdown ‚Was machst du?‘, 12 Optionen. Schritt 3: Bank verbinden — überspringbar. Schritt 4: Vorlagenauswahl für die erste Rechnung, mit Beispielkunde vorausgefüllt. Testrechnung nach etwa 4 Minuten verschickt. Keine Karte verlangt. Preisseite: Free (5 Rechnungen/Monat), Pro, Team — Preis für Pro hab ich nicht notiert. Jede verschickte Rechnung hat die Fußzeile ‚Gesendet mit Ledgerly‘. Am nächsten Tag Erinnerungsmail an mich: ‚Deine Rechnung wurde angesehen.‘ Hab gehört, sie erhöhen die Preise.“

**Ausgabe:**

```markdown
# Teardown: Ledgerly — Onboarding und Preise

**Belege:** Testnotizen, 2. Mai · **Erstellt:** [Datum]

## Zusammenfassung
- Jemand Neues verschickt die erste Rechnung nach etwa 4 Minuten ohne Karte; der Beispielkunde nimmt die Angst vor der leeren Seite.
- Die Grenze des kostenlosen Tarifs sind Rechnungen pro Monat, also kommt der Upgrade-Auslöser mit echter Nutzung.
- Jede kostenlose Rechnung trägt ihre Marke zu den Kunden der Nutzer.

## Onboarding
| # | Bildschirm / Schritt | Was abgefragt wird | Hinweise | Quelle |
|---|---|---|---|---|
| 1 | Registrierung | E-Mail, Passwort | Standard | geprüft 2. Mai |
| 2 | Rolle | Dropdown, 12 Optionen | Lange Liste; Zweck für Neue unklar | geprüft 2. Mai |
| 3 | Bank verbinden | Bankverbindung | Überspringbar, gut | geprüft 2. Mai |
| 4 | Erste Rechnung | Vorlage, vorausgefüllter Beispielkunde | Stark: man sieht sofort eine fertige Rechnung | geprüft 2. Mai |

**Schritte bis zum ersten Nutzen:** 4 · **Karte nötig:** nein

## Preise und Pakete
| Tarif | Preis | Wichtige Grenzen | Quelle |
|---|---|---|---|
| Free | Kostenlos | 5 Rechnungen pro Monat | geprüft 2. Mai |
| Pro | [prüfen: aktueller Preis] | [prüfen: Grenzen] | nicht notiert |
| Team | [prüfen: aktueller Preis] | [prüfen: Grenzen] | nicht notiert |

**Upgrade-Auslöser:** die 6. Rechnung in einem Monat [Annahme, aus der Grenze des kostenlosen Tarifs].

## Core Loop
Man verschickt eine Rechnung, der Kunde sieht sie an, und Ledgerly mailt, dass sie angesehen wurde, was einen zurückholt, um die Zahlung zu prüfen. Die Fußzeile „Gesendet mit Ledgerly“ zeigt das Produkt jedem Kunden.

## Stärken
- Vorausgefüllte erste Rechnung — erster Nutzen nach etwa 4 Minuten.
- E-Mail „Rechnung angesehen“ — ein Grund, am nächsten Tag zurückzukommen.

## Lücken
- Dropdown mit 12 Rollen, bevor es irgendeinen Nutzen gibt.
- Gerücht über eine Preiserhöhung — ungeprüft.

## Für uns
- **Übernehmen:** eine vorausgefüllte Beispielrechnung — auch unsere Nutzer starten vor einem leeren Bildschirm [prüfen: unsere Daten].
- **Nicht übernehmen:** eine Fußzeile mit unserer Marke in bezahlten Tarifen — unsere Nutzer sind Agenturen, die Arbeit unter ihrer eigenen Marke verschicken [prüfen].
- **Abheben:** vor der ersten Rechnung nichts abfragen; die Frage nach der Rolle danach stellen.

## Zu prüfen
- Preise und Grenzen von Pro und Team — die Preisseite lesen und das Datum festhalten.
- Preiserhöhung — Changelog oder Ankündigungen prüfen; streichen, wenn nichts zu finden ist.
- Ob die Fußzeile in bezahlten Tarifen erscheint — einen bezahlten Tarif testen oder die Hilfedokumente lesen.
```

## Prüfen vor dem Senden

- [ ] Jede Zeile in Onboarding und Preisen hat eine Quellenmarkierung: geprüft mit Datum oder ungeprüft.
- [ ] Kein Preis, keine Grenze und keine Zahl, die nicht in der Eingabe stehen.
- [ ] Gerüchte und Ableitungen sind als ungeprüft oder „[Annahme]“ markiert.
- [ ] „Für uns“ hat mindestens 1 Übernehmen, 1 Nicht übernehmen und 1 Abheben, jeweils mit Grund.
- [ ] Jede ungeprüfte Aussage, die eine Empfehlung beeinflusst, steht unter „Zu prüfen“.

## Häufige Fehler

- Eine Funktionsliste schreiben. Ein Teardown folgt dem Weg der Nutzer; die Reihenfolge der Schritte ist das Ergebnis.
- Die Preise eines Wettbewerbers übernehmen, weil sie sichtbar sind. Seine Grenzen passen zu seinen Kosten und seiner Zielgruppe, nicht zu euren.
- Preise aus dem Gedächtnis als Tatsache nennen. Preisseiten ändern sich; datiere, was du gesehen hast.

Teile ihn mit deinem Team

Füge ihn einem AI Skill Pod hinzu, und alle im Team, auch Freelancer, nutzen dieselbe Version aus ihrer eigenen KI. Lies, wie Teams KI-Skills am besten teilen

Zum Pod meines Teams hinzufügen

Änderungen

Quellen

  1. Competitive Usability Evaluations: Definition - NN/G (gelesen am 2026-11-04)
  2. 10 Usability Heuristics for User Interface Design - NN/G (gelesen am 2026-11-04)