Viele Erkenntnisse, kein besseres Produkt: Das Lernproblem in der Produktentwicklung (#376)

0:11 Herzlich willkommen zum Podcast aus dem Maschinenraum für Strategie, Marketing und Vertrieb mit mir Michael Stiller, dem Gründer und Geschäftsführer von Effektweit der Unternehmensberatung für Strategien, Marketing & Vertrieb. Heute mal wieder ein Thema beschäftigt gerade die Energiewirtschaft ganz extrem neu Produkte-Produktentwicklung und wir haben schon viele Produktinfektionsprojekte begleiten dürfen auch strukturieren dürfen und ganz häufig sehen diese Produktentwicklungs Projekte Echt lernfähig aus.

0:42 Da werden Kunde-Interviews gemacht, Marktenlösen gefahren, Workshops gemacht, Tests, Technics checks, Vertriebserfahrungen, Business Case Runden... Also echt viele Wissen und vor allem viel Lernen! Aber trotzdem wird das Produkt nicht klarer. Der Nutzen wird häufig gar nicht einfacher die Umsetzung nicht leichter, die Vermarktung nicht schärfer.

1:03 Das Projekt wirkt dann wahnsinnig beschäftigt aber irgendwie wird es nicht so richtig klüger. Also wenn ihr in Produkten regelmäßig über Standaufgaben und offene Punkte sprecht, aber selten über das was ihr als Organisation neu verstanden habt. Dann ist die Folge wahrscheinlich relevant! Und wenn Research, technische Produktentwicklung, Marketing, Vertrieb, Service & Führung jeweils Erkenntnisse haben, aber trotzdem kein gemeinsames Produktbild entsteht dann habt ihr ja wahrscheinlich gar keinen Erkenntnisproblem mehr.

1:32 Dann habt ihr ein Lernsystem Problem. also wenn alle etwas lernen bis das Produkt nicht besser wird Dann ist das Lernen nicht verbunden. und genau darum geht es heute, dass lernen zu verbinden. Das geht nicht um mehr Feedback Es geht nicht Um bessere Marktforschung Es geht Nicht um perfekte Produktenentscheidungen Sondern um das gemeinsame Lern in der Produktentwicklung.

1:52 Also wie wird ausverteilten wissen ein gemeinsames Verständnis? Wenn euch das alles bisschen bekannt vorkommt Und ihr denkt nur das könnte spannend sein Vielleicht sind wir noch niemals nur für die produktentwicklungen dann bleibt dran denn Darum gehts Heute. Ich bleibe trotzdem bei der Produkteentwicklung.

2:09 Die wird häufig als Ablauf gedacht, ist ganz häufiger. auch wenn wir angefragt werden Wenn das Produkt oder das Projekt am Anfang steht, dann haben wir hoffentlich gefragt könnt ihr da irgendwie so einen Wasserfallslide oder Schad raus machen? So ein Gent-Schad wo als Projektplan eine Idee Kundenbedarf Lösung Business Case Umsetzung go to market launch Klingt total sauber Ist aber viel zu linear Denn in Wirklichkeit entstehen Ganz, ganz viele Erkenntnisse in so einem Projekt gleichzeitig.

2:39 Markterkenntnisse entstehen Produkterkenntnisse also Nutzen, Machbarkeit, Prioritäten die Umsetzung mit Prozessensystem und irgendwelche Höhen und auch die Risiken also führungsrelevante Themen Budget und die strategische Relevanz Und das sind alles Lernperspektiven. die sind total wichtig. Das Problem dabei ist keine ist vollständig.

3:06 Diese Perspektiven werden dann oft koordiniert, aber eben nicht gemeinsam verarbeitet. Dann fragt man nämlich nach was ist der Stand? Wer macht was bis wann? Das ist Koordination! Aber organisationales Lernen ist etwas anderes wenn ich das zusammen bringen möchte. Da muss sich halt diese Frage stellen was verstehen wir denn heute anders?

3:26 wo widersprechen sich eigentlich unsere Beobachtung der Kenntnisse? welche Annahme trägt eigentlich gar nicht mehr? und was is unser gemeinsames Produktverständnis? also Das ist manchmal total unmöglich, das sind die härteren Fragen. Aber ein Produktprojekt kann hervorragend koordiniert sein aber eben schlecht lernen und das ist ein Problem.

3:48 Der zentrale Denkfehler Wenn einzelne Teams lernen, lernt automatisch die gesamte Organisation oder das gesamte Projekt-Entwicklungsteam. Ist leider Gottes nicht so. Ein Research Team kann schlauer werden, ein Produkteam aufruhen, Vertrieb kann schlauer werden, Service und auch die Führung. Aber trotzdem bleibt das gemeinsam Produktverständnis schwach an der Stelle.

4:09 Warum? Weil jede Funktion ihre eigene Logging hat, neue Research suchen Muster, Marketing sucht Anschlussfähigkeit oder starke Aussagefähigkeiten, Vertrieb sucht Kaufbarkeit und Management sucht Tragfähigkeit. ist alles legitim aber Alles nebeneinander gestellt. daraus entstehen dann Lerninseln Und Lerninseln.

4:29 die sehen halt für sich total vernünftig aus eine ganze Fläche, nicht ein Kontinent. Sondern Lerninten sind voneinander abgegrenzt und ergeben eben kein vernünftiges Produkt. Wenn wir da in die Theorie reinschauen dann ist es auch agiris-und-schön, die organisationales Lernen sich mal angeschaut haben und die unterscheiden zwischen Single Loop Learning wo es darum geht vieler innerhalb einer bestehenden Annahme zu korrigieren.

5:02 Ein klassisches Beispiel, was da immer wieder angeführt wird. Ich habe eine Zimmertemperatur die ich erreichen möchte. Ich hab ein Thermostat... ...ich messe die Abweichung und korrigiere meinen Fehler in der Steuerung. Sie grenzen das aber ab vom Double Loop Learning! Da wird nicht nur der Fehler korrigiert sondern er wird auch die Annahme selbst überprüft.

5:23 an euch... ...Zimmertemperatur, Thermostat, Abweicherungen.... Ich frage aber wie kann ich diese Abweicherung wieder korrigieren? Sondern ich frage auch noch Macht denn eigentlich vor diesem neuen Messwert mein Ziel wert noch Sinn? Also nicht nur Fragen wie verbessern wir die Lösung, sondern sind wir weiter vom richtigen Problem ausgegangen.

5:43 Stimmt unser Bild vom Kunden, vom Nutzen oder stimmt unser Bild davon wie dieses Produkt was wir da gerade entwickeln wollen gekauft genutzt und betrieben wird? das ist total unbequem. aber nachjustieren es eben halt auch kein Lernen sondern manchmal eben nur Reparatur. Produktentwicklung braucht also Nicht zuerst immer mehr Informationen, sie braucht eine gemeinsame Deutung.

6:10 Wenn wir da von Karl Weik des Sensemaking sehen, Organisationen handeln selten auf Basis vollständiger Wahrheiten. Sie brauchen eine plausible gemeinsame deutung um handlungsfähig zu werden. praktisch heißt das es reicht eben nicht dass viele Bereiche irgendwas beobachten. Da muss ne gemeinsame Lesart raus entwickelt werden.

6:31 Also nicht der Kunden hat gesagt, der Vertrieb meint Technik sieht irgendwas. Sondern was heißt das zusammen? So Beispiel für solche Lernhypothesen sind Das Kundenproblem ist vielleicht relevant aber eben nicht dringend genug. oder die Lösung ist vielleicht attraktiv Aber operativ zu schwer Oder auch schlichtweg der Kaufanlass fehlt.

6:52 Das sind Arbeitsannahmen Lern-Hypothesen. Wenn wir uns das anschauen Produktentwicklungsprojekte erzeugern Dauernd Erkenntnisse. Wir machen halt, wie gesagt, Interviews, Tests Technic Chests, irgendwelche Workshops Das alles ist Lern Aber eben häufig nur lokal. Ein Bereich versteht etwas besser Marketing versteht was besser Vertrieb aber nicht die Menge dieser Erkenntnis entscheidet sondern eben ob sie zusammenfinden.

7:28 Typische Bruch. da wird so ein Kundenproblem beschrieben Da wird eine Lösung gewickelt Da wird ne Umsetzung geplant und die Vermarktung nachgezogen. Aber niemand fragt, eigentlich passt unser gemeinsames Bild noch zusammen? oder optimiert jetzt jeder nur seinen Ausschnitt. Das sind eben solche Dinge wie wir lösen ein dringendes Kundenproblem.

7:51 das wäre eine Annahme. der Nutzen ist erklärbar die Organisation kann es liefern aber diese Annahmen müssen gemeinsam verprobt werden sonst entstehen halt eben Teilwahrheiten aber kein tragfähiges Produktbild. in aller Regel ...produziere ich damit Widersprüche. Das fast schon zwangsläufig, ne? Manchmal sagen die Kunden aus der Marktforschung heraus das ist wichtig.

8:20 Die Technik sagt bei dem Feature aber das aufwendig. Marketing sagt es super schwer erklärbar, Vertrieb sagt es schwer verkaufbar. Servicke sagt oh das krieg ich schwierig nur im Betrieb eigentlich hin... Dann sagt aber die Führung, aber das ist strategisch total relevant. Was ist der Reflex? Der Reflex ist dann dass diese Widersprüche geglättet werden.

8:43 Eine Sicht gewinnt eine Perspektive gewinn die anderen werden irgendwie weg moderiert. Da hat man Ruhe! Dann läuft das Projekt auf wieder schön. Du hast Ruhe, aber nicht unbedingt ein Erkenntnis daraus geholt. Der bessere Reflex wäre eigentlich diese Wiedersprüche als Lernmaterialbehandeln. also nicht fragen wer recht sondern was zeigt uns dieser Widerspruch über unser Produktverschwendnis?

9:07 Also als Beispiel, der Bedarf ist da aber wir haben keinen Kauf an das. Er gibt sich daraus vielleicht ein anderes Problem also Kundenproblem oder den Nutzen ist klar eigentlich aber schwer erklärbar. dann ist vielleicht die Wertlogik und scharf Oder die Lösung ist attraktiv Aber die Umsetzung ist total schwer.

9:30 Dann ist vielleicht das Produkt versprechen zu breit. Also Widersprüche sind nicht das Ende der Produktentwicklung, sie sind eben auf den Anfang des Produktlerns an der Stelle. Zudem wird der wichtigste Schritt häufig übersprungen. also zwischen Beobachtung und Handlung liegt die Deutung. Häufig haben wir es, wir beobachten was dann handeln wir danach aber müssen erstmal zusammen deuten Was wurde beobachtet?

9:59 Was bedeutet das? Und was heißt das letztendlich für unser Produktverständnis? Und diesen Schritt hast du halt genau das, was wir gerade hatten. Research sieht einen Bedarf oder ein Produkt sieht eine Lösung. Haben alle recht aber niemand hat das ganze im Blick und ohne gemeinsame Deutung wird aus Wissen halt irgendwie nur so ein Hintergrund rauschen.

10:21 Deswegen sollte eben in so Produktentwicklungstermin nicht nur offene Punkte geklärt werden sondern es muss auch immer ne gemeinsame Lesart erzeugt werden. Damit meine ich keine Konsenssoße Nicht Konfliktenvermeidung, sondern wirklich gemeinsame belastbare Lernhypothese wie ich es gerade beschrieben habe.

10:42 Eine gute Lernehypothese ist nämlich mehr Wert als zehn unverbundene Erkenntnisse. die stehen dann da einfach nur so doof im Raum herum und keiner macht was damit. Deswegen braucht ihr eine Lernarchitektur. Also gelerntes Wander nicht von alleine von A nach B. Ihr braucht eine Architektur, das ist jetzt nicht direkt eine Bürokratie oder auch nicht direkt ein neues Wissensmanagement-Tool was ihr braucht.

11:09 Oder irgendeine Form von Reporting sondern einfach nur eine wiederholbare Art erkennt es zusammen zu führen. So eine Lernarchitätstour muss nämlich Folgendes leisten die muss Perspektiven sichtbar machen, die muss Annahmen offenlegen, die müssen Widersprüche nutzbar machen und dadurch ein gemeinsames Verständnis schärfen.

11:31 Das ist auch ein Riesenunterschied. Es ist einmal der Meeting-Rhythmus, im klassischen Produktentwicklungsstatusbericht da habe ich was ist fertig? Was ist offen? Wer braucht was? und ich hab nen Lernrhythmus! Da geht es dann eher darum zu sagen das verstehen wir heute anders. welcher Annahme ist schwächer geworden?

11:50 oder was is unsere Lernhöpothese für die nächste Runde? Nur weil die Menschen nämlich regelmäßig in ihrem Projekt Meetings zusammenkommen lernen sie halt eben noch nicht. Strukturen darf lernen nicht ersticken und Lernen darf aber auch strukturlich auflösen. Dafür braucht es eine Methode. Und ja, wir haben für uns aus der Erfahrung vieler Projekte und dem was ich jetzt hier gerade schon in Schildern bei effektweiten eine methode entwickelt.

12:23 Product Flywheel haben wir es genannt, das hat jetzt nichts mit dem Flywheel von Collins zu tun. Es ist aber halt auch eine Art Schwungrad, es geht in Zyklen und es denkt Produktentwicklung eben als lernes System. Das gibt immer so ne Grundbewegungen die wir haben, die wir immer wieder etariieren, wo wir sagen erkennen also was sehen wir?

12:41 Was machen wir daraus? Und dreht das was wir daraus gelernt haben, erkennen, fokussieren oder gestalten und verproben. Ist jetzt keine Methodenliste sondern sondern ein Lernvideo. Da geht es darum, das Kundenproblem zu schärfen und dann die Wertlogik zu überprüfen, die Machbarkeit verstehen, das Go-to-Market mitzudenken, Reibungen zu erkennen und eben dieses gemeinsame Verständnis zu aktualisieren.

13:08 Und deswegen ist es auch für uns immer schwer zu erklären, dass Produktflywheel nämlich dann interessant wird, wenn man es nicht nur als reinen Prozesskreis liest, sondern eben als eine Art Lernerchitectur Ein Lernarchitektur, in der nicht jede Funktion alleine lernt. Sondern eben die Organisation ein gemeinsames Produktverständnis aufbaut.

13:29 Deswegen vielleicht beim nächsten Produktentwicklungstermin? Nicht mit dem Statusanfang! Also nicht verstehen wir was fertig ist offen sondern... Was verstehen wir heute als Organisation anders als beim letzten Termin? Dann vielleicht drei kurze Klärungen Wo sind diese Erkenntnisse erstanden? Wo widersprechen sie sich und welche gemeinsame Lernhypothese nehmen wir mit in unseren nächsten Zyklus.

13:51 Da geht es nie um finale Wahrhalten, da geht's immer um bessere Arbeitsannahmen. Pragmatisch heißt nicht schneller eine Lösung zu behaupten sondern pragmatisch heisst ja auch schneller zu klären was wir gemeinsam verstanden haben. Und das ist auch so häufig der Punkt. und der Pragmatismus wird dann mit.

14:08 Wir machen es ganz schnell und der lauteste setzt sich durch. Nee darum gehts eben nicht Im Pragmatismus, sondern es geht halt darum schneller zu klären was wir gemeinsam verstanden haben aus um meiner Sicht zumindest. Das bringt mich so ein bisschen zum Fazit. Also Produktentwicklung scheitert oft nicht an fehlenden Wissen, sondern daran das Wissen fragmentiert bleibt.

14:30 Teams können lernen also die einzelnen teams und dass Die gesamte Organisation lernt Was auch wichtig dabei ist. die widersprüche die entstehen zwangsläufig entstehen sind kein Störfall purees Lernmaterial. Und indem ihr diese Widersprüche aufnehmt und gemeinsam deutet, dadurch entsteht organisationales Lernen oder das ist der Kern des organisationalen Lerns.

15:00 Wenn wir Aguris und Schönen nehmen Single Loop Learning und Double Loop Learning als überlegende Form auch von den beiden kristallisiert die sagen halt du musst immer die Annahmen mit prüfen Ganz wichtiges Ding. Und Bike Sense-Mating sagt, wir brauchen dafür eine gemeinsame Deutung. Rückkopplung ist wichtig laut Ries und das Stagegate brinnt uns halt Struktur.

15:24 Das Produkt Flywheel wie wir es entwickelt haben verbindet diese Logik eben genau als Lernarchitektur. also Produktentwicklung braucht eben nicht nur bessere Ideen sie braucht eine Organisation die gemeinsam lernt. wenn ihr jetzt gerade so ein Produkt entwickelt oder irgendwie ein neues Angebot in den Markt bringen wollt, dann schaut nicht nur auf die Roadmap.

15:45 Nicht nur aufs Budget, nicht noch den Launch-Termin sondern schaut auf den Lernfluss. Da reichen drei Fragen als erster Test immer die Frage wo entstehen Erkenntnisse und wo bleiben sie hängen? Welche Widersprüche werden nicht sauber geklärt? um was versteht ihr heute wirklich anders als noch vor ein paar Wochen?

16:03 wenn es bei diesen Fragen unscharf wird? Dann lasst uns doch mal ganz kurz quatschen. zwanzig Minuten Blick auf eurem Produktentwicklungsprozess. Wo lernt ihr schon, wo bleibt Lern fragmentiert? und vielleicht auch ob das Produkt Flywheel euch wirklich als Lernerchitektur helfen kann? Manchmal sieht man mich schon in zwanziger Minuten ob so ein Produktentwirkungsprozess wirklich lernt oder nur sehr ordentlich beschäftigt ist.

16:32 Wenn euch das geholfen hat dann nehmt doch den Podcast mit in euer Produktentwicklungstermin und empfehlt den da. Vielleicht ist es für den ein oder anderen auch gut. abonniert dem Podcast, liked den gerne auch gerne auf LinkedIn Und am meisten freut mich wie immer wenn ihr nächste Woche wieder bei seid bis dahin sage ich tschüss.