Product-Market-Fit: Hör auf zu bauen, was niemand braucht

Stell dir einen Gründer vor, der einem potenziellen Kunden gegenübersitzt.

Das Produkt funktioniert. Die Demo sitzt. Die AI-Features tun, was sie versprechen. Der Kunde nickt, stellt ein paar kluge Fragen und sagt etwas, das jeder Gründer kennt:

«Das ist wirklich spannend. Schicken Sie mir doch ein paar Unterlagen.»

Wieder ein vielversprechendes Meeting. Wieder eine Opportunity im CRM. Drei Wochen später: nichts.

Der Gründer baut ein weiteres Feature, verbessert das Onboarding und schreibt den Sales Pitch neu. Vielleicht muss das Produkt nur ein bisschen besser werden. Oder vielleicht hat es von Anfang an niemand gebraucht.

Das ist ein illustratives Szenario, aber die meisten Gründer werden es wiedererkennen. Wir verwechseln Kundeninteresse mit Kaufabsicht, Produktnutzung mit Product-Market-Fit und Aktivität mit Fortschritt. Es ist dieselbe Verwechslung, die MQLs zu Lead-Theater macht.

AI macht diese Verwechslung teurer. Bauen ist billig geworden, also können wir heute viel bauen, bevor irgendjemand eine echte Zusage gemacht hat.

In einer aktuellen Folge von Lenny's Podcast hat Rob Snyder, Autor von The Power of Pull, sein Framework für Product-Market-Fit durchgespielt. Lenny stellt ihn als jemanden vor, der mehr als 50 Startups von null auf 1 Million Dollar ARR begleitet hat.

Seine zentrale Idee passt in zwei Sätze. Finde Menschen, die bereits etwas erreichen müssen und es mit ihren bestehenden Optionen nicht schaffen. Dann schau, ob sie tatsächlich versuchen zu kaufen.

Ich glaube, das reicht weit über Early-Stage-Startups hinaus. Es verändert, wie wir Produktmanagement, Go-to-Market und die AI-Systeme dazwischen angehen sollten.

Dein grösster Konkurrent ist die To-do-Liste des Kunden

Die meisten Produktteams starten bei Problemen. Sie führen Kundeninterviews, sammeln Pain Points, schätzen Marktchancen und bauen etwas dagegen. Dann übersetzt das Marketing das in Value Propositions, und Sales versucht, Prospects davon zu überzeugen, dass es sie kümmern sollte.

Der Prozess wirkt logisch. Es fehlt nur eine Variable: Priorität.

Ein Kunde kann ein echtes Problem haben, erkennen, dass dein Produkt es löst, und zustimmen, dass es einen guten Gegenwert bietet. Und trotzdem keinerlei Absicht haben zu kaufen.

Er hat in diesem Quartal fünfzehn andere Dinge zu erledigen. Sein bestehender Workaround reicht. Der Chef will etwas anderes. Oder das Problem nervt, hat aber keine spürbaren Folgen.

In Snyders Framework heisst der Unterschied zwischen Interesse und echter Nachfrage Pull. Pull entsteht, wenn eine bestimmte Person bereits versucht, etwas Wichtiges zu erreichen, es jetzt erreichen muss und ihre bestehenden Optionen nicht ausreichen.

Diese Person versucht bereits, etwas zu verändern. Niemand muss sie davon überzeugen, dass Veränderung nötig ist.

Diese Unterscheidung dreht den Ansatz für Product-Market-Fit um. Die Frage verschiebt sich: weg davon, wie du mehr Leute zum Kaufen überredest, hin zu der Frage, wo Leute bereits versuchen, etwas zu kaufen, das es so noch nicht gibt.

Das PULL-Framework: vier Bedingungen für echte Nachfrage

Snyder zerlegt das in vier Elemente.

Element	Die Frage
P: Project (Projekt)	Was versucht diese Person aktiv zu erreichen?
U: Unavoidable (unvermeidbar)	Warum muss sie es jetzt erreichen?
L: List of options (Liste der Optionen)	Welche Alternativen zieht sie in Betracht oder nutzt sie schon?
L: Limitations (Grenzen)	Warum schaffen diese Alternativen den Job nicht?

Alle vier zählen. Ein Projekt ohne Dringlichkeit wird zur netten Idee fürs nächste Jahr. Dringlichkeit ohne Grenzen heisst, dass der Kunde es vermutlich selbst lösen kann. Ein besseres Produkt ohne wichtiges Projekt ist einfach ein weiteres Tool, das niemand braucht.

