Vor drei Wochen starrte ich um 22:30 Uhr auf eine Notion-Seite. Ein Kunde hatte ein Briefing für eine maßgeschneiderte Buchungsplattform eingereicht. Das Briefing bestand aus vier Stichpunkten und einem Emoji. Einfach nur: „wie Calendly, aber für Hundefriseure 🐶". Das war alles. Keine User Flows. Keine Edge Cases. Keine Ahnung, ob sie eine SaaS oder eine Single-Tenant-Installation wollten. Und sie brauchten ein Spec bis Freitag.
Ich habe solche Momente früher gefürchtet. Jetzt freue ich mich fast darauf.
Denn ich habe einen Workflow rund um Claude aufgebaut, der diese Art von Chaos in wenigen Stunden in ein strukturiertes, verteidigbares Spec umwandelt. Ich habe ihn über etwa 40 Projekte bei Seahawk im letzten anderthalb Jahr verfeinert, und er hat mich vor mindestens drei „aber ich dachte, es würde X tun"-Umschreibungen bewahrt, die echtes Geld gekostet hätten.
Lass mich dich ordnungsgemäß hindurchgehen.
---
Warum ein vages Briefing tatsächlich ein guter Ausgangspunkt ist
Das ist die Sache mit vagen Briefings: Sie enthalten Signal. Die Hundefriseur-Calendly-Sache sagt dir Branche, Vergleichsprodukt und implizierte Skalierung (kleines Unternehmen, nicht Enterprise). Das ist nicht nichts.
Der Fehler, den ich früher machte, war, das Briefing sofort selbst auszuarbeiten. Ich würde Annahmen machen, sie in ein Dokument einbetten, und dann würde ein Kunde etwas unterzeichnen, das zu 40% meine Vermutungen waren. Das ist ein Desaster, das nur darauf wartet, passiert zu werden.
Claude hat dieses Problem nicht. Es fragt. Oder besser gesagt: Wenn du es richtig promptest, generiert es die Fragen, die du hätte stellen sollen.
Mein erster Schritt bei jedem neuen Projekt ist, das rohe Briefing in Claude zu kopieren und es aufzufordern, jede Annahme zu identifizieren, die ich machen müsste, um die Sache zu bauen. Nicht Features. Annahmen. Die Ausgabe sind normalerweise 15-25 Fragen, und etwa ein Drittel davon sind welche, über die ich hinweggegangen wäre.
Für das Hundefriseur-Projekt hat Claude Dinge wie diese ans Licht gebracht: Hat der Friseur mehrere Mitarbeiter, oder ist es ein Einzelbetrieb? Muss die Buchung berücksichtigen, dass die Haustiersgröße die Terminlänge beeinflusst? Gibt es eine Anzahlung oder Zahlungserfassung zum Buchungszeitpunkt? Ich hatte gar nicht an die Haustiersgröße gedacht. Der Kunde auch nicht, wie sich herausstellte. Wir haben das im Discovery Call statt in Sprint drei gefunden.
---
Die Prompt-Struktur, die wirklich funktioniert
Ich habe viele verschiedene Wege ausprobiert, um Spec-Arbeiten zu prompen. Generische Sachen wie „hilf mir, eine Buchungs-App zu designen" geben dir generisches Zeug. Was funktioniert, ist eine strukturierte Eingabe, die Claude genug Kontext gibt, um seine Ausgabe einzuschränken.
Hier ist das ungefähre Template, das ich jetzt nutze:
- Rollendefinition. Ich sage Claude, es agiert als Senior Product Manager, der B2B SaaS schon geliefert hat und allergisch gegen Scope Creep ist.
- Rohes Briefing. Wörtlich einfügen, egal wie roh es ist.
- Constraints. Budget-Spanne, Tech Stack falls bekannt (wir nutzen standardmäßig WordPress/WooCommerce für die meisten Client-Websites, Custom Laravel für alles Schwerere), Timeline, Team-Größe.
- Output-Format. Ich fordere ein strukturiertes Dokument mit spezifischen Sections an: Problem Statement, User Personas, Core User Flows, Feature List (MVP vs. Post-Launch), offene Fragen und Risiken.
Der Constraints-Teil ist das Stück, das die meisten überspringen. Es zählt enorm. "Budget: £8.000, Zeitrahmen: 8 Wochen, zwei Entwickler und ein teilzeitlicher Designer" führt zu einer völlig anderen Spezifikation als das gleiche Briefing ohne Constraints. Ohne sie wird Claude glücklich ein Produkt spezifizieren, das sechs Monate und £60.000 zum Bauen bräuchte. Das macht Spaß zu lesen und ist nutzlos zum Ausliefern.
---
Die Spec mit Adversarial Prompting iterieren
Eine erste Entwurfsspezifikation zu bekommen ist das Leichte. Der eigentliche Wert liegt in der Iteration.
Nachdem Claude das Anfangsdokument erstellt hat, führe ich das aus, was ich einen adversarialen Durchgang nenne. Ich frage es buchstäblich: "Argumentiere jetzt gegen diese Spec. Wo ist Scope Creep am wahrscheinlichsten? Was haben wir unterschätzt? Welche Funktion auf dieser Liste wird in 12 Monaten die meisten technischen Schulden verursachen?"
Seahawk hatte 2022 einen Fintech-Kunden, der ein Dashboard zum Tracking von Micro-Investment-Portfolios wollte. Die erste Spec sah solide aus. Der adversariale Durchgang zeigte, dass die "Echtzeit-Preisaktualisierungen"-Funktion im MVP viel Gewicht trug und wahrscheinlich eine WebSocket-Architektur brauchte, die wir weder in unserem Zeitrahmen noch in unserem Budget vorgesehen hatten. Wir haben es erkannt. Wir haben es auf Polling alle 60 Sekunden für das MVP begrenzt, mit Echtzeit als Phase-zwei-Feature. Der Kunde war damit einverstanden. Hätten wir das ohne den adversarialen Durchgang erkannt? Vielleicht. Aber wahrscheinlich erst, als jemand drei Wochen im Bau war.
Der adversariale Schritt kostet vielleicht 20 Minuten des Prozesses. Es lohnt sich jedes Mal.
---
Spec in User Stories übersetzen
Sobald die Spec so solide ist, dass ich mich nicht dafür schämen muss, gehe ich zur User-Story-Generierung über. Das ist, wo Claude wirklich glänzt, denn gute User Stories zu schreiben ist mühsam und leicht, es schlecht zu machen.
Ich füttere Claude die Spec zurück und frage nach User Stories im Standardformat: "Als [Rolle] möchte ich [Aktion], damit [Ergebnis]." Ich frage auch, dass es Akzeptanzkriterien für alles Nicht-Triviale kennzeichnet, denn "als Groomer möchte ich Urlaubszeit blockieren" hat eine überraschende Anzahl von Sonderfällen (wiederkehrende Blöcke? welche Zeitzone? benachrichtigt es Kunden mit bestehenden Buchungen?).
Ein paar Dinge, auf die ich bestehe:
- Stories sollten für eine spezifische Persona geschrieben werden, nicht für einen generischen "Nutzer"
- Jede Story bekommt eine grobe Komplexitätsschätzung (S/M/L, nichts Granulareres als das auf diesem Stand)
- Alles im "L"-Bucket wird zur weiteren Zerlegung gekennzeichnet, bevor es in Jira geht
Dieser letzte Punkt zählt. Eine L-Story in einem Sprint-Planning-Meeting ist grundsätzlich eine Granate. Claude dazu zu bringen, sie früh zu identifizieren, bedeutet, dass wir ein Gespräch führen, bevor jemand anfängt zu bauen.
---
Wo ich mit Claude die Linie ziehe
Ich möchte ehrlich darüber sein, denn ich sehe viele enthusiastische Takes, dass KI jetzt alles macht.
Claude ist nicht gut darin, Dinge zu entscheiden. Es ist ausgezeichnet darin, Optionen und Kompromisse darzulegen, aber die eigentliche Entscheidung, ob man ein benutzerdefiniertes Benachrichtigungssystem bauen oder Novu nutzen soll (das wir auf drei Projekten genutzt haben und würden empfehlen), erfordert immer noch jemanden, der das Projekt, den Kunden und die Fähigkeiten des Teams kennt.
Ich habe auch festgestellt, dass es bei allem mit bestimmten Bibliotheksversionen oder Nischen-API-Verhalten unzuverlässig ist. Für breite Architektur-Diskussionen ist es okay. Für "wird diese spezifische Version von WPGraphQL dieses spezifische Query-Pattern unter Last handhaben", würde ich lieber testen als vertrauen.
Und ehrlich? Das Prompting selbst braucht Geschick. Ein Junior in meinem Team versuchte, den gleichen Workflow zu nutzen und bekam mittelmäßige Specs zurück, weil das Constraint- und Rollen-Framing nicht eng genug war. Das Tool verstärkt, wer es nutzt. Das ist keine Kritik, nur wert, realistisch darüber zu sein.
---
Die Ausgabe in ein lebendes Dokument organisieren
Die Spec, die Claude produziert, ist nicht das Endprodukt. Es ist Input.
Mein eigentliches Deliverable für einen Kunden ist ein Notion-Dokument, das aus der Claude-Ausgabe gebaut, aber in ein Format reorganisiert wird, das für Sign-off Sinn macht. Typischerweise:
- Zusammenfassung für die Geschäftsführung (3-4 Sätze, kein Jargon)
- Umfang (was enthalten ist, was explizit ausgeschlossen ist)
- Nutzer-Personas (maximal 2–3, mehr ist in diesem Stadium nur Lärm)
- Kernabläufe (als nummerierte Schritte geschrieben, nicht als Prosa)
- Feature-Tabelle (Spalten: Feature, MVP oder Phase 2, ungefährer Aufwand, Verantwortlicher)
- Offene Fragen (alles, das eine Entscheidung blockiert, mit benannter verantwortlicher Person)
- Risiken und Maßnahmen
Diesen Abschnitt zu offenen Fragen habe ich nach einem Projekt 2020 eingeführt, das schiefging, weil alle davon ausgegangen waren, dass jemand anders die Datenspeicherrichtlinie geklärt hatte. Eine Person gegen jede offene Frage zu benennen bedeutet, dass sie nicht einfach auf unbestimmte Zeit liegen bleibt.
Das Notion-Dokument wird mit dem Kunden geteilt, er kommentiert direkt darin, und wir führen ein 45-minütiges Gespräch, um es durchzugehen. Nichts geht an einen Entwickler, bis jede offene Frage beantwortet ist.
---
The Actual Time Savings, Honestly Stated
Vor diesem Arbeitsablauf würde eine Spezifikation für ein mittelkomplexes Projekt (sagen wir ein Membership-Portal oder einen Custom-E-Commerce-Aufbau) einen Tag und eine Halbe dauern. Schreiben, in Frage stellen, umschreiben. Einen Entwurf an einen Kollegen schicken, Kommentare bekommen, diese einarbeiten.
Jetzt sind es etwa zwei bis drei Stunden für den Claude-gestützten Entwurf, dann vielleicht noch eine Stunde manuelles Bearbeiten und kundenorientiertes Feinschleifen. Rechnet man alles zusammen, sind es drei bis vier Stunden insgesamt.
Das ist über ein Jahr betrachtet kein unbedeutender Zeitgewinn. Bei Seahawk erstellen wir Spezifikationen für vielleicht zwei bis drei Projekte pro Monat. Selbst bei konservativer Rechnung sind das 50–70 Stunden pro Jahr, die ich nicht damit verbringe, Erstabzüge von Spezifikationen von Grund auf zu schreiben.
Aber der größere Gewinn ist ehrlich gesagt die Qualität. Der adversariale Durchgang findet insbesondere Dinge, die ich übersehen hätte. Das Aufdecken von Annahmen am Anfang macht Discovery-Calls produktiver, weil wir echte Entscheidungen diskutieren, nicht ich, der versucht, Lücken zu füllen, die ich nicht bemerkt hatte.
---
FAQ
Funktioniert dieser Arbeitsablauf auch für interne Tools genauso wie für Kundenprojekte?
Ja, und manchmal funktioniert er für interne Sachen sogar besser, weil man den Nutzer besser kennt, als jeder Kundenbriefing dir sagen kann. Ich habe im Wesentlichen denselben Prozess verwendet, als wir letztes Jahr Seahawks eigenes internes Zeitverfolgungstool spezifizierten. Die Constraint-Eingabe war einfach, weil ich das Budget kannte (0 £ externe Ausgaben, ein Entwickler, drei Wochen) und die Personas waren buchstäblich Leute im Büro.
Kann ein nicht-technischer Gründer das ohne einen Entwickler nutzen?
Bis zu einem gewissen Punkt. Die Schritte zum Aufdecken von Annahmen und zur User Story funktionieren ohne technische Kenntnisse gut. Wo es knifflig wird, ist der adversariale Durchgang und die Aufwandsschätzung. Du brauchst etwas Erfahrung, um zu wissen, wann Claude die Komplexität unterschätzt. Wenn du nicht technisch versiert bist, mach diesen Schritt mit jemandem zusammen, der bereits Software ausgeliefert hat, auch wenn es nur ein einstündiges Gespräch ist.
Wie gehst du mit vertraulichen Kundeninformationen um, wenn du Claude nutzt?
Ich anonymisiere alles Sensible, bevor es in einen Prompt geht. Kundennamen werden zu „[Client]", alle personenbezogenen Daten werden entfernt. Ich nutze Claude auch über die API für alles wirklich Vertrauliche, wo Anthropics Enterprise-Datenverarbeitungsbedingungen gelten, anstelle des Consumer-Produkts. Es lohnt sich, Anthropics Nutzungsrichtlinie zu lesen, bevor du entscheidest, was für deinen Kontext angemessen ist.
Überlebt die Spezifikation immer den ersten Kontakt mit Entwicklern?
Nein. Und das sollte sie auch nicht. Die Spezifikation ist ein erzwingendes Mittel, um die richtigen Gespräche früh zu führen, kein Vertrag, der das Denken einfriert. Was ich Kunden sage: Die Spezifikation ist unser gemeinsames Verständnis dessen, was wir heute bauen. Sie wird sich ändern. Was sie tut, ist diese Änderungen sichtbar und absichtlich zu machen, statt zufällig.
---
Eine Spezifikation ist kein Dokument. Es ist ein Argument. Du argumentierst, dass du das Problem gut genug verstehst, um etwas Wertvolles zu bauen. Claude führt dieses Argument nicht für dich. Aber er ist ein bemerkenswerter sparring partner, während du herausfindest, was du eigentlich sagen willst.
Das ist zwei Stunden jemandem wert.