Arbeiten mit Hypothesen

Das Super-Über-Ziel ist, dass wir mit möglichst wenig Aufwand / Invest / Zeit idealerweise 100% sicher sind dass unser Kunde(nsegment) unsere Lösung kauft (und wir in der Lage sind diese Lösung auch zu liefern und technisch erzielen können, Viable – Feasible – Desireable). Optimal wäre wenn wir bei unserem Kunden anrufen, ihm am Telefon erzählen was wir machen/vorhaben, und der dann direkt bestellt und das Geld vorab überweist, und wir entwickeln und bauen dann erst los wenn das Geld auf dem Konto ist.
Ausserdem sollte natürlich die Zielgruppe möglichst groß sein (viele Kunden) und wir sollten möglichst viel Geld (Rohertrag/Marge) damit verdienen.

Warum geht das nicht so einfach?

  • Wir kennen das Problem der Kunden nicht
  • Wir wissen ggf. nicht auf welchen Kanälen wir den Kunden am besten erreichen
  • Wir können die Lösung nicht beschreiben / wir haben oder kennen die Lösung noch nicht
  • Andere Firmen bieten auch schon Lösungen an. Wir müssen also besser/billiger/anders sein.
  • Sind wir überhaupt in der Lage eine Lösung zu bieten? (Technisch? Wirtschaftlich sinnvoll?)
  • Wir kennen die Kosten der Lösung (auf Herstellungsseite) noch nicht, können also keinen Preis nennen.
  • Wir wissen nicht ob wir das sinnvoll massen-produzieren (skalieren) können
  • Wir wissen nicht ob der Kunde denn dann wirklich kauft/kaufen will / kann (Kein Budget, andere Lösung, Entscheidung für Wettbewerb…)
  • …

Grundlegende Annahme ist dass wir eben NICHT wissen wie die Welt funktioniert, (VUCA) was unsere Kundin will, und ob sie unser Produkt kauft. Das was wir grob und schnell mit VUCA zusammenfassen.
Hier kommt jetzt Thema Nummer 2 dazu: Produktentwicklungen schlagen eigentlich immer fehl.

„According to Harvard Business School professor Clayton Christensen, there are over 30,000 new products introduced every year, and 95 percent fail. According to University of Toronto Professor Inez Blackburn, the failure rate of new grocery store products is 70 to 80 percent. „

Hypothesen bauen wir aus drei Gründen:

  1. Um einen Überblick über (und eine Fläche für) Punkte zu haben die wir im Kopf haben, die wir „schon immer so gemacht haben“ oder von Quellen erfahren haben bei denen wir uns nicht ganz sicher sind (Blogs, Bekannte, Erfahrungen aus der Vergangenheit bei denen aber zB. nicht klar ist ob sie auf diese Situation/Zielgruppe/Zeit übertragbar sind).
  2. Um die Komplexität dieser ganzen Faktoren (Kunden/Produkte/technische Machbarkeit/Marktzugang/Vertriebskanäle….) zu reduzieren indem wir Szenarien bauen.
  3. Drittens um diese dann strukturiert abarbeiten und eben validieren zu können und den Überblick zu behalten. Wir versuchen diese Fehlerquote möglichst klein zu kriegen, oder zumindest die „Schwere“ des Fehlers in Form von verschwendeter Zeit und Geld möglichst gering halten. Fail Fast – Fail Early.

Wir versuchen für unsere Zielgruppe, unser Thema, unsere Situation – eben unser Szenario – spezifische Validierung (Erprobung in der Realität mit einem Teil unserer tatsächlichen Zielgruppe) zu erreichen. Wir wollen uns so nah wie möglich an das Szenario mit dem „anrufen und bezahlen lassen“ rantasten und eben dabei so wenig wie möglich Geld ausgeben und Zeit verschwenden.
Der VPC hilft die Bedürfnisse (Jobs/Pains/Gains) der Kunden (im spezifizierten Segment) und die Fähigkeiten des Unternehmens (Gain Creators/ Pains Relievers/ daraus resultierende Produkte und Services) abzugleichen und zu matchen. (Problem – Solution – Fit)
Dazu müssen wir kategorisch skeptisch zu sein, zu (hinter)fragen und erst mal alles als Hypothesen (jemand behauptet etwas) zu betrachten, bevor wir es nicht sauber mit unserer Zielgruppe validiert haben. (Um eben weniger Entwicklung fehlschlagen zu lassen, bzw. viel früher im Entwicklungsprozess festzustellen ob etwas klappt oder nicht. Eben nach Tagen und nicht nach Jahren).