AI Product Discovery & KI-Produktentwicklung: das richtige Problem zuerst

Was AI Product Discovery von klassischer Discovery unterscheidet

Klassische Software ist deterministisch: gleicher Input, gleicher Output, und jede Fehlerursache lässt sich im Code zurückverfolgen. KI-Systeme sind probabilistisch – sie wägen Wahrscheinlichkeiten ab, und ihr Verhalten hängt an Trainingsdaten, Systemeinstellungen und Kontext. Discovery muss deshalb eine Frage mehr beantworten als früher: Verträgt dieses Problem überhaupt eine Lösung, die manchmal danebenliegt?

Die Antwort entscheidet über die Produktarchitektur. Eine Betrugserkennung in einer Bank braucht Erklärbarkeit und menschliche Kontrolle; ein Formulierungsvorschlag im Editor verträgt Fehler, weil der Nutzer sie in Sekunden korrigiert. Der Deep Dive «AI Product Discovery: Probleme finden, die KI wirklich lösen sollte» liefert dafür das Framework aus vier Kernfragen – Problem belegt, KI begründet, Fehlertoleranz definiert, Daten legal.

Die Tabelle unten zeigt die Verschiebung im Überblick. Sie erklärt auch, warum Discovery im KI-Zeitalter wichtiger wird, nicht unwichtiger: Je weniger das Verhalten des Systems im Code festgeschrieben ist, desto mehr hängt am sauberen Verständnis des Problems.

Die Hype-Falle: Technologie ist kein Selbstzweck

Die häufigsten Denkfehler am Anfang einer KI-Initiative sind gut dokumentiert: Trends blind übernehmen, negative Signale aus der Testphase ignorieren und naiv davon ausgehen, dass saubere, strukturierte Daten schon vorhanden sind. Alle drei führen zum selben Ergebnis – ein technisch beeindruckendes Feature, das keinen messbaren Geschäftswert liefert.

Das Korrektiv ist unbequem, aber einfach: Jede Initiative wird an Wert, Aufwand und Risiko gemessen, bevor Ressourcen fliessen. Ein Anwendungsfall, der technologisch fasziniert, aber nur Randprozesse optimiert, wird abgelehnt. Diese Disziplin beginnt in der Discovery – nicht erst in der Roadmap-Diskussion, wenn politischer Druck die Priorisierung längst verzerrt hat.

Der Context Workspace: verstreute Signale werden Produktkontext

In den meisten Unternehmen liegen Marktsignale, Kundenfeedback und technisches Wissen über fünf oder mehr Systeme verteilt – Jira, Confluence, Code-Repositories, E-Mail, Köpfe. Gute Produktentscheidungen brauchen aber den Gesamtkontext. Ein Context Workspace verbindet diese Quellen zu einem lebendigen Produktkontext, der kontinuierlich dazulernt und sich manuell um die Nuancen erweitern lässt, die zählen.

Für die Discovery ändert das die Arbeitsweise konkret: Meldet ein Kunde ein verwirrendes Verhalten in der Preisberechnung, recherchierst du direkt im Quellcode, statt Entwickler aus der konzentrierten Arbeit zu reissen – und die Untersuchung fliesst als dauerhaftes Artefakt zurück ins System. Ohne diesen Kontext rät jede KI; mit ihm kennt sie den historischen und technischen Hintergrund einer Entscheidung.

Das KI-MVP: Teste den Zauberer, bevor du die Maschine baust

Ein massgeschneidertes Modell zu entwickeln ist der teuerste und riskanteste Weg, eine falsche Hypothese zu widerlegen. Die Discovery-Phase validiert deshalb mit dem kleinstmöglichen Einsatz: Wizard-of-Oz-Tests, bei denen ein Mensch die KI simuliert, und Foundation Models, die eine Idee in Tagen statt Monaten prüfbar machen.

