Kategorie: Discovery & Validierung Lesezeit: 3 Min.
Wir müssen reden. Wie oft saßt du in den letzten Wochen in einem Meeting, in dem fünf Leute eine Stunde lang darüber diskutiert haben, was der Kunde wahrscheinlich will?
Der Vertriebschef sagt A, der Lead Engineer sagt B, und am Ende entscheidet der CEO, weil er das teuerste Auto fährt (HIPPO-Effekt: Highest Paid Person’s Opinion). Das ist kein Produktmanagement. Das ist Glücksspiel mit Firmenbudget.
In der Deep-Tech-Welt verstecken wir uns oft hinter Komplexität: „Wir können das nicht testen, wir haben zu wenig User“ oder „Unsere Kunden sind riesige Industrie-Player, da geht das nicht.“ Bullshit. Du kannst immer testen. Du musst nur wissen, wie.
Am Limonadenstand bedeutet das:
Stell dir vor, du und dein Geschäftspartner streitet euch. Er sagt: „Die Leute wollen Himbeer-Limo!“ Du sagst: „Quatsch, die wollen Minze!“
Ihr könntet jetzt stundenlang diskutieren, Marktstudien über Beerenfrüchte lesen oder teure Berater anheuern.
Oder ihr macht folgendes: Ihr stellt zwei Krüge auf den Tisch.
- Krug A: Himbeer.
- Krug B: Minze.
Dann haltet ihr den Mund und schaut zu. Welcher Krug ist nach einer Stunde leer? Diskussion beendet. Der Markt hat entschieden. Das hat euch 5 Euro für Zutaten gekostet, statt 5.000 Euro für falsche Produktion.
Die Deep-Tech Realität (Vom Stand in die Fabrik)
Natürlich ist es im Enterprise-Umfeld oder in der OT/IT-Integration schwerer als beim Limonadenstand. Wir haben keine Millionen User wie Facebook, wo wir mal eben die Button-Farbe ändern und statistische Signifikanz erreichen.
Aber das Prinzip bleibt gleich: Validierung schlägt Spekulation.
Im B2B-Bereich testest du oft nicht „Rot gegen Blau“. Du testest Konzepte. Bevor dein Team 6 Wochen lang ein neues Dashboard für die OEE-Auswertung baut (Variante A), baue einen Dummy oder klickbaren Prototypen einer alternativen Ansicht (Variante B).
Zeig es 5 Kunden. Wenn 4 Kunden bei Variante B sofort verstehen, wo das Problem in der Fertigungslinie liegt, und bei Variante A nur fragen „Was bedeutet diese Zahl?“, dann hast du deinen Gewinner. Du brauchst keine Big Data. Du brauchst klare Signale.
Tacheles: Dein Action-Plan
Hör auf, Features auf Basis von Meinungen zu bauen. Mach Folgendes:
- Definiere die Wette: Bevor ihr eine Zeile Code schreibt, legt fest: „Wir glauben, dass Lösung B die Konfigurationszeit um 20% senkt.“
- Keep it dirty: Ein A/B-Test muss nicht fertig programmiert sein. Ein PDF-Mockup gegen ein anderes PDF-Mockup ist auch ein Test. Wir nennen das „Wizard of Oz“ – vorne sieht es echt aus, hinten machst du es manuell.
- Definiere den Gewinner VORHER: Legt fest, was passieren muss, damit Variante B gewinnt. Wenn du das erst hinterher machst, lügst du dir die Daten schön („Ja, aber die User haben da länger draufgeschaut, das ist bestimmt gut…“).
Fazit
Dein Job als Product Leader ist es nicht, die richtigen Antworten zu haben. Dein Job ist es, die richtigen Tests zu bauen, um die Antworten zu finden. Daten schlagen Meinung. Immer.