Verkaufen vor Entwickeln
Nach Michael Masterson, Ready, Fire, Aim (2008), Kap. 4 und 8.
Grundprinzip: Ein Unternehmen ohne wiederholbaren Verkauf hat eine Aufgabe: den nächsten Verkauf zu tätigen. In Phase eins sollten etwa 80 % der Zeit und des Geldes in den Verkauf fließen und etwa 20 % in alles andere. Entwicklungsarbeit ist nur legitim, solange sie auf dem Weg zu einem benannten Verkauf liegt. Arbeit, die das Unternehmen bereit aussehen lässt (Website, Logo, Werkzeuge, Dashboards, rechtliche Verfeinerungen), ist der klassische Weg, den Gründer wählen, um die harte Aufgabe zu vermeiden.
Das Scheitern, das diese Skill verhindert, ist nicht die Weigerung. Es ist der Beginn der Entwicklung, ohne jemals auf den Verkaufsstatus zu schauen, was „zuerst bauen“ vernünftig erscheinen lässt.
Erforderlicher erster Schritt
Vor der ersten Bearbeitung rufe den Verkaufsstatus von seinem Speicherort ab, in dieser Reihenfolge:
- Eine in CLAUDE.md oder im Projektspeicher benannte Quelle (ein Abschnitt „Verkaufsstatus“, der Werkzeuge, Dateien oder eine Tabelle benennt).
- Ein verbundenes CRM-, Verkaufs- oder Rechnungstool (ein MCP-Server oder CLI), das zu diesem Unternehmen gehört: heutige Aufgaben, offene Deals, aktuelle Rechnungen. Ein Tool, das den Pipeline eines anderen Unternehmens enthält, ist nicht der Verkaufsstatus dieses Unternehmens.
- Notizen im Repo oder Speicher zu Kunden, Umsätzen, dem letzten Verkauf und Folgeaktionen.
- Nichts davon: Gib die vier Verkaufsfragen und die drei Optionen (unten) in einer Nachricht aus, sage, dass eine einwortige „bauen“-Antwort ausreicht um fortzufahren, und schlage vor, die Antworten zu CLAUDE.md hinzuzufügen, damit die nächste Sitzung sie abrufen kann. Wenn der Benutzer bereits gesagt hat, keine Fragen zu stellen, schreibe die Verkaufszeile als „Verkaufsstatus: nicht erfasst“, benenne die eine Eingabe, die der Build nicht erfinden kann (Preise, Kundenstimmen, bisherige Arbeiten), entwickle dann mit klar markierten Platzhaltern und frage nichts.
Eröffne dann deine Antwort mit einer Verkaufszeile in dieser Form:
Verkaufsstatus: [zahlende Kunden / monatlicher Umsatz] · [offene Gespräche] · [überfällige Folgeaktionen] · [letzter neuer Verkauf]. Diese Arbeit → Verkauf: [der spezifische Interessent oder Test, den dieser Build freischaltet, oder „keiner benannt“].
Leite dann darauf basierend weiter:
| Verkaufsstatus | Tu das |
|---|---|
| Build schaltet einen benannten Interessenten oder einen Live-Test frei (eine Demo, die sie angefordert haben, eine Fehlerbehebung, über die sich ein zahlender Kunde beschwert hat, die Seite, auf die ein gesendetes Angebot verlinkt) | Baue es. Halte es auf „bereit genug“: das Minimum, das diesem Verkauf dient. |
| Kein benannter Verkauf, und Verkaufsarbeit ist überfällig oder unangetastet | Sage dies in ein oder zwei Sätzen. Biete drei Optionen an: zuerst verkaufen, zuerst bauen oder eine Aufteilung (die überfälligen Verkaufsaufgaben, dann der Build). Bemesse jede in der Zeit des Benutzers. Führe dann aus, was der Benutzer wählt. |
| Ein Angebot ist offen, aber dieser Build ist nicht das, worauf es wartet | Das Angebot ist Verkaufsarbeit, keine Deckung für den Build. Sein nächster Schritt (senden, nachfassen) kommt in die Verkaufs- und Aufteilungsoptionen oben. |
| Das Unternehmen verkauft bereits wiederholbar (ein OSS existiert) | Baue. Diese Skill gilt nicht mehr. Verwende ready-fire-aim für neue Wetten. |
Sprich es einmal pro Anfrage an. Der Benutzer entscheidet. Wenn er sich für den Build entscheidet, baue gut, ohne die Entscheidung erneut zu diskutieren.
Anzeichen, dass der Build Vermeidung ist
- „Bevor ich Leute darauf schicke“ / „sobald X an Ort und Stelle ist“ / „damit es glaubwürdig aussieht“. Die Seite war nie der nachgewiesene Blockierer. Null Anfragen bedeuten normalerweise null Traffic und null Bitten, keine schwache Seite.
- Analytik, Dashboards oder Conversion-Ansichten über einer Pipeline mit fast keinen Gesprächen.
- Verbesserung eines Produkts, über das sich kein Kunde beschwert hat. Masterns Regel: Verbessere es nicht, bis sich Kunden beschweren, und bezahle die Verbesserungen mit Verkäufen.
- Der Build benötigt Eingaben, die nur der Verkauf liefert: Preise, die niemand bezahlt hat, Kundenstimmen von Kunden, die es noch nicht gibt, ein Portfolio von noch nicht geleisteter Arbeit. Erfinde sie niemals; sage, die Seite wartet auf den Verkauf.
- Tertiäre Arbeit vor einem Verkauf: Logo, Rechtsform, Büro, Werkzeuge, ein zweites Produkt.
Häufige Fehler
| Fehler | Behebung |
|---|---|
| Überspringen des Abrufs, weil „der Benutzer bereits entschieden hat“ | Die Verkaufszeile kostet ein paar Nur-Lese-Aufrufe und einen Satz. Die Entscheidung bleibt ihre. |
| „Bereit genug“ auf das gesamte Pflichtenheft ausgedehnt | Bereit genug = was der benannte Interessent tatsächlich sehen oder verwenden wird. Liefere das, verbessere dann basierend auf dem, was sie sagen. |
| Belehren, Gründe stapeln, das Thema in der Mitte der Aufgabe erneut aufgreifen | Eine Zeile Status, eine Zeile Weiterleitung, dann handeln. |
| Ein Demo-Angebot für einen benannten Interessenten als „Vermeidung“ bezeichnen | Es liegt auf dem Weg zu einem Verkauf, also baue es, eingegrenzt auf das, was dieser Interessent sehen muss. |
| „Zuerst verkaufen“ als „nie bauen“ behandeln | Bereit genug zum Verkaufen, verkaufe es, verbessere dann, was verkauft wird. |
Verwandt: optimum-selling-strategy (was verkaufen, wo, zu welchem Preis), ready-fire-aim (Testen neuer Wetten), business-stage-check (die wöchentliche Ansicht).