Vom Discovery‑Call zu build‑fertigen Prompts, die Teams nutzen können

Warum Discovery‑Calls beim Handover oft scheitern

Der Bruch passiert meist nach dem Meeting, nicht währenddessen. Alle verlassen den Discovery‑Call mit dem Gefühl, auf derselben Seite zu sein, aber die Notizen sind zu dünn, um daraus zu bauen. Teams schreiben Sätze wie „benötigt Genehmigungen“, „Admin‑Ansicht“ oder „Kundenportal“ auf und gehen davon aus, das sei genug. Meistens ist es das nicht.

Gefangen geht die tägliche Realität des Geschäfts verloren. Ein Call kann Funktionen abdecken, aber wer die Arbeit macht, in welcher Reihenfolge Dinge passieren, welche Regeln nicht gebrochen werden dürfen und wie Erfolg in einer normalen Woche aussieht, fehlt oft. Wenn dieser Kontext verschwindet, wird die erste Version auf Vermutungen gebaut.

Diese Vermutungen führen zu schwachen ersten Versionen. Ein Bildschirm kann poliert aussehen und trotzdem am Ziel vorbeischießen, weil das falsche Problem gelöst wird. „Benutzer senden Anfragen“ klingt nützlich, sagt aber nicht, ob der Benutzer ein Kunde, ein Außendienstmitarbeiter oder ein Manager ist oder was nach der Einreichung passieren soll.

Deshalb braucht ein guter Prompt Geschäftskontext, nicht nur eine Feature‑Liste. Ein klarerer Handoff klingt eher so: „Außendienstmitarbeiter senden Service‑Anfragen mobil, Vorgesetzte prüfen sie am selben Tag, dringende Jobs überspringen die normale Warteschlange und jede Änderung muss protokolliert werden.“ Das gibt dem Entwickler etwas Reales, woran er arbeiten kann.

Das ist noch wichtiger, wenn ein Team schnell vom Prompt zum funktionierenden Produkt wechseln kann. Bei einer Plattform wie Koder.ai ist Geschwindigkeit ein echter Vorteil — aber nur, wenn der Prompt die Geschäftslogik mitliefert.

Das Ziel ist einfach. Nach dem Call sollte eine Person den Prompt lesen und sofort mit dem Bauen beginnen können. Sie sollte kein Transkript entschlüsseln oder fehlende Details nachjagen müssen.

Beginnen Sie mit den Akteuren und ihren tatsächlichen Aufgaben

Ein guter Handoff beginnt mit Menschen, nicht mit Features. Ohne diesen Schritt verwandelt sich der erste Build oft in einen Haufen Bildschirme ohne klaren Besitzer. Der schnellste Weg, Discovery‑Notizen nützlich zu machen, ist zu fragen: Wer wird dieses Produkt öffnen und was versucht diese Person zu erreichen?

Nennen Sie jede Nutzergruppe, auch wenn sie offensichtlich erscheint. Gründer, Vertriebsmitarbeiter, Manager, Finanzleiter und Support‑Agent können dasselbe System aus völlig unterschiedlichen Gründen nutzen. Wenn diese Rollen verwischt werden, wird der Prompt vage und die erste Version versucht, allen gleichzeitig gerecht zu werden.

Halten Sie jeden Akteur an konkrete Aufgaben gebunden. Ein Vertriebsmitarbeiter aktualisiert vielleicht Deal‑Phasen, protokolliert Anrufnotizen und prüft nächste Schritte. Ein Manager prüft Pipeline‑Zahlen, genehmigt Rabatte und exportiert Wochenberichte. Diese Unterschiede bestimmen, was jede Person zuerst sehen sollte und was sie ändern dürfen sollte.

Eine einfache Aufteilung hilft:

• Tägliche Nutzer wiederholen die gleichen Kernhandlungen.
• Manager prüfen, genehmigen und korrigieren.
• Admins kümmern sich um Einstellungen, Berechtigungen und Systemregeln.
• Nur‑Ansehen‑Nutzer prüfen den Status ohne Bearbeitung.
• Finanz‑ oder Operations‑Nutzer benötigen oft Exporte und Reports.

So vermeiden Sie einen häufigen Fehler: Alle Nutzer wie Admins zu bauen. Die meisten Menschen brauchen keine Vollkontrolle. Sie brauchen den kürzesten Weg zu ihrer üblichen Aufgabe.

Dieses Detail verändert die Qualität des ersten Prompts. „Baue ein CRM“ ist vage. „Vertriebsmitarbeiter aktualisieren Leads, Manager genehmigen Angebotsänderungen, Support kann Kontohistorie einsehen und Finance exportiert abgeschlossene Deals“ gibt dem Produkt eine echte Form.