Snyder bringt ein Beispiel von Jump, einem AI-Produkt für die Meeting-Notizen von Finanzberatern.

Finanzberater müssen Kundengespräche dokumentieren und die Einträge in ihrem CRM pflegen. Laut Snyder machen Compliance-Pflichten diese Arbeit unvermeidbar. Generische AI-Notetaker liefern vielleicht gute Zusammenfassungen, sind aber nicht unbedingt mit den nötigen Systemen verbunden und erfüllen die Compliance-Anforderungen nicht zwingend. Jump schliesst genau diese Lücke.

Vergleich das mit Versicherungsagenten. Auch sie verbringen viel Zeit in Kundengesprächen, und auch sie schreiben vielleicht ungern Notizen. Aber im Beispiel, das Snyder beschreibt, müssen sie diese Einträge nicht im CRM führen. Nichts zu tun ist eine akzeptable Alternative.

Im Groben derselbe Schmerz. Ein ähnlicher Workflow. Ein völlig anderes Kaufverhalten.

Das ist eine wichtige Lektion für alle, die ein Ideal Customer Profile definieren.

Eine Branche ist nicht dein Kunde. Eine Firma ist nicht dein Kunde. Eine Person mit einem unvermeidbaren Projekt ist dein Kunde.

Und die aktuellen Prioritäten dieser Person zählen mehr als deine sorgfältig polierte Value Proposition.

AI hat verändert, was es kostet, beim Product-Market-Fit danebenzuliegen

Hier würde ich Snyders Argument erweitern.

Jahrelang war Software teuer genug, um eine gewisse Disziplin zu erzwingen. Ein grösseres Feature brauchte Entwickler, Planung, Tests und Monate an Engineering-Kapazität.

Heute kann ein fähiger Gründer mit AI-gestützter Entwicklung in wenigen Tagen einen funktionierenden Prototyp bauen. Das ist echter Fortschritt, und es schafft eine neue Falle: Wir halten Ausführungsgeschwindigkeit für einen Beweis von Fortschritt.

Ein Team baut zehn Features, lanciert drei Landing Pages, automatisiert Outbound und baut eine polierte Demo. Das Weekly sieht produktiv aus. Doch die wichtigste Frage bleibt unbeantwortet.

Wer versucht, das zu kaufen, und warum jetzt?

Coding ist schnell geworden. Der Weg in den Markt nicht. Genauer: Der Engpass hat sich verschoben. Wenn Bauen billig wird, wird die Entscheidung, was es verdient, gebaut zu werden, relativ wertvoller. Als ich darüber geschrieben habe, wie man ein SaaS-Produkt in 90 Tagen baut, war der schwierige Teil nie der Code. Es war das Streichen.

Product-Market-Fit lässt sich nicht mehr als Phase behandeln, die nach der Produktentwicklung kommt. Er muss die Entwicklung von Anfang an prägen.

Das heisst: Kundengespräche sind mehr als Research-Input für Produktmanager. Sie sind kommerzielle Experimente, die testen, ob der Kunde handelt. Und das stärkste Signal ist ein Kauf.

Hör auf, Leute zu deiner Idee zu interviewen. Teste, ob sie versuchen zu kaufen.

Snyder empfiehlt, mit einer sogenannten Pull-Hypothese zu starten. Bevor du das Produkt baust, schreibst du deine Annahmen über die Situation des Käufers auf.

Hier ein hypothetisches Beispiel aus der B2B-Softwareentwicklung. Eine VP Product steht unter Druck, in diesem Quartal ein grosses Release zu liefern. Ihr Team nutzt Jira, Dokumentationstools und AI-Coding-Assistenten, aber wichtige Produktentscheidungen landen nicht zuverlässig in der Umsetzung. Das Release ist gefährdet, und mehr Entwickler lösen das Koordinationsproblem nicht unbedingt.

Die Hypothese lautet:

• Project: Ein zugesagtes Release liefern, ohne dass kritische Anforderungen zwischen Product und Engineering verloren gehen.
• Unavoidable: Das Release hat eine extern zugesagte Deadline.
• Options: Mehr Meetings, mehr Produktmanager, bessere Dokumentation, bestehende Jira-Integrationen und AI-Coding-Tools.
• Limitations: Diese Optionen verbessern vielleicht einzelne Aufgaben, ohne Entscheidungen, Tickets und Umsetzung verlässlich auf einer Linie zu halten.

