Consulting Insight: Pre-Sales Validation
Wenn im Sprint Review plötzlich niemand eine Antwort hat
Montagmorgen, 9:00 Uhr. Sprint Review. Der Raum ist stiller als sonst, nur das leise Tippen auf Laptops und ein kurzes Räuspern durchbricht die Spannung. Einer scrollt nervös durch die Präsentation, ein anderer lehnt sich zurück, die Arme verschränkt. Alle schauen nach vorne. Das Team präsentiert ein Feature, an dem seit drei Monaten gearbeitet wurde – sauber umgesetzt, technisch solide, alle Anforderungen erfüllt. Dann wird es still. Aus dem Fachbereich kommt die erste Frage: „Wer nutzt das eigentlich konkret?“ Ein kurzer Blick in die Runde, niemand antwortet sofort. Die nächste Frage folgt direkt: „Haben wir dafür schon Kunden?“ Wieder keine klare Antwort.
Und wenn Sie ehrlich sind, kennen Sie diese Situation nicht nur – Sie haben sie selbst schon erlebt. Die eigentliche Frage ist: Warum passiert das immer wieder?
Sie bauen aus Annahme. Der Markt ignoriert es.
Was hier passiert, ist kein Ausrutscher. Es ist der Normalfall. Und genau das wird intern oft noch als Fortschritt verkauft. Features entstehen selten aus echter Nachfrage, sondern aus Annahmen: Ein Stakeholder hat eine Idee, ein Wettbewerber hat etwas Ähnliches gebaut, ein Kunde hat beiläufig etwas erwähnt – oder das Team ist überzeugt, dass „der Markt das braucht“. Also wird priorisiert, das Thema landet im Backlog, Roadmaps werden angepasst und Budget wird freigegeben. Und dann wird gebaut. Monate später steht ein Feature im System, funktional korrekt, aber ohne klaren Platz im Markt.
In Meetings wird währenddessen über Prioritäten diskutiert, als wären sie objektiv – im Steering Committee, entlang von KPI-Zielen, unter Zeitdruck, mit vorbereiteten Slides und impliziten Erwartungen, welches Ergebnis am Ende stehen soll. „Das ist strategisch wichtig“, „das zahlt auf unsere Vision ein“, „das wird mittelfristig relevant“. Alles valide Argumente – und dennoch beantworten sie nicht die entscheidende Frage: Zahlt jemand dafür?
Solange diese Frage unbeantwortet bleibt, bewegen sich Entscheidungen im Raum der Spekulation. Das Ergebnis sind volle Backlogs, lange Release-Zyklen und Features, die nach Go-Live leise verschwinden. Niemand misst es offen, aber jeder spürt es: Ein erheblicher Teil der gebauten Funktionalität erzeugt keinen echten Wert.
Das Gefährliche ist nicht der einzelne Fehlschlag, sondern dass er systematisch produziert wird. Organisationen gewöhnen sich daran, dass ein großer Teil ihrer Arbeit keine Wirkung entfaltet. Teams optimieren Delivery, während die eigentliche Frage – ob überhaupt geliefert werden sollte – nicht gestellt wird. Je größer die Organisation, desto stabiler wird dieses Muster.
- Budgets werden jährlich geplant
- Roadmaps im Voraus definiert
- Erfolg wird an Output gemessen
Genau dadurch verstärkt sich das Verhalten, das Wachstum eigentlich verhindert.
Der Wendepunkt: Vom Bauen zum Verkaufen
Keine Analyse. Keine weiteren Studien. Keine Ausreden. Verbindlichkeit. Und genau daran scheitert es in den meisten Organisationen: Verbindlichkeit!
Bevor etwas gebaut wird, muss geklärt sein, ob jemand bereit ist, dafür zu bezahlen. Nicht hypothetisch. Nicht „würde ich vielleicht nutzen“. Sondern konkret. Genau hier kippt die Logik:
Produktentwicklung beginnt nicht mit Spezifikation, sondern mit Verkauf.
Starten Sie stattdessen direkt: Formulieren Sie das Feature als Angebot mit klarem Nutzen und Preis – als Pre-Sales Validation. Zuerst wird ein Feature nicht entwickelt, sondern als Angebot formuliert – mit klarem Nutzenversprechen und Preis. Dieses Angebot wird echten Kunden präsentiert. Nicht als Idee, sondern als etwas, das sie kaufen können. Die Reaktion ist eindeutig: Entweder es entsteht ein Auftrag oder nicht. Beides liefert Klarheit, aber nur eines rechtfertigt Umsetzung. Und wenn sich kein Angebot formulieren lässt, das für den Kunden wirtschaftlich Sinn ergibt, wird das Feature verworfen – bevor Zeit und Budget gebunden werden.
Darauf aufbauend wird nicht sofort ein vollständiges Produkt gebaut, sondern ein begrenzter, bezahlter Pilot umgesetzt. Kleiner Scope, klare Zielsetzung, reale Nutzung. Der entscheidende Unterschied: Der Kunde investiert bereits. Dadurch verändert sich die Dynamik. Feedback wird konkreter, Anforderungen präziser und es entsteht ein echter Nutzungskontext. Viele vermeintlich „wichtige“ Features verlieren in dieser Phase plötzlich an Bedeutung.
Der nächste Schritt geht noch weiter: Die Analyse- und Konzeptphase (Discovery) wird nicht mehr intern als unverbindlicher Workshop durchgeführt, sondern als bezahlte Leistung beim Kunden positioniert. Statt Hypothesen im eigenen Team zu diskutieren, investiert der Kunde aktiv darin, sein Problem sauber analysieren zu lassen und eine konkrete Lösung zu erarbeiten. Dadurch verändert sich die Qualität sofort. Es geht nicht mehr um theoretische Szenarien, sondern um echte, priorisierte Probleme – und die Lösung ist bereits validiert, bevor überhaupt eine Umsetzung beginnt.
Ein einfaches Beispiel macht den Unterschied greifbar: Das Reporting-Feature geht live. Montagmorgen, erster Arbeitstag nach dem Release. Die Zahlen sind da, die Dashboards sind gebaut. Einer aus dem Team öffnet das Tool, klickt sich durch die Reports. Danach passiert nichts. Keine Rückfragen, keine Nutzung im Fachbereich, keine Diskussion. Das Feature ist da – aber es existiert praktisch nicht im Alltag.
Im Kontrast dazu ein anderes Vorgehen: Dasselbe Team bietet ein erweitertes Reporting vor der Umsetzung aktiv zwei Kunden an. Beide kaufen. Mit ihnen wird ein Pilot umgesetzt, basierend auf realer Nutzung und konkretem Bedarf. Erst danach entsteht das eigentliche Produkt.
Im ersten Fall wird gehofft. Im zweiten wird gewusst.
Die entscheidende Frage, die über Umsetzung oder Verschwendung entscheidet
Würden Sie dieses Feature heute einem konkreten Kunden aktiv anbieten – mit Preis, klarer Leistung und der Erwartung, dass er es sofort kauft?
Wenn Sie diese Frage nicht präzise beantworten können, fehlt nicht noch ein Refinement. Es fehlt Marktvalidierung – und genau hier setzt Pre-Sales Validation an: als konkreter Mechanismus, um diese Lücke vor der Umsetzung zu schließen.
Unternehmen, die dieses Prinzip konsequent umsetzen, bauen weniger Features – aber die richtigen. Prioritäten klären sich schneller, Budgets werden zielgerichteter eingesetzt und Roadmaps werden belastbar. Das ist kein theoretischer Vorteil. Es ist der Unterschied zwischen Aktivität und Wachstum.
Nächster Schritt: Vor dem nächsten Feature ansetzen
Wenn Sie aktuell Features entwickeln, ohne dass dahinter konkrete Zahlungsbereitschaft steht, ist das kein Einzelfall, sondern ein strukturelles Thema. Es lässt sich lösen – mit einem klaren, wiederholbaren Workflow:
- Feature als Angebot formulieren
Beschreiben Sie das Feature als konkrete Leistung mit messbarem Nutzen und Preis. Kein Konzeptpapier – ein kaufbares Angebot.
- Beispiel 1: Reporting Feature
„Sie ersetzen Ihre Excel-Auswertungen durch ein automatisiertes Monatsreporting – inklusive fertiger KPI-Dashboards, die Ihr Team ohne manuelle Nacharbeit nutzen kann. Ergebnis: mindestens 50 % weniger Reporting-Aufwand ab dem ersten Monat. Wenn wir dieses Ziel nicht erreichen, haben Sie kein Interesse – korrekt? Preis: 12.000 € einmalig + 500 € monatlich Betrieb.“
- Beispiel 2: AI-gestützte Support-Automatisierung
„Wir reduzieren Ihr Ticketvolumen in 90 Tagen um 30–40 %, indem wir einen AI-Assistenten für Ihre häufigsten Anfragen implementieren. Das ist kein Experiment, sondern messbar in Ihren Support-Zahlen. Wenn dieser Effekt für Sie nicht relevant ist, sollten wir es nicht bauen. Preis: 18.000 € Setup + nutzungsbasierte Gebühren.“
- Beispiel 3: Prozessdigitalisierung im Backoffice
„Wir verkürzen Ihre Kreditfreigaben von aktuell 3 Tagen auf unter 24 Stunden – durch automatisierte Prüfregeln und einen durchgängigen digitalen Prozess. Das wirkt sich direkt auf Ihre Durchsatz- und Abschlussquote aus. Wenn diese Beschleunigung für Sie keinen wirtschaftlichen Hebel darstellt, stoppen wir hier. Preis: 25.000 € Implementierung, Erweiterungen erst nach nachgewiesenem Effekt.“
- Zielkunden auswählen und aktiv ansprechen
Identifizieren Sie 5–10 konkrete Kunden. Stellen Sie das Angebot direkt vor – im Gespräch, nicht per Umfrage.
- Reaktion erzwingen
Bitten Sie um eine Entscheidung: kaufen, nicht kaufen oder unter Bedingungen kaufen. Keine „interessant“-Antworten akzeptieren.
- Signale auswerten
- Kauf/Zusage → klarer Bedarf
- Bedingungen/Einwände → Anpassungspotenzial
- Ablehnung → fehlende Zahlungsbereitschaft
- Entscheidung treffen
- Zusagen vorhanden → bezahlter Pilot starten
- Bedingungen dominieren → Angebot schärfen und erneut testen
- Keine Zahlungsbereitschaft → Feature verwerfen
Dieser Ablauf ersetzt Spekulation durch belastbare Signale – bevor Zeit und Budget gebunden werden.
Vor dem nächsten Feature, das Sie bauen, entscheiden Sie, ob Sie es zuerst verkaufen – oder ob Sie weiter ins Leere entwickeln.
Genau dort entsteht der Unterschied.
Prüfen Sie es an einem konkreten Feature
Wenn Sie das in Ihrer Organisation konkret prüfen wollen: Bringen Sie ein aktuelles Feature oder Vorhaben mit, und wir gehen gemeinsam durch, ob es sich heute verkaufen lässt – inkl. Angebotsformulierung, Zielkundenansprache und klarer Entscheidungslogik (bauen oder verwerfen). In 60–90 Minuten haben Sie keine Theorie, sondern eine belastbare Entscheidung und einen umsetzbaren Plan.
Sprechen Sie mich noch heute an und wir vereinbaren einen konkreten Termin.
Kategorie: Consulting Insights |
Tags: Pre-Sales Validation Marktvalidierung Produktentwicklung Feature Priorisierung Softwareentwicklu