Machen Sie aus dem Gespräch klare Aufgaben

Ein nützlicher Prompt zerlegt Arbeit in Aktionen, die Menschen tatsächlich ausführen. An diesem Punkt werden Discovery‑Notizen baubar.

Wenn jemand sagt: „Wir brauchen eine bessere Möglichkeit, Bestellungen zu verwalten“, haken Sie nach, bis die Schritte klar sind. „Bestellungen verwalten“ ist keine Aufgabe. „Eine Bestellung anlegen, Zahlungsstatus prüfen, Versand freigeben und eine Bestätigung senden“ ist eine Aufgabe.

Eine kurze Liste von Aktionsverben hilft, verschwommene Notizen zu säubern:

• Erstellen
• Prüfen
• Genehmigen
• Senden
• Aktualisieren

Nutzen Sie diese Verben, um allgemeine Aussagen in Aufgabenzeilen umzuschreiben. Ein Klinikleiter könnte sagen: „Ich möchte, dass das Personal Buchungen schneller bearbeitet.“ Eine build‑bereite Version ist klarer: „Rezeption erstellt einen Termin, prüft die Verfügbarkeit der Ärzte, bestätigt den Slot und sendet eine Erinnerung an den Patienten."

Jede Aufgabe braucht außerdem einen Vor‑ und Nachzustand. Was löst sie aus? Was soll danach passieren? Wenn ein Manager eine Rückerstattung genehmigt, was muss bereits vorhanden sein und was ändert sich nach der Genehmigung? Solche kleinen Details formen Bildschirme, Buttons, Statuslabels und Benachrichtigungen.

Eine einfache Kette funktioniert gut: Auslöser, Aktion, Ergebnis. Zum Beispiel: „Wenn ein neuer Lead eingeht, prüft der Vertriebsmitarbeiter die Details, aktualisiert die Priorität und sendet eine erste Antwort.“ Das lässt sich viel leichter in einen ersten Build übersetzen.

Markieren Sie auch, welche Aufgaben am ersten Tag wichtig sind. Wenn drei Aktionen täglich passieren und zwei einmal im Monat, bauen Sie zuerst die täglichen. Das hält die erste Release fokussiert und nützlich.

Erfassen Sie Einschränkungen, bevor sie zur Überraschung werden

Ein guter Prompt ist nicht nur eine Feature‑Liste. Er braucht auch die Grenzen, innerhalb derer das Team arbeiten muss. Bleiben diese Limits im Call vage, kann die erste Version auf den ersten Blick richtig aussehen und in der Praxis scheitern.

Beginnen Sie damit, Geschäftsregeln in einfacher Sprache aufzuschreiben. Vermeiden Sie technische oder juristische Begriffe, es sei denn, das Team spricht so. Statt „rollenbasiertes Genehmigungs‑Matrix“ lieber „Vertriebsmitarbeiter können Rabatte entwerfen, aber nur Manager dürfen sie genehmigen.“

Einige Einschränkungen prägen den gesamten Build und sollten früh erfasst werden. Dazu gehören Datenschutzregeln, Anforderungen an den Datenstandort und Branchenvorgaben. Muss Kundendaten in einem bestimmten Land oder einer Region bleiben, sagen Sie das klar.

Halten Sie auch fest, was nicht ersetzt werden darf. Viele Teams wollen eine neue App, verlassen sich aber weiterhin auf ein paar bestehende Tools oder manuelle Schritte. Die Buchhaltung braucht vielleicht weiterhin dasselbe System. Der Support benötigt eventuell, dass Tickets im aktuellen Helpdesk verbleiben. Diese Grenzen sind genauso wichtig wie neue Features.

Führen Sie einen kurzen Abschnitt mit praktischen Einschränkungen, z. B.:

• fixes Launch‑Datum
• Budgetrahmen
• Teamgröße und verfügbare Reviewer
• Tools, die im Workflow bleiben müssen
• rechtliche, Datenschutz‑ oder Standortanforderungen

Diese Details schützen den ersten Build vor falschen Annahmen. Sie helfen dem Entwickler auch, bessere Kompromisse zu machen.

Nutzen Sie Beispiele, um den Prompt konkret zu machen

Beispiele verwandeln vage Notizen in etwas, das ein Team tatsächlich bauen kann. Allgemeine Phrasen wie „Bestellungen verwalten“ oder „Leads prüfen“ zeigen nicht die echte Eingabe, das erwartete Ergebnis oder das Qualitätsniveau.

