← Alle Artikel
Das Richtige bauen
Wie man ein einseitiges Produkt-Brief schreibt, das wirklich verwendet wird
Vom FabricLoop-Team · Mai 2026 · 4 Min. Lesen
Die meisten Produkt-Briefs teilen dasselbe Schicksal: sorgfältig vor Projektbeginn geschrieben, einmal im Kickoff-Meeting überprüft und nie wieder geöffnet. Wenn das Team mitten im Aufbau ist, ist das Brief ein historisches Artefakt — gelegentlich in Scope-Diskussionen herangezogen, aber selten als lebendiger Leitfaden für Entscheidungen behandelt.
Das ist ein Prozessversagen, kein Formatversagen. Das Brief wird nicht verwendet, weil es nicht für die Verwendung geschrieben wurde. Es wurde geschrieben, um einen Prozess zu erfüllen — um das Kästchen „Wir haben die Anforderungen definiert" abzuhaken — nicht um dem Team tatsächlich zu helfen, bessere Entscheidungen unter Unsicherheit zu treffen.
Ein Brief, das verwendet wird, ist kurz, meinungsstark und rund um die Fragen strukturiert, die das Team tatsächlich in der Mitte des Aufbaus stellen wird: Was lösen wir, für wen, und wie werden wir wissen, ob es funktioniert hat?
"Ein Brief ist kein Anforderungsdokument. Es ist eine Entscheidungsreferenz — eine einzige Seite, auf die das Team zurückgreifen kann, wenn es nicht sicher ist, ob eine Design- oder Scope-Entscheidung richtig ist."
Die fünf Abschnitte, die wichtig sind
Alles in einem Produkt-Brief sollte eine von fünf Fragen beantworten. Wenn ein Abschnitt keine dieser Fragen beantwortet, gehört er wahrscheinlich nicht in ein einseitiges Brief — sondern in eine separate, detailliertere Spezifikation.
Problem
Nutzer verpassen wichtige Updates, weil sie nicht zwischen hochrelevanten Benachrichtigungen (jemand hat ihnen eine Aufgabe zugewiesen) und weniger relevanten (ein Kommentar in einem Thread, dem sie folgen) unterscheiden können. Das Ergebnis: Sie ignorieren alle Benachrichtigungen oder schalten sie ganz ab. Support-Tickets zu „Ich habe es nicht gewusst" machen in diesem Quartal 18 % aller Produktbeschwerden aus.
Nutzer
Primär: Teamleiter und Projektverantwortliche, die häufig erwähnt werden und mit dem Volumen nicht Schritt halten können. Sekundär: Einzelne Mitarbeiter, die standardmäßig Ruhe wollen, aber kritische Aufgabenzuweisungen empfangen müssen. Nicht für Admin-Nutzer — deren Benachrichtigungsbedarf wird durch das Admin-Panel abgedeckt.
Erfolgskennzahl
Primär Benachrichtigungsbezogene Support-Tickets sinken innerhalb von 60 Tagen nach dem Launch um 40 %.
Sekundär Wöchentlich aktive Nutzer, die Einstellungen angepasst haben, steigen von 12 % auf 35 %.
Frühindikator Opt-out-Rate (Nutzer, die alle Benachrichtigungen deaktivieren) sinkt von 23 % auf unter 15 %.
Nicht im Scope
- E-Mail-Benachrichtigungseinstellungen (separates Arbeitselement — andere Infrastruktur)
- Arbeitsbereich-weite Benachrichtigungseinstellungen (zukünftig; diese Version ist nur pro Nutzer)
- Benachrichtigungsplanung / Nicht-stören-Zeiten (validierter Bedarf, Q3-Roadmap)
- Detaillierte Mobile-Push-Benachrichtigungssteuerung (web-first; Mobile folgt wenn validiert)
Offene Fragen
Blockierend Teilen wir Benachrichtigungen in 2 Stufen (kritisch / alles andere) ein oder erlauben wir granulare Pro-Typ-Kontrolle? Nutzerinterviews sprechen für 2 Stufen, aber das Engineering bevorzugt granulare Kontrolle für Flexibilität. Entscheidung notwendig vor Designbeginn.
Nicht-blockierend Sollen Einstellungsänderungen rückwirkend auf bestehende Benachrichtigungen angewendet werden? Kann während des Aufbaus basierend auf dem technischen Aufwand entschieden werden.
Warum „Nicht im Scope" der wichtigste Abschnitt ist
Teams verbringen viel Zeit damit, zu schreiben, was sie bauen werden. Sie verbringen sehr wenig Zeit damit, zu schreiben, was sie nicht bauen werden — und diese Asymmetrie verursacht den meisten Scope-Creep. Wenn der Designer einen „Ruhezeiten"-Schalter hinzufügt, weil er naheliegend erscheint, oder der Ingenieur arbeitsbereichsweite Einstellungen hinzufügt, weil er bereits in der Gegend ist, liegt das meist daran, dass niemand explizit entschieden hat, dass diese außerhalb des Scopes lagen.
Das Aufschreiben von Nicht-im-Scope-Elementen erzwingt ein Gespräch über Grenzen, das sonst mitten im Aufbau stattfinden würde, wenn die Kosten für Kursänderungen viel höher sind. Es gibt dem PM auch eine klare, dokumentierte Grundlage, um Ergänzungen abzulehnen: „Wir haben das im Brief als außerhalb des Scopes entschieden — hier ist der Grund."
Wie man gute Nicht-im-Scope-Elemente schreibt
Listen Sie nicht nur auf, was Sie nicht bauen — notieren Sie kurz warum. „E-Mail-Einstellungen (separate Infrastruktur)" teilt dem Leser mit, dass die Entscheidung bewusst und begründet war, nicht ein Versehen. Das verhindert, dass dieselbe Scope-Frage dreimal während des Sprints wieder auftaucht.
Offene Fragen: der Abschnitt, den die meisten Briefs weglassen
Jedes Projekt beginnt mit ungelösten Fragen. Die meisten Briefs tun so, als wäre das nicht der Fall — sie werden geschrieben, als wären alle Entscheidungen getroffen worden, selbst wenn der Autor weiß, dass das nicht stimmt. Das Ergebnis ist, dass Teams die offenen Fragen mitten im Aufbau entdecken, wenn sie am störendsten sind.
Das explizite Auflisten offener Fragen bewirkt zwei Dinge. Erstens: Es zeigt auf, welche Fragen vor Arbeitsbeginn gelöst werden müssen (blockierend) gegenüber jenen, die während des Aufbaus entschieden werden können (nicht-blockierend). Zweitens: Es signalisiert dem Team, dass das Brief ein Arbeitsdokument ist, keine fertige Spezifikation — was es wahrscheinlicher macht, dass es darauf zurückgreift und es aktualisiert, wenn Entscheidungen getroffen werden.
Die Längenfalle
Ein Brief, das über eine Seite hinausgeht, ist kein Brief mehr — es ist ein Spezifikationsdokument. Spezifikationen haben ihren Platz, dienen aber einem anderen Zweck. Wenn Sie mehr als eine Seite benötigen, extrahieren Sie das Detail in einen verlinkten Anhang und halten Sie das Brief auf die fünf Kernabschnitte beschränkt.
Wie FabricLoop das Brief lebendig hält
Ein Brief bleibt nur nützlich, wenn das Team es finden und aktualisieren kann. FabricLoop pinnt das Brief an den Projekt-Thread, sodass es immer nur einen Klick entfernt ist — und die Diskussion darum (getroffene Entscheidungen, gelöste offene Fragen, Scope-Änderungen) ist direkt im Kontext statt verteilt über E-Mail und Slack.
10 Erkenntnisse aus diesem Artikel
- Die meisten Produkt-Briefs werden geschrieben, um einen Prozess zu erfüllen, nicht um Teams bei besseren Entscheidungen zu helfen. Deshalb werden sie nie wieder verwendet.
- Ein Brief ist eine Entscheidungsreferenz, kein Anforderungsdokument. Es sollte die Fragen beantworten, die mitten im Aufbau entstehen.
- Die fünf wichtigen Abschnitte: Problem, Nutzer, Erfolgskennzahl, Nicht im Scope, Offene Fragen. Alles andere ist eine Spezifikation.
- Der Problem-Abschnitt sollte den Nutzerschmerz konkret beschreiben — mit Daten wo möglich — nicht nur den zu adressierenden Bereich benennen.
- Zu benennen, für wen man nicht baut, ist genauso wichtig wie zu benennen, für wen man baut. Unklarheit über Nutzer verursacht Scope-Creep im Design.
- Erfolgskennzahlen müssen messbar, zeitgebunden und vor Baubeginn vereinbart sein — nicht nachträglich aus Nutzungsdaten abgeleitet.
- Der Nicht-im-Scope-Abschnitt ist der wichtigste. Ungeschriebene Scope-Grenzen dehnen sich während eines Aufbaus zuverlässig aus.
- Nicht-im-Scope-Elemente mit kurzen Begründungen beschriften, um zu verhindern, dass dieselben Fragen während des Sprints wieder auftauchen.
- Offene Fragen sollten explizit als blockierend (vor dem Aufbau entscheiden) oder nicht-blockierend (während des Aufbaus entscheiden) gekennzeichnet werden.
- Ein Brief, das mehr als eine Seite umfasst, ist zu einer Spezifikation geworden. Das Detail in einen Anhang extrahieren und das Brief eng halten.
