Was vorher fertig sein muss
Mindestens fünf dokumentierte Kundeninteraktionen oder konkrete Job-to-be-Done-Insights liegen vor, sodass das Press Release nicht aus interner Phantasie entsteht.
Was vor Start vorliegen muss
Press-Release-Template (Headline, Subheadline, Datum, Stadt, Lead-Absatz mit Problem und Lösung, Kunden-Quote, Spokesperson-Quote, Call to Action); FAQ-Template (interne und externe Fragen); Reviewer-Liste; Tracking-Tool für Iterationen.
Ein Owner (PM oder Product Lead) als Autor; ein bis zwei Reviewer pro Iteration; Sponsor mit Vetorecht; optional ein Copy-Editor für Klarheit; Stakeholder für FAQ-Antworten.
Vision oder Strategie-Anker; Kundenforschung mit Quotes; bekannte Constraints (Tech, Regulatorik, Markt); vergleichbare Wettbewerber-Releases als Inspiration; Definition was nach Akzeptanz passiert.
4-8 h verteilt über mehrere Iterationen
Dokument anlegen mit zwei Sektionen: Press Release und FAQ. Reviewer-Termine im Kalender. Iterations-Cadence festgelegt (z. B. Initial Draft, Review-Runde 1, 2, 3, Final).
Die eine Frage, die diese Methode beantwortet
Welche Pressemitteilung und welche FAQ kann das Team heute schreiben, damit klar wird, was der Launch in 12-24 Monaten für Kunden bedeutet und ob es sich zu bauen lohnt?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Headline und Subheadline | 30-45 min | Headline (max 10 Wörter) und Subheadline (Wirkung in einem Satz) iterieren. Mindestens drei Versionen schreiben, beste wählen. Test: würde ein Kunde stehen bleiben? | Wenn die Headline Featurelisten enthält, ist sie nicht headline-tauglich. Wirkung vor Funktion. Wenn ein Kunde nicht aus Headline und Subheadline den Nutzen versteht, ist die Story nicht klar. |
2Phase 2: Lead-Absatz und Problem | 45-60 min | Erster Absatz: Datum, Stadt, Unternehmen, Produkt-Statement. Zweiter Absatz: Problem in Kundensprache (kein Insider-Jargon). Konkretes Szenario mit Person und Situation. | Problem-Absatz testet, ob das Team versteht, was Kunden heute wirklich frustriert. Wer dort Annahmen statt Beobachtungen formuliert, baut auf Sand. |
3Phase 3: Lösung und Kunden-Quote | 45-60 min | Lösung in 2-3 Sätzen erklären: was, wie, warum besser als heute. Kunden-Quote schreiben, als hätte ein realer Nutzer (z. B. Sabine) das gesagt. Quote muss spezifisch sein, nicht generisch („super App“). | Wenn die Quote auch zur Konkurrenz passen würde, ist sie zu allgemein. Quote muss das Unikum benennen, das nur dieses Produkt liefert. |
4Phase 4: Spokesperson-Quote und Call to Action | 30-45 min | Quote des Sponsors oder Founders mit strategischer Botschaft. Call to Action konkret (Where to buy, sign up, learn more). Datum, Verfügbarkeit, Preis grob anvisieren. | CTA muss heute formulierbar sein. Wenn niemand sagt, was der Kunde nach dem Release tun soll, ist das Konzept noch nicht ausgereift. |
5Phase 5: FAQ (intern und extern) | 1-2 h | Mindestens 15 harte Fragen: technische Machbarkeit, Wirtschaftlichkeit, Regulatorik, Wettbewerb, Risiken, Kanibalisierung. Antworten ehrlich, mit offenen Punkten und Annahmen markiert. | FAQ ist der härteste Teil. Wer die FAQ nicht ehrlich beantworten kann, kennt das Vorhaben nicht. Offene Antworten zwingen zu Spikes und Validierungen. |
6Phase 6: Review-Iterationen | Halber Tag bis 1 Tag | Mindestens zwei Review-Runden mit Reviewer-Pool. Pro Runde schriftliche Kommentare, dann Überarbeitung. Versionen versionieren. Sponsor signiert finale Version oder verwirft. | Reviewer-Kommentare zeigen oft Storylücken. Wer Kommentare nur kosmetisch einarbeitet, verfehlt den Sinn. Substantielle Kritik führt zur Überarbeitung von Lösung oder Problem. |
Was am Ende rauskommt
Press-Release-Dokument (max 1.5 Seiten) plus FAQ (3-6 Seiten) mit versionierten Iterationen, Reviewer-Kommentaren, Decider-Signature und Verweisen auf zugrundeliegende Research-Quellen.
Pro Iteration Datum und Version (v0.1, v0.2, ...). Final Version mit Signature und Datum. Spätere strategische Updates erzeugen neue Major-Version, alte bleibt archiviert.
Kompakte Arbeitsvorlage für Working Backwards mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Working Backwards Arbeitsvorlage
## Ziel
Schreibt zuerst die Pressemitteilung und FAQ einer Lösung, bevor sie gebaut wird (Amazon).
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Future Press Release:
- FAQ:
- Vision Statement:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Press Release (Konzept v0.4, 18.05.2026)
**FOR IMMEDIATE RELEASE — 15.09.2027, München**
# Solo-Selbstständige sehen ihre Steuerlast in Echtzeit
## Neuer KI-Co-Pilot „Klarheit“ liefert tagesaktuell, was bisher der Steuerberater im Quartal liefert.
München, 15.09.2027 — Klarheit GmbH startet heute den Co-Piloten Klarheit für Solo-Selbstständige in DACH. Das Produkt zeigt jederzeit die aktuelle Steuerlast und Liquidität, ohne dass Nutzer Belege manuell sortieren oder warten müssen.
Bisher erfahren viele Solo-Selbstständige ihre Steuerlast erst im Quartalsgespräch mit dem Steuerberater. Bis dahin bleibt unklar, wieviel sie ausgeben dürfen.
Klarheit erfasst Belege per Foto in unter 30 Sekunden, ordnet sie automatisch zu und aktualisiert Steuer- und Liquiditätsstand live. Ein DATEV-kompatibler Export geht jederzeit an den Steuerberater.
„Ich weiß jetzt morgens beim Kaffee, ob ich heute den neuen Laptop kaufen kann oder nicht“, sagt Sabine M., Solo-Steuerberaterin aus Leipzig. „Ich rufe meinen Berater nur noch für das Jahresgespräch an, nicht mehr für Zwischenstände.“
„Wir wollen die Wissenslücke zwischen Selbstständigen und ihrer Steuer schließen“, sagt @julia, Gründerin von Klarheit. „Tagesaktuelle Klarheit war bisher exklusiv für große Unternehmen mit Inhouse-Buchhaltung. Wir bringen sie zu allen.“
Klarheit ist ab heute für iOS, Android und Web verfügbar, ab 12 EUR/Monat. Mehr unter klarheit.app.
## FAQ (Auszug)
**Wie genau ist die Steuerprognose?** Initial ±5% basierend auf Beleg-Klassifikation. Genauigkeit steigt mit Datenmenge. Genaue Endabrechnung bleibt beim Steuerberater.
**Akzeptieren Steuerberater unseren DATEV-Export?** Validierungs-Annahme. Status: 5 STB-Gespräche bis 15.06.2026, dann Update.
**Was passiert bei einer Steuerprüfung?** Nutzer behält volle Belegdaten in Klarheit, exportierbar. Klarheit ist kein Steuerberater-Ersatz für rechtsverbindliche Beratung.Symptome erkennen, gegensteuern
Headline lautet „App mit KI-OCR und DATEV-Export“ statt Wirkung.
Wirkung in Kundensprache. Test: würde ein Kunde anhand der Headline verstehen, was er bekommt? Featurelisten gehören in den FAQ, nicht ans Cover.
Kunden-Quote könnte auch für drei andere Produkte gelten.
Quote spezifisch machen: was kann der Kunde mit diesem Produkt, das er ohne nicht konnte? Namen, Beruf, konkrete Situation. Wenn die Quote austauschbar ist, fehlt Differenzierung.
FAQ-Antworten klingen alle positiv, schwierige Fragen werden umschifft.
Mindestens drei Fragen, deren Antwort „wir wissen es noch nicht, validieren bis X“ ist. Ehrliche FAQ ist der Wert der Methode. Glättung verfehlt den Zweck.
Owner schreibt allein, kein Reviewer kommt rein, blinde Flecken bleiben.
Mindestens zwei Reviewer aus verschiedenen Disziplinen (Engineering, Sales/Markt, Kundenkontakt). Kommentar-Runde mit Frist. Owner überarbeitet substantiell.
Team schreibt PR, um Stakeholder zu beeindrucken, statt Konzept zu schärfen.
Methode ist Tool fürs Denken. Wer kein Wort an der Lösung ändert durch das Schreiben, hat den Hebel verfehlt. PR-Iteration muss Konzept beeinflussen.
CTA „Mehr unter example.com“, niemand kann sagen, was Kunde wirklich tun wird.
CTA konkret machen: Anmeldung, Download, Buchung, Test. Wenn das nicht definierbar ist, ist Go-to-Market nicht durchdacht.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.