Beginnen Sie mit einem normalen Beispiel aus der jüngsten Arbeit. Wählen Sie etwas Häufiges, nicht einen seltenen Sonderfall. Wenn ein Team sagt, es will eine App zur Qualifizierung von Leads, bitten Sie um einen echten Lead‑Datensatz, welche Details reinkamen und wie das fertige Ergebnis nach der Prüfung aussehen soll.

Ein nützliches Beispiel enthält normalerweise vier Dinge:

• die Beispiel‑Eingabe
• die Schritte oder Entscheidungen, die die App treffen soll
• die erwartete Ausgabe
• was dieses Ergebnis ausreichend gut macht

Bitten Sie dann um einen typischen chaotischen Fall. Dort tauchen oft versteckte Regeln auf. Vielleicht fehlt ein Telefon, vielleicht erscheint derselbe Kunde doppelt, vielleicht ist die Anfrage unklar. Wenn Sie das jetzt festhalten, kann der erste Prompt sagen, ob die App das markieren, überspringen oder nach weiteren Informationen fragen soll.

Seien Sie präzise beim Qualitätsmaßstab. „Es soll funktionieren“ ist kein nützliches Ziel. „Es soll Duplikate gruppieren, die neuesten Kontaktdaten behalten und Matches mit geringer Zuverlässigkeit zur Prüfung markieren“ ist etwas, woran ein Entwickler arbeiten kann.

In der Praxis helfen zwei eingefügte Beispiele oft mehr als eine lange abstrakte Beschreibung. Ein sauberer Fall und ein häufiger chaotischer Fall geben dem Entwickler ein Muster.

Definieren Sie Non‑Goals, um den ersten Build zu schützen

Ein starker erster Prompt braucht klare Grenzen. Ohne sie füllt sich Version eins schnell mit zusätzlichen Ideen und das Ergebnis wird unübersichtlich, langsam oder unkonzentriert.

Schreiben Sie auf, was das Produkt noch nicht tun soll. Das schützt den Kern‑Workflow, den Sie wirklich testen wollen.

Nice‑to‑have‑Ideen sind meist leicht zu erkennen. Sie klingen nützlich, sind aber nicht nötig, um zu beweisen, dass die App funktioniert. Ein individuelles Dashboard, erweiterte Rollen, tiefe Reports oder polierte Benachrichtigungen können später kommen. Sie dürfen nicht mit dem Must‑have‑Flow für Version eins konkurrieren.

Ein paar Fragen helfen:

• Worin können Nutzer in den ersten 1–2 Wochen verzichten?
• Was kann das Team zunächst manuell handhaben?
• Was klingt nützlich, ist aber nicht an das Hauptziel gebunden?
• Welche Integrationen können warten, bis der Kernfluss stabil ist?

Manuelle Arbeit ist oft die richtige temporäre Wahl. Wenn Leads einmal täglich manuell geprüft werden können, brauchen Sie vielleicht noch kein automatisches Routing. Wenn Rechnungen exportiert und manuell versendet werden können, kann die vollständige Abrechnung‑Automatisierung warten. Das ist kein Versagen. Das ist Fokus.

Dasselbe gilt für Integrationen. Teams fragen oft sofort nach Zahlungsanbietern, E‑Mail‑Plattformen, Kalender‑Sync und CRM‑Verbindungen. Wenn Version eins nur einen Workflow validieren soll, notieren Sie, welche Systeme außerhalb dieser Runde bleiben.

Beispiel: Ein internes CRM kann mit Kontakt‑Erfassung, Status‑Updates und einer einfachen Aufgabenliste starten. Non‑Goals könnten Mehrteam‑Berechtigungen, erweiterte Analysen, Mobile‑Push‑Benachrichtigungen und Live‑Sync mit externen Tools sein.

„Nicht in Version eins enthalten“ reicht oft aus. Klare Grenzen machen den ersten Build schneller lieferbar und leichter testbar.

Eine einfache Schritt‑für‑Schritt Prompt‑Vorlage

Ein nützlicher Prompt sollte wie ein kurzes Briefing gelesen werden, nicht wie ein Haufen Notizen. Dieselbe Struktur jedes Mal zu verwenden, erleichtert das Handover enorm.

