Bezahltes Pilotprojekt vs. PoC vs. Design Partner: Was beweist Nachfrage?

Ein bezahltes Pilotprojekt liefert das stärkste Signal für kommerzielle Nachfrage: Ein echter Käufer gibt Budget frei und testet das Produkt in einem echten Arbeitsablauf. Ein Proof of Concept beweist technische Machbarkeit. Ein Design Partner zeigt, dass ein repräsentativer Kunde das Problem hat und an der Lösung mitarbeitet. Keines der drei Modelle beweist allein wiederholbare Marktnachfrage.

Der Name im Statement of Work bestimmt nicht, was du gelernt hast. Ein Kunde kann für einen PoC zahlen, weil er individuelle Forschung kaufen will, nicht dein späteres Produkt. Ein Design Partner kann begeistert unterschreiben und die Software nie einsetzen. Ein Pilot kann kommerziell wirken, obwohl der Founder so viel manuell erledigt, dass kein zweiter Kunde dasselbe Produkt bekommen könnte.

Diese Seite beantwortet die kommerzielle Auswahlfrage. Für die reine Definition bleibt der Glossareintrag zum Proof of Concept bewusst eng. Wenn du zuerst klären musst, ob überhaupt ein echtes Produkt nötig ist, lies die Definition des MVP.

Bezahlter Pilot, Proof of Concept und Design Partner im direkten Vergleich

Auch offizielle Leitlinien ziehen diese Grenze. Das Innovation Procurement Toolkit der Europäischen Kommission ordnet den PoC der praktischen Machbarkeit zu und den Pilot der begrenzten Nutzung in der späteren Betriebsumgebung. Der PoC-to-Scale-Leitfaden der australischen Regierung trennt auch die Messgrößen: technische Machbarkeit beim PoC, Nutzer und Geschäftswirkung beim Pilot.

Welches Modell beweist Nachfrage?

Wähle einen bezahlten Pilot, wenn die größte Unsicherheit die kommerzielle Nachfrage ist. Er ist ein stärkeres Signal als Interview, Letter of Intent oder kostenloses Beta, weil der Käufer eine Budgetentscheidung treffen muss. Das Signal ist nur glaubwürdig, wenn er für ein wiederholbares Produktergebnis zahlt, nicht für Founder-Stunden oder einen individuellen Build.

1. Problem-Evidenz: Zielnutzer beschreiben denselben schmerzhaften Workflow und einen aktiven Workaround.
2. Commitment-Evidenz: Ein Käufer stellt Daten, Personalzeit, Security Review oder Implementierungszugang bereit.
3. Payment-Evidenz: Ein Budgetverantwortlicher zahlt eine relevante, nicht rückzahlbare Gebühr.
4. Wert-Evidenz: Echte Nutzung verbessert eine vorab vereinbarte operative oder finanzielle Baseline.
5. Conversion-Evidenz: Der Käufer unterschreibt Produktionsbedingungen oder nutzt zum beabsichtigten Preis weiter.
6. Wiederholbarkeits-Evidenz: Mehrere unabhängige Kunden im selben Ideal Customer Profile kaufen aus demselben Grund, ohne jeweils ein neues Produkt zu verlangen.

Ein bezahlter Pilot kann die Stufen drei bis fünf erreichen. Ein einzelner Pilot erreicht Stufe sechs nicht. „Wir haben einen bezahlten Pilot“ bedeutet deshalb: Ein Account hat unter diesen Bedingungen Nachfrage gezeigt. Es bedeutet nicht: Der Markt ist validiert. Unser Leitfaden zum Minimum Credible Product zeigt, wie du die kleinste Version definierst, die stärkeres Marktverhalten auslöst.

Was beweist ein Proof of Concept tatsächlich?

Ein PoC soll eine technische Unsicherheit beseitigen, bevor Produktbudget fließt. Kann eine Legacy-Schnittstelle den nötigen Durchsatz halten? Erreicht ein Modell den vereinbarten Wert auf repräsentativen Daten? Passt eine kryptografische Konstruktion ins Latenzbudget? Die Antwort lautet Ja, Nein oder nicht entscheidbar, gemessen an einem schriftlichen Test.

