Lässt Vibe Coding Product Owner und Developer Rollen verschmelzen?

Weibcoating ist in aller Munde. Eine häufige Vermutung dabei ist, dass dadurch Product-Owner ihre eigenen Prükte bauen können. Lässt Weibcoating also die Rollen von Product-Owner und Developer miteinander verschmelzen? Dazu unterhalten sich in dieser Folge, Themen und Oliver. Wir wünschen euch nun viel Spaß und natürlich viele hilfreiche Impulse beim Hören dieser Folge. Wir haben hier in unserem Podcast vor einiger Zeit schon mit Ben Sofiani über das Thema Weibcoating gesprochen und in der Tat beobachtig in meiner Umgebung und bei dem Product-Owner mit den nicht zusammenarbeiten, dass sie mehr und mehr sich mit dem Thema Weibcoating beschäftigen, damit eine ganze Menge auch schon experimentiert haben. Aber jetzt konkreter auch in Richtung ihrer eigenen Produkte arbeiten und experimentieren. Und die Frage, die sich darstellt, ist, ob ich da als Product-Owner nicht mehr und mehr auch Dinge tue, die wir eigentlich ganz ursprünglich den Developer zu schreiben und welche Vor-Nachteile das Ganze so haben könnte und das zu reflektieren, das werde ich in dieser Folge mit dem Tim, heilt ich heilt im Halleholy, teilst du denn so meine Beobachtung, die ich gerade so eine Anmoderation hatte? Ja, ich mach selber vor allem die Erfahrung, also ich hatte ja in der Folge mit Ben Sofiani, wir werden ihn noch mal verlinken im Herbst auch angekündigt, ich glaube, das war irgendwie Anfang Oktober oder so, dass ich selber in Q1 dann in dieses Programm, ich baue mein eigenes Saas-Produkt mit Einsteige, ich hab das auch gemacht, das heißt, ich bin jetzt gerade auf dem Weg komplett aus meiner eigenen Komfortzone als kleiner Blöder BVL herauszugehen und ja, bin jetzt selber dabei mit Curse zu arbeiten, noch nicht mit Clot Code, das ist so mein Ziel, vielleicht für Q2, aber ja Gott, ich sitze plötzlich vor der Kommando-Zeile und habe ein Terminal offen und arbeite mit GitHub also, es ist am Anfang argschmerzhaft gewesen, aber ja, da werden wir sicher auch darauf kommen, es zeigt mir trotz über 25 Jahre Erfahrung, Anwendungsnah oder Entwicklungsnah trotz dem nochmal wieder auf, was unsere lieben Software-Enginierst und so für Probleme und Schmerzen auch haben, die natürlich zum Teil mit Vibecoating verschwinden, aber genau, was wir jetzt ja heute diskutieren wollen, ist, was für weitere Beobachtungen, ich da mache, wenn man selber aus einer Produktdänkerhaus plötzlich klar gesagt entwickeln kann. Ist also so ein bisschen bei dir die Zeit des Ausprobierens ein bisschen experimentieren vorbei oder wird weniger und du bist eher in Richtung von, lass mal gucken, ob ich da ein Produkt schaffe, was tatsächlich auch Nutzerbedürfnisse zufrieden stellt, strecksstrich irgendwie ein wirtschaftlichen Nutzen generiert. Kann man das so formulieren? Also für mich ganz persönlich wäre das wahrscheinlich zu viel gesagt, weil ich bin selber natürlich noch dabei auszuprobieren, aber was ich eben beobachte, ringsherum, ich treib mich auch recht viel hier, in Köln haben wir ein sehr, sehr gutes Vibecoating, mietabmonatlich, das wext und gedreit und das sind immer so knapp 100 Leute am Start und was man da so hört und präsentiert kriegt, das zeigt mir also, dass die Leute nicht mehr nur rum spielen, das hast du noch noch genug Leute, es ist auch wichtig mit den Systemen rumzuspielen, aber es ist halt nicht mehr so dieses herbebauen mal eine Lendingpage und danke schön und mit entsprechenden LLMs unterwegs sei es fürplexe T-Germany oder eben auch überall, sondern es werden, ich würde behaupten robuste Systeme geschaffen, die auch produktiv einsetzbar sind und das ist glaube ich der Unterschied, es geht eben weg davon nur reine Prototypen zu erstellen, das was ja auch super hilfreich ist um mein Fingern als Produktmensch, meinem Entwicklungsteam klar zu machen, was die Idee ist, das ersetzt aber für mich dann eher so was wie fick man und so, jetzt geht es glaube ich da drum, echte Produkte zu bauen, natürlich so ein bisschen auf dem Greenfield-Proach, also ich mein jetzt nicht wirklich es arbeiten an bestehenden Software-Produkten mit KI, das gibt es auch, das ist super wichtig, da ist die richtige Musik würde ich sagen, aber darum, das bewegt mich gerade so, ich sehe halt ganz viele Leute gerade in so einer Aufbruchstimmung, auch viele sehr langjährige, super erfahrene Software-Enginis, die sind wie kleine Kinder, also die Sprühen vor Begeisterung, die bauen und bauen und das Feature und noch ein Feature etc. und ich denke mal manchmal so, hey stopp mal innehalten, habt ihr das Problem überhaupt verstanden, dass ihr hier lösen wollt und habt ihr es geklärt, habt ihr Klarheit, ob das Robbins-Latements, wisst ihr für wen, also Zielgruppe Personas, die arbeitet und wie reflektiert ihr das überhaupt, also Product Discovery als Stichwort und weil ich hab's ja das Gefühl, momentan leiden Feedback-Schleifen, zwar Feedback-Schleifen mit Humane Feedback-Schleifen, wo echte potenzielle Nutzer Feedback gibt. Also das kann ich nur unterstützen, was mich noch zusätzlich tatsächlich umtreibt ist, wenn es jetzt um real existierende, wirkliche Produktentwicklung geht und die Umsetzung von solchen Produkten und ich dauert als Product ohne quasi ja auch als Developer tätig werde und so haben wir den Titel der Folge ja auch so ein bisschen geframed, dann übernehme ich auf einmal mehrere Verantwortlichkeiten in diesem ganzen Prozess und mir ist klar, die Menschen, die ich beobachte, dass die eher alleine oder mit weniger Personen unterwegs sind. Also das ist ganz häufig nicht so, wir haben ein großes Scrum Team und haben sechs Developer in dem Scrum Team und ich bin dein Product ohne Set-Up arbeiten, du hast es ja auch schon so ein bisschen angedeutet. Aber trotzdem habe ich so in meinem Kopf immer so den Schmerz oder zumindest so ein Alert und Achtungzeichen von, ja, werde ich jetzt als Projekt ohne auf einmal auch der Developer und eigentlich haben wir ja hier die letzten Jahre immer davor gewarnt, auch egal in welchem Kontext oder in welchem Umfeld und das, was du ja beschrieben hast mit dem hab ich genug darauf geguckt, wer meine Zielgruppe ist, wie das Businessmodell hält, haben wir genug Projekt Discovery gemacht, dass das gefühlt aus deiner sich zu kurz kommt, ist ja auch ein ähnliches Alarmzeichen, vielleicht dafür, dass es gute Gründe gab, bestimmte Verantwortung zu trennen, um halt mehr Fokus auf bestimmte Themen, tatsächlich zu haben. Ja, man kann natürlich auf der anderen Seite sagen, Scrum ist halt als Framework explizit dafür gemacht worden, in der Teamgröße von drei bis neun Personen zu arbeiten, Anfangs ja sogar noch mehr, also eher sechs bis neun, nicht fünf bis neun, dann irgendwann drei bis neun, aber sei es darum, wenn ich denn jetzt sozusagen nur mit mir selber überspitzt formuliert, entwicke, brauche ich natürlich auch so, was wie ein Scrum Framework vielleicht gar nicht mehr, aber und da bin ich beide, die sind mal so die Konflikte, die da potentiell aufkommen können zwischen einer Produktsicht und einer Developmentsicht, weshalb ist eben so wichtig war immer in das Scrum Logik diese Rolle, also der Fanfurtigkeit als Product-Owner und Developer zu trennen und eben möglichst nicht als Product-Owner auch mitzuentwickeln, was danach wie vor viel gibt, das lassen uns gerne mal beleuchten, weil ich teile davon sind sicherlich immer noch als Problemvalide. Ja, wobei ich da anmerken würde, in dem Fall, wenn ich nur mit mir alleine irgendwas mache, ob ich mich dann Product-O als Product-Owner bezeichnet würde, aber das ist glaube ich eher eine theoretische Diskussion, ich übernehme selber wahrscheinlich Aufgaben und Verantwortlichkeiten an das Product-Owners-Form-Liech so, aber wenn ich dann mit Weibkoding unterwegs bin, übernehme ich halt auch Aufgaben und Verantwortlichkeiten eines Diverloppers, ja. Ja, ich spür das ja jetzt gerade selber, ich bau da so eine kleine Anwendung, um das Ganze natürlich auch zu erlernen und was ich natürlich täglich tue, dauernd eigentlich nicht mehr täglich, dauernd tue ist Produktentscheidung zu treffen und damit bin ich im übertragenen Sinne Product-Owner, also ich übernehme Product-Owner Schimpf vielleicht sogar auch, weil ich entscheide alleine für was setz ich meine Zeit ein, kümmere ich mich jetzt um das System Robuster zu machen, sicherer zu machen, kümmere ich mich da drum User Feedback einzusammeln oder kümmere ich mich, was sehr verleitend ist in diesem Weibkoding, kümmere ich mich um das nächste Feature und habe das, was mir selber ja so geht, ich bau was, guck da drauf und denke, das gefällt mir nicht, man könnte das auch so machen, hause kurzen Promt rein oder ich mache es sogar direkt mit Spracheingabe, erzähl dem System, was ich sonst will, nur macht es das anders und dann guck ich mich wieder an und habe eine Meinung, das heißt es ist sehr opinion driven finde ich, es ist sehr von meinem eigenen Bauchgefühl, von meiner eigenen Meinung bestimmt, ob ich das Feature so lasse, ob ich das Feature verändere, ob ich ein neues Feature denzufüge, so auf der Ebene bin ich und damit bin ich finde ich Product-Owner, weil ich dauernd Entscheidungen treffe was zu tun oder zu lassen ohne mir entsprechende Feedback-Zyklen. Das mit dem fehlenden Feedback-Zyklus ist sicherlich etwas, was man kritisch betrachten muss und sollte in dem Setup, den du beschrieben hast, aber implicit hast du ja durchaus Vorteile beschrieben, wenn ich halt als PO selber mit Weibkoding mein Produkt entwickelt, selber dass das stich wird, ich kann es als wirklich selber machen, also ich bin nicht von anderen abhängig, ich kann halt auf welchem Wege auch immer mein Produkt weiterentwickeln, mich im bestimmte Themen einarbeiten und es irgendwie gestalten und das zweite hast du ja auch schon gesagt, es geht es ja wahrscheinlich auch viel schneller, als wenn ich dann noch mit anderen Menschen zusammenarbeite, die dann meine Produktentscheidungen wieder umsetzen können, zumindest, wenn ich in dem Umfeld bin, die du beschrieben hast und wenn ich das mit AI-Unterschützungen mit Weibkoding irgendwie realisieren will und auch kann, also es geht auf jeden Fall schnell, also ich habe sicherlich hier so ein etwas strukturierteren Einsatz, ich einsatz, ansatz, verfolgt um mich einzuarbeiten, entlang eben dieses Weibkoding Codex inzwischen heißt das Bilder Codex bei, bei PirateSkills.com können wir noch mal verlinkt und ich finde wirklich ein echt cooles Vorgehen, weil es mir Schritt für Schritt ermöglicht hat innerhalb von 24 Stunden, also es war von dem einen Tag Mittags bis zum nächsten Tag Mittags und ich habe nachts geschlafen, habe ich was gebaut und die pleut, das war schon krass, aber fährereweise muss man natürlich sagen, ich habe natürlich auch Opportunitätskosten, sprich in der Produktdenke habe ich jetzt mal vom einer Beiden abgesehen, die andere Dinge nicht getan, Stichwortmarkt, Beobachtung User Research, das heißt ja, ich kann alles selber machen, super schnell machen, es geht sehr schnell, es geht zum Teil schneller als mit developern, ja, das find ich die Frage, ab welcher Skalierung das vielleicht dann noch spannend wäre, aber ich, als ich Vorteil, die ich zum Beispiel sehe, ich habe so diese Schleife nicht, dass ich erst was immer in Schriftform überführen muss, so dass andere das wieder verstehen, also still postproblem, Vermeidung von Missverständnissen, wie oft ist uns das selber auch passiert und dann diskutierst du sehr lange darüber, was du meinst, hier hast du natürlich, wenn du an so was wie cursor oder so sitzt oder Cloud Code kannst du sofort sehen, ob das System dich gut genug verstanden hat oder nicht und es sofort revidieren oder anpassen, das ist ein riesen Vorteil. Wobei ich da ja denke, wenn ich in so einem kleinen Set-up wäre, ich hätte einen Developer neben mir als Produkt ohne und wir würden uns die ganze Zeit nebeneinander setzen und der Developer entwickelt, dann könnte ich das ja auch haben. Also häufig ist das, was du jetzt gerade erzählt hast, wo ich da dabei bin, dass ich weniger Schleifende habe oder mehr Missverständnisse vermeiden kann, völlig dackur, aber das liegt ja häufig eher, selbst in kleinen Set-ups in meiner Welt, dass ich doch sehr getrennt unterwegs bin, anstatt in die maximale Interaktion und Zusammenarbeit zu kommen und wenn wir zu zweit oder zu dritt irgendwo vor einem System sitzen würden und ich würde es nicht benutzen als PO, sondern die Developer würde entwickeln, dann könnte ich diese Vorteile ja durchaus auch zielen, das muss ja nicht zwangsläufig nur an dem Weibkodigen sein. Mir fällt es ja wahrscheinlich einfacher, es ist mit weniger Schmerzen verbunden, so wie du das sagst, weil ich mache die Sachen halt mit mir selber aus und nicht noch mit einer anderen Person. Ich musste gerade spontan an eines dieser Zwift agilen Prinzipien aus dem sogenannten Agimen manifest denken, weil Entwickler und Produktmenschen oder so ähnliches da sollten täglich oder Entwicklung und Fachbereister und täglich zusammenarbeiten und täglich zusammen sitzen. Genau das, was du beschreibst, das war ja immer die Idee, dass man am besten im Co-Creation-Modus direkt nimmer nana sitzen, was entwickelt. Das Problem glaube ich einen klassischen Entwicklungsvorgehen ist, dass du zu viele Fähigkeiten in der Breite brauchst und deshalb mindestens zwei Leute, eine aus Produktsicht, einer aus Entwicklungssicht, raus und oftmals ja aus der Software-Inginierung sich auch mehrere Leute, weil du selten so den super perfekten Fulsdeck-Entwickler hast. Und das ist natürlich jetzt im Bereich dieses dieser AI-basierten Entwicklung und Agentik und so geht da nochmal und MCP-basierte Sachen gehen da nochmal wesentlich weiter natürlich. Dazu auch die gute Folge von mit Björn Schotte, der sehr stark auf die MCP-Sachen eingeht. Jetzt hast du halt selber Systeme in der Hand, denen du, so entleblich das ja auch, ohne großartig viel Fachwissen, aber Fragen stellen kannst, Hilfe anfordern kannst und dieses technische Fachwissen, so sag ich es mal, von der Software-Entwicklung ernt sich ja ein bisschen zu echtektur, wird dir Großteils auch gegeben. Die große Gefahr und das auf jeden Fall zu sagen hier auch ist natürlich, dass ich jetzt mit meinem Hintergrund das oftmals nicht gut genug reflektieren und bewährten kann. Da bräuchte es jetzt auf jeden Fall als fahre Senior-Entwickler und Architekten, die das Feedbacken und Review. Aber erst mal von der Rhein-De-Livery, vom Erstellprozess her, habe ich so viele, also irgendwie hat sagt ihr jetzt in einem Zitat, sag ich, er fahre eine Entwickler über 30 Jahre in der Entwicklung, gesagt ich habe das Gefühl, ich habe 10 je arme und jeder arm hat noch eine Verlängerungsextension dran und plötzlich kann ich so viel auf einmal schaffen, so in so einem Modus empfehlen. Es ist aber spannend, dass du das in diese Richtung formulierst und auch eben auf Agilles Manifest und Prinzipien kommst, weil erst das Prinzip ist individuell in den Interaktionen. Zumindest da, wo wir halt herkommen und du hast auch in der Anmoderation schon gesagt, du hast so ein bisschen das Gefühl, dass dieser menschliche Faktor halt weniger wird oder nicht so betrachtet wird. Und ich glaube, dass er tatsächlich auch aus dieser Interaktion und aus der Kommunikation mit Menschen auch nochmal ein Mehrwert entstehen kann. Und ich mein selbst, wenn du bei diesen Nutschat GPT-Lösungen bist, nochmal an der ganz woanders, an der ganz anderen Stelle, ich weiß nicht, Markus andere zack war, glaube ich, derjenige, der neulich mal prostete, ja, wenn ich das alles einsetze, da habe ich endlich eine Legitimation den unangenehmen Gesprächen aus dem Weg zu gehen, die mich Nerven und Zeit kosten. Aber auch da entsteht ja ein gewisser Wert oder eine gewisse Magic da drin. Ich verstehe was nun mal hin, ich glaube auch, dass das so ist, dass das im Bezogen auf wie schnell kann man vorwärts kommen und selber Sachen verändern und Missverständnisse vermeiden richtig ist. Aber in vielen Umgebungen, in denen wir unterwegs sind, glaube ich, brauche es vielleicht auch diese Missverständnisse um gemeinsam Sachen nochmal anders geklärt zu haben. Und so ein bisschen hast du das ja auch gerade zum Beispiel auf Bezogen auf technische Qualität auch formuliert, ne? Du kannst gar nicht bewerten, ob das was rauskommt, vielleicht gewissen Standards oder gewissen Dingen entspricht, so das, was hinterher weiterentwickelt werden kann, darauf aufgebaut werden kann, ist es so belastbar, dass das Ganze auch noch in einem halben Jahr irgendwie funktioniert und da sind natürlich durchaus auch eine ganze Reihe gefahren, halt mit drin, ne? Ja, ja, fahren Sie mal viel weiter bei, aber ich schiebe man aber weg weiter dahin. Also bleiben wir mal nur rein in der Delivery, also rein in der technischen Entwicklung und dein Hinweis auf Agilismanifest, Individu und Interaktion sind uns wichtiger als Prozess und Werkzeuge, habe ich dabei im Hinterkopf. Es geht jetzt nicht nur um das Werkzeug, der karibasierten Entwicklungstuls an sich, sondern was für, ja, was für eine Interaktion und Feedback bekommen. Ich so jetzt aus meiner Erfahrung nicht alle Architekten und Architekten, mit denen ich zusammengearbeitet habe, haben mir einen entsprechenden gutes Feedback geben können. Alleine vielleicht hatten Sie das wissen, aber Sie haben Ihre PS nicht auf die Straße gebracht, 0.1, plus 1, 0.2. Ja, so, ich habe aktuell das Gefühl mit den aller neuesten Modellen, jetzt jetzt hier gerade Sorichtungen, Claude und Ananzer Claude und den großen ganz frischen Modellen, also das entwickelt sich ja rasen weiter, dass da so viel Wissen drin steckt, also ich mein persönlich, mein persönlicher Eindruck ist, dass da auch nicht mehr viel Halluzination, in der in dem Sinne drin steckt, wie wir alle, seit drei Jahren eben auf Judgey-Pity oder so gucken, sondern daßes Aussage wäre, oder meine Tese aktuell, ich glaube, ich kann mir da sogar mehr und besseres Architektur wissen und Claincord-Wissen zum Beispiel reinholen über dieses Systeme, als mir viele im Haus, im Team zur Verfügung stehenden Software-Engineering-Experten bieten können, da magst sicherlich Ausnahmen geben, keine Frage, aber hey, ich habe auch wirklich schon mit vielen nicht so erfahren Software-Engineers zusammengearbeitet und da habe ich den Eindruck, dass mir dieses Systeme hier mehr bieten, also konkretes Beispiel, ich habe schön was gebaut und nach zwei Tagen habe ich dem System dann einfach mal gesagt, hey, überprüft ich mal bitte selber, wo siehst du noch Probleme, Fehler, Errors oder Sachen, die nicht so gut uns selber programmiert sind und da kam eine lange Liste raus, wo das System sich selber quasi kritisiert hat und dann zwar, ja, soll ich das verbessern, kommt ja die Frage schon, ja, mach so und dann wird das verändert, ob das und das ist der Punkt, den ich nicht richtig einschätzen kann, ob das die richtigen Findings waren, der KI, das weiß ich nicht, da brauchst du jetzt den Buddy an meiner Seite, aber um das schnell, ich glaube, dass man da mit auf einem sehr hoßen Niveau kommt, das ist mal eine momentane Sicht, auf der Achtung Delivery-Seite, wo ich ganz andere Schmerzen habe, ist eben auf der Discovery-Seite. Aber bleiben wir noch ganz kurz bei der Delivery, weil das klingt so, als ob du mehr Verständnis und Empathie für die developer entwickelt? Ja, also alleine, wenn ich sowas wie Kurser jetzt als Beispiel oder Cloth Code, wenn ich dazu gucke, wie du kannst ja dann sehen, wie der Code entsteht oder auch wie der Code verändert wird oder wie der Fehler findet. Das ist im realen Prozess, wenn du diese Fehler finden musst, wenn du diesen Code wirklich tippen musst, brutal auffindig. Also ich hatte jetzt, weil ich ein Beispiel, was ich gerade hatte, hatte Motophäle findet, finde Fehler, war eine Situation, das war einem anderen Punkt, da baute das System nicht mehr, kompallte nicht richtig und hatte ein paar Singfehler. Und ich hätte es persönlich nie gefunden, das Problem war, dass das Anführungszeichen oder das Apostroff irgendwie, ich weiß nicht mehr, ob es ein typografisches oder ein anderes war. Also dieses Hochkommann gibt es ja auf verschiedene Arten. Und das war der Fehler, weshalb es zu einem paar Singfehler kam, ganz ehrlich, den Backt muss ein Entwickler erst mal finden. Das war hier mit dem System eine Sache von, ja, unter einer Minute. Und dann war es Systemweit ausgemärzt, das Problem. Aber ich bin beide. Die Probleme und Schmerzen von Devs verstehe ich glaube ich, oder ich weiß nicht, ob sie verstehe, aber ich bekomme immer mehr Empathie dafür und auch nach 5,5 Jahren habe ich viele Empathie auch vorher schon dafür gehabt. Dann lass uns mal einen Schritt weiter gehen. Wir haben zwar auch immer zwischendurch schon so ein paar Nachteile, wenn ich als PO mit Webcoating selber entwickel mit einfließen lassen, aber vielleicht können wir sie hier an der Stelle noch mal kurz zusammenfassen und vielleicht noch mal aus einer anderen Perspektive beleuchten und auch kommentieren. Wenn ich darf, fange ich einfach mal an. Du hast ja gesagt, du triffst deine Produkteentscheidung selber und kannst sie dann selber umsetzen. Und natürlich sind wir bei ganz vielen Produkteentscheidungen vor allen Dingen, wenn sie nicht auf Basis von Daten und Fakten, du hast schon gesagt, vielleicht kommt auch so was wie Discovery zu Kurz oder Hypothesen, Validieren oder rausfinden, ob das jetzt wirklich gebraucht ist. Bin ich gebeist selber. Auch dazu haben wir ja schon an der einen oder anderen Stelle hier in dem Podcast gesprochen, dass wir gewisse kognitive Verzerrung selber bei uns haben und dass das ja auch nicht unbedingt gute Produkteentscheidung zum Teil sein müssen, die wir da so haben. Und was mir sofort natürlich für ein Bayes einfällt ist, wenn du das jetzt auch noch alles selber mit Vibecoating entwickelt, hast du halt den IKEA-Effekt, also alles, was ich hier selber mache, ist halt viel wertvoller als das, was irgendjemand anderes irgendwie gemacht hat. Also ich sehe schon, wenn ich also auch in die Rolle des Entwicklers des Developers gehe und auch gleichzeitig Produkt ohne bin, dass ich da durchaus mir dieser Bayes des Bewusstsein muss und gucken muss, wie ich damit umgehe, damit ich nicht denke, ich mache das tolls so und das habe ich halt alles selber gemacht und deswegen muss das auch alles besonders gut sein und dort einfach auch bessere Produkteentscheidung treffen können. Ja, vielleicht kann man also direkt schon mal eine Idee an der Stelle, vielleicht kann man sich ein weiteres paralleles System auch aufsetzen, was an die ganze Zeit so kritischen Fragen stellt oder mich selber auch dann während des Wahlcoatings dran erinnert, hey, zeig mir das nochmal, oder hey, hast du daran gedacht, daran gedacht, trotzdem koche ich weiter natürlich ein bisschen im eigenen Saft, aber so eine Reflexionsschicht wäre auf jeden Fall da nochmal hilfreich. Und ich muss dann aufpassen, zumindest je nachdem, wo ich mir das Feedbackherbesorge, dass ich nicht mit den Systemen, mit denen ich arbeite, dauert auch die Bestätigung und gesagt, kriege, wo alles toll, was du da machst, weil da tendierten ja bestimmte Systeme zumindest in meiner Welt, wenn ich nicht dagegen arbeite, auch eine Zeit lang irgendwie zu, wer ich wieder ganz klar in Richtung confirmation war, ist unterwegs, ne? Also ich krieg das sogar auch noch positiv zurück gespielt. Also ich glaube, ich müsste mir auch da explizit kritisches Feedback einfordern und auch bestimmte Dinge so aufsetzen, dass ich das kritische Feedback auch bekomme. Genau, wen frage ich, dem zeige ich das und natürlich richtig rauszugehen, mit potenziellen Nutzerinnen und Nutzern zu sprechen, zu sprechen oder den meine Zwischenergebnis zu zeigen, das hält enorm auf. Das kost Zeit. Und ja, was kann ich stattdessen machen? Ich kann so sagen, ne, Mum testmäßig meiner Mutter zeigen oder dir als Kollegen oder meiner Freundin und alle sagen, ja, nee, das ist doch ganz cool oder da haste daran gedacht, daran gedacht und da hast du alle Beistes dieser Welt, das was uns vielleicht weniger erwischt oder das muss man vielleicht dann lernen, ist dieser, wie heißt es, das ist ein Kostbeis oder wie heißt, ich weiß nicht genau. Das ist los, los, los, los. Also was ist diese Flugzeuge nur untersucht hat, die noch gesund war, das ist der Survival. Ach, das ist der Survival, das ist noch die Ankoko, die zurückkommen. Ich meine, was meine ist mit dem Taxifahren, dass die den Verlust höher bewerten als den Gewinn, den ich kriegen kann, meintest du das? Das ist dieser Lost Awareness. Nee, ich weiß nicht, ich meinte, dass ich in der klassischen Entwicklung natürlich viel mehr Zeit und Ressourcen reinstecke und dann das Gefühl habe, das haben wir jetzt schon alles gebaut und typisches Konzernen, da haben wir jetzt schon so viel reingesteckt und das Projekt und das vorhaben, das jetzt zu stoppen, nee, komm, lass uns doch lieber das weiter bauen. Ah, okay. Ich muss auch nochmal nachgucken, wie dieser Explicit sieht, bei es heißt. Aber auf jeden Fall, ich glaube, das pack ich mir auch die eigene Nase, was man halt lernen muss, ist wegwerfen können, also dieses sich gut fühlen beim wegwerfen von dem, was man schon gebaut hat, den eigenen Entwickler stolz, oder wie nennen wir das so, die Bergstolz ein Stück weit zu überwinden und zu sagen, ja, das habe ich gestern entwickelt, so was, wirklich heute halt, was neu ist, fangen wieder von vorne an. Ich glaube, das ist sehr stark bislang sonst so in uns drin. Ja, aber ich finde es ganz spannend, weil wir verangementieren ja jetzt gerade, wenn ich das Tour selber mit Weibkoding entwickeln, dass es super schnell geht, dann ist es ja auch eigentlich nicht schlimm, den einen Tag wieder wegzuschmeißen, weil ich muss nicht wieder vier Wochen warten, wenn ich in was auch immer für eine Mechanismus mit externen Developern unterwegs bin, sondern ich krieg's vielleicht auch wieder in einem Tag. Also eigentlich wäre es ja sogar ein Argument dafür, mir noch mehr Nutzer Feedback zu holen und in noch kürzeren Zyklen, weil ich in der Lage bin, auch ganz schnell darauf zu reagieren. Ich finde es aber spannend aus deiner Beobachtung heraus, dass das natürlich unglaublich schwerfällt, aber eigentlich ist das ja nur eine Bestätigung von, wenn ich das vorher nicht gewohnt bin oder zu einer Gewohnheit gemacht habe, dass mir dann auch alles, was so in die Richtung AI-Unterstützung, was auch immer geht, eher in eine Tendenz haben könnte, dass sich das vielleicht auch nochmal verdoppelt, verdreifacht potenziert und ich die schlimm Dinge in Anführungsstrichen nur noch mehr mache oder noch eher in solche Fallen halt reinlaufe. Ja, also das ist sicherlich extrem, aber das ist das, was ich momentan merke, was ich noch so ein bisschen entlernen muss als Habit. Ich glaube, dass es vielen so geht, weil du bist so drin, vielleicht bist du auch in einem Flow, das war gar nicht so negativ gemein, aber ich muss mehr genauso wie die Beist ist bei der Produkteentscheidung, glaube ich muss mir die Dinge bewusst machen und auch die Zeit dafür nehmen und auch sagen, ich tue das jetzt, auch wenn es sich vielleicht nicht so gut anfühlt oder ich denke ich könnte ja auch einfach weiterarbeiten. Lass uns nochmal so ein bisschen Strukturiter in den Bereich der Nachteile reingucken, also ein Thema, was mich gerade wirklich umtreibt ist, mein Gedanke, was ist mit unseren vier großen Produktrisiken, oder Big Risks. Zum Produktrisiken haben wir auch schon mal eine Folge gemacht, die kann man normal verlinken, es geht also um user-bill-risk, weil you-bill-risk, feasible-risk und business-bill-risk und ich glaube, dass feasibility-risk, also das machbarkeitsrisiko, das wird gerade deutlich geringer, weil alles so schnell und machbar und einfach erscheint, aber was ich fürchte, was gerade vernachlässigt wird, ist eben, dass, mindestens man das valuable risk, vielleicht auch das user-bill-risk, bleiben wir mal bei valuable, also hat das, was ich bau, löst das wirklich ein Problem, oder glaube ich nur in meiner Annahme, dass es ein Problem löst, das sind wir genau bei diesen fehlenden User Feedback, bei Überprüfung meiner Annahmen und Hypotesen und da bist du in dem ganzen Bereich drin mit Opportunity solution-trees und so weiter, Jobs to be dann, nie man eigentlich machen sollte, was ich aber so gut wie gar nicht erlebe in dem Webcoding, also jetzt hier in dem Close oder in dieser cohort hier mit Bensofjan, die fängt das tatsächlich beim Anersdancher Problem an, das finde ich erst mal gut, oder da Challenge your idea, aber das ist ein kleiner Part von sehr, sehr vielen und ja, es ist schon richtig, das fängt mit Problemstatement an, mit dem Solutionsstatement, mit der Reflexion der Zielgruppe und Personas, aber ich glaube da brauchts noch mehr und eine begleitende und ständige Reflexion dessen, ob das was ich hier bau, wirklich ein echtes Problem löst. Aber ich glaube da wird sich auch so ein bisschen die Spräu vom Weizen trennen, ob denn jetzt der Einsatz von Webcoding auch als Primarklooner mich noch mehr in das Reine Delivery treibt, also so genau so wie du hast gesagt hast, oder ob ich genug verstanden habe, wie Produktentwicklungen funktioniert, dass ich auch im Richtung Product Discovery ein Fokus setzen muss. Und meine naive Hoffnung ist ja immer noch, dass wir auch dazu beitragen, dass alles, was mit Identifizierung dieser vier großen Produktrisiken und wie ich das angehe und wie ich versuche, auch bestimmter Annahmen und Risiken zu validieren, zu falsifizieren, um bessere Produktentscheidungen zu treffen, dass das auch noch ein größeres Gewicht gewinnt über die Zeit, aber ich sehe, was du sagst, dass man natürlich sehr schnell auch in sich in die Richtung entwickeln kann, das wieder wegzuwischen, weil eigentlich brauchen wir es ja nur bauen, und das geht jetzt alles ganz schnell und warum wir vorher Zeit investieren, die nichts mit bauen und entwickeln, das Produkt das eigentlich an sich zu tun hat. Ja und das dann sind wir direkt bei einem Weibel-Risk, das passt jetzt genau zu der Folge, die wir gerade hatten mit Simoneta Bateiger. Was sind denn die realen Kosten und der Return on the West von solchen Kainiziativen? Ich glaube momentan sind wir sicherlich noch in dem Bereich, wo ja relativ blind und euphorisch auch in Companies gespendet wird, nach dem Auto mach irgendwas mit AI und wir müssen das machen und so weiter. Ich würde mal ein bisschen was drauf wetten, dass es mindestens im Laufe dieses Jahres jetzt mehr und mehr dazukommt, dass die Wirtschaftlichkeit von diesen AI-Sachen da fragt hat. Und das ist sicherlich, abcoding zum Beispiel in Vergleich zu den ganzen Entwicklungsresourcen, die man uns einsetzen müsste, kann ich ganz schön viele andere AI-Kosten, wie in der letzten Folge da beschrieben verbrennt, keine Frage, aber sich überhaupt die Frage zu stellen, während man so in dieser Euphorie, das ist, wir können das bauen, es ist machbar, es ist wohl dann so viel schneller und toller machbar als al die Jahre zuvor. Ja, ich glaube wir es braucht so ein Innerhalten zwischendurch und nochmal zur Reflexion, braucht es das überhaupt, lösen wir das Problem damit überhaupt, wen könnte ich fragen, wer gibt mir Feedback und eben ist es wirtschaftlich an the long run. Es bringt mich zu noch einem weiteren Punkt. Wir hatten ja auch mal eine schöne Folge darüber, wo ich glaube, der hier ist eine Unterscheidung gemacht hat zwischen einem MVP-To-Learn und einem MVP-To-Earn und was mich so ein bisschen umtreibt, ist das natürlich das, was auch wirklich rauskommt, wenn ich anfange zu weibkoden, sich ganz schnell auch schon wie ein Produkt-To-Earn anfühlt und auch aussieht und so, weil ich natürlich auch ganz viele Dinge sehr einfach sehr schnell, wie wir gesagt haben, irgendwie bekomme. Und ich weiß manchmal nicht so wirklich, wenn es da noch andere Menschen, um mich drumherum gibt, die dann vielleicht auch sehen, was da so entwickelt wird, ob wir das gleiche Verständnis davon haben. Also es fühlt sich vielleicht schon nach mehr an, als es in der Realität um wirklich Geld damit zu verdienen und Business zu betreiben, tatsächlich auch in irgendeiner Art und Weise ist und das hat natürlich auch ein bisschen damit zu tun, haben wir eben schon mal diskutiert, welche technische Qualität steckt schon dahinter oder wie belastbar ist das Ganze. Und dafür bin ich zumindest ein falscher Ansprechpartner, das bewerten zu können, aber ich bin viel zu weit weg, du hast sich ein bisschen tiefer mit ein Gegrama, du hast ja auch gesagt, an manchen Stellen kannst du es auch nicht beurteilen. Also wie qualitativ belastbar das Ganze tatsächlich technologisch dann schon ist. Ja, wenn wir über produktive Anwendungen reden, ja, wobei es schon auch kaibasiert, dann sehr, sehr gute Möglichkeiten gibt, dass auch Security Mess ich abzusicher und stabil zu bekommen, etc., also das ist schon krass. Wenn wir über andere webcoating-Formate reden, also eher so diese Tools, wie Loveable, We Zero, Windsurf und so, die also eher so plattgesagt. Fick mal ersetzen, sprich sehr schnell Prototypen entwickeln, das ist auch toll, also damit kann ich als Produktmensch super viel machen, um zum Beispiel mein Verständnis einer Lösung meiner Solutions, meinen Steak Holden zu vermitteln oder auch meinen Entwicklern. Das sind genau über diese Systeme, da bin ich beide, die dann vielleicht den Effekt erzählen. Wow, das ist das läuft ja schon. Sieht ja schon so fertig aus, wie früher so Pixel-Exakte vorlagen oder Pixel-Exakte Entwürfe von der Agentur. Wo man direkt dachte, ja, wunderbar macht das so und so denkst du, erhallo, das ist nur, das sind nur Pixel, das ist noch nicht funktionierendes und entsprechende Klickdamis, da ging man mit Fick mal dann irgendwann auch sehr, sehr viel los in den letzten, die macht ja an, das darf uns nicht darüber hinweg täuschen, was eben noch nicht geht unter der Haube. Auf der anderen Seite gibt das natürlich ein Riesenmärwert, um entsprechende User-Sests drauf zu machen. So, deshalb würde ich momentan unterscheiden, diese Tools, wie Loveable und Co, die wunderbar sind und die Riesenhyp gerade vorrufen. Was die so können und was dann so, die Sachen durch die Cloud Code ermöglichen, das ist ein normaler Unterschied. Also was da alleine in 2025 passiert ist, wow, ich kann es immer wieder betonen, macht euch die Mühe und verfolgt es zumindest am Rande und sagt nicht, da da kümmere ich mich später drum, weil es zumindest brauche ich so ein, finde ich zumindest für mich, so ein Grundrausch, um das, alles und um NLN mit der Automation zum Beispiel auch, um mit Verfolgen zu können, wann ist es wichtig, da wirklich den kompletten Fokus drauf zu legen, sonst ist dazu irgendwann ziemlich weit schon weggefahren. Ich sage nicht abgefahren, aber weggefahren. Jo, auch weil du das gerade mit Loveable meinst und den das eigene Uhr so an den Geschehen ist und zu haben, also ich weiß ja, dass gefühlt 95 Prozent aller POs mit denen ich zusammen arbeite. Zumindest uns irgendwas von Ed Lesson im Einsatz haben, Jira oder wie auch immer. Und auch da gibt's ja glaube ich große Kooperationsbestrebungen, ich mein mit Loveable, wenn ich das noch richtig in meinem Hinterkopf habe, dass halt Dinge, die aus Jira in Anforderungen sind dann irgendwie in Produkte und Software automatisierter zu gießen. Ich will jetzt gar nicht in der Stelle drüber diskutieren, ob ich das gut oder schlecht finde, aber es finden natürlich ganz an ganz vielen Stellen und da bin ich komplett bei dir, dein Appell, den du gerade hattest, zumindest zu verfolgen, was passiert denn da gerade, weil es schon auch meine Rolle, Verantwortlichkeit, Aufgaben als Product-Owner, über Kurze oder lang maßgeblich beeinflussen und verändern wird und ich würde das auch beobachten. Jetzt haben wir viel darüber diskutiert, was vor allen Dingen auch, was deine Erfahrungen waren, auch danke nochmal dafür, dass du hier so offen geteilt hast, in welches Rabbit hole du wo gefallen bist unter ich Erfahrungen, du gemacht hast, aber dafür kennen wir uns ja auch schon mit dem Rabbit und mir das manchmal auch tatsächlich passiert, wenn wir uns für Sachen begeistern können. Vielleicht versuchen wir es aber nochmal ein bisschen nach oben zu heben und ein bisschen abstrakter und allgemeiner zu formulieren, welche Tipps und Tricks würdest du denn mitgeben, wenn ich als PO anfange, auch selber zu Weibkoden und mich ein bisschen intensiver damit zu beschäftigen, auf was sollte ich da achten? Also das eine habe ich ja schon gesagt, überhaupt ein bisschen am Ball zu bleiben, aber auf der anderen Seite eben auch nicht schlecht zu machen und zu geisteln, wenn man noch nicht mit Görnerklautkurt und so unterwegs ist, also bleibt zumindest am Ball lest die entscheidenden Newsletter oder hört so das Rauschen, man muss auch nicht in jedes neue Tool dann verfolgen, aber so ein paar, also man sollte zumindest mitkriegen, welche Trends so gerade da sind und welche Sachen ein bisschen länger bleiben und mal abgesehen davon ist mein Eindruck, wenn man denn dann einsteigt, dass man sich ja klar machen muss, ob will ich nur Prototypen bauen, also was heißt nur, brauche ich Prototypen, um vielleicht entsprechend Feedback zu Öklen zu unterstützen oder habe ich wirklich die Chance, ein neues produktives System zu bauen oder drittens, aber arbeite ich an bereits bestehenden produktiven System mit AI um dort zu verbessern, Softwaremigration zu machen oder oder und das sind glaube ich schon unterschiedliche Sachen, noch mal was ganz anderes ist, das ist ja das, wo du das Live-Event jetzt gerade auch letztens erst so hattest, ist wie kann mich KI in meiner Rolle und Verantwortung als Produkt auch noch unterstützen, also mehr so im Entwicklungsprozess, das ist auch ganz viel mit KI möglich. Wir sind ja heute die ganze Zeit nur unterwegs auf der Frage wirklich mit KI oder mit AI unterstützen Sachen etwas zu bauen, also wirklich im Ein Produkt zu bauen. Das muss mir erst mal klar sein, was will ich hier, will ich an nur rum spielen, so ganz am Anfang und irgendwie die Systeme ein bisschen zu verstehen, auch total wichtig, will ich Prototypen bauen, um es in die Kommunikation einfließen zu lassen, will ich wirklich echte interne oder sogar externutzbare Systeme bauen. Das bedeutet dann im Endeffekt tatsächlich auch, wo hab ich gefühlt das Verbesserungspotenzial, was ich sehe oder schmerzen, die ich versuche mit dem Einsatz solcher Systeme vielleicht zu lindern und zu minimieren. Also es kann ja durchaus schnellere Delivery sein, also ich will das auch gar nicht wegdiskutieren, auch wenn ich eben so ein bisschen kritischer an der einen oder anderen Stelle auch unterwegs war. Ich halte immer noch so ein bisschen das Fähnchen hoch, vielleicht mehr Sachen zu machen, die dazu führen, dass ich bessere Produktentscheidungen treffen kann im Sinne meines Verständnis als Projekt. Aber das muss ja nicht in jedem Kontext tatsächlich auch das primäre Problem sein. Also ich kann ja durchaus auch eher bei einer Aufgabe auf der Seite der Delivery haben und durch solche Tools da mir ja auch einen gewissen Vorteil noch mal erzielen oder eine Hoffnung haben, dass sich das dann da verbessert. Aber ich bin völlig bei dir, ich glaube, brauche glaube ich selber eine Klarheit, wo ist denn jetzt hier der Schmerz oder das größte Potenzial, was ich verbessern will, um dann Ziel gerichtet, mich auf dem Weg zu machen und ich beobachte leider aktuell auch noch so ein bisschen, dass noch viel experimentiert wird, ohne und ausprobiert wird, ohne eine Klarheit zu haben. Was will ich denn eigentlich? Ich würde das normalen weiterer Tipp oder dass ich würde es beides verbinden. Ich finde, dass die Delivery künftig kein Problem mehr sein wird. Jetzt man sehr, sehr platt formuliert, aber das Delivery so ultra schnell wird, das sehe ich erstmals Vorteil. Wenn wir darauf achten, bestimmte, ja, Discovery Sachen trotzdem noch zu tun. Darum geht es mir. Ich bin ja gar nicht das aufhalten, dass es so schnell wird in der Entwicklung. Ich will nur sagen, oder sehe jetzt hier mein Tipp, haltet euch immer selber den Spiegel vor, ob wir genug Problem an das Standing haben. Verstehen wir das Problem gut genug. Wir sehen unsere Annahmen aus. Haben wir vorher eine Hypothese vielleicht aufgestellt, bevor wir anfangen zu deliveren. Also das, das kann sein halben Podcast hier von uns die letzten sechs Jahre hören, ne? Also alles rund um Jobs to be done. Opportunity solution tree is function mapping, personas, user research. Die ganze Flöte ist doch weiterhin noch relevant und wird vielleicht noch relevant her, um eben nicht von dem Speed der Delivery komplett ausgefressen zu werden. Wobei, also das miteinander zu verbinden, leuchtet mir ein, gehe ich auch mit, ne? Also es sind natürlich zwei Seiten der gleichen Medaille oder der gleichen Münze, völlig d'accord. Ich sehe halt ein bisschen die Gefahr und das würde ich auch noch als Tipp mitnehmen, dass wenn ich halt vor allen Dingen auf der Delivery Seite jetzt viel, viel, viel schneller werde, zumindest ist es so erscheint, dass ich viel, viel schneller werde, dass es trotzdem noch eine ganze Menge Organisation gibt, die dann denken, dass sie, wenn sie noch zehnmal schneller werden, schon die eine oder die zwei richtigen Dingefeatures in meinem Produkt mit dabei sind und dass ich deswegen erfolgreich werde. Irgendwo habe ich neu gelesen, also unser Problem in der Produkteentwicklung aktuell ist, glaube ich, viel weniger Effizienz der Entwicklung, auch wenn ich die an vielen Stellen trotzdem sehe, in alt eingesessenen Unternehmen und Organisationen oder in alten komischen Produkten, die keiner mehr irgendwie überblickt. Aber ich würde schon auch versuchen, und das wäre so ein bisschen mein letzter Tipp, den ich mitgeben würde, zu gucken, welche Art von Erwartungshaltung ich gegenüber dem Management durch diese vorgehendsweise selber zu Weibkoden und schnell vorwärts zu kommen, irgendwie Erzeuge. Und vielleicht bin ich auch immer noch ein bisschen zu sehr alarmiert, von Jeff Sutherland und seinem Buch Twice the Work in Half the Time, die aus meiner Sicht ein völlig falsches Framing zumindest mit dem Titel gemacht hat als das, worum es geht. Es ging gar nicht darum, viermal so schnell zu werden, sondern eigentlich ging es darum, in einem bestimmten Kontext zumindest in meiner Welt bessere Produktentscheidung zu treffen. Und das wird jetzt eher potenziert, oder die Gefahr ist, dass es eher potenziert wird. Und ich würde gucken, welche Erwartungshaltung auf einmal auf Seiten von Unternehmensführungen und Management entsteht, wenn ich das Spiel in der gewissen Art und Weise spiele oder in der gewissen Art und Weise halt vorwärts laufen. Ich glaube ganz bestimmt, dass wir sowas wie eine bis zu zehnfach schnellere Delivery hinkriegen. Das wäre meine Antwort jetzt hier so auch an die Management Ebene. Kannst da haben, alles zehnmal schneller. Die Frage ist entwickeln wir das Richtige, lösen wir die richtigen Probleme. Und das trifft natürlich dann gerade auf Organisationen, die auch heute vielleicht in die letzten Jahre nur geschrieben haben, wir müssen Ajay machen, damit wir schneller werden. Was für Bullshit, da es ging nie um Effizienz, sondern Effektivität. Genau. Und weil wir das Agile manifest und die Prinzipien hier schon mehrfach zitiert haben, noch von mir als allerletztes, vielleicht hast du dann auch noch ein Tipp. Ich mag ja am liebsten die Menge, der nicht getanen Arbeit ist, zu maximieren. Also, dass wir uns ganz viel Zeit nehmen und Zeit auch reinstecken zu gucken, was ist das eine richtige, was den größten Wert generiert und hebel hat. Und ich wollte damit ja nur sagen, dass es eine Risiko gibt, dass sich ein Verständnis in Organisationen dann in eine falsche Richtung wieder entwickeln kann. Und wir waren auch in der Vergangenheit nie da. Also zu sagen, lass uns über 80 Prozent nachdenken und das eine identifizieren, um dann genau das zu bauen mit einer ausreichenden Sicherheit. Aber ist vielleicht auch, könnte man eine eigene Folge drüber machen, glaube ich, noch mal. Ist sehr cool, hab ich schon gerade gedacht. Also, mein Hirn hat gerade sofort angefangen zu rattern, mega geil. Also zu sagen, okay, lass uns normal das Agile Prinzip maximiere, die Summe der nicht getanen, arbeiten nehmen und das auf den Gedanken oder auf die Beobachtung von Bobcoating und Co. drauf zu legen. Uu, da kann man, kann man noch mehr draus machen. Aber ich wollte, genau, ich würde gerne noch was ganz praktisches einwerfen, bevor ich hier eben so stark in Emotionen unterwegs war. Ich hab ja im Laufe der Folge schon mal auf diesen Bilder Codex hingewiesen und jetzt auf mehrfach natürlich den Namen von Bensofiani schon genannt. Ich pack dir link mal in die Show notes ansonsten, PirateSkills.com/build/codex. Was das ist, das ist eine Anleitung, eine Schritt für Schritt Anleitung und ich finde, also kostenfrei und richtig gut gemacht, wie man in dieses Wahlbcoating Thema reinkommt und das ist, ich hab mich, als ich das dann selber auch gemacht hab, okay, ich hatte noch ein paar begleitende Videos und Sessions und so dazu, weil ich in diesem Bezahltprogramm bin. Aber man kann sich hinsetzen und Schritt für Schritt, dass durchgehen und jetzt mit, an Beispiel Körser und GitHub und Diploment of Versel, das wirklich durchspielen mit allen Security-Fragestellungen und so. Das sind, ich weiß gar nicht mehr auswendig, wie viele, ich glaube, sechs, Level und dann jeweils sechs, also irgendwie so 35 bis 40 Schritte, die Pöer-Pö beschrieben sind und wo auch direkt Promp-Beispiele drin sind, die ich dann diesen System wie Körser und Co. geben muss, damit es das für mich macht und das super cool, also wirklich total wertvoll wäre, Lust hat sich da rein zu arbeiten, kann damit starten. Ja, ansonsten guckt nochmal in die alte Folge mit Ben Sofiane, der war ja auch sogar noch ein Discount-Code drin, den er uns gegeben hat, ich glaube, der ist immer noch gültig, schätze ich mal, ansonsten schreibt uns an, wenn ihr an dem kommunizellen Ding da, heißt nicht mehr "Seo to SARS", es heißt ja jetzt "Builder Forge", teilnehmen wollte. Ein paar tatsächlich sind, das habe ich da wieder getroffen aus unserem Podcast, also von daher danke an die, die das hier gehört haben und unserer unserer Empfehlung befolgt sind. Sehr cool, dann vielen Dank, dass du auch so persönlicher Erfahrung mit Weibkoding und was dir so passiert ist mit uns geteilt haste. Ich hoffe ihr konnte den ein oder anderen Impuls aus dieser Folge mitnehmen und ich bin gespannt, was für Feedback ihr habt, wie immer gerne auch unter dem Link-In-Artikel zu dieser Folge oder auf unserer Website der Produktverkarte.de, freuen wir uns immer sehr drauf und wenn ihr sonstige Fragen habt, schreibt uns auch einfach gerne. Das Thema wird uns glaube ich auch im Jahr 2026 noch weiter beschäftigen. Dank dir Tim. Dank dir Oli. Ich musste direkt hier wieder an meine Kommando-Zeile an meinen Terminals. Na ja, dann kommen wir nicht. Schnell, schnell, schnell, schnell. Ich kann auch mal bauen heute. Genau, viel Spaß und nehm ein paar Bause mit und schreibt vielleicht auch einfach mal unter unseren Link-In-Post oder unter unseren Blog-Post auf der Website, was eure Erfahrungen so damit sind und wie ihr vor allem, was wir ihr für Tipps habt, wie ihr dieses Thema Problem verständnis und Discovery in dieser achso schnelle Delivery dann integriert noch eine Sache, bevor wir uns von euch verabschieden. Ihr habt uns in diesem Podcast kennengelernt und vielleicht habt ihr gemerkt, dass wir eine Leidenschaft für das Teilen von Wissen und Geschichten haben. Aber wusstet ihr schon, dass wir nicht nur Podcastgastgeber sind, sondern auch als Speaker für Events zur Verfügung stehen? Wir sind begeistert, unser Wissen und unsere Leidenschaft für die Produktentwicklung mit euch zu teilen. Wenn ihr also auf der Suchen nach fesselnden Rednern für eure Veranstaltungen seid, sei es Konferenzen, Meetups oder Firmen-Events, dann denkt direkt gerne an uns. Wir freuen uns darauf, eure Veranstaltung mit frischen Ideen und einem Interaktiven Ansatz zu bereichern. Schreibt uns einfach eine E-Mail an [email protected] oder vereinbart einen Telefontermin unter Produktwerker.de.