1. Beginnen Sie mit einer einzeiligen Produktzusammenfassung. Sagen Sie, was es ist, für wen es gedacht ist und welches Hauptresultat es liefern soll.
2. Nennen Sie die Akteure. Listen Sie die Personen auf, die es nutzen werden.
3. Beschreiben Sie die Schlüsselaufgaben. Konzentrieren Sie sich auf die wenigen Aktionen, die in Version eins am meisten zählen.
4. Fügen Sie Einschränkungen und Beispiele hinzu. Schließen Sie Regeln, Limits, Datenanforderungen und ein oder zwei reale Fälle ein.
5. Beenden Sie mit Erfolgskriterien. Definieren Sie, was Version eins gut genug leisten muss, um nützlich zu sein.

Halten Sie die Formulierungen einfach und konkret. Schreiben Sie nicht „Projekte besser verwalten“, wenn Sie eigentlich meinen „Teamleiter können ein Projekt anlegen, Aufgaben zuweisen und Arbeit als erledigt markieren."

Einfache Sätze funktionieren am besten. Zum Beispiel: „Bauen Sie ein kleines CRM für ein Vertriebsteam. Akteure: Vertriebsmitarbeiter und ein Manager. Aufgaben: Leads anlegen, Deal‑Phase aktualisieren und Folgemaßnahmen anzeigen. Einschränkungen: mobilfreundlich, einfaches Dashboard, CSV‑Export. Beispiel: Ein Vertriebsmitarbeiter sollte einen Anruf in unter 30 Sekunden protokollieren können. Erfolg: Das Team kann aktive Deals ohne Tabellenkalkulationen verfolgen."

Das reicht, um einem Entwickler einen klaren Ausgangspunkt zu geben, ohne das ganze Produkt beschreiben zu müssen.

Beispiel: Einen Call in einen nutzbaren Prompt verwandeln

Stellen Sie sich ein kleines Dienstleistungsunternehmen wie eine lokale Reinigungsfirma vor. Im Call sagt der Inhaber: „Kunden müssen online buchen, einfach zahlen und mein Team braucht eine einfache Möglichkeit, Termine zu verwalten.“ Das ist nützlich, aber für einen ersten Build noch zu vage.

Eine build‑bereite Version macht das Gespräch sofort nutzbar:

Build a mobile-friendly booking app for a small cleaning service.

Actors:
- Customer: browse services, choose a time, pay, and get a confirmation.
- Staff: view bookings, block unavailable times, and manage refunds.

Rules and constraints:
- Bookings are available only during business hours: Monday to Friday, 9am to 5pm.
- Same-day bookings close at 2pm.
- Refunds are allowed only if the customer cancels at least 24 hours before the appointment.
- The main use case is mobile, so booking and payment screens must be simple on a phone.

Version 1 should include:
- service list with prices
- available time slots
- online payment at checkout
- booking confirmation for customers
- a basic staff view for upcoming jobs

Version 1 should not include:
- loyalty rewards
- advanced reporting
- multi-location support
- live chat

Das funktioniert, weil es die Akteure klar benennt und vage Anforderungen in echte Aufgaben verwandelt. Die Einschränkungen sind genauso wichtig. Begrenzte Öffnungszeiten verhindern, dass das System unmögliche Zeitfenster anbietet. Rückerstattungsregeln vermeiden später Verwirrung. Mobile Nutzung prägt von Anfang an das Layout.

Die Non‑Goals schützen den Build. Ohne sie kann aus einer einfachen Buchungs‑App schnell ein viel größeres Projekt werden.

Häufige Fehler, die die erste Version schwächen

Eine schwache erste Version scheitert meist nicht, weil das Team sie nicht bauen kann. Sie scheitert, weil der Prompt zu verschwommen war.

Ein häufiger Fehler ist, Feature‑Ideen mit Geschäftsregeln zu vermischen. Ein Gründer sagt vielleicht: „Wir brauchen ein Dashboard, Filter und Alerts“, aber die eigentliche Regel lautet: „Nur Manager dürfen Rückerstattungen über einem bestimmten Betrag genehmigen.“ Wenn diese Regel in einer Wunschliste versteckt ist, kann die erste Version poliert aussehen und trotzdem falsch sein.

Ein weiteres Problem ist, nur aus der Sicht des Gründers zu schreiben. Gründer beschreiben oft, was sie sehen wollen, nicht was jeder Nutzer tun muss. Ein Vertriebsmitarbeiter, ein Operations‑Manager und ein Support‑Agent können das gleiche System ganz unterschiedlich nutzen. Wenn der Prompt nur die Führungsebene widerspiegelt, geht die tägliche Arbeit verloren.

Die häufigsten Fehler sind:

• Ideen, Regeln und Annahmen gleichzusetzen
• die App nur für eine Person anstatt für alle wichtigen Nutzer zu beschreiben
• Edge‑Cases wie Teilzahlungen, späte Genehmigungen oder doppelte Datensätze zu überspringen
• Genehmigungsschritte vage zu lassen, ohne Auslöser, Besitzer oder Frist
• zu versuchen, die gesamte Roadmap in Version eins zu quetschen