Achte darauf, was fehlt. Keine Feature-Liste, keine grosse Produktvision, kein Pitch über AI-Magie. Nur eine konkrete Person, ein wichtiges Projekt und ein Grund, warum die bestehenden Methoden nicht funktionieren.

Das ist die Art Hypothese, die es sich für ein Produkt wie Teklens zu testen lohnt, das ich mitgegründet habe: das gemeinsame Product Brain, ein gemeinsames Gedächtnis für Menschen und KI-Agenten, das Produktgespräche, Jira und Code verbindet.

Aber es bleibt eine Hypothese. Der relevante Käufer hält das Problem vielleicht nicht für dringend. Das Team bekommt es vielleicht schon gut genug hin. Oder der eigentliche Käufer ist ein CTO, der sich auf ein Audit vorbereitet, und nicht eine VP Product, die ein Release managt.

Genau das soll Discovery herausfinden.

Snyder empfiehlt, potenziellen Kunden eine einfache Beschreibung von Projekt, Dringlichkeit und Grenzen zu zeigen, gefolgt von einer konzeptionellen Erklärung, wie du helfen könntest. Dann schau, was sie tun.

Manche fragen nach einem Umsetzungsplan, ziehen eine Kollegin dazu, sprechen den Einkauf an oder fragen, wann sie starten können. Andere gratulieren dir zur Vision und versprechen, in Kontakt zu bleiben. Das sind sehr unterschiedliche Signale.

Ein mündliches Kaufversprechen ist ermutigend. Eine bezahlte Zusage ist stärker. Echte Nutzung und Retention sind noch stärker.

Fünf Sales-Gespräche lehren dich mehr als fünf Wochen Entwicklung

Eine von Snyders nützlichsten Empfehlungen: in kleinen Discovery-Zyklen arbeiten. Starte mit einer Hypothese. Finde die passenden Leute. Führe etwa fünf Gespräche. Werte aus, was du gelernt hast.

Wenn niemand vorwärtsmachen will, buchst du nicht automatisch fünfzig weitere Meetings. Ändere die Hypothese. Vielleicht ist das Problem echt, aber nicht dringend. Vielleicht gehört es der falschen Person. Vielleicht reichen die bestehenden Tools. Oder du hast ein anderes Projekt entdeckt, das viel mehr zählt.

Ein Weg, das herauszufinden, ist das, was Snyder die Hail-Mary-Frage nennt:

«Gibt es etwas auf Ihrer To-do-Liste, für das Sie jemanden bezahlen würden, damit er es Ihnen sofort abnimmt?»

Eine schlichte Frage, und viel nützlicher als die Frage, welche Features sich jemand wünscht. Sie lenkt das Gespräch weg von Meinungen über das Produkt, hin zu echten Prioritäten.

Menschen sind grosszügig mit Feedback zu Produkten, die sie nie kaufen wollen. Sie verbringen gern eine Stunde damit, deine Roadmap zu entwerfen. Finanzieren werden sie sie nicht.

Snyder ist besonders skeptisch gegenüber Design-Partnerschaften, die viel Feedback, aber wenig kommerzielle Verbindlichkeit bringen.

Ich würde Design Partner nicht ganz abschreiben. In komplexen B2B-Umgebungen kann gemeinsame Entwicklung Integrationsgrenzen, Workflow-Realitäten und organisatorische Anforderungen sichtbar machen, die sonst verborgen blieben. Aber der kommerzielle Test zählt trotzdem. Ein Design Partner sollte ein echtes Projekt haben, ein definiertes Erfolgskriterium und einen glaubwürdigen Weg zum zahlenden Kunden. Sonst hast du vielleicht einen hilfsbereiten Produktberater gewonnen, aber keinen Käufer.

Verkauf das Ergebnis, bevor du die Plattform baust

Es gibt eine weitere Konsequenz, die AI besonders interessant macht. Um Nachfrage zu testen, brauchst du nicht immer ein fertiges Softwareprodukt. Wenn ein Kunde einen bestimmten Job erledigt haben muss, kannst du das Ergebnis manchmal mit einer Kombination aus Menschen, bestehender Software und Automatisierung liefern.

Snyder beschreibt Gründer, die mit servicenahen Angeboten starten, bevor sie die Software dahinter entwickeln.

