Was ist ein Product Brief?

Ein kurzes Dokument, das sagt, was ein Produkt ist, welches Problem es für wen löst und was es bewusst weglässt. Es gibt allen, die am Produkt arbeiten, Menschen wie Agenten, denselben Ausgangspunkt.

Worin unterscheidet sich ein Product Brief von einem PRD?

Der Brief deckt das ganze Produkt auf einer Seite ab. Ein Anforderungsdokument (PRD) geht bei einem Feature oder Release in die Tiefe und beschreibt genau, wie es sich verhalten muss. Fang mit dem Brief an und schreib PRDs, wenn ein Feature diese Detailtiefe braucht.

Kann ein KI-Coding-Agent diesen Brief nutzen?

Ja. Speichere die Markdown-Datei in deinem Repository und verweise in AGENTS.md darauf oder importiere sie in CLAUDE.md. AGENTS.md ist einfaches Markdown, und Claude Code liest CLAUDE.md zu Beginn jeder Sitzung.

Warum Markdown und JSON?

Markdown ist für Menschen und Agenten leicht zu lesen und wird auf jeder Code-Plattform dargestellt. JSON enthält denselben Inhalt mit festen englischen Schlüsseln, sodass Skripte und Formulare ihn lesen können, ohne Fließtext zu parsen.

Wird mein Brief gespeichert oder irgendwohin geschickt?

Er liegt nur im lokalen Speicher deines Browsers, damit ein Neuladen ihn nicht löscht. Nichts wird hochgeladen oder an eine Analyse geschickt, und Leeren löscht den Entwurf.

Product-Brief-Vorlage: kostenlos, als Markdown und JSON

Von Aleksandar Vuk JovanovicAktualisiert 30. September 2026So recherchieren und aktualisieren wir

Brief ausfüllen

Tipp direkt in die Felder. Markdown und JSON darunter aktualisieren sich beim Tippen und sind bereit zum Kopieren oder Herunterladen.

Dein Entwurf liegt im lokalen Speicher dieses Browsers und übersteht so ein Neuladen. Er wird nie hochgeladen. Leeren entfernt ihn.

Markdown-Vorschau

# [Produktname]

> [Was es macht, für wen, in einer Zeile]

Zuletzt aktualisiert: [Datum]

## Problem

[Wer sich heute womit herumschlägt]

## Für wen es ist

[Wichtigste Nutzer und Käufer]

## Was es macht

[Wie das Produkt das Problem löst]

## Wichtigste Funktionen

- [Bis zu drei Dinge, die es heute kann]

## Statt

[Was die Leute heute nutzen und warum das hier besser ist]

## Nicht im Umfang

[Was es bewusst nicht macht]

## Woran wir merken, dass es funktioniert

[Ein Signal, das du prüfen kannst]

## Link

[URL der Website oder des Repositorys]

JSON-Vorschau

{
  "format": "product-brief",
  "version": 1,
  "language": "de",
  "updated": "",
  "name": "",
  "oneLiner": "",
  "problem": "",
  "audience": "",
  "solution": "",
  "features": [
    "",
    "",
    ""
  ],
  "alternative": "",
  "nonGoals": "",
  "success": "",
  "url": ""
}

Leere Dateien

Lieber im eigenen Editor? Nimm die leere Vorlage in einem der beiden Formate.

Wofür jedes Feld da ist

Zehn Felder reichen, um Menschen und Agenten darauf auszurichten, was du baust. Jedes beantwortet eine Frage, die dir sonst jemand stellen würde.

Produktname: Alle, auch ein Agent, sollten den Namen gleich schreiben. Leg die Schreibweise hier einmal fest.
Einzeiler: Die Zeile, die du in Einträgen, Bios und auf deiner Startseite wiederverwendest. Wenn du sie nicht schreiben kannst, ist das Produkt noch nicht klar.
Problem: Arbeit beginnt beim Problem, nicht bei der Funktion. Ein klares Problem erlaubt anderen, bessere Lösungen vorzuschlagen als deine.
Für wen es ist: Eine enge Zielgruppe macht jede spätere Entscheidung leichter: Wortwahl, Funktionen, wo du launchst.
Was es macht: Wie das Produkt das Problem löst, in einfachen Worten. Das braucht jemand Neues als Erstes.
Wichtigste Funktionen: Drei Funktionen, die es heute gibt. Ein Agent, der Texte schreibt, sollte nie eine vierte erfinden.
Statt: Menschen vergleichen mit dem, was sie heute tun. Den Behelf zu nennen, erklärt deinen Nutzen besser als eine Funktionstabelle.
Nicht im Umfang: Das Feld, das die meisten Briefs auslassen. Es bremst ausufernden Umfang und hält einen Agenten davon ab, Funktionen einzubauen, um die du nicht gebeten hast.
Woran wir merken, dass es funktioniert: Ein beobachtbares Signal zeigt dir, ob das Produkt funktioniert, und gibt einem Agenten ein Ziel, an dem er sich messen kann.
Link: Mit einem Link können Lesende oder ein Agent Details nachprüfen, statt sie zu raten.

Prüfe deine Tagline gegen das Zeichenlimit jeder Plattform →

Den Brief deinem Agenten geben

Coding-Agenten lesen Markdown-Dateien aus deinem Repository. Ein kurzer Brief neben deinem Code liefert ihnen den Produktkontext, der im Code allein nicht steckt.