Auch ein bezahlter PoC beweist nicht automatisch Produktnachfrage. Die Zahlung kann zeigen, dass der Kunde Forschung, Integration oder die Expertise deines Teams schätzt. Sie zeigt nicht, dass er das entstehende Produkt zum Produktionspreis kauft. Trenne gedanklich zwei Ausgaben:

• Machbarkeitsgebühr: Zahlung für die Antwort auf eine technische Frage.
• Produktausgabe: Zahlung für die wiederholte Nutzung eines Ergebnisses im Betrieb.

Wenn nur Anforderungen, Ownership oder Scope unklar sind, passt eine Software-Discovery-Phase meist besser. Erfinde kein technisches Experiment, um normale Produktentscheidungen wissenschaftlicher wirken zu lassen.

Was beweist ein Design Partner?

Ein Design Partner gibt einem frühen Produktteam wiederkehrenden Zugang zu echtem Workflow, Nutzern und einem Käufer, der den Beschaffungsweg erklären kann. Der beste Partner ist repräsentativ für das Zielsegment, spürt das Problem dringend und hat genug Kapazität zum Testen. Das sind auch die drei Kriterien im Design-Partner-Framework von Andreessen Horowitz.

Ein kostenloser Design Partner kann hervorragende Problem- und Usability-Evidenz liefern. Für Zahlungsbereitschaft ist das Signal schwach. Lob, Feature Requests, Begeisterung im Management und Logo-Freigabe ersetzen keinen Kauf. Die kommerzielle Frage bleibt offen, bis ein Budgetverantwortlicher Preis und Produktionspfad akzeptiert.

Ein bezahlter Design Partner kann der stärkste frühe Hybrid sein. Der Kunde zahlt, gibt wöchentlich Feedback und formt ein noch unfertiges Produkt mit. Sierra nutzte dieses Modell mit Zahlung, Systemzugang und regelmäßiger Mitarbeit, wie First Round zur Design-Partner-Strategie beschreibt. Das Risiko bleibt Overfitting. Jede Anforderung muss gegen weitere Zielkunden geprüft werden, bevor sie in die Core Roadmap kommt.

Wann ist ein bezahlter Pilot ein valider Nachfragenachweis?

Vergib je Bedingung einen Punkt. Sechs oder sieben Punkte liefern brauchbare kommerzielle Evidenz, vier oder fünf ein gemischtes Signal. Drei oder weniger ähneln eher Demo, Beratung oder subventioniertem Experiment.

Die Europäische Weltraumorganisation beschreibt Piloten als Tests mit Kunden im primären Zielmarkt und in echter Betriebsumgebung, um das Wertversprechen zu bestätigen. Das ist der richtige Maßstab. Zahlung erhöht die Beweiskraft, aber Betriebsrealität trennt Pilot von bezahltem Theater. Siehe die ESA-Abgrenzung von PoC-Studien und Pilotprojekten.

Wie triffst du die Auswahl?

Führe nicht aus Gewohnheit alle drei durch. Nimm das kleinste Instrument, das die riskanteste Unbekannte auflöst. Wenn bewährte Technik den Workflow trägt, überspringe den PoC. Wenn das Produkt den Workflow schon bedient, überspringe kostenlose Co-Creation und frage nach Pilot oder Produktionsvertrag.

Was gehört in die Vereinbarung?

Dieser Commercial Brief gehört vor den juristischen Entwurf. Er ist keine Rechtsberatung. IP-, Datenschutz-, Haftungs- und Procurement-Regeln müssen zur Jurisdiktion und zu den Parteien passen.