Stell dir eine Firma vor, die ihren Marktforschungszyklus von Wochen auf Tage verkürzen muss. Die erste Version besteht vielleicht aus Researchern mit AI-Tools, manuellen Qualitätschecks und einer einfachen Reporting-Oberfläche. Der Käufer bekommt das Ergebnis. Der Anbieter lernt, welche Schritte sich wiederholen. Dann automatisiert das Team diese Schritte. Das ist die Reihenfolge, in der ein Forward Deployed Engineer arbeitet: zuerst den echten Prozess kartieren, dann automatisieren, was sich wiederholt.

Das kehrt die klassische Reihenfolge um. Die alte: Software bauen, Kunden finden, hoffen, dass sie sie nutzen. Die neue: einen dringenden Job finden, das Ergebnis verkaufen, es liefern, den Workflow lernen, dann automatisieren, was sich wiederholt.

Das ist besonders relevant für AI-native B2B-Firmen. Aber es gibt ein Risiko. Wenn jeder Kunde eine andere Umsetzung braucht, hast du nicht unbedingt ein skalierbares Produkt gefunden. Vielleicht hast du ein Beratungsgeschäft mit sehr gutem Tooling gebaut. Wo diese Linie verläuft und wie der ehrliche Mittelweg aus Produkt plus Services aussieht, habe ich in Service-Agentur versus Software-Produktgeschäft beschrieben.

Die Disziplin liegt darin, den wiederholbaren Kern von der Massarbeit drumherum zu trennen. Verrechne das Ergebnis früh. Lerne, was wiederverwendbar ist. Mach aus der wiederkehrenden Arbeit ein Produkt. Und verwechsle fünf unzusammenhängende Kundenprojekte nicht mit Product-Market-Fit.

Product-Market-Fit endet nicht mit dem Kauf

Ein Kunde, der unbedingt kaufen will, kann trotzdem kündigen. Vielleicht funktioniert das Produkt nicht wie versprochen. Vielleicht ist die Einführung zu kompliziert. Vielleicht endet das unmittelbare Projekt des Käufers, und das Produkt wird nicht mehr gebraucht.

Snyder schlägt vor, die Customer Journey in zwei Etappen zu denken. Vor dem Kauf musst du jemanden finden, für den der Kauf offensichtlich Sinn ergibt. Nach dem Kauf musst du den Moment finden, ab dem ein Wechsel keinen Sinn mehr ergäbe.

Dieser zweite Moment ist nützlicher, als Aktivierungsraten zu feiern. Ein Login beweist wenig. Ein Kunde, der eine Aufgabe abschliesst, die sein Geschäft vorher blockiert hat, ist ein viel besseres Signal.

Bei einem Produkt, das Anforderungen, Tickets und Code verbindet, könnte dieser Moment sein, dass ein Team eine wichtige Abweichung entdeckt, bevor sie in Produktion geht, und sie mit dem richtigen Kontext löst. Bei einem GTM-System könnte es ein Verkäufer sein, der ein verwertbares Kaufsignal bekommt, das sonst zwischen CRM, Meetings und Mails verschwunden wäre.

Das sind Hypothesen zum Testen, keine allgemeingültigen Aktivierungsmetriken. Die operative Frage lautet:

Was muss ein Kunde erleben, bevor er das Produkt wirklich vermissen würde, wenn es verschwände?

Dann bau das Onboarding rückwärts von diesem Moment aus.

Führe deine Firma als Case-Study-Fabrik

Gegen Ende des Gesprächs bringt Snyder eine Idee, die ich nützlicher finde als das PULL-Akronym selbst: Sieh deine Firma als Fabrik, die wiederholbare Kundenerfolge produziert.

Er meint Kundenergebnisse, die sich wiederholen, Kunde für Kunde. Marketing-Case-Studies mit polierten Logos und verdächtigen Prozentzahlen sind etwas anderes.

Jeder erfolgreiche Kunde folgt ungefähr demselben Muster. Eine bestimmte Person hat ein dringendes Projekt. Ihre bestehenden Optionen reichen nicht. Sie kauft etwas, das hilft. Sie erreicht das gewünschte Ergebnis. Sie bleibt, weil es weiterhin wertvoll ist.

Deine Firma wird zu einem System, das dieses Muster wiederholt:

1. Den richtigen Käufer finden.
2. Das dringende Projekt verstehen.
3. Zeigen, dass dein Angebot glaubwürdig hilft.
4. Eine kommerzielle Zusage gewinnen.
5. Das versprochene Ergebnis liefern.
6. Dauerhaften Wert erreichen.
7. Halten, lernen, wiederholen.