Nehmen Sie „Auftragsfreigabe“ als Beispiel. Es klingt klar, ist es aber nicht. Wer genehmigt? Was passiert, wenn der Genehmigende abwesend ist? Muss jede Bestellung genehmigt werden oder nur Bestellungen über einem Schwellenwert? Diese Details ändern den Build.

Bei schnellen App‑Bau‑Tools zeigen sich diese Lücken schnell. Ein sauberer Prompt liefert eine erste Version, die die Leute tatsächlich testen können, statt nur darauf zu reagieren.

Kurze Checkliste, bevor Sie mit dem Bauen beginnen

Bevor Sie einen Prompt an einen Entwickler senden, machen Sie einen kurzen Review. Hier werden dünne Notizen zu klaren Anweisungen.

Was Sie zuerst bestätigen sollten

• Akteure sind leicht zu benennen. Sie sollten jede Nutzertyp schnell auflisten können.
• Jeder Akteur hat echte Aufgaben. Jeder Akteur sollte 2–5 klare Aktionen haben.
• Limits sind aufgeschrieben. Einschließlich Genehmigungsschritten, Datenschutzanforderungen, mobiler Nutzung oder notwendiger Tools.
• Beispiele machen es konkret. Fügen Sie einen normalen Fall und einen Edge‑Case hinzu.
• Non‑Goals sind sichtbar. Machen Sie klar, was Version eins nicht tun wird.

Ein kurzes Beispiel macht den Unterschied deutlich. „Mitarbeiter legt Buchungen an“ ist dünn. Ein stärkerer Prompt sagt: Mitarbeiter können Buchungen anlegen, bearbeiten und stornieren; Manager können Ausnahmen genehmigen; Doppelbuchungen müssen blockiert werden; Version eins enthält keine Rechnungsstellung.

Wenn eines dieser Teile fehlt, halten Sie kurz inne und ergänzen Sie es. Ein kurzes, vollständiges Prompt schlägt fast immer ein langes Prompt mit Lücken.

Nächste Schritte für einen reibungsloseren ersten Build

Wenn der Call vorbei ist, lassen Sie die Notizen nicht über Chat, Docs und Gedächtnis verstreut. Verwandeln Sie sie in ein gemeinsames Build‑Briefing, das jemand in wenigen Minuten lesen kann. Das Briefing sollte Nutzer, Schlüsselaufgaben, Regeln, Beispiele und Non‑Goals in einfacher Sprache erfassen.

Holen Sie dann eine Freigabe für den Scope der ersten Version ein. Keine Zustimmung für das ganze Produkt, nur Übereinkunft darüber, was Version eins tun wird und was nicht. Dieser kleine Schritt verhindert das häufige Problem, dass eine Person eine Demo erwartet und eine andere etwas fast Fertiges.

Ein gutes Scope‑Briefing beantwortet vier Fragen:

• Für wen ist das jetzt gedacht?
• Welche 3–5 Aktionen müssen zuerst funktionieren?
• Welche Einschränkungen dürfen nicht gebrochen werden?
• Was ist für diese Runde bewusst außerhalb des Scopes?

Führen Sie vor dem Generieren einen Planungsdurchgang durch. Verwandeln Sie rohe Notizen in einen nutzbaren Build‑Prompt, prüfen Sie fehlende Details und streichen Sie vage Wörter wie „einfach“, „schnell“ oder „benutzerfreundlich“. Diese Wörter klingen hilfreich, sagen einem Entwickler aber selten, was zu bauen ist.

Zum Beispiel: Statt „Onboarding für Kunden einfach machen“ schreiben Sie: „Ein neuer Kunde kann Name, Kontaktdaten, Projekttyp und Budget in einem Formular angeben und erhält danach eine Bestätigungsseite."

Wenn Sie mit Koder.ai arbeiten, passt dieser Planungsschritt gut zum Planungsmodus. Er hilft Teams, die App zu formen, bevor die Generierung startet, und Snapshots erleichtern das Testen von Prompt‑Änderungen, ohne eine funktionierende Version zu verlieren.

Das Ziel ist kein perfekter Prompt am ersten Tag. Es ist ein gemeinsamer, freigegebener Prompt, der der ersten Version die richtige Richtung gibt. Wenn das Briefing klar ist, ist die erste Version leichter zu prüfen, leichter zu verbessern und deutlich seltener entfernt von der tatsächlichen Geschäftsanforderung.