Produkt-Briefing für die KI: vom Problem zum Prompt

Du hast eine Idee, öffnest Lovable und tippst los. Nach einer Stunde hast du Bildschirme, die irgendwie passen, und eine KI, die bei jeder Änderung etwas anderes kaputt macht. Das Problem ist selten das Tool. Es fehlt ein klares Bild davon, was du eigentlich baust. Genau das ist ein Produkt-Briefing: eine Seite, die der KI sagt, worum es geht, und die du nicht in jedem Prompt neu erklären musst.

Kein Pflichtenheft, sondern eine Richtung

Wenn du „PRD“ hörst, denkst du vielleicht an lange Anforderungsdokumente. Brauchst du nicht. Die Lovable-Doku sagt es deutlich: Du schreibst keine Spezifikation, du gibst eine Richtung vor. Vage Ideen erzeugen vage Ergebnisse.

Lovable empfiehlt, vor dem ersten Prompt etwa fünfzehn Minuten in vier Fragen zu stecken:

• Was ist dieses Produkt?
• Für wen ist es?
• Warum werden diese Menschen es nutzen?
• Was ist die eine Aktion, die ein Nutzer ausführen soll?

Wenn du die vierte Frage nicht in einem Satz beantworten kannst, ist das kein Prompt-Problem. Dann ist die Idee noch nicht scharf genug. Geh in dem Fall einen Schritt zurück und prüf deine Idee mit echten Gesprächen, bevor du baust.

Erzähl eine Geschichte statt einer Feature-Liste

Ein Trick aus der Lovable-Anleitung: Beschreib dein Produkt als kurze Geschichte. Wer sitzt vor dem Bildschirm, was will die Person erreichen, wie soll es sich anfühlen? Eine Stichpunktliste lässt genau diesen Kontext weg. Gibt es schon eine Skizze, einen Figma-Entwurf oder eine Seite, die dir gefällt, häng einen Screenshot an, statt das Layout in Worten zu beschreiben.

Dann der wichtigste Teil: Halt die erste Version klein. Lovable formuliert es als ein Nutzer, eine Aktion, ein Ergebnis. Im Beispiel der Doku, einer Buchungs-App für ein kleines Fotostudio, heißt das: Kunden buchen einen Termin. Das ist die ganze Version 1. Zahlung, Erinnerungen und Kalenderansicht kommen später, und später ist billiger als ein erster Prompt, der alles auf einmal will. Wie du deinen Kern findest, steht ausführlicher in MVP mit KI bauen: Wie klein ist klein genug?.

Lass die KI zurückfragen, bevor sie baut

Für alles, was größer ist als eine Kleinigkeit, empfiehlt Lovable den Plan mode. Dort schaut sich Lovable deine Dateien, Datenbank und Logs an, stellt Rückfragen und schlägt einen strukturierten Plan vor. Den kannst du bearbeiten, bevor eine Zeile Code entsteht. Plan mode ist fürs Entscheiden, Build mode fürs Umsetzen.

Nutze das für dein Briefing. Bitte die KI, dir Fragen zu stellen, die du noch nicht beantwortet hast. Oft kommen dabei Punkte hoch, an die du nicht gedacht hast: Welche Rollen gibt es? Was passiert, wenn noch keine Daten da sind? Jede Frage, die du jetzt klärst, ist eine Korrekturschleife weniger.

Das Briefing dauerhaft hinterlegen

Ein Briefing im ersten Chat reicht nicht. Die Tools brauchen einen festen Ort dafür.

In Lovable sind das die Project instructions (früher hießen sie Knowledge). Sie sind immer Teil des Kontexts. Laut Doku sollen sie sich wie ein einseitiges Briefing lesen, nicht wie ein Wiki:

• was das Produkt ist und für wen,
• die wichtigsten Nutzerwege,
• die Kernfunktionen und wie sich unterschiedliche Rollen verhalten,
• Hinweise zum Design: Farben, Ton, Do’s and Don’ts,
• alles, was Lovable immer wieder falsch macht.

Du kannst Lovable auch bitten, einen ersten Entwurf zu schreiben, und ihn dann kürzen. Daneben gibt es Workspace instructions für Regeln über alle Projekte hinweg, mit bis zu 10.000 Zeichen.

In Claude Code übernimmt eine CLAUDE.md-Datei diese Rolle. Jede Sitzung startet mit leerem Kontext, die Datei wird zu Beginn jeder Sitzung gelesen. Die Doku nennt einen guten Anlass für Ergänzungen: wenn Claude denselben Fehler zum zweiten Mal macht oder du dieselbe Korrektur wie in der letzten Sitzung eintippst.

Was das für deinen Launch bedeutet

Ein Briefing ist kein Garant. Beide Tools behandeln deine Anweisungen als Kontext, nicht als erzwungene Regel. Lovable warnt, dass sie in sehr langen Unterhaltungen nicht immer zuverlässig befolgt werden. Claude Code folgt Anweisungen beständiger, je konkreter und kürzer sie sind. Halte dein Briefing deshalb knapp und pflege es, statt es wachsen zu lassen.

Für deinen Weg zum Launch heißt das konkret:

• Diese Woche: die vier Fragen schriftlich beantworten, die Kernaktion in einem Satz.
• Version 1 auf einen Nutzer, eine Aktion, ein Ergebnis kürzen und aufschreiben, was bewusst später kommt.
• Briefing als Project instructions oder CLAUDE.md hinterlegen, bevor du das erste Feature baust.
• Baue in kleinen Schritten: Lovable rät zu einer Änderung pro Prompt. Wenn du mehr als zweimal „und“ schreibst, teil den Prompt auf.
• Jedes Mal, wenn du dieselbe Korrektur zweimal gibst, gehört sie ins Briefing.

Das Briefing ersetzt auch keine Prüfung am Ende. Wer Login und Nutzerdaten hat, sollte vor dem Launch mit zwei Konten testen, ob jeder nur seine eigenen Daten sieht.

Fazit

Die KI baut, was du ihr sagst. Wenn du selbst nicht weißt, was die eine Kernaktion ist, kann sie es auch nicht wissen. Eine Seite Briefing, fest hinterlegt und gepflegt, ist der günstigste Schritt auf dem ganzen Weg zum Live-Produkt.

Du willst dein Briefing nicht allein schreiben und dein Produkt mit Anleitung bis zum Launch bringen? Trag dich in die Warteliste fürs Bootcamp ein und schildere vorab deine Idee – du bekommst eine ehrliche Einschätzung, ob sie zum Format passt.