Dieses Denkmodell verbindet Produktmanagement, Sales, Marketing und Customer Success über eine gemeinsame Definition von Erfolg. Und es verändert, wie du über Wachstum denkst.

Wenn die Pipeline der Engpass ist, verbessere, wie du ähnliche Käufer findest. Wenn Kunden dringende Projekte haben, aber nicht kaufen, untersuche Angebot, Glaubwürdigkeit, kommerziellen Prozess oder Einkaufshürden. Wenn sie kaufen, aber nicht bleiben, verbessere Lieferung und Time to Value, oder prüfe, ob die ursprüngliche Nachfrage wiederholbar ist.

Der Fokus wechselt mit dem Engpass. Das ist viel nützlicher, als jeder Abteilung zu sagen, sie solle alle KPIs gleichzeitig verbessern.

Wo gemeinsamer Kontext zur fehlenden Infrastruktur wird

Hier sehe ich die Verbindung zu den Systemen, die wir rund um Product, GTM und AI bauen.

Stell dir vor, ein Kunde sagt Sales, seine grösste Priorität sei, Release-Verzögerungen zu verringern. Das Gespräch liefert nützliche Belege zu Dringlichkeit, bestehenden Alternativen, Blockern, Budget und den beteiligten Personen.

In vielen Organisationen bleibt diese Information in einer Call-Aufnahme oder einer CRM-Notiz liegen. Product bekommt einen Feature-Request ohne den ursprünglichen Kontext. Marketing schreibt eine generische Pain-Point-Botschaft. Customer Success bekommt eine Onboarding-Checkliste, aber nicht das Geschäftsergebnis, das der Kunde erwartet. Dann soll ein AI-Agent ein Follow-up vorbereiten, aus den Fragmenten, die er gerade findet.

Alle arbeiten. Alle haben andere Informationen.

Snyders Case-Study-Fabrik verlangt etwas Zusammenhängenderes. Dieselben Kundenbelege sollten die Produktentscheidung, das kommerzielle Versprechen, den Umsetzungsplan und den Retention-Meilenstein speisen. Dafür muss niemand dasselbe riesige Dokument lesen. Jede Person und jeder Agent braucht die relevanten Belege in dem Moment, in dem entschieden wird.

Das ist das Prinzip hinter Get Multiplayer: Menschen setzen Ziele, entscheiden und geben frei. Agenten bereiten vor und übernehmen wiederkehrende Aufgaben. Gemeinsame Ziele und gemeinsamer Kontext halten die Arbeit zusammen.

Ein Agent kann zum Beispiel das aktive Projekt und die Alternativen eines Kunden aus einem Sales-Gespräch ziehen. Ein zweiter kann diese Anforderungen mit dem Product Backlog abgleichen. Ein dritter kann einen Onboarding-Plan auf Basis des versprochenen Ergebnisses vorbereiten.

Aber Menschen müssen die Belege weiterhin prüfen und entscheiden, was sie bedeuten. Sonst automatisierst du einfach Annahmen. Schneller. Im grossen Stil.

Wo ich widerspreche: Pull allein garantiert kein gutes Geschäft

Snyders Framework ist besonders nützlich, weil es kommerzielle Ehrlichkeit erzwingt. Aber es ist keine vollständige Theorie des Firmenaufbaus.

Ein Kunde kann echte Dringlichkeit haben und trotzdem für einen schlechten Markt stehen. Vielleicht kommt das Projekt nur alle fünf Jahre vor. Vielleicht hat der Käufer keine Budgetbefugnis. Vielleicht kostet die Lieferung mehr als der Vertrag. Vielleicht ist das Problem sehr wertvoll, existiert aber in zu wenigen Organisationen.

Starker Pull bestätigt eine bestimmte Gelegenheit. Er bestätigt nicht automatisch Marktgrösse, attraktive Margen, wiederholbaren Vertrieb oder Verteidigbarkeit.

Im Enterprise-B2B ist der Unterschied zwischen einer Person, die das Produkt will, und einer Organisation, die es kaufen kann, besonders wichtig. Der Champion hat vielleicht Pull. Security, Legal und Einkauf haben trotzdem eigene Anforderungen.

Deshalb sehe ich das PULL-Framework als Ergänzung zu einem gut geführten Enterprise Sales Process, nicht als Ersatz dafür. Und deshalb zählt Retention genauso viel wie frühe Kaufabsicht.