Lade die Markdown-Datei herunter und speichere sie in deinem Repository, zum Beispiel als docs/product-brief.md.
Verweise deinen Agenten darauf: Ergänze eine Zeile in AGENTS.md oder importiere sie in CLAUDE.md mit @docs/product-brief.md.
Für GitHub Copilot verlinkst oder kopierst du das Wichtigste in .github/copilot-instructions.md.
Leg das JSON daneben, wenn ein Skript oder ein anderes Tool dieselben Fakten lesen soll.
Ändere die Datumszeile bei jeder Änderung und lösch Sätze, die nicht mehr stimmen.

Thema	Offizieller Wortlaut	Was das für deinen Brief bedeutet
Format	AGENTS.md is just standard Markdown.	Ein einfacher Markdown-Brief funktioniert als Agentenkontext ganz ohne besondere Syntax.
Überschriften	Use any headings you like; the agent simply parses the text you provide.	Die Abschnittsnamen dieser Vorlage sind ein Vorschlag. Benenn sie um, wenn dein Team andere Begriffe nutzt.
Wann gelesen wird	You write these files in plain text; Claude reads them at the start of every session.	Claude Code lädt CLAUDE.md zu Beginn jeder Sitzung, ein importierter Brief ist also immer im Kontext.
Import	CLAUDE.md files can import additional files using @path/to/import syntax.	Eine Zeile wie @docs/product-brief.md in CLAUDE.md genügt, um den Brief einzubinden.
Länge	target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.	Kurzer Kontext wird besser befolgt. Ein einseitiger Brief bleibt weit unter dieser Größe.
Copilot	Add natural language instructions to the file, in Markdown format.	Auch die Anweisungen für Copilot sind Markdown, derselbe Text passt also auch dort.
JSON-Kodierung	JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8	Der JSON-Download ist UTF-8, so überstehen Akzente, CJK-Zeichen und Emoji jedes Tool.

Brief, PRD oder Kontextdatei

Drei Dokumente, die oft verwechselt werden. Sie beantworten unterschiedliche Fragen, und viele Produkte brauchen mehr als eines.

Dokument	Beantwortet	Umfang	Geschrieben von
Product Brief (diese Vorlage)	Was wir bauen, für wen und wo es aufhört	Eine Seite, zehn Felder	Gründer oder Produktverantwortliche
Anforderungsdokument (PRD)	Wie sich ein Feature oder Release genau verhalten muss	Mehrere Seiten pro Feature	Produktmanagement zusammen mit Engineering
Produkt-Kontextdatei	Welche freigegebenen Fakten und Texte ein Agent veröffentlichen darf	Wächst mit jedem Kanal	Wer den Launch verantwortet

Launchplan-Vorlage →

Was diese Vorlage weglässt

Sie ist ein Ausgangspunkt, keine vollständige Spezifikation. Detaillierte Anforderungen, Designs und Recherchen gehören in eigene Dokumente.
Preise, Launch-Termine und Varianten von Marketingtexten gehören bewusst nicht dazu.
Die Seite prüft nicht, ob deine Aussagen stimmen. Schreib nur auf, was das Produkt heute kann.
Nichts wird irgendwohin geschickt: Der Entwurf bleibt in diesem Browser, bis du auf Leeren klickst.

Quellen

Wir haben diese Seiten am 30. September 2026 gelesen und zitieren sie oben wörtlich.

Seite	Datum auf der Seite	Von uns geprüft
AGENTS.md	kein Datum angegeben	30.09.2026
Claude Code Docs: How Claude remembers your project	kein Datum angegeben	30.09.2026
GitHub Docs: Adding repository custom instructions for GitHub Copilot	kein Datum angegeben	30.09.2026
RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format (December 2017)	kein Datum angegeben	30.09.2026
CommonMark Spec, version 0.31.2	kein Datum angegeben	30.09.2026

FAQ

Was ist ein Product Brief?: Ein kurzes Dokument, das sagt, was ein Produkt ist, welches Problem es für wen löst und was es bewusst weglässt. Es gibt allen, die am Produkt arbeiten, Menschen wie Agenten, denselben Ausgangspunkt.
Worin unterscheidet sich ein Product Brief von einem PRD?: Der Brief deckt das ganze Produkt auf einer Seite ab. Ein Anforderungsdokument (PRD) geht bei einem Feature oder Release in die Tiefe und beschreibt genau, wie es sich verhalten muss. Fang mit dem Brief an und schreib PRDs, wenn ein Feature diese Detailtiefe braucht.
Kann ein KI-Coding-Agent diesen Brief nutzen?: Ja. Speichere die Markdown-Datei in deinem Repository und verweise in AGENTS.md darauf oder importiere sie in CLAUDE.md. AGENTS.md ist einfaches Markdown, und Claude Code liest CLAUDE.md zu Beginn jeder Sitzung.
Warum Markdown und JSON?: Markdown ist für Menschen und Agenten leicht zu lesen und wird auf jeder Code-Plattform dargestellt. JSON enthält denselben Inhalt mit festen englischen Schlüsseln, sodass Skripte und Formulare ihn lesen können, ohne Fließtext zu parsen.
Wird mein Brief gespeichert oder irgendwohin geschickt?: Er liegt nur im lokalen Speicher deines Browsers, damit ein Neuladen ihn nicht löscht. Nichts wird hochgeladen oder an eine Analyse geschickt, und Leeren löscht den Entwurf.

Brief fertig? Bring das Produkt vor Menschen.

LaunchRepo gibt deinem Coding-Agenten ein Playbook für jede Launch-Plattform und jedes Verzeichnis, damit das Produkt, das du gerade beschrieben hast, dort gelistet wird, wo deine Zielgruppe sucht, und verfolgt, welche Einträge live gegangen sind.

Preise ansehen