1. Entscheidungsfrage: ein Satz dazu, was das Engagement beweisen muss.
2. Scope und Ausschlüsse: Workflow, Nutzer, Daten, Integrationen, Volumen und bewusst ausgeschlossene Arbeit.
3. Kundenpflichten: Sponsor, operativer Owner, Nutzerzeit, Datenzugang, Security Review und Feedback-Takt.
4. Evidenzplan: Baseline, Metriken, Instrumentierung, Stichprobe und Owner des Readouts.
5. Commercials: Gebühr, Zahlung, Auslagen, Produktionspreis oder Preismechanik und mögliche Anrechnung.
6. Produktgrenze: Standardprodukt, konfigurierbare Arbeit und Sonderlieferungen separat.
7. Rechte: bestehendes und neues IP, Kundendaten, aggregiertes Lernen, Vertraulichkeit und Referenzrechte.
8. Exit Gate: Enddatum, Entscheidungsmeeting und genau drei Optionen: Conversion, eine begrenzte Iteration oder Stop.

Bei einem Software-Build ergänzt ein klares Statement of Work den Brief. Bei personenbezogenen oder regulierten Daten dürfen Security und Datenverantwortung nicht auf den Rollout vertagt werden.

Drei Beispiele, drei unterschiedliche Aussagen

1. Eine Bank zahlt €20.000 für einen Integrations-PoC

Der Anbieter beweist, dass seine Engine ein Legacy-Format schnell genug liest. Die Bank kauft Spezial-Engineering. Urteil: Technik und Nachfrage nach der Dienstleistung sind belegt, Produktnachfrage nicht.

2. Fünf Design Partner kommen kostenlos in wöchentliche Sessions

Vier nutzen den Prototyp wiederholt und beschreiben denselben schmerzhaften Workaround. Urteil: Problem und Produktrichtung sind gestützt. Zahlungsbereitschaft bleibt unbekannt. Biete denselben begrenzten bezahlten Pilot an, nicht fünf Sonder-Roadmaps.

3. Drei Operations-Teams kaufen denselben Sechs-Wochen-Pilot

Jedes zahlt aus dem späteren Budget, nutzt dasselbe Core Product und misst dasselbe Ergebnis. Zwei konvertieren zum vereinbarten Preisrahmen, eines stoppt wegen zu wenig Volumen. Urteil: Im High-Volume-Segment gibt es frühe wiederholbare Nachfrage. Der Verlust schärft den ICP.

"Ein PoC beweist, dass die Maschine funktionieren kann. Ein Design Partner beweist, dass das Problem Aufmerksamkeit verdient. Ein bezahlter Pilot beweist, dass ein Käufer Geld ausgibt, um einen echten Workflow zu verändern. Wiederholbare Nachfrage beginnt, wenn ein zweiter Käufer dasselbe tut, ohne aus dir ein anderes Unternehmen zu machen."

Wie viel Nachfrage ist genug?

• Ein bezahlter Pilot: Nachfrage-Evidenz auf Account-Ebene.
• Mehrere ähnliche Piloten: Nachfragehypothese für ein Segment.
• Conversions zum Zielpreis: frühe kommerzielle Validierung.
• Weiternutzung, Renewal oder Expansion: Evidenz für dauerhaften Wert.
• Wiederholbarer Sales- und Delivery-Prozess: glaubwürdiger Weg zum Product-Market Fit.

Zahlungsbereitschaft zählt, weil Nachfrage ohne tragfähige Economics kein Geschäft ist. Der Pricing-and-Packaging-Leitfaden von Andreessen Horowitz verbindet Willingness to Pay mit Nachfrage und erwartetem Return. Teste den beabsichtigten Preis früh genug, damit ein rabattierter Pilot keinen später unakzeptablen Produktionspreis verdeckt.

Hat ein KI-Pilot repräsentative Betriebsdaten gesammelt, nutze unsere Kill-or-Scale-Scorecard für KI-Piloten. Für konventionelle Software lassen sich Baseline, Kosten, Adoption, Zuverlässigkeit und Amortisation genauso anwenden.

Quellen und Methodik

Dieses Vergleichsmodell ist eine originale Wavect-Systematik nach der Art der Unsicherheit, die jedes Engagement reduziert. Definitionen und Procurement-Grenzen wurden am 22. Juli 2026 anhand von Europäischer Kommission, australischer Regierung und ESA geprüft. Aussagen zu Design Partnern und Zahlungsbereitschaft wurden mit Andreessen Horowitz und First Round abgeglichen. Evidenzleiter und Sieben-Punkte-Test sind Wavect-Frameworks, keine universellen Standards.