Ein Unternehmer stellt eine Frage. „Geht das?“

Die Versuchung ist groß, sofort in Lösungen zu springen: Welche Software gibt es dafür, was würde eine Entwicklung kosten, wer könnte das bauen. Alles Fragen, die irgendwann relevant werden — nur nicht zuerst. Zwischen einem Kunden, der etwas verlangt, und einem Produkt, das es wert ist, gebaut oder verkauft zu werden, liegen einige Schritte.

Ein Kunde beschreibt zudem selten ein Produktproblem. Er beschreibt, was ihm heute fehlt. Wer eine App verlangt, hat vielleicht vor allem genug von einem Prozess, der über fünf E-Mails und drei Tabellen läuft. Wer eine eigene Plattform will, interessiert sich oft weniger für Technologie als für Marge, Kundendaten oder Kontrolle über die Kundenbeziehung. Und wer eine Funktion nennt, die er von einer großen Plattform kennt, meint manchmal nur die Wirkung dieser Funktion — nicht die Funktion selbst.

Nimmt man die gewünschte Lösung wörtlich, kann man exakt das bauen, was verlangt wurde, und trotzdem das falsche Problem lösen.

Deshalb zerlege ich eine solche Frage zuerst. Was muss der Endkunde wirklich können? Was muss intern passieren, damit das möglich wird? Was muss in Echtzeit sein, und was ganz und gar nicht? Und von welcher Abhängigkeit will der Unternehmer sich genau befreien — und welche neue kauft er sich dafür ein?

Erst wenn das schärfer steht, wird Technologie interessant. Und selbst dann finde ich „das geht“ eine dürftige Antwort. Fast alles lässt sich bauen, wenn Zeit und Budget keine Rolle spielen. Die geschäftliche Frage ist, ob es sinnvoll geht. Gibt es schon etwas, das einen großen Teil des Problems löst? Können zwei bestehende Systeme zusammen leisten, was ein neues System leisten müsste? Wer muss es täglich bedienen, und was passiert, wenn etwas schiefläuft? Und bleibt der Vorteil größer als die Komplexität, die man dafür hinzufügt?

Genau dort beginnt für mich Opportunity Validation: nicht beweisen, dass die ursprüngliche Idee gut war, sondern versuchen herauszufinden, warum sie vielleicht keine gute Idee ist. Das klingt negativer, als es ist. Eine Opportunität, die stichhaltige Gegenfragen übersteht, wird dadurch nur interessanter. Und eine Idee, die bei dieser Übung scheitert, kostet weit weniger als eine, die scheitert, nachdem sich Monate an Entwicklung, Lieferantengesprächen und internen Erwartungen daran geknüpft haben.

Manchmal ändert sich die Frage unterwegs vollständig. Man geht von der Annahme aus, dass eine einzige integrierte Plattform nötig ist, und stellt fest, dass zwei spezialisierte Systeme zusammen besser funktionieren. Oder man liest bei einem Anbieter einen Funktionsnamen, der genau das abzudecken scheint, wonach man sucht, und stellt bei genauerem Nachfragen fest, dass er etwas viel Begrenzteres meint. Das sind keine Nebensächlichkeiten: War genau diese Eigenschaft der Grund, die Recherche zu starten, steht und fällt die Opportunität damit.

Deshalb führe ich Behauptungen so schnell wie möglich auf das zurück, was nachweisbar ist. „Der Anbieter unterstützt das“ sagt für sich genommen wenig: Wer sieht was, auf welchem Bildschirm, auf Basis welcher Daten? Und dass es eine API gibt, wird erst dann interessant, wenn sie Zugriff auf genau die Daten und Aktionen gibt, die nötig sind. Eine Funktionsliste sagt meist weniger aus, als sie zu tun scheint.

Dasselbe gilt für die Wettbewerbsrecherche. Dass es bereits fünf Anbieter gibt, beweist nicht, dass eine Idee tot ist. Und dass niemand exakt dasselbe anbietet, bedeutet noch nicht, dass man eine Marktlücke gefunden hat — vielleicht gibt es sie, weil niemand sie braucht oder weil sie sich wirtschaftlich nicht rechnet. Vielleicht ist tatsächlich Raum vorhanden. Aber das ist eine Schlussfolgerung, kein Ausgangspunkt.

Deshalb ist Product Discovery für mich eine Form von Business Development. Nicht weil sofort etwas verkauft werden muss, sondern weil man versucht, kommerzielle Möglichkeiten zu verstehen, bevor man Mittel bindet. Wo liegt der Wert? Wer würde dafür bezahlen? Welche bestehende Alternative muss man schlagen, und was muss dafür nachweisbar besser sein? Was kann man zukaufen, und was muss man selbst besitzen?

Der nächste Schritt kann dann ein Prototyp sein, ein Lieferantengespräch, eine kleine Marktvalidierung oder eine finanzielle Prüfung. Oder schlicht: aufhören. Das Letztere wird viel zu selten als Ergebnis betrachtet. Ich halte es für eines der nützlichsten Ergebnisse überhaupt. Nicht jede Opportunität verdient eine Roadmap; manche verdienen ein schnelles, gut begründetes Nein. Andere kommen nach der Recherche in einer Form zurück, die einfacher, günstiger oder interessanter ist als die ursprüngliche Idee. Und eine kleine Gruppe übersteht alle Gegenfragen. Mit denen will ich weiterarbeiten.

Eine gute Produktfrage beginnt also nicht mit „Wie bauen wir das?“, sondern mit: Welches Problem lösen wir hier eigentlich — und was muss zutreffen, bevor daraus eine Opportunität wird?

Update — was dieser Fall inzwischen klarer gemacht hat

Seit der ersten Version dieses Beitrags ist der zugrunde liegende Fall weitergegangen. Die breite Frage — müssen wir dafür etwas Neues bauen? — ist inzwischen deutlich enger geworden.

Mehrere Optionen sind weggefallen. Nicht weil es schlechte Systeme waren, sondern weil genau das Element, mit dem die Recherche begann, nicht nachweisbar vorhanden war. Marketingbegriffe erwiesen sich als dehnbarer als das, was tatsächlich dahintersteckte.

Was übrig bleibt, ist eine viel konkretere Frage: Kann eine Kombination bestehender Systeme leisten, was verlangt wird, ohne dass erneut Individualsoftware gebaut werden muss?

Das ist ein besseres Ergebnis als ein frühes „Go“. Discovery muss nicht in einem neuen Produkt enden. Bauen, kaufen, kombinieren, zusammenarbeiten oder aufhören sind allesamt gültige Ergebnisse, solange die darauffolgende Entscheidung kleiner und besser fundiert ist als die Frage, mit der man begonnen hat.

Die Frage verschiebt sich dann von „was gibt es alles?“ zu: Was muss diese eine Option noch beweisen, bevor wir Zeit und Geld daran knüpfen?