Das MVP ist in dieser Phase kein verkaufsfertiges Produkt, sondern ein Lerninstrument. Es beantwortet zwei Fragen: Löst die Lösung das Problem gut genug, dass Nutzer sie wollen – und bei welcher Fehlerquote kippt die Akzeptanz? Der Deep Dive «Das MVP für KI: Teste den Zauberer, bevor du die Maschine baust» zeigt die Testanlage im Detail.

Customer Journey: Vertrauen ist Teil des Produkts

In Umfragen misstraut rund die Hälfte der Nutzer KI-Systemen. Für B2B-Software heisst das: Vertrauen ist keine Marketingaufgabe nach dem Launch, sondern ein Designproblem der Discovery. Die AI-Journey hat vier entscheidende Momente – Erwartung, erster Erfolg, erster Fehler, Gewohnheit – und der erste Fehler entscheidet häufiger über die Adoption als der erste Erfolg.

Ein B2B-Nutzer muss nachvollziehen können, warum ein System eine Empfehlung abgibt. Ein Prozentwert allein reicht nicht; das Produkt muss den Kontext der Entscheidung liefern. Wie ein Onboarding aussieht, das Unsicherheit transparent kommuniziert, statt sie zu verstecken, zeigt «Customer Journey Mapping für KI: Onboarding, das Vertrauen aufbaut» – inklusive der Ableitung von Akzeptanzkriterien für die Define-Phase.

EU AI Act: Compliance als Designprinzip, nicht als Bremse

Der EU AI Act klassifiziert KI-Systeme nach Risikopotenzial – und die Risikoklasse entscheidet, ob eine Produktidee legal und wirtschaftlich tragfähig ist. Deshalb gehört die Klassifizierung in die Discovery, nicht in die Rechtsprüfung kurz vor dem Release. Ist das rechtliche Risiko zu hoch, wird das Problem-Framing oder die Datengrundlage iteriert, bevor Budget gebunden ist.

Compliance by Design heisst konkret: Mechanismen gegen Verzerrungen einplanen, Datenquellen lückenlos nachweisbar halten und maschinelle Entscheidungen durch Menschen überprüfbar und überstimmbar machen – bei Hochrisiko-Systemen ist das Pflicht. «EU AI Act für Product Manager: Compliance als Designprinzip» führt durch Risikoklassen, Fristen und die fünf Bausteine, die ins Produkt gehören.

Anforderungen für Daten entwerfen, nicht nur für Features

Offene Sprachmodelle verfügen über breites Allgemeinwissen. Der strategische Vorteil eines B2B-Produkts entsteht aus dem, was sie nicht haben: spezifische Prozesskenntnis und eigene, nicht öffentliche Daten. Qualität, Relevanz und Repräsentation der realen Welt in dieser Datenbasis bestimmen die Qualität des Endprodukts – nicht die Modellwahl.

Für die Discovery heisst das: Zu jeder Produkthypothese gehört eine Datenhypothese. Wo werden die Daten erfasst, wem gehören sie, welche Kennzahl macht ihre Qualität messbar? Wer diese Fragen in der Discover-Phase beantwortet, erspart sich das häufigste Scheitern der Build-Phase – ein Modell, das auf Daten wartet, die es nie geben wird.

Das Ergebnis der Discover-Phase: eine qualifizierte Hypothese

Am Ende der Discovery steht ein überprüfbares Artefakt, kein Bauchgefühl: ein belegtes Nutzerproblem, eine begründete Entscheidung für oder gegen KI, eine definierte Fehlertoleranz, eine geklärte Rechtslage und eine Datenhypothese mit Qualitätskennzahl. Erst dieses Paket rechtfertigt den Übergang in die Define-Phase.

Die Reihenfolge ist der Punkt. Teams, die direkt mit dem Prompt beginnen, holen diese Arbeit später nach – unter Zeitdruck, mit gebundenem Budget und einem halbfertigen Feature im Rücken. Teams, die sie vorne leisten, spezifizieren gegen ein stabiles Ziel.

Häufige Fragen