Du brauchst drei Ebenen von Belegen:

• Nachfrage: Versuchen Leute dringend zu kaufen?
• Wert: Bringt dein Angebot ein Ergebnis, das ihnen wichtig ist?
• Ökonomie: Kannst du dieses Ergebnis profitabel bei genug Kunden wiederholen?

Erst wenn sich diese drei gegenseitig stützen, beginnt eine spannende Gelegenheit, einem skalierbaren Geschäft zu ähneln.

Ein praktisches Playbook für Product-Market-Fit

Wenn ich nächsten Montag ein neues B2B-Produkt starten würde, würde ich den ersten Zyklus um sieben Aktivitäten herum organisieren.

1. Wähl eine Person, keinen Markt. Bestimme Rolle, Verantwortung und Situation, in der der Bedarf wahrscheinlich dringend ist. «Mid-Market SaaS» ist zu vage.
2. Schreib eine PULL-Hypothese. Halte Projekt, Warum jetzt, bestehende Optionen und deren Grenzen fest. Trenne Annahmen von bestätigten Kundenbelegen.
3. Geh nah an die Arbeit. Beobachte echte Workflows, Kundenmeetings, Tools und Übergaben. Interviews helfen, aber wer jemandem beim Ringen mit einer echten Aufgabe zusieht, sieht auch, was im Interview vergessen geht.
4. Führe fünf kommerzielle Gespräche. Frag nach aktuellen Projekten, Deadlines, bisherigen Versuchen und Einkaufsschritten. Zeig nur so viel von deinem Angebot, dass du testen kannst, ob sie weitergehen würden.
5. Such nach Handlung, nicht nach Begeisterung. Eine bezahlte Diagnose, ein unterschriebener Auftrag, eine kommerzielle Zusage oder ein vom Kunden getriebener Einkaufsprozess sind stärkere Belege als positives Feedback.
6. Liefere das Ergebnis und finde den Retention-Moment. Arbeite eng mit den ersten Kunden. Bestimme das Ereignis, das dauerhaften Wert beweist, und stell es ins Zentrum des Onboardings.
7. Mach aus dem Gelernten ein wiederholbares System. Speise bestätigte Belege in Positionierung, Produktprioritäten, Sales-Qualifizierung und Onboarding ein. Finde den nächsten Engpass und verbessere ihn.

AI kann in jeder Phase helfen. Sie kann Calls analysieren, Muster clustern, Optionen vergleichen, Prototypen bauen, Angebote vorbereiten, Gelerntes dokumentieren und wiederholbare Lieferarbeit automatisieren.

Was sie nicht kann: eine dringende Kundenpriorität herstellen, wo keine existiert. Deshalb bleibt die menschliche Rolle unverzichtbar: entscheiden, ob die Belege die nächste Investition rechtfertigen.

Weniger bauen. Lernen, was es verdient, gebaut zu werden.

Ich habe mit einem Gründer begonnen, der eine polierte Demo hatte, und einem Prospect, der versprach, sich wieder zu melden.

Die typische Reaktion: das Produkt verbessern, noch ein Follow-up schicken und das Outreach-Volumen erhöhen. Manchmal ist genau das nötig. Manchmal ist der wertvollste nächste Schritt das Eingeständnis, dass du etwas verkaufen willst, das niemand dringend kaufen will.

Rob Snyder gibt uns einen praktischen Weg, den Unterschied zu erkennen. AI gibt uns die Möglichkeit, viel schneller danach zu handeln. Die Kombination funktioniert, wenn wir die Technologie in der richtigen Reihenfolge einsetzen.

Finde das dringende Projekt. Beweise, dass der Kunde handelt. Liefere das Ergebnis. Mach es wiederholbar.

Finde zuerst die Kunden, für die sich das Bauen lohnt. Dann lass dich von AI schnell machen.

Wenn du eine Operator-Notiz pro Woche zu Product, GTM und AI willst: abonniere den Newsletter The Science of GTM.

Basierend auf Rob Snyders Gespräch mit Lenny Rachitsky in Lenny's Podcast, An 86-minute guide to finding PMF, veröffentlicht am 25. Oktober 2026 (auf Snipd anhören). Rob Snyders Buch: The Power of Pull, John Murray Business, 2026. Das PULL-Framework, die Hail-Mary-Frage und die Case-Study-Fabrik stammen von Snyder. Die Einordnung für Product, GTM und AI und die praktischen Erweiterungen sind meine.