Vibe-Coding, AI-Programmierung, No-Code, Low-Code? …Und Produktarbeit? Hendrik Hemken zu Gast (CPO @ DealCircle, ex SMAVA / Finanzcheck, ex GoodGame)

Wie aktuelle Prototyping Methoden 360° Product Management ermöglichen.

„Vibe Coding“ ist das Meme du Jour [Exhibit 1] der digitalen Szene. Doch bei allen Lachern wäre es ein Fehler, wenn sich ProduktmanagerInnen nicht ernsthaft damit auseinandersetzen würden – denn die Chancen, die in AI-Code, Low-Code und No-Code stecken, sind enorm! ...Und das potenzial unsere Arbeitsweisen nachhaltig zu verändern ist es ebenso.

Die Erfahrung, dass die heutigen Möglichkeiten der schnellen Prototypisierung kein Hype, sondern echte Gamechanger für Produktarbeit und Softwareentwicklung sind, hat mein heutiger Gast Hendrik Hemken selbst gemacht.

In seiner aktuellen Rolle als Chief Product Officer bei DealCircle kommen all diese Technologien produktiv zum Einsatz. Wie sie Produktmenschen die Chance eröffnen, echtes 360°-Produktmanagement zu betreiben – und wie klassische Engineering-Arbeit im operativen Alltag sinnvoll mit „vibe-codenden“ ProduktmanagerInnen zusammenspielt – das erklärt Hendrik in dieser Folge.

Hört in die sechste PRODUKTKRAFT-Podcast-Folge rein, um mehr darüber zu erfahren – und warum auch ihr jetzt mit Vibe-Coding und No-Code-Prototyping starten solltet!

Product Support Needed?

Du brauchst freiberufliche Hilfe im Produktmanagement? Egal ob Coaching, operativer Support, interimistische Product Leadership oder Consulting: Melde Dich gerne unverbindlich unter jan@produktkraft.com bei mir und wir besprechen, wie eine Zusammenarbeit aussehen könnte.

Credits

Host & Producer: Jan Hoppe - https://www.linkedin.com/in/jan-hoppe-30b38ba3/ - http://www.produktkraft.com

Gast: Hendrik Hemken - https://www.linkedin.com/in/hendrikhemken/

Audio Engineering: Tim Nippert - https://www.linkedin.com/in/tim-nprt-69a377286/

Links

• https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/

• https://lovable.dev

• https://bubble.io

• https://www.airtable.com

• https://www.notion.so

• https://elementor.com

• https://www.cursor.com

• https://replit.com

• https://www.clay.com

• https://www.xano.com

• https://www.weweb.io

• https://www.softr.io

Transkript (Auto Generated)

Jan: Moin Moin, du hörst den Produktkraft Podcast, in dem ich, Jan Hoppe, mit verschiedenen Gästen über die vielen Aspekte des digitalen Produktmanagements in Deutschland, Österreich und der Schweiz spreche. Unser heutiger Gast ist Hendrik Hemken. Hendrik blickt auf eine 12-jährige Karriere im digitalen Produktmanagement zurück, die bei GoodGame Studios begann, die ihn für eine Weile bei StarFinance, Finanzcheck und Only in die Fintech-Szene bewegt hat, bevor er nun als Chief Product Officer bei DealCircle arbeitet. Ich bin auf Hendrik als potenziellen Podcastgast aufmerksam geworden, als er vor einigen Wochen beim von Rainer Gibbard organisierten Product Leader Stammtisch in Hamburg einen spannenden Vortrag darüber gehalten hat, wie AI, Low-Code und No-Code-Tools die Möglichkeiten eröffnen, ein wahrer 360° Produktmanager zu sein. Was sich hinter diesem Begriff verbirgt, welche Rolle Vibe-Programming bzw. AI-Coding oder Prompt-Coding schon heute in der Start-up-Praxis spielt und wie die Entwicklung von AI-entwickelten MVPs mit konventionellen Engineering-Teams einhergeht, besprechen wir heute. Eine Anmerkung vorweg erlaube ich mir noch. Wenn dir die Folge gefällt, dann freue ich mich sehr über das Teilen, Abonnieren und gute Bewertung. Nun aber los. Moin Hendrik, schön, dass du da bist.

Hendrik: Grüß dich Jan, danke für die Einladung.

Jan: Ja, sehr gerne. Bevor wir in unser eigentliches Thema von heute springen, möchte ich natürlich wie immer der Tradition nachkommen, dass ich einmal die Product Journey unseres Gastes nachvollziehe. Und deswegen beginnt meine Frage, wie immer, oder unser Podcast heute, wie immer damit, dass ich dich einmal frage, wie bist du eigentlich ursprünglich mal ins Produktmanagement gekommen?

Hendrik: Gute Frage. Ich glaube, das ist bei jedem. Jeder hat so seine Journey, die selten gleich ist, selten ähnlich ist. Bei mir hat es damals mit GoodGames begonnen. Und gar nicht sofort mit dem Produktjob. GoodGame Studios ist für alle, die es nicht wissen, eine große Spielefirma in Hamburg, die früher mal noch sehr viel größer war. Und ich bin da eingestiegen 2013, weil mein Bruder zu der Zeit da schon gearbeitet hat und ich zu den Plus-1-Partys mitgekommen bin. Und da kannte ich die ganzen Leute von den Partys. Das war irre.

Jan: Da wurden auch recht viele Partys gefeiert damals, oder?

Hendrik: Es war großartig. Es war eine richtig großartige Zeit. Eine Menge Bubenzeit, Mobile-First, Gaming, alles noch sehr neu. Und habe dann irgendwann einen von der Party angerufen, also einen, den ich da auf einer Party kennengelernt habe, und gesagt, du hast ja nicht Verwendung für jemanden wie mich, der damals, ich war in so einem Trainee-Programm im Großhandel, in Kiel damals noch, Großhandel Logistik. Und habe dann angefangen, die Payment-Verhandlung zu führen mit PayPal und Co., weil der Kollege den Payment-Shop geleitet hat. Der ist heutzutage übrigens CEO von Good Games, die gibt es immer noch, und er hat das dann übernommen. Und habe von da aus, nach dem Payment-Shop, bin ich über eine Finanzrolle dazwischen in die Monetarisierung und da in eine Art Produktmanagement reingelaufen. Da haben wir die Ingame-Advertisement gemacht und habe das im Grunde als Produktmanager nicht für ein Produkt, sondern für eine Monetarisierungsart übernommen und das quasi in die Produkte getragen. Ohne dass ich es wusste, war ich der Produktmanager und habe mich selber nicht als Produktmanager gesehen, weil das waren eigentlich die, die die Spiele gemanagt haben. Aber im Nachhinein kann ich sagen, ich habe da tatsächlich die Produktmanagement gemacht, Businesspläne, User-Interviews und so weiter und dann überlegt, wie es am besten funktioniert. Und bin nach GoodGames dann auch in den anderen Fintech-Firmen danach. Nach dem Gaming war es dann eher das ehrbare Business in Fintech-Läden und Banking-Apps. Und bin da eingestiegen. Und mein Einstieg war tatsächlich bei der Star-Finanz als ersten Produktmanager oder Product-Owner-Job damals noch. Da habe ich davor, ich habe ein halbes Jahr erzwungen, dass ich zur Bettecke gemacht habe, nach den GoodGame-Layoffs und habe aber sechs Monate...

Jan: Hast du damals leider betroffen.

Hendrik: Ja, ich weiß nicht, ob es so negativ war. Also im Grunde, natürlich wäre es schön, wenn es weitergegangen wäre, aber für mich hat es auch noch mal einige Dinge klar gemacht. Und davor war ich nicht im Produktmanagement, danach schon. Und was ich gemacht habe, diese sechs Monate waren halt unglaublich cool. Ich bin ins Programmieren eingestiegen, also klingt jetzt mehr als es gewesen ist. Ich habe ein bisschen Python programmiert, nebenbei Mr. Robot geguckt und habe wirklich von sechs Monate lang ganz viel gebastelt und einen ersten Scraper für meine Banking-App oder für meinen Online-Banking gemacht und danach im Bewerbungsgespräch mit der Staffin und im Grunde mit dem Kollegen darüber philosophiert, wie man aus Verwendungszwecken irgendwelche Learnings ableiten kann, also Verwendungszwecke von Transaktionen im Online-Banking. Und das war so ein bisschen die... Also die Product Journey ist im Grunde nicht bewusst gewesen. Und danach tue ich... Ich habe mal was gebastelt und dann im Gespräch genau diese Knöpfe gedrückt. Nicht, wie ich jetzt die besten KPIs misse, sondern dass ich das, was ich dann bei der Staffin ans managen sollte, dass ich damit bastle, da Bock drauf habe und damit schon mal gearbeitet habe. Also das war eher die Journey.

Jan: Total spannend, also da werden wir ja gleich noch dann fast nochmal eine Brücke zu unserem eigentlichen Thema heute haben, wenn du damals auch schon so Hands-on-die-Dinge gebaut hast. Ja, Staffinans, du warst danach noch ein bisschen länger im Fintech unterwegs. Was ist dann passiert?

Hendrik: Genau, nach der Staffinans hatte ich ein, oder bin ich zu jetzt Smava, damals noch Financheque gewechselt. Das war ein kurzes Intermezzo. Es war eine super interessante Zeit, auch weil die komplett anders gearbeitet haben. Da ging es ganz viel um Organisation und Zusammenarbeit an einem Produkt, an einem großen Produkt mit verschiedenen Produktmanagern. Da haben wir ganz viel Discovery, gemeinsames Verständnis und so weiter daran gearbeitet. Da habe ich immer noch sehr gute Kontakte aus der Zeit. Dann hat mich allerdings ein GoodGame-Kollege, mit dem ich damals zusammengearbeitet habe, gefragt, ob ich nicht Bock hätte, in ein WealthTech-Startup einzusteigen, nämlich Only, wo es darum ging, Vermögenswerte für arme Millionäre mit aufzubauen. Da hatte ich unglaublich viel Lust drauf, weil ich den Kollegen unglaublich gerne mochte und mit ihm zusammengearbeitet habe. Das Produkt fand ich noch ein bisschen interessanter, als Kredite. Kredite hatten auch einen gewissen Charme, aber nur den Abschluss von Krediten. Ich wäre gerne darüber hinausgegangen. Das Produkt war sehr spannend und gab es viel zu tun. Dann bin ich da eingestiegen und da haben wir versucht, das Startup nach vorne zu bringen. Das hat so funktioniert, aus den verschiedensten Gründen, wie das bei Startups immer so ist. Ich bin dann über eine kurze Freelancer-Zeit bei DealCircle gelandet und habe hier auch von Anfang an das Produkt mit aufgebauten internen Produkten, auch weitere externe Produkte, also Customer-Facing-Produkte, aber vor allem ging es uns darum, internes Produkt zu bauen, mit dem wir schnell unser eigentliches Produkt herstellen können, nämlich unsere Käuferlisten für M&A-Transaktionen.

Jan: Ja genau, da wollte ich gerade einmal darauf hinweisen. Viele kennen DealCircle ja vielleicht nicht. Vielleicht erklärst du einmal kurz, was ist denn da die Mission?

Hendrik: Ja, das ist natürlich auch kein Produkt, wo man sagen kann, okay, das passt jetzt auf jeden Fall zu dieser Zielgruppe. Wir erstellen Käuferlisten für M&A-Transaktionen, d.h. ein M&A-Berater kommt auf uns zu und sagt, ich habe ein richtig schickes Unternehmen zu verkaufen. Ich bräuchte hier mal eine Liste von Käufern, die großes Potenzial haben, das Unternehmen zu übernehmen. Und wir erstellen diese Käuferliste. Das hat angefangen mit einer Excel-Liste und sehr, sehr viel manueller Arbeit. Und wir haben es automatisiert, immer weiter mit verschiedensten Tools, die uns zur Verfügung standen, in dem jeweiligen Jahr. Und gerade daher kommt jetzt auch gerade dieses Thema, weshalb ich unter anderem auch hier bin und wir uns damals in einem Standtisch getroffen haben. Wir haben diesen Prozess immer weiter verschlankt und automatisiert. Und das ist halt alles, was wir gerade bei KI sehen. Bei den Entwicklungen ist das ein Riesentreiber gewesen. Also KI und No-Code, Low-Code. Also wir haben da Gebrauch gemacht von allem. Wir haben natürlich unser eigenes Software, das Front-Scratch-Produkt aufgebaut mit einem Elasticsearch-Indexing drin. Und eine vernünftige Datenbank, eine richtigen, selber gehostet und so weiter. Aber daran haben wir jetzt halt durch die neuen Entwicklungen immer mehr fancy, shiny Tools geknüpft, die uns verschiedene Dinge so weit erleichtern oder so stark vereinfachen, wie wir es selber nicht hinbekommen hätten zu bauen, wenn man es so sagen kann.

Jan: Ja, und gerade das fand ich in der Diskussion oder in deinem Vortrag beim Stammtisch so spannend, weil ich glaube, dieses Thema, was macht man als Unternehmen gerade auch als Unternehmen, das sich schnell bewegen muss, in Start-up-Strukturen arbeitet, Product Market Fit noch nicht zu 100 Prozent gefunden hat, da haben Low-Code, No-Code, Vibe-Programming, Prompt-Programming, however you want to call it, das hat immer mehr und immer krassere Relevanz. Und ich sehe aktuell auf der einen Seite viele befreundete Leute, die in Gründungsphasen von Unternehmen sind, in den Start-up-Kontext, es gibt noch kein Produkt, es gibt noch kein Product Market Fit, wo es eine riesen Rolle spielt, wo Entwicklungsteams nur noch den Bruchteil der Größe haben, die sie vorher hatten. Und ich sehe parallel aber auch sehr viele Leute, die noch sehr wenig damit arbeiten. Und ich dachte, das ist ja gerade ein total spannender Umbruchsmoment, um ihn vielleicht auch noch mal zu unterstreichen. Ich habe im Vorfeld auch noch mal nach ein paar Zahlen gesucht und vor kurzem hatte Combinator zum Beispiel verlauten lassen, dass ein Viertel von deren Startups aus 2025 inzwischen eine Codebasis haben, die zu 95 Prozent auf AI-Code basiert ist. Also zu 95 Prozent haben wir hier gepromteten Code. Und das ist jetzt totale Startup-Welt. Aber die Frage ist natürlich, wie weit geht das auch später in etabliertes Software hinein? Und du bist jetzt mal jemand, der da wirklich schon sehr viel praktische Erfahrung mit hat. Und deswegen bin ich super gespannt, was du uns dazu erzählen hast.

Hendrik: Ja, also um, kann man nachher vielleicht auch noch ganz kurz darüber sprechen. Natürlich ist es das absolut genialste für jeden, für jedes Startup und jeden Prototypen, damit zu starten. Genau, können wir gleich noch mal ein bisschen tiefer einsteigen. Aber genau, die meisten fragen sich natürlich, ich habe hier ein Produkt und das läuft, was soll ich jetzt, also kann ich das auch irgendwie nutzen? Und das war auch damals unsere Idee. Tatsächlich, wo sind die Anfänge hergekommen? Gut, die Anfänge, Anfänge waren vor zwei Jahren. Da haben wir, da hatte ein Kollege eine Idee für ein weiteres Produkt und gesagt, hey, wollen wir das nicht, können wir sowas nicht bauen, kann nicht so schwer sein, wie das immer so ist. Wir kennen es, ein Stakeholder kommt an und...

Jan: Das ist doch eine simple Sache.

Hendrik: Ganz genau, ganz genau. Es ist ja nur eine Website mit ein bisschen Clickness. Es war ein Directory, wo du halt eine Website hast und dann kannst du ein bisschen suchen und kannst du dir Tools raussuchen, die für M&A-Transaktionen relevant sind, wo die Berater suchen können nach dem Datenraum und so weiter, CRM. Und da haben der Marketing, der frühere Marketingkollege und ich gesagt, hey, lass uns doch mal gucken, ob man da hier irgendwas mit No-Code bauen kann. Da gibt es doch Lösungen. Und haben uns übers Wochenende hingesetzt und halt in, keine Ahnung, ein paar Stunden mit Airtable und Softer damals. Das sind, Softer sind deutsche Lösungen, Airtable nicht. Ich weiß gar nicht, wo die jetzt genau herkommen, wahrscheinlich die USA. Was zusammengebaut, was denen die Idee des Produktes ziemlich genau getroffen hat. Natürlich war es limitiert in vielerlei Hinsicht. Softer ist ein sehr leichtgewichtiges Baukastensystem. Mittlerweile sehr, sehr viel stärker. Aber es ist krank an dem einen oder anderen, wo man hier noch ein bisschen Detail hinzufügen möchte und so weiter. Aber es hat sehr gut getroffen, was die eigentliche Idee war. Und wir sind dann darüber auch ins Gespräch gekommen, hey, was soll das Ding eigentlich können? Also du bist halt sehr schnell auf einem Prototypen-Level der Release-Bice und klickbar und erlebbar, wo du nicht nur Nutzer drauf lassen kannst, wo du auch Nutzer drauf lassen kannst, aber vor allem auch kannst du darüber schon mit einem Kollegen sprechen oder mit einem Stakeholder. Geht das in die Richtung? Das ist halt ein Bruchteil der Zeit. Also bis ich mit Figma oder mit einem Designer irgendwas in Figma zusammengeklickt habe, habe ich halt locker so eine Softwaregeschichte aufgesetzt und dann können wir uns darüber schon mal austauschen. Das war damals der Start.

Jan: Das hat vielleicht noch mal eine kurze Frage dazu. Also du meintest ja vorhin schon, dass du auch in der Zeit vor Star Finance da schon angefangen hast, eigene Scraper zu bauen. Also glaubst du, dieser Hacker-Spirit hat dich da reingetrieben? Oder wie bist du überhaupt auf die Idee gekommen zu sagen, komm, ich überspringe den ganzen Figma-Prozess, ich überspringe jetzt hier die Arbeit mit einer Designperson, ich bau jetzt einfach mal selber was. Da gehört ja auch ein bisschen Schöpfergeist zu, oder?

Hendrik: Absolut. Und ich bin ja nicht als Entwickler auch zu GoodGames gekommen, sondern als armer BWLer und hatte dann auf einmal überall Techies und Entwickler um mich herum und habe gesagt, es fühlt sich so ein bisschen an, als wenn du durch einen Dschungel gehst und überall böse Tiere aus dem Wald kommen, kannst du immer nur sagen, oh bitte, den Jaguar einmal, der greift mich sonst an. Das ist ein sehr, sehr, sehr grobes Beispiel gerade. Aber du willst halt eigentlich selber die Person sein, die jetzt Dinge tun kann und nicht immer nur anderen Leuten sagen, bitte kannst du das mal machen, das wäre super cool. Und kannst du das mal schick machen? Außerdem bist du halt sehr abhängig und auch sehr langsam, weil es immer irgendwo auch ein Bottleneck gibt. Und wenn du es einfach selber bauen kannst, ist das einfach eine komplett andere Art und Weise, Produkte zu sehen. Und es ist eher so ein bisschen die Founders Journey, wenn man selber Sachen zusammenbauen kann. Und es ist schon cool, wenn man auch mit einem Team etwas baut und launcht und released und die ersten Nutzer sieht. Das ist cool. Aber es ist nur was anderes, als wenn du es selber gebaut hast und dann released hast. Und das ist irre. Das selber machen zu können, ist schon wirklich cool. Und da war früher das Problem, ich war nie ein Programmierer und vor allem nicht gut genug, etwas zu bauen. Wo ich sage, okay, das ist wirklich releasefähig und mit Server-Aussetzen und was alles dazu gehört. Und es dauerte noch ewig und ich bin schrecklich langsam und habe gesagt, damit werde ich nie fertig. Aber mit den Tools, die es heutzutage gibt, ist das halt wirklich absolut möglich. Und das ist wirklich ein Quantensprung, von dem ich dann wirklich, der mich umgehauen hat. Auch als wir dieses kleine Produkt dann gelancht haben, das war wirklich irre, dass wir gesagt haben, es läuft, wir haben Daten drauf. Es ist online, du kannst es über eine Website. Das ist schon, das ist ein großes, im Großen, im Kleinen ist es Magic.

Jan: Was fühlt sich denn daran Magic an? Oder woran machst du die Magic fest, damit wir es für die Zuhörenden auch einmal greifbar machen?

Hendrik: Die Magic ist, dass du selber was erschaffen hast, was auf einmal alle Leute auf der Welt einsehen können und nutzen können. Wovon du davor immer dachtest, da brauchstest du ein Entwicklerteam. Also ich wusste, wie schwierig das war, weil ich selber versucht habe, mal so einen Linux-Apache-Server aufzusetzen und einen Django-Python-Framework draufzusetzen. Und das war ein irrer Akt, auch weil ich natürlich nicht die Skills hatte, das wirklich routiniert zu tun. Viele Entwickler haben das anders, aber als Produktmanager bist du nicht der, der das aus dem FF mal eben macht. Aber du hast ein paar Ideen, die du gerne live von den Farben sehen würdest. Also die Magic kommt gerade beim No-Code daher, dass du halt diese Dinge mal eben umsetzen kannst und tatsächlich launchen kannst, auf den Knopf drücken kannst und zack, dann läuft's. Obwohl du davor immer der Meinung, jahrelang der Meinung war, dazu brauchst du ein Team, dazu brauchst du was weiß ich.

Jan: Paarhunderttausend Euro.

Hendrik: Zum Beispiel, ganz genau, ja, ganz genau. Du brauchst Geld und niemand hat so viel Geld, um irgendwie ein sechsköpfiges Entwicklerteam auf irgendeine Plattform loszulassen und dir was bauen zu lassen.

Jan: Vielleicht bevor wir jetzt richtig einsteigen, wir wollen hier gleich mal ein paar Beispiele beleuchten, wo dieser Ansatz, die Dinge einfach selbst zu bauen als Produktmanager, gut funktionieren kann. Aber bevor wir reinspringen, macht es vielleicht Sinn, wir schmeißen hier ein bisschen mit Begriffen um uns. Low-Code, No-Code, Prompt Engineering, AI-Coding, Vibe Programming. Vielleicht wollen wir mal die wichtigsten Begriffe zum Start klären. Was sind die wichtigsten Begriffe, die man deiner Meinung nach kennen sollte?

Hendrik: Ja, absolut. Jeder hat es natürlich oder jeder interpretiert diese Landschaft für sich selber leicht anders. Aber ich würde es so starten. Es gibt No-Code-Tools, bei denen du innerhalb eines Tools ein komplettes Produkt baust und das innerhalb des Tools auch releasest. Das heißt, das ganze Tool lebt innerhalb dieses Bilders, sag ich mal. Dieses Frameworks, das ist wieder ein falsches Wort, aber dieses Baukastensystems. Bestes Beispiel dafür ist Bubble oder Software. Bubble als Full-Stack-Bilder. Da könnte man auch wieder unterscheiden, aber da hast du sowohl Backend-Datenbank als auch Frontend drin. Software zum Beispiel wäre eine Frontend-Lösung und dann würdest du da noch ein Airtable, ein Notion, also eine Backend, eine Datenbank mit dranbinden. Aus diesen zwei Tools wird dann aber trotzdem ein Tool, was aus zwei Bestandteilen besteht. Also es ist aber komplett ohne Code baubar und wird Release. Die Leute können sich einloggen und du musst im Grunde keine Zeile Code schreiben.

Jan: Ich benutze Drag & Drop, ich ziehe da einen Button hin. Ich habe vielleicht einen Editor, wo ich sage, wenn, dann das. Aber ohne dass ich das in eine IDE reintippern muss, sondern ich kann mir das alles zusammenschieben und dann funktioniert es.

Hendrik: Ja, absolut. Lass uns mal ein Beispiel machen. Ein Beispiel denken, ein Bubble. Was du hast, du hast einen Button. Du hast in der UI, du definierst, das ist ein Button und wenn du draufklickst, dann definierst du Workflows. Was passiert denn, wenn gedrückt wird? Dann suchst du z.B. in der Datenbank nach dem aktuell eingeloggten User und dann guckst du, was hat der User für ein, sagen wir mal, Haustier, wenn das irgendwie eine App ist für Hundehaltsbänder. Und dann kannst du sagen, okay, Haustier A hat einen Hund und der Hund hat fünf Hundehaltsbänder. Und du kannst dich im Grunde dadurch klicken, okay, das ist der Hund und dann öffnet sich ein weiteres Kontextmenü. Der hat Halsbänder A, B, C. Dann klickst du auf das Halsband C und dann wird da vielleicht ein Preis angezeigt, oder? Und es ist wirklich visuell zusammenklickbar aus Datenbankobjekten, die da tatsächliche Datenbankobjekte sind. Also du definierst auch einen Datenbankschema. Das heißt, du sagst, das ist ein Hund, der hat einen Namen, einen Alter. Und dann kannst du da im Grunde noch weitere Objekte ranknüpfen, wie zum Beispiel da Halsbänder, die der Hund besitzt. So und du kannst aus diesem Tool und das ist vielleicht eine Sache, die mittlerweile anders ist, die früher nicht funktioniert hat. Du kannst mit anderen APIs sprechen, du kannst mit anderen Tools sprechen, du kannst weitere Services ansprechen. Das funktioniert wunderbar. Kann ich gleich, auch wenn wir zu den Beispielen kommen, noch ein bisschen mehr zu erzählen.

Jan: Also das heißt, man ist da nicht limitiert, einfach auf die Welt dieses einen Baukastensystems, in dem Fall Bubble, sondern ich habe die Möglichkeit, alles anzusprechen, als wäre es TailorMade Software, die jetzt eine API ansprechen soll und Ähnliches?

Hendrik: Absolut. Und das ist der Riesenunterschied zu ganz, ganz früher. Also ich weiß noch, als ich diese Baslerzeit habe, habe ich mir auch mal No-Code-Baukastensysteme angeguckt und die waren halt sehr genau limitiert, nur auf sich selber. Und da konntest du Workflows oder sowas, Wizards zusammenklicken. Und der große Unterschied jetzt auch gleich zu der zweiten Kategorie, zu der wir kommen, ist, du kannst mit externen Services sprechen und wesentlich mehr an Magic und Funktionalität zur Verfügung stellen, als jetzt einfach eine Listenansicht, ein weiteres Listelement hinzufügen. Also bist du dann limitiert auf ein paar Aktionen, die du tun kannst und das beliebig komplex werden lassen. Und das ist der große Unterschied. Und alle diese Tools, die wir ausprobiert haben, um das einzugrenzen und nutzen, können genau das, nämlich nach außen telefonieren und man kann sie von außen ansprechen. Sie können Tools außerhalb ihres Einzugsbereichs über APIs ansprechen. Du kannst eigene APIs damit bauen, die im Hintergrund laufen. Du musst gar nicht ein Frontend bauen. Also die sind einfach unglaublich stark geworden.

Jan: Und auch das Bauen der API funktioniert dann auf No-Code, Drag-and-Drop-Ebene? Oder wie kann ich mir das vorstellen?

Hendrik: Genau. Du hast einen Endpunkt und sagst, wenn der Endpunkt angesprochen wird, dann guckst du in der Datenbank, je nachdem, was angefragt wurde. Zum Beispiel du fragst über eine API, gib mir doch mal die Liste der Halsbänder von Hund Emil. Und dann sagst du einfach, ich gucke in die Datenbank, guck mir an, wer Emil ist und was für Halsbänder der hat. Und das ist im Grunde zusammenklickbar über einen visuellen Editor. Also wirklich, das war ein großes Oho, aha, dass sowas funktioniert. Weil man kennt die eigentlich immer nur von den, oder hauptsächlich von den Website-Bildern, wo halt ganz viel UI ist, wo du hier Elemente hast, aber dass das auch über APIs und Backend-Prozesse funktioniert, das war wirklich ein großer Schritt.

Jan: Ja, super spannend, dass es in der Tiefe möglich ist inzwischen. Und das sind No-Code-Tools, also Drag-and-Drop-Editoren. Ich baue mir meine Software. Ich muss die Logik dessen, wie Software funktioniert, verstehen. Aber ich muss die Semantik dessen, wie ich es umsetze, nicht ganz verstehen. Wir haben auch über Low-Code gesprochen. Was ist das?

Hendrik: Oh du, damit tue ich mich in der aktuellen Situation schwerer als mit den ganzen restlichen Kategorien. Low-Code, würde ich sagen, war für uns bisher Elementor, was auf dem WordPress lief. Das heißt also ein Template-System, was du immer noch aber anreichern musstest für einige Funktionalitäten, weil es relativ begrenzt war. Die meisten Tools, die du jetzt heute hast, sind entweder, oder sind meistens so, dass du sie komplett auf No-Code laufen lassen kannst. Und du kannst auch bei Bubble-Code injecten, eigene JavaScript-Elemente hinzufügen. Low-Code, mir würde Elementor einfallen. Aber im Grunde will ich, wenn ich ein Tool bediene, auch nicht mehr selber programmieren, also selber Code schreiben, weil ich keine Ahnung habe, wie jetzt nach neuen Standards die Elemente gebaut werden, sondern das soll mir der Builder vorgeben. Können wir jetzt natürlich, was Low-Code angeht, in Richtung Vibe-Coding noch ein bisschen weitergehen, weil das könnte man heutzutage tatsächlich eher als Low-Code definieren.

Jan: Okay, also Low-Code im Grunde in deinen Augen keine so relevante Kategorie mehr, weil es ja sehr zwischen den Stühlen ist.

Hendrik: Ich würde eher sagen, das ist eine Verfeinerung von einem No-Code-Tool, um dann noch ein bisschen mehr Funktionalität reinzubringen, wenn du es brauchst. Du kannst halt ganz besondere Interaktionen und besondere Elemente dazu bauen und bestehende Elemente verbessern, wenn du eigenen Code injectest und Sachen zur Verfügung stellt, sie gibt es auf dem Marktplatz für und so weiter. Aber das brauchst du sehr oft nicht. Also oft kommst du auch mit den Wortmitteln zum Ziel.

Jan: Okay, und Vibe-Programming kam gerade zur Sprache. Ich glaube, der Begriff, wir können ihn ja gleich einmal definieren, aber der ist jetzt gerade der letzte, den ich dafür gefunden habe, der trendet. Man hat das aber auch mal Citizen Engineering, habe ich auch mal gehört, aber Prompt Engineering, aber die Begriffe sind alle gerade noch sehr phasien. Ich habe das Gefühl, in der Diskussion noch ein bisschen wackelig, aber vielleicht definieren wir mal die für dich wichtigsten.

Hendrik: Ja, da können wir auch gleich nochmal kurz darüber sprechen, über Citizen Engineer und Prompt Engineering. Da haben wir unsere eigenen Begriffe und auch Bereiche für Kollegen, die genau das machen. Ja, ich würde Vibe-Coding einfach gerade als die beste Bezeichnung dafür nutzen, was es gerade ist. Nämlich du promptest einen Coding Agent, dass er etwas für dich bauen soll. Und der guckt sich das Projekt dann und basierend auf dem Kontext und dem, was du gesagt hast, baut es etwas. Und eine Mangelung eines besseren Begriffs wäre das genau für mich Vibe-Coding. Wäre auch nicht Low-Code, weil klar am Ende ist es Code, aber du programmierst ja nicht selber. Du musst es zumindest nicht. Du kannst es. Und das ist vielleicht auch innerhalb der Vibe-Coding-Tools, um da nochmal kurz einzusteigen, vielleicht ein Unterschied. Da gibt es auch eine, ich würde sagen eine Skala an Tools, wie die aufgestellt sind. Und Cursor wäre für mich eher für die Programmierer, die ihr eigenes Programmieren verbessern wollen und sagen, okay, ich will jetzt hier Vorschläge basierend auf dem Kontext haben und dann werden Sachen vorgeschlagen. Und dann sind aber eher in einer IDE unterwegs und weniger in einem Promptfenster.

Jan: Der nächste Schritt wäre vielleicht, ich würde dich da gerne einmal unterbrechen, weil nicht alle Leute, die uns zuhören, haben selbst mal mit einer IDE gearbeitet, haben selbst mal Code geschrieben, also eine Entwicklungsumgebung gehabt, in der sie Code geschrieben haben. Vielleicht kannst du einmal, wenn wir Vibe-Coding, also die Idee, ich prompte einfach mal die Applikationen, die ich da bauen will zusammen mit einem AI-Agent, vielleicht kannst du mal kurz erklären, wie das so richtig greifbar dann im Alltag aussieht, wenn man das macht.

Hendrik: Das beste Beispiel dafür, wo wir alle Facetten unter einen Dach bekommen, wäre für mich Replit. Und du musst dich vorstellen, du öffnest einen Editor, einen relativ mächtigen Editor und der startet mit einem Fenster, bitte gib ein, was du bauen möchtest. Und dann sagst du hier eine To-do-Liste, Dating-App, Hundehalsband-App und so weiter. Und dann baut er dir das, basierend auf wie er, je nachdem, was du an Kontext gegeben hast und wie er meint, dass es richtig ist. Und was der Output davon ist und das Ergebnis, es ist ein Softwareprojekt in dem Editor mit verschiedenen Dateien, sowie ein Softwareentwickler, das für sich auch machen würden. Das sind Frontend-Komponenten, dann sind Workflows und hier sind Konfigurationen in einer anderen Datei. Du kannst aber trotzdem weiter prompten und dir Features dazu wünschen. Und dieses Promptfenster ist im Grunde integriert. Und man kann sich so vorstellen, links sind diese Dateien, in der Mitte ist das Promptfenster und rechts ist das, was gebaut wurde. Und da bekommt man ein Preview und kann auch klicken und sich anschauen, wie es funktioniert. Das ist, glaube ich, der aktuelle Mittelweg zwischen dem, was zum Beispiel ein Lovable kann. Da hast du hauptsächlich das Promptfenster richtig und weniger Editor. Aber willst du es vielleicht dann auch nicht editieren und nicht selber in die Dateien reingehen und eine URL austauschen oder oder? Und da gibt es halt ein bisschen Bewegung. Aber im Grunde ist es genau das. Du hast einen Editor und kannst dir Features zusammenprompten.

Jan: Also anstatt, dass ich früher, wenn ich jetzt jemand bin und ich möchte ein Stück Software bauen, dann musste ich mir früher überlegen, was ist das? Dann musste ich das aufschreiben, da vielleicht mit Design-Leuten, mit Engineers drüber reden, das Design, das danach über einen normalen Entwicklungsprozess, über Tickets in einem Kanban oder Scrum-Prozess oder wie auch immer bauen, um irgendwann mal Software rauszukriegen, nachdem das ganze Thema durch X-Hände gegangen ist. Und heute schreibe ich einfach meine initialen Anforderungen dafür in ein Fenster und ich bekomme ein Tool, das das schon mal halbwegs macht.

Hendrik: Ja, absolut. Und das ist ein ganzes Stück Magic. Also du bist halt eher auf dem Weg, du startest mal locker mit einem Prompt und dann ist es eher so, dass du die Änderung wünscht. Also stell dir einen Junior-Junior-Entwickler vor, der aber sehr schnell im Entwickeln ist. Und dem sagst du einfach immer, okay, da guckt der Text drüber, das sieht nicht gut aus. Oder dafür hätte ich gerne andere Formen. Oder der Button soll jetzt das machen. Oder ich will ein ganz neues Feature. Und schickst du ihm einfach immer deine Wünsche rüber. Und testest im Grunde die ganze Zeit. Und guckst, wie es funktioniert und was du gerne anders haben würdest. Und es kann passieren, dass du sehr häufig das frühere Fehler noch mal, also dass du ihn bittest, den noch mal zu lösen und das bitte noch mal richtig zu machen. Bisher bin ich dabei immer zu einem Ergebnis gekommen. Aber auch da gibt es Grenzen. Also das ist gerade noch die Frage, wie tief kommst du da bei der Komplexität? Auch meine Tests sind da irgendwann, irgendwann habe ich nicht weiter gemacht, aber ich bin schon ziemlich weit gekommen. Und ich habe es neben dem Job gemacht. Also ich habe quasi stündlich mal reingeguckt, habe ihnen dann immer wieder neue Ideen gegeben, dem Agent und habe dann geguckt nach einer Stunde, was ist da rausgekommen. Hab kurz geklickt und getestet. Nee, das müsste noch ein bisschen anders. Und ihnen wieder machen lassen. Also von daher, das ist Magic, aber ist noch mit Vorsicht zu genießen, bei wirklich Dingen, wo man eine große Stabilität braucht in der Applikation.

Jan: Ja, das ist natürlich ein ganz gutes Stichwort, wenn wir dann später differenzieren zwischen, was braucht vielleicht ein Start-up, das noch gar nicht weiß, ob jemand Interesse langfristig an einem Produkt hat, an einer Dienstleistung hat. Was macht jemand, der das Ganze schon als reifes Produkt etabliert hat? Wenn ich dich richtig verstanden habe, habt ihr ja aber bei DealCircle aktuell tatsächlich auch produktive Software, die auf diesem Wege entstanden ist, richtig?

Hendrik: Auf dem Weg tatsächlich nicht, nee. Also wir haben das jetzt vor. Tatsächlich hat mich ein Entwickler gefragt, ob wir ein Replet-Repo aufmachen können, also quasi so ein Team, dass wir da zusammen ein bisschen rum experimentieren können. Das habe ich noch vor, aber damit ist noch nichts entstanden, was bei uns produktiv ist. Das ist eher in meinem Hobbyraum.

Jan: Okay, und welche Hobbys haben gut funktioniert?

Hendrik: Tatsächlich habe ich eine Vermögens-App nachgebaut. Und das Besondere da war, diese Vermögens-Apps sind unglaublich, sind Listen. Also je nachdem, wo drauf du klickst, du kriegst immer irgendwo eine Liste und willst aber eigentlich eine Art Baum-Hierarchie haben von wegen. Der Nutzer steht oben, der eine Person, die Vermögen besitzt. Und dann da drunter sind verschiedene Assets. Und das können wie die Immobilie oder ein Depot sein und so weiter. Und vielleicht ist es auch eine Firma oder Firmenanteile und unter der Firma hängen weitere Assets. Das heißt, es ist eine Struktur, eine Baumstruktur. Und so was muss man, und da habe ich keine Ahnung von, in einem Frontend, in einem Canvas darstellen. Man vergleicht, das ist für alle Produktzuhörenden, Miro und Co. Da kann man wunderbar diese Strukturen darstellen. Da habe ich keine Ahnung, wie man das in der Software macht. Und im Frontend mit React. Und das habe ich gepromptet und das ging hervorragend. Hätte ich nie hinbekommen. Also viele andere Varianten hätte man mit ein bisschen Arbeit hinbekommen, mit einer ganzen Menge Fleiß. Aber es wäre auch wieder nur eine Liste geworden. Und das ist jetzt mal wirklich was Neues, wo ich wirklich gesagt habe, okay, das waren Skills, die ich nicht gehabt hätte, unabhängig davon, ob ich einfach ein halbes Jahr lang durcharbeiten würde und einfach irgendwas zustande bekommen würde.

Jan: Okay. Und was sind so Bereiche, wo ihr tatsächlich schon auf No-Code-Lösungen setzt und damit produktiv arbeitet in eurem Alltag?

Hendrik: Das sind vor allem, und da fehlt uns noch eine Kategorie, die ich mit dazu packen würde. Neben No-Code, Low-Code, Vibe-Coding würde ich als weitere Kategorie Third-Party-Tools oder Schrägstrich-AI-Tools mit dazu packen, die einen speziellen Use-Case haben und diesen Use-Case besonders gut können. Und diese Tools haben immer schon existiert bis zu einem gewissen Punkt. Das könnte zum Beispiel ein Stripe sein für Payment oder ein Tool, um Unternehmensdaten anzureichern. Und diese Tools haben durch den KI-Hype ihren Use-Case noch stärker werden lassen, ohne dass man das hätte selber bauen müssen. Sondern du greifst im Grunde auf deren Funktionalitäten zurück und kannst damit im Grunde jedes zum Beispiel auch leicht gebaute, mit einer No-Code-Lösung gebaute Tool anreichern, um Funktionalitäten, von denen du nie gedacht hättest, dass sie möglich wären. Auslesen von Dokumenten und Scraping von Webseiten und Scraping von anderen Dingen, Schicken von E-Mails, also Scraping von LinkedIn oder das ist wirklich die Magic, bei der es bei uns große Veränderungen gegeben hat, die wir auch gerade in einem etablierten Software-Stack gut integrieren konnten. Weil diese Tools haben nämlich genau den Vorteil, den ich am Anfang bei den No-Code-Tools einmal beschrieben habe, nämlich die sind ansprechbar von außen, wir haben eine gut dokumentierte API, da kannst du Sachen hinschicken, zurückbekommen. Sie sind sehr weasy-wick, sie sind sehr visuell zusammenbaubar, sie sind konfigurierbar von einer Person, die nicht programmieren können muss. Da auch wieder den Wink auf den Citizen-Developer und eine Person, die kein Programmierer sein muss, aber effektiv die Arbeit eines Programmierers macht, wenn du das Feature sonst selber bauen müsstest. Und diese Tools sind ein ganz essenzieller Teil von allem, was wir gerade haben. Denn vor allem ist da natürlich Chatchipity, also die API von Chatchipity und allen LLMs, KIs gemeint, die du ansprechen kannst und im Grunde aus unstrukturierten Texten strukturierte Texte machen kannst. Du kannst Dinge, ich weiß nicht, wie zu, in die technische Richtung, du kannst Dinge parsen, du kannst HTMLs vorbereiten, aufbereiten, anzeigen, Jasons formatieren. Das ist ein Tool, das an sich schon sehr, sehr stark ist. Aber viele andere Tools haben das integriert und nutzen das und können damit jetzt auch Use-Cases zur Verfügung stellen, die davor einfach nie möglich gewesen sind. Und um da auf deine Frage zurückzukommen, wir haben genau da ein Tool eingebaut, was es uns erlaubt, was muss es dir vorstellen als eine Exit-Tabelle oder ein Air-Table auf Steroiden, das heißt eine Liste. Erstmal nichts anderes als eine Liste. Wir schicken eine Liste an Käufern, die wir zusammengestellt haben. Erinnert sich, wir stellen Käuferlisten zusammen für M&A-Projekte und wir schicken eine Vorauswahl an potenziellen Käufern an dieses Tool, schicken dazu die Informationen, um welches Projekt es geht. Und wir lassen im Grunde innerhalb dieses Tools von Spalte zu Spalte einen Agent drüber laufen und ihn fragen, was meinst du, wenn du dir dieses Unternehmen anguckst, die Daten haben wir zur Verfügung gestellt, und du jetzt anguckst, das ist das Target, und du dir jetzt die Website von diesem Unternehmen anguckst, geh einmal auf die Website und guck dir mal an, was die können, würdest du sagen, dass das zusammenpasst? Und das können wir natürlich mit unseren Historiendaten anreichern, also mit früheren Interessensbekundungen von dem jeweiligen Käufer und geben halt genug Kontext mit, dass die KI eine gute Entscheidung treffen kann. Und da haben wir, das haben wir, dann wird es angereichert, um das kurz zu Ende zu führen, da wird es über, werden verschiedene Entscheidungen getroffen, warum das jetzt gut ist oder nicht gut ist. Und am Ende wird das Ding zurückgespielt oder wird die Liste zurückgespielt an unser System. Und wir haben einen Arbeitsprozess geschaffen, der davor komplett manuell gewesen ist, weil das alles manuell geprüft wird von Leuten, von Spezialisten und was wir jetzt aber erreicht haben. Und das, was das LLM erreicht hat, ist, es hat einen Report geschrieben für jeden Käufer und hat eine Priorisierung vorgenommen, warum der passt und wie gut der passt. Dann kommt noch eine Person, also ein Human in the Loop, kommt noch mit hinzu, guckt da drauf, aber halt auf einem ganz anderen Level und mit einer ganz anderen Vorbereitung.

Jan: Das heißt, ihr habt wirklich einen kompletten Workflow einmal durchautomatisiert und das, indem ihr eigentlich kaum Engineering, keine oder so gut wie keine Engineering-Ressourcen investiert habt. Hast du das dann alles selbst gemacht oder wie lief das?

Hendrik: Wir hatten, was ich gemacht habe, ich habe mir aus einem Strategiemeting von uns rausgekommen, hey, es gibt auch so viele fancy Tools da draußen, könnte man unser Geschäftsmodell nachbauen? Und das war so ein bisschen scherzhaft gemein und stand so im Raum und da haben wir erst mal so stehen lassen und gesagt, ja, könnte sein, wissen wir aber nicht. Und im Grunde habe ich mir zwei Wochen geblockt und bin tief eingestiegen und habe überlegt, okay, könnte man das und mit welchen Tools? Und bin selber auf die Suche gegangen und bin dann auf ein Tour gestoßen, auf Clay. Ich bin auch auf weitere Tours gestoßen, die dann wiederum weitere Use Cases zur Verfügung stellen, nämlich direkt auch die Ansprache, ein E-Mail-Versand aus Clay heraus, eine WhatsApp-Ansprache, eine LinkedIn-Ansprache und so weiter und so fort und das alles wieder zurückführen. Dann haben wir gesagt, das geht. Es ist möglich und habe einen Hackathon angesetzt von einer knappen Woche mit ein paar Leuten, nämlich mit Leuten, die selber die Listen prüfen und zusammenstellen und entwicklern und haben gesagt, okay, lass uns versuchen, das Geschäftsmodell nachzubauen und zu gucken, wie weit wir kommen. Und während wir das getan haben, haben wir gesagt, im Grunde, also so am zweiten Tag, haben wir gesagt, im Grunde könnten wir das auch direkt einfach mal mit unseren Daten probieren, also nämlich genau, während wir es gebaut haben, gesagt, lass uns da noch mal was hinschicken und gucken, wie das funktioniert mit unseren Daten. Und so sind wir am Ende da rausgekommen und im Grunde hat am Ende ein Entwickler, der für die Kommunikation zwischen Systemen zuständig ist, da Liebe reingesteckt und einer der Kollegen, die sonst die Listen zusammenstellen und reviewn, der hat im Grunde die ganzen Promts geschrieben. Und da kam ich mit dem Prompt Engineering her. Der hat halt passend für diese Abfrage-Logik und diese Agent-Systeme so geschrieben, dass wir Halluzination vermeiden, dass wir die richtigen Antworten bekommen, dass es am Ende alles in ein Ergebnis reinläuft, ob der Lied, also ob der Käufer geeignet ist oder nicht. Und da hat er mittlerweile acht iterationen, acht größere Release-Iterationen gehabt, die wir immer verbessert haben. Und mittlerweile sind wir komplett skaliert auf das System und funktioniert irre gut. Also hätten wir nie gedacht am Anfang, dass es auf dem Level funktioniert, sondern dass es immer noch sehr viel manuelle Arbeit ist.

Jan: Okay, krass. Also das heißt, der absolute Großteil der Arbeit, den hast du tatsächlich einfach zusammengesteckt. Aber bei so Themen wie, wie stelle ich sicher, dass unser System nicht halluziniert? Und bei so Themen wie, wie integriert, wie integrieren sich die Daten dann in unsere eigentliche produktive Software? Bei den Themen hast du dir noch mal Hilfe von Spezialisten oder Spezialistinnen geholt.

Hendrik: Wir haben das mit dem Halluzinieren, haben wir selber versucht zu lösen, also über ganz viel Trial and Error. Und da haben wir im Grunde Weichen eingebaut, wo wir dann das Ergebnis, also du musst dir vorstellen, in dieser Exit-Tabelle auf Geruiden bei Clay hat man verschiedene Agents die Dinge tun. Und du kannst den einen von einem anderen prüfen lassen und kannst dann gucken, ab wann halluziniert er? Und ab wann, wo sind die Thresholds? Und wie musst du die Frage stellen? Und das haben wir sehr deutlich, auch natürlich mit der Entwicklung neuerer Modelle. Die haben uns natürlich extrem in die Hände gespielt. Dieses Risiko konnten wir extrem minimieren, weil wir auch immer genug Kontext mitgegeben haben. Also man muss sich vorstellen, es wird halluziniert, wenn zu wenig Kontext vorhanden ist. Und wir haben immer eine ganze Menge Kontext geben können durch das Scraping der Webseiten und unsere eigenen Daten. Und unter anderem auch so konnten wir es minimieren. Aber trotzdem, das war Wissen, was wir selber erarbeiten mussten. Uns erarbeiten mussten, weil das gab es noch nirgends. Oder gibt es einfach zu wenig. Und klar gab es Best Practices. Aber für unseren Use-Case mit unseren Daten ist es immer eine sehr individuelle Betrachtung. Von daher mussten wir da einfach Hands-on lernen und gucken. Also auch mal verschmerzen, dass hier was nicht richtig rausgegeben wurde. Und das dann aber abfangen. Aber mittlerweile funktioniert es besser, als wir es uns ursprünglich mal geträumt haben.

Jan: Man muss ja auch sagen, auch in der konventionellen Softwareentwicklung ist es ja nicht so, dass immer alles sofort problemlos funktioniert. Insofern ist das wahrscheinlich auch ein fairer Prozess, dass es da zu einigen Iterationen kommt. Absolut. Ich meine, das Prompt-Engineering leuchtet mir sofort ein, dass man da genug Zeit reinstecken muss, um zu gucken, kommen da wirklich sinnvolle Ergebnisse raus? Wird hier halluziniert? Wird hier zu viel halluziniert? Die Fragestellung auf der anderen Seite. Du hast vorhin gesagt, es ist inzwischen gar kein Problem, mit No-Code-Tools auch APIs anzusprechen und Ähnliches. Und trotzdem habt ihr aber nochmal Engineering-Aufwand reingesteckt, dann die Daten, die aus dem Tool kommen, in eure hauptsächliche produktive Software einzubinden. Da habt ihr trotzdem nochmal ein Ingenieur zu bemüht. Warum habt ihr da mit Engineering-Power gearbeitet, anstatt auch das mit No-Code-Tools umzusetzen?

Hendrik: Ja, weil die Daten aus unserem eigenen System kommen mussten. Das heißt, wir mussten einen Backend-Endpunkt zur Verfügung stellen, um diese Daten aus unserem System rauszuziehen. Und dazwischen musste ein Service sitzen, der dieses Rausziehen übernimmt. Und der hat im Grunde die Daten gepusht in das andere Tool. Das heißt, wenn du Daten aus deinem eigenen System rausbekommen möchtest, dann brauchst du heute Entwickler-Power. Das war im Grunde der Punkt. Also mit einem No-Code-Tools können wir gleich jetzt noch mal zu kommen, wo wir die im Einsatz haben. Aber in dem Fall haben wir das wirklich an unser Hauptprodukt angedockt, was wirklich komplett auf einer Java-Basis mit dem React Frontend gebaut ist. Und das ist sehr klassisch. Und das reichern wir gerade einfach nur mit solchen Use-Cases an.

Jan: Die Sache ist, wenn ich sowas inzwischen höre, dann denke ich, holy shit, da ändert sich eine ganze Menge in der Art und Weise, wie Produktmanagement klassischerweise funktioniert. Und da ändert sich auch eine ganze Menge dahingehend, wie man mit Entwicklern und Entwicklerinnen zusammenarbeitet. Aber bevor wir auf den zweiten Part eingehen, bei dem, was du jetzt in den letzten ein, zwei Jahren in der Arbeit oder in der stärkeren Arbeit mit solchen Tools gelernt hast, was glaubst du, wie sich Produktmanagement verändert? Und wie siehst du die Praxis? Wie fühlt sie sich anders an?

Hendrik: Das ist eine gute Frage. Und das ist auch genau die, die mich bewegt hat, während wir die Dinge gebaut haben. Bei vielen der No-Code-Themen und auch der Tool-Themen, die wir gebaut haben, also vielleicht kurz zu den No-Code-Themen. Wir haben damit einen Dashboard gebaut, wo wir in unser Backend reingucken konnten. Und wir haben im Grunde, ja, es ist ein Dashboard. Du kannst dich einloggen als Käufer bei uns und kannst halt schauen, für welche Projekte du Interesse bekundet hast zum Beispiel. Und die habe ich selber mitgebaut mit einem Kollegen. Nicht, weil ich nichts zu tun hatte, sondern weil ich wissen wollte, funktioniert das? Also, ich musste mich selber davon überzeugen, ob das funktioniert oder ob das eine Sache ist, auf die wir bauen können für solche Fälle. Und ich weiß nicht, ob ich es einem Entwickler hätte geben können und bis zu welchem Punkt, dass er mir eine Antwort gegeben hätte. Er hätte wahrscheinlich ganz viele andere Cases im Hinterkopf gehabt, weshalb das eigentlich keine so gute Idee ist, das zu tun, weil vieles vielleicht nicht möglich ist. Aber für mich und die Use-Cases, die wir rausgearbeitet haben, hat das einfach hervorragend funktioniert. Ich habe es gebaut mit einem damals noch nicht Entwickler oder Junior-Entwickler, der für uns ein paar Tools gebaut hat und der ist mittlerweile sehr, sehr fit. Der baut Features im Stundentakt. Features ist immer eine breite Sache, wie wir alle wissen. Aber es geht tatsächlich äußerst schnell. Und wir haben zu zweit im Grunde jetzt schon das zweite Tool hochgezogen. Und wir managen das auch selber ohne Jira, ohne irgendwelche Discovery-Prozesse. Wir sprechen mit Nutzern, zeigen es dem und nach einem Nutzergespräch baut er das ein. Und wenn es irgendwie nicht ganz passt, dann drehen wir es noch ein bisschen auf links und testen es. Das ist eine ganz andere Art. Es ist so, wie ich Agil eigentlich immer verstanden habe. Nur halt ohne die großen Kosten bei der Delivery. Wenn du die einfach so klein wie möglich machst, die Kosten bei der Delivery, dann ist es auch nicht so wild, wenn irgendwas falsch verstanden wurde. Dann baust du es halt mal eben schnell um. Nachdem du ein Feedback bekommst oder dir das anguckst und sagst, ah, das fühlt sich nicht so gut an. Dann machst du es aber ohne Figma-Design, Prototypen, schieß mich tot. Dein Prototyp ist der Working Code.

Jan: Das heißt, der Workflow, der im Prinzip losgetreten wird. Also wenn wir agil mal so als schnelle Anpassung an neues Gelerntes begreifen, in dem Sinne, wie vielleicht auch der Lean-Startup-Gedanke, wir bauen was, wir messen, was macht es, wir lernen etwas daraus und dann verändern wir, was wir bauen. Wenn man das mal so betrachtet, klingt es für mich jetzt wie eine radikale Entschlackung des Prozesses, wo ich lerne, was von einem Nutzer halt nicht mehr heißt oder einer Nutzerin, dann halt nicht mehr heißt, okay, dann nehme ich das wieder mit ins Team. Wir besprechen, was machen wir aus dem Gelernten. Wir prototypisieren neue Click-Dummies. Wir machen noch mal einen Engineering-Kick-Off. Wir schreiben Jira-Tickets. Wir haben einen QA-Prozess. Es wird released. Insgesamt sind sechs, sieben Leute beteiligt. Und auch in den schnellen Fällen dauert es zwei Tage. Und das sind jetzt wirklich eher die Start-up-Cases, die ich meine, im Konzern oder da dauert es noch mal deutlich länger. Sondern du lernst was, du promptest oder passt das No-Code-Tool eben an. Und zehn Minuten später habt ihr die neue Variante von der Software dastehen.

Hendrik: Genau wie du es gerade gesagt hast und noch schlimmer, um es wirklich jetzt mal deutlich zu machen, ist es ja eine Realität. Im Worst Case hast du noch in einer anderen Unternehmung konkurrierende Prioritäten, wo du sagen musst, okay, für die nächsten zwei Wochen ist aber das noch wichtig, und hier soll das noch gemacht werden. Das muss in die Vision eingepflegt werden, obwohl das irgendwie alles nicht Teil war, aber der User sich das gewünscht hat. Du hast halt so viele organisatorische Hürden, plus die ganze Kommunikation mit dem Team, hat es jeder richtig verstanden, ist nicht einer im Urlaub, der ist morgen wieder da, der soll es aber im Frontend machen und so weiter und so fort. Da bist du im Grunde hauptsächlich mit Kommunikation unterwegs und weniger mit Ausliefern und mit dem Kunden sprechen und Lösungen, vielleicht bessere Lösungen finden, als das, was du dir ursprünglich überlegt hast. Nämlich auch das ist ein bisschen ein Teil davon, hey, spielen wir einfach mal mit ein paar Dingen rum, mit ein paar Tools rum, die die eine Funktion, die vielleicht viel noch mal stärker vereinfachen? Oder können wir das irgendwie mit Magic, mit Staticity lösen an verschiedenen Stellen? Was wir auch oft gemacht haben, weil wir einfach die Zeit hatten. Wir haben mal gesagt, die Delivery kostet uns wenig Zeit. Da ist es jetzt locker wert, einen halben Tag einmal darauf zu verschwenden, das eine und das andere Tool damit anzubinden und damit zu versuchen, dass es noch einfacher geht. Würdest du in einer normalen Entwicklung wahrscheinlich so nicht tun, weil schon die normale Entwicklung lang genug dauert, mit allen Iterationen, Zyklen, QA und so weiter und so fort, das so zu tun. Und das ist ein Mindset, was ich sehr zu schätzen... Nee, das ist ganz klar untertrieben, wo ich gesagt habe, das verändert, wie wir Software bauen in Zukunft. Du hast eine Frage auf der Zunge, sehe ich gerade.

Jan: Nee, also gar keine direkte Frage, aber ich überlege auch gerade, wie ich dieses Konzept zu greifen kriege. Weil du hast vorhin auch gesagt, dann muss ich viel weniger discoveren und so. Und es stimmt ja auch. Discovery ist am Ende ja dann, also Discovery im Sinne von, ich mache das nicht mit echter Software, ich discovere nicht am lebenden Herzen, sondern ich discovere, indem ich Click-Dummies baue, Prototypen baue, et cetera. Qualitative Nutzerforschung und alles, was dazugehört, Artiation-Prozesse, die typische Design-Thinking-Badewanne. Das alles mache ich ja eigentlich, um zu vermeiden, dass ich teure, viel teure Ressourcen in die Hand nehme, weil ich basierend auf wackeligen Annahmen einfach etwas baue. Weil die Annahme bisher immer war, bauen ist der teure Punkt in unserer Gleichung. Wenn bauen jetzt aber nicht mehr der teure Punkt in der Gleichung ist, muss man sich natürlich schon grundsätzlich die Frage stellen, was ist denn der limitierende Faktor? Und wenn man es dann in dem Fall, den du gerade nennst, also ich rede jetzt noch nicht von irgendwie, wir haben etablierte Software und da gibt es auch was zu verlieren, sondern in dem Fall von wir bauen wirklich neue Prototypen, wir bauen nur MVP für was, was es noch nicht gibt und wissen noch gar nicht, ob es in irgendeiner Form funktioniert. Wir müssen dann glaube ich als Produktleute schon aufpassen, dass der limitierende Faktor nicht wird, dass wir zu langsamen Discoveren und unseren User-Tests nicht hinterher kommen, wenn das Bauen eigentlich nicht mehr der teure Punkt ist. Deswegen habe ich gerade so ein bisschen geguckt, weil ich mir gerade noch nicht sicher war, geht dieser Punkt genauso auf, aber ich glaube, genauso ist es oder siehst du es anders?

Hendrik: Ich sehe es ganz genauso. Alles, was wir gerade in Richtung Discovery sehen und auch in der Produktbar-Bild, jeder, der in LinkedIn drin ist, sieht halt genau die Techniken, die man sich überlegen muss, um die Entwicklung herumzutanzen. Genau wie du es gesagt hast, das ist der teure Punkt. Das will man vermeiden. Das heißt, man versucht, Proxies zu finden, um die Technik und das tatsächliche Produkt darzustellen oder den Nutzer darzustellen, die richtigen Fragen zu stellen, sodass er dir die richtigen Antworten auf ein fiktives Produkt gibt oder auf einen fiktiven Use-Case. Und es ist alles ein Getanze um die Produktentwicklung herum. Und das muss man sich wirklich noch mal deutlicher vor Augen führen. Denn wenn diese ganzen Arbeitsleistungen wegfallen, die man dann nicht mehr machen muss, und ich wiederhole jetzt gerade das, was du gesagt hast, aber das ist wirklich, das ist nicht zu unterschätzen, sondern einfach sagt, dann baue ich es einfach und gucke, wie es ankommt, weil es einfach nicht lange dauert, dann müssen wir Produktmanagement und auch einen großen Teil vom UX, vom User Research, zumindest in dem qualitativen Research-Teil wirklich überdenken. Und dessen, da bin ich wirklich mittlerweile absoluter Verfecht davon. Also auch einfach weil Produktmanager, und da können wir vielleicht nachher noch drüber sprechen, welches gilt, die sollten einfach Dinge selber bauen können, bis zu einem gewissen Teil. Und genau das einfach nicht über, also die Interviews auf Basis tatsächlich selbstgebauter Software vertesten. Und das ist der Job. Und dann gucken, was kommt dabei raus. Ich glaube, da hatte ich zwischendurch mit einem anderen Kollegen drüber gesprochen. Eine Zukunftsvision, die so nie existieren wird, aber die man sich, die vielleicht ein gutes Bild malt, ist der Vibe-Produktmanager, der vor dem Tool sitzt und im Grunde hat das ganze Tool gepromptet, hat vielleicht drei Tage damit zugebracht, irgendwas zu bauen, irgendeinen Use-Case zu bauen, indem er einfach davor gesessen hat und mit dem Tool gesprochen hat. Und ein Agent hat das gebaut. Und dann, was er macht, er release das Ganze. Er kümmert sich darum, dass die Informationen an die potenziellen Nutzer kommen. Er ist vielleicht in Communities unterwegs, spricht mit Nutzern, sagt, hey, ich habe hier was Neues gebaut, guckt mal rein, schreibt Newsletter, lädt Leute ein, tut, was halt ein Marketing-Go-to-Market-Spezialist machen würde. Nutzt vielleicht ein Go-to-Market-Tool, die auch größtenteils mittlerweile auf KI basieren. Und sammelt Feedback ein, basierend auf neuen Registrierungen, neuem Userverhalten in den Tools drin. Weil du kannst einfach sagen, bau bitte Tracking mit ein und zeig mir das hier bitte an, in der Atmungansicht. Basierend darauf, Vibe-Coded, also prompted er weitere Features. Und das ist ein Cycle. Und am Ende wird er daran gemessen, was am Ende, also am Outcome, nämlich an den Nutzern, die, an der Retention kommen die Nutzer wieder, an der Monetarisierung. Kaufen sie, wenn es noch mal was zu kaufen gibt, je nach Produkt, was noch mal für eine KPI man als Ziel hat. Aber sie können, er kann sich tatsächlich auf das eigentliche Outcome konzentrieren, wo aktuell die Diskussion so abstrakt zu führen ist, weil das Outcome so weit weg ist und hinter der Delivery versteckt ist. Und das ist, glaube ich, etwas, ich weiß nicht, ob du dahin kommst zu dem Punkt, aber das ist ein Bild, während ich das in Replet gepromptet habe, das Tool, was mir einfach nicht aus dem Kopf gegangen ist.

Jan: Ja, so ein wirklich super spannendes Bild. Und ich glaube, in vielen Kontexten wird das ohne Frage super, super viel verändern. Weil wenn wir mal rauszoomen, wofür sind denn die ganzen best practices der modernen agilen Welt da? Also am Ende geht es ja darum, eigentlich schneller von der echten Welt zu lernen, was wir tun müssen, um Geschäftsziele zu erreichen. Und wenn wir jetzt Techniken haben, die es uns erlauben, diesen Arbeitsprozess ganz anders zu denken und dieses eigentliche Lernziel und Iterationsziel viel schneller zu erreichen, dann ist das, glaube ich, was, mit dem wir uns alle mal befassen sollten.

Hendrik: Ja, also deswegen hatte ich versucht, das in irgendeine Form zu gießen. Und deswegen habe ich gesagt, ja 360-Grad-Produktmanager, so ein bisschen aus mir selber gesprochen, weil ich Spaß daran hatte, selber zu bauen. Aber das ist tatsächlich ein Bild, was einem hilft, das einzuordnen und auch vielleicht so die eigene Rolle in Frage zu stellen. Du kannst mehr machen als vielleicht noch davor vielleicht.

Jan: Ja, vielleicht gehst du auf den Begriff mal ein 360-Grad-Produktmanager. Was genau meinst du damit und was ist da die neue Qualität?

Hendrik: Im Grunde genau die Vermeidung. Also sagen wir in frühen Phasen von Produkten. Also wir bauen, wir haben ein neues Produkt, was wir bauen wollen, was wir ausprobieren wollen. Wir haben einige Hypothesen im Raum, die wir vertesten wollen. Und das nicht mit Prototypen, sondern das mit einem Prototypen, aber nicht mit einem Paper-Prototypen, sondern mit irgendwas mit Working-Code, mit tatsächlichen Nutzern optimalerweise. Und der Stadt, wir kennen es alle, ein Produktplan, eine Vision und wie passt das zur Strategie und wie viele Ressourcen brauche ich am Anfang, einmal aufzustellen, das an 15 Stellen zu verpitschen, kann sich der Produktmanager hinsetzen und sagen, ich baue euch einen Bubble an, dann machen wir mal in zwei Wochen was zusammen. Das publishe ich, sammle die ersten Nutzer ein, kümmere mich darum, dass ich es vertestet bekomme mit ein paar, je nachdem, was für Nutzer du hast, und gucke mal, was dabei rumkommt. Und dabei mache ich im Grunde alles, was dann anfällt. Customer Support, User Interviews, das Entwickeln neuer Features und so weiter und so fort. Immer gern mit Sparring. Also du brauchst, alleine ist es eine sehr einsame Geschichte. Das heißt, du brauchst irgendwie eine andere Person, auch um so ein bisschen mehr Input zu bekommen. Zu zweit geht es schon besser, aber um das jetzt mal wirklich überspitzt darzustellen, du sparst dir jegliche Kommunikation. Nicht, dass Kommunikation schlecht ist, aber es ist immer das, wo die Produktmanager seit Anbeginn der Zeit die größten Probleme mit hatten. Nämlich, wenn du mit einem Team mit sechs Leuten kommunizieren musst, was gebaut werden soll, die ganze User-Story, wie viele Dokumentationen der Tickets brauche ich, was ist eine User-Story. Diese ganze Geschichte, welche Edge-Cases, welche Test-Cases und so weiter. Und wenn du diese ganze Arbeit statt in der Stellung der Dokumente einfach in die Stellung des Produktes steckst und die ganzen Streuverluste an Missverständnissen nicht hast, dann ist das, glaube ich, ein besserer Prozess.

Jan: Das heißt, der 360° Produktmanager macht von der ursprünglichen Ideation bis zum Launch über die Iteration alles selbst, ohne Streuverluste in Kommunikation dabei in Kauf nehmen zu müssen.

Hendrik: Ja, ganz genau.

Jan: Spannendes Bild und sicher auch ein Bild, das in der Engineering Community nicht ganz unumstritten ist oder vielleicht auch teilweise als Zukunft mit ein bisschen Sorge gegebenenfalls auch gesehen wird oder eventuell auch mit Skepsis. Viele umarmen das Thema auch. Wie ist so deine Erfahrung? Du arbeitest jetzt in einer Organisation, in der klassische Engineering Workflows genauso gelebt werden wie Arbeitsweisen mit No-Code-Tools, Arbeitsweisen mit Prompt Engineering, mit Vibe-Coding und ihr bringt die Dinge zusammen. Wie kann das in der Praxis gut funktionieren, diese beiden Welten nebeneinander stehen zu haben oder vielleicht auch ineinander?

Hendrik: Ja, nicht einfach, sagen wir es so. Und vielleicht, wie hat das Ganze begonnen? Ich habe niemand gefragt, ob wir das mal ausprobieren wollen. Ich habe es einfach gesagt, ich probiere es jetzt selber mal aus. Und da ging es schon los, damals noch nicht, weil es niemand wusste, aber im Nachhinein, hey, trifft die Entscheidung, wie was gebaut werden soll, nicht eigentlich die Leute, die Techies umsetzen hart zu, also die Entwickler. Wird die Entscheidung nicht von denen getroffen? Und da ist der erste Punkt, wo die Welten aufeinander stoßen. Aber nichtsdestotrotz bin ich immer noch dabei, und das war genau der richtige Schritt, weil ohne dass ich selber gesehen habe, dass es funktioniert, hätte ich das, glaube ich, nicht gestartet. Die Gedanken und die Einschätzung von den Entwicklern gehen in verschiedene Richtungen. Und da muss man sich mal überlegen, welche Kategorien haben wir an Gedanken. Zum einen sind das natürlich, wenn du als Entwickler hörst, okay, wir nutzen hier irgendein Tool, irgendein Tool von außen, ob das jetzt ein Third-Party-Tool ist, mit dem du irgendeine Funktionalität besser machst, oder ein No-Code-Tool, dann kaufe ich mir erstmal eine Blackbox ein. Am Ende ist ein Entwickler immer der, der es lösen soll, wenn es nicht funktioniert. Das ist ein total nachvollziehbarer Punkt, und eine nachvollziehbare Angst, weshalb erstmal eine ablehnende Haltung ist. Jeder kann den selbstgeschriebenen Code, jeder versteht den selbstgeschriebenen Code, es ist lange genug her, dass er ihn geschrieben hat. Aber eine Sache, die von außen kommt, ist erstmal sehr schwierig, und dafür habe ich vollstes Verständnis. Das ist nicht ganz einfach, und damit muss auch eine ganze Organisation fein sein. Wir hatten auch Downtimes mit den Tools, die wir angebunden haben, wo wir nichts machen konnten, wo wir dann darauf angewiesen sind, dass sie es wieder fixen. Aber insgesamt war es weniger als unsere eigenen Downtimes, weil da noch ein ganz anderer Druck hinter ist, wenn die Unternehmen gut genug finanziert sind und selber genug Wert darauf legen, dass sie funktionieren. Aber der Punkt war auf jeden Fall ein sehr großer. Das zweite Thema, was die Entwickler vorgebracht hatten, war, dass sie Angst haben, dass die komplette Arbeit damit ersetzt wird. Also die Arbeit, die sie machen, dass es ersetzt wird durch No-Code-Tools und dass sie oft keine Lust haben, mit No-Code-Tools zu arbeiten und zu sagen, es macht mich nicht besser als Entwickler. Was ich nachvollziehen kann, ist, dass ein Java-Entwickler, der zwei Jahre mit No-Code-Tools arbeiten musste, hat vielleicht den Anschluss an verschiedenen, gut, Java ist vielleicht nicht das richtige Beispiel, jetzt an Programmiersprachen, aber der hat vielleicht einen Anschluss verloren, was irgendwie den neuesten Tech-Shit angeht. Das ist ein Thema und natürlich gibt es Sicherheitsaspekte, Skalierungsaspekte, die aber mittlerweile deutlich geringer geworden sind und nicht mehr das gespenst sind, was man vor einer ganzen Weile noch dachte, dass sie sind. Gerade so Sicherheitsthemen, da sind solche Tools natürlich auch sehr hinterher.

Jan: Was sind denn die Sicherheitsthemen? Und vielleicht können wir danach auch noch mal über die Skalierungsthemen reden.

Hendrik: Natürlich ist die Frage, wie Authentifizierung, Autorisierung, wie kommunizieren Systeme miteinander? Welche Daten werden wo exposed? Was kannst du irgendwie abrufen? Und das haben Entwickler doch schon gerne bei sich und in der eigenen Datenbank. Und wie das alles funktioniert, das ist aber mittlerweile fast das, was mit am einfachsten funktioniert, weil du das sehr oft out of the box mitbekommst. Bei Bubble zum Beispiel sind die Passwörter. Du kriegst im Grunde für jedes Projekt, kriegst so eine Autorisierung, Authentifizierungsflow dazu, Password Reset und so weiter. Die Passwörter sind nicht irgendwo gespeichert. Die kannst du auch als Editor nicht sehen. Die sind in der Tabelle, die du nicht allen sehen kannst. Und nur der Nutzer kann sie zurücksetzen. Und da ist schon viel, da ist schon eine Menge Gehirnschmalz reingeflossen, genauso wie bei anderen, die sich darum kümmern, dass das nicht nirgendwo exposed werden kann. Dass du halt diesen Fehler nicht machen kannst, auch wenn du halt überhaupt keine Ahnung hast, wie das Tool funktioniert. Dass du irgendwo Passwörter im Klartext schickst. Klar, es gibt eine ganze Menge andere Sicherheitstools, gerade was Kommunikation mit APIs angeht. Wenn du dir überlegst, in Bubble eine API zu bauen, dann musst du dir natürlich auch gewissen Kriterien entsprechen. Ich weiß nicht, ob ich mit Bubble die API bauen würde, mit der ich ein Tool betreibe. Da gibt es andere Tools, Xerno und Co., wo du großartige Backend-Systeme und Datenbanken skalierbar darstellen kannst, die genau, out of the box, einige Sicherheitsfeatures mitbringen. Da ist die Frage, welches Tool nimmt man dabei? Innerhalb der Bubble-Infrastruktur ist das absolut auch ausreichend.

Jan: Spannend. Wenn wir gerade schon dabei sind, Thema Skalierung hattest du gerade auch erwähnt. Manche gibt es auch Bedenken und Grenzen, aber die seien nicht mehr ganz so schlimm wie früher. Was hat es damit auf sich?

Hendrik: Vor zwei Monaten habe ich auch noch gesagt, Skalierung ist der Punkt, wo es vielleicht wackelt. Nehmen wir eine Bubble, eine hinreichend große Plattform, wo du eine ganze Menge User drauf hast. Wir haben seit einem Jahr eine Plattform im Einsatz, die komplett auf Bubble gebaut ist. Es sind mittlerweile 3.000 Nutzer drauf. Das ist eine Plattform, die heißt Ember, wo man sich Projekte anschauen kann, Unternehmen, die verkauft werden und da Interesse bekunden und so weiter. Und völlig innerhalb der Plattform chatten, Nachrichten austauschen und dann auch mit dem Berater kommunizieren kann. Und da haben wir keinerlei Skalierungsthemen bisher. Also die Bubble skaliert hervorragend und es gibt mittlerweile Backend-Lösungen. Ich hatte eben Xerno angesprochen, wo du oder die sich speziell auf diesen Case eingeschossen haben, gesagt haben, wir bauen eine No-Code-Lösung, wo du auch Backend-Workflows definieren kannst. Von wegen, ob das jetzt Cron-Jobs, also regelmäßig laufende Jobs sind oder wenn das, dann das. Und das wirklich skalierbar zur Verfügung stellst für Frontend-Systeme, wie WeWeb zum Beispiel und auch Bubble, wo du quasi davor setzen kannst, was du möchtest. Wo die Kommunikation aber mehr oder weniger nativ schon miteinander zusammengeführt ist. Also du hast meistens, wenn du ein Frontend-Tool hast oder ein Backend-Tool hast, hast du, gibt es eine Anzeige, welches Tool möchtest du hiermit verknüpfen? Also welches Frontend-Tool möchtest du an dieses Backend-Tool knüpfen? Und andersrum, für ein Frontend-Tool, welches Backend-Tool möchtest du nutzen? Weil die davon leben. Das ist deren Business. Die leben davon, dass es ihnen jeweils anderen Teile gibt. Das macht es auf der einen Seite auf jeden Fall skalierbar, auch weil du bis zum gewissen Punkt, ich bin immer vorsichtig, was absolute Aussagen angeht, aber es macht es wirklich bis zum ordentlichen Punkt skalierbar. Weil du im Zweifel auch sagen kannst, okay, dann ziehe ich meine Daten vom einen Backend ins andere. Wir wissen alle, wie schwierig Migrationen sind. Ob das denn wirklich so einfach ist, ist ja eine andere Sache. Aber das ist alles möglich. Und es gibt viele, viele Player, die sich genau darauf einschießen, weil das genau die Marktlücke ist, die bedient werden muss.

Jan: Okay. Und wir sind, danke für die Klarstellung. Wir sind da ja eigentlich drauf gekommen, weil wir so an der Frage waren, wo reibt es mit einer klassischen Engineering-Kultur? Und da hattest du erwähnt, es gibt einerseits das Thema Rollen und Werteverständnis. Wer ist eigentlich für was zuständig? Wessen Aufgabe ist was? Das bricht auf. Wir haben das Thema, das ist eine gewisse Blackbox, die Ärger machen kann und man weiß gar nicht genau, warum. Und jetzt hatten wir gerade die Skalierungs- und Sicherheitsaspekte. Weitere Aspekte, wo man auch gewisse Säubelstellen in der Orga hat?

Hendrik: Wir haben oder tatsächlich gerade überlege ich mir, wie kriegen wir ein, ich will mal sagen, ein klassisches Scrum-Deal zusammen mit freien Radikalen, die halt als Citizen-Engineer selber ihre Tools zusammenbauen. Will man das überhaupt? Es gibt Abhängigkeiten. Man will die Leute menschlich zusammenbringen, dass sie sich miteinander austauschen, dass der eine auch von seinem Projekt erzählt und da ein bisschen mehr mit reinbringt. Das ist etwas, was wir schaffen möchten, auch weil unsere Tools alle miteinander kommunizieren. Also unsere Dashboards kommunizieren alle mit unserem großen internen System, was die Endpunkte zur Verfügung stellt. Und wie man die, ich will nicht sagen Welten, weil so weit ist es nicht, aber wie man die verschiedenen Charaktere miteinander zueinanderbringt, das ist noch eine Frage. Was gerade sehr gut funktioniert, dass wenn du Engineers hast, vielleicht nochmal zurück, wir haben das Tool damals, das Exit-Tabelle auf Steroiden, mit einem Herkarton gestartet. Und da haben zwei Kollegen miteinander gearbeitet, nämlich der Entwickler, der diese Verknüpfung hergestellt hat und der, der das Tool konfiguriert hat und genau dieses Prompt-Engineering gemacht hat. Die beiden arbeiten hervorragend frei miteinander, ohne dass ich da großartig oder dass ein Produktmanager bei uns irgendwas zutun müsste, sind selber aktiv, ohne dass sie gemanagt werden müssen. Weil der Nutzer am Ende, der Kollege, der es konfiguriert, ist am Ende auch der Nutzer mehr oder weniger. Das heißt, wir bauen es nicht für jemand, sondern er baut es mehr oder weniger für sich selber. Und das ist ein großer Shift. Aber diese, dass die nebenbei selber agieren können, während das andere Team einen Stand-up, einen Daily hat und einen Stand-up und so weiter, das sind noch Dinge, von denen ich auch noch nicht weiß, wie sie final aussehen oder wie sie in einem Jahr aussehen, wenn wir vielleicht noch weitere Teile separiert haben oder hinzugefügt haben. Bisher ist es auf jeden Fall alles unter einem Dach und am Ende erfüllt es alles einen Zweck. Und das ist vielleicht auch so von der strategischen Ansicht nicht unrelevant. Am Ende haben wir ein Resultat und ein Outcome. Das wird vielleicht in verschiedenen Tools oder in verschiedenen Produkten erschaffen, ob das jetzt ein Third-Party-Tool ist oder unser internes Tool. Aber am Ende führt es dazu, dass wir eine gute Liste erstellen. Und das ist im Grunde alles ein Team. Und das muss auch dem Team klar sein, den Entwicklern, den No-Code-Engineers, den Promt-Engineers. Das ist der Spirit, den du eigentlich haben willst. Und die Interdisziplinär, das ist tatsächlich mehr Interdisziplinär als nur Front- und Back-End zusammenzukriegen, zum Beispiel zusammenzukommen. Das ist jetzt noch eine Herausforderung. Mein Plan ist für dieses Jahr mehr Hackathons anzusetzen und zu sagen, wie können wir etwas lösen? Überlegt euch, welche Technologien ihr einsetzen wollt, um vielleicht auch eine Distanz zu überbrücken.

Jan: Das geht vielleicht auch ganz gut in die Richtung meiner nächsten Frage, weil wir haben gerade darüber geredet, wo reibt es viel? Du hast gerade schon den ersten Ansatz genannt, wie man Dinge lösen kann. Du hast dabei bestimmt ja auch noch mehr, wenn ich jetzt in meinem Unternehmen sage, ich will jetzt mal ein Projekt starten, wo wir mit No-Code oder mit Vibe-Programming eine Lösung für ein kleines Problem iterieren und an den Start kriegen. Welchen Tipp würdest du den Leuten mitgeben, die das das erste Mal probieren?

Hendrik: Such dir Leute, die darauf Lust haben. Die müssten wirklich davon überzeugt sein. Du kannst wenig den Leuten sagen, mach das mal. Also gerade auch Entwicklern, viele Entwickler haben da Lust drauf. Und es gibt sehr, sehr viele, die sagen, ich wollte ich immer mal angucken, da wollte ich immer mal tiefer reinsteigen. Und in Zweifel mach selber. Also ich glaube auch die Magic und die Überzeugung, warum das so gut funktioniert, kommt erst daher oder entsteht erst dann, wenn man selber gemerkt hat, warum das ist gut funktioniert. Deswegen sei dabei, mach es vielleicht als Hackathon. Also unser Start war tatsächlich nicht, weil ich jetzt irgendwie das super gewusst hatte, dass es genau das ist Mitte der Wahl, sondern ich wusste nicht einfach ranzugehen. Das war genau richtig. Such ein paar Leute zusammen von denen, wenn du meinst, die Bock darauf haben, gibt ihnen ein paar Tage Zeit, gibt vielleicht ein paar Tools mit, die in Frage kommen können und lebt mal los. Allerdings brauchst du dafür halt Zeit. Also auch zur Vorbereitung darauf, die zwei Wochen, die ich mir rausgeschnitten habe, das war natürlich schmerzhaft. Und auch als ich mir an Bubble gesessen habe, habe ich auch von meinen Chefs gesagt bekommen, hey, hast du nicht besseres zu tun, als dir die ganze Zeit mit dem Kollegen dieses Tool zu bauen? Da habe ich gesagt, nee, das ist tatsächlich gerade das, wo die Ressourcen richtig investiert sind. Denn das entscheidet, wie wir Produkte in der Zukunft bauen. Und das ist die eine Entscheidung, die viele andere Entscheidungen überflüssig macht. Und wenn da was Gutes rauskommt, dann wird es den Hebel umsetzen. Und das war eine Argumentation, der sie nicht widersprechen konnten.

Jan: Ja, das Argument gefällt mir sehr gut. Wir haben jetzt viel über Möglichkeiten gesprochen. Viel, glaube ich, auch über Dinge gesprochen, die für Leute, die selbst noch nie ausprobiert haben, mit solchen Tools zu arbeiten, ziemlich überraschend klingen. Und wir haben den Appell auch vernommen, jeder sollte das mal ausprobiert haben, um auch zu verstehen, welche Möglichkeiten tun sich da eigentlich auf. Dennoch ist es ja wahrscheinlich so, dass diese Art Produkte zu bauen für manche Zielgruppen relevanter ist als für andere. Wem würdest du denn besonders ans Herz legen, sich da am besten schon gestern mal mit befasst zu haben? Und bei welchen Rollen und in welchen Kontexten sagst du auch, naja, hier ist es vielleicht wirklich noch kein Thema.

Hendrik: Meinst du mit Rollen Produktmanager, Entwickler, Designer?

Jan: Ich meine, das, ich dachte aber auch ein bisschen an, in welchen Kontexten bewege ich mich, also bin ich ein Start-up, bin ich ein Konzern, also ein bisschen eine Mischung aus beidem. Und ich habe es bewusst ein bisschen offen gehalten, weil du da mehr Erfahrung drin hast, zu wissen, was da die entscheidenden Faktoren sind.

Hendrik: Ja, also ich würde sagen, jeder, der an Produkten arbeitet und mit Produkten arbeitet und mit Ideen konfrontiert ist, wie man Dinge bauen kann, muss da reingucken. Das ist, natürlich hat nicht jeder Konzern jetzt, na doch, wenn man es anders formuliert, jedes Unternehmen. Ich habe es noch nie erlebt, dass es in einem Unternehmen keine Ideen gibt, was man nicht noch Neues, Schickes bauen könnte für die Kunden, für die Nutzer. Es gibt immer zu viele Ideen und immer zu wenig Kapazitäten, Dinge zu bauen. Man mag mir widersprechen, wenn jemand ein anderes Beispiel findet an Unternehmen. Die Fragen sind eher, was ist das Wichtigste und wo sind die Opportunitätskosten, nicht vielleicht zu groß, das anzugehen. Aber genau vor dem Hintergrund, auch von einem Konzern, kann man kleine Beibote, man muss sich keine Start-ups kaufen, um kleine Beibote zu bauen, sondern man kann einzelne Personen abstellen oder zwei Personen abstellen. Die Kosten des Experimentierens sind extrem reduziert und mal mit etwas starten. Man könnte auch eine ganze Plattform, die irgendwie existiert, nachbauen. Da bin ich auch der Meinung, dass das sehr wahrscheinlich ist, dass viele Start-ups den Weg gehen und etwas nachbauen, was aktuell schon existiert, aber wesentlich schneller sind und wesentlich dynamischer sind, Dinge ein- und nachzubauen und damit andere bestehende Player überholen. Aber das wäre ein Argument dafür, auch für Enterprise-Größen damit reinzusteigen. Produktmanager auf jeden Fall, also rein jetzt von der Rolle her, jedes Start-up sollte sein Produkt erst in No-Code bauen, auch als VC würde ich glaube ich keine Pitches entgegennehmen, wo der Founder nicht mindestens schon mal ersten Low-Code-Working-Prototype aufgesetzt hat, um ein gutes Gefühl dafür zu bekommen, wie es aussehen soll. Und vielleicht sogar die ersten Kunden schon ongebordet hat. Also mir würde nichts einfallen, weshalb ich darauf verzichten sollte als VC. Jeder hat viele Ideen, die in Unternehmen kursieren. Also wir haben noch einige andere Ideen, wo es mir im Grunde in den Fingern juckt, zu sagen, ok, jetzt bauen wir da einfach mal los. Wo ich eigentlich versuche, auch als Support-Mitarbeiter, als Spezialist für irgendetwas, die Leute zu begeistern und empowern, sich selber ranzusetzen. Ein, vielleicht zwei Wochen Urlaub zu nehmen und dann einmal einzusteigen. Und nach zwei Wochen kann man tatsächlich eine ganze Menge mit den Tools und das selber aufzuziehen. Das ist, glaube ich, der beste Karriereschritt, den man machen kann. Und zu sagen, ich habe hier mal was gebaut, das funktioniert und ich weiß genau, dass es gut ist, weil ich selber der bin, der es am Ende haben will. Ich habe damals meine ersten Python-Schritte, da habe ich mir über die Osterferien zwei Wochen Urlaub genommen und habe den ganzen Tag mir die ersten Python-Sachen reingezwiebelt. Das war die beste Entscheidung ever. Also kann ich jedem nur nahelegen, die Zeit ist nirgends so besser investiert, als einmal zwei Wochen da reinzusteigen. Und im Gegensatz zum tatsächlichen Programmieren reichen zwei Wochen heutzutage. Und es gibt keine Ausreden, mehr das nicht zu tun. Also vor allem diese Citizen-Engineers, Support-Mitarbeiter, Vertriebler, Fachleute für gewisse Themen, die können ihre Ideen umsetzen. Und natürlich sind es Produktmanager, die mehr damit konfrontiert sind, die richtige Idee herauszufiltern. Und das Optimum davor schon abzutesten. Und in anderen Kategorien vielleicht besser ausgebildet sind. Aber im Grunde kann es jeder. Das ist Vor- und Nachteil, weil es natürlich auch zu einer Produktinflation kommen wird. Aber da jetzt sind wir im Meta.

Jan: Das stimmt aber. Also der Grundappell, jeder in unserer Branche sollte sich zumindest mal eingehend damit befasst haben, um zu wissen, was möglich ist. Und um Erfahrungen da drin auch für die eigene Karriere und für das eigene Skillset zu sammeln. Wir haben eine ganze Menge Tools heute aufgebracht. Links übrigens in den Show-Notes. Wenn ich mir jetzt zwei Wochen freinehm, ich bin jetzt Zuhörer oder Zuhörerin, ich habe den Appell gehört, ich nehme mal zwei Wochen, ich fuchs mich da rein. Die Tool-Landschaft entwickelt sich sehr schnell. Wo würdest du Stand heute sagen, da kann man einen guten Einstieg finden?

Hendrik: Das ist egal. Also nicht ganz. Es ist wichtig, dass man anfängt und dann wird man sehr schnell sehen, was man interessant findet. Man wird Grenzen kennenlernen. Das Wichtige ist, dass man etwas hat, was man bauen möchte. Also du brauchst irgendeine Idee. Ich habe letztens mit einer Produktkollegin gesprochen, das ist schon eine ganze Weile her. Die hat gesagt, ich würde mal eine Weinenhandelsplattform diskutieren über Weine oder so etwas gerne bauen. Und jetzt wäre meine Antwort, dann bau das. Dann bau das mit einem sehr einfachen Tool. Da kann ich einem Software nahelegen, mit einem Airtable oder Notion-Backend. Und setze ich am Wochenende ran. Das wird reichen, um die ersten Sachen darzustellen. Also das reicht für Software sehr locker. Für Bubble braucht man die zwei Wochen. Das ist tatsächlich tricky am Anfang. Es ist ein bisschen wie Photoshop. Allerdings kann man da halt auch skalieren, je nachdem, wie kompliziert man es haben möchte und welche Funktionalitäten, welche Richtung man gehen möchte. Es gibt sehr, sehr viele YouTube-Videos, die unglaublich viel erklären. Also es gibt keinen Mangel daran, Lösungen zu finden, wenn man auf Grenzen stößt. Das ist im Programmieren auch sehr viel anstrengender gewesen. Mittlerweile mit JetGPT auch machbar. Aber auch für diese Tools kann man JetGPT nutzen, um zu fragen, wie kriege ich das dargestellt. Also das ist auch von daher, ich glaube, meine wirklich meine erste Empfehlung wäre Software und Airtable oder Software und Notion.

Jan: Aber relevanter noch, mach dir klar, welche Idee du einmal umsetzen willst.

Hendrik: Genau, weil du wirst dann sagen, wenn das jetzt schon so schnell, wenn ich mit Software und Airtable mache, das ging irgendwie schon, keine Ahnung, in fünf Stunden habe ich etwas erschaffen und gesagt, okay, da sind es aber die Grenzen, aber es funktioniert. Dann gehe ich nochmal zu Bubble und versuche es damit umzusetzen. Und da sehe ich, ich komme weiter und ich komme bis zu der und der Funktionalität. Und dafür bilde ich jetzt noch ein weiteres Tool ein und kann das irgendwie im Hintergrund machen. Also das ist genau die Journey, die man braucht, um auch ein gutes Verständnis dafür zu bekommen. Dann kommt man von Höckchen zu Stöckchen.

Jan: Ja, super spannend. Also Appell an alle, probiert es aus und lasst uns wissen, was ihr dabei gelernt habt. Ich glaube, das ist wirklich ein super spannender Schritt für unsere Professionen und unsere Arbeit, der da im Moment sich vollzieht. Bevor wir gleich in die schnellen Schlussfragen übergehen, Hendrik, wir haben jetzt knapp eine Stunde, ein bisschen über eine Stunde darüber geredet, was ihr bei DealCircle schon macht, außerhalb der klassischen Engineering-Prozesse. Wir haben darüber geredet, wie man No-Code und Vibe-Programming mit klassischen Programmieren verbindet. Wir haben gerade darüber gesprochen, wo man einen Anfang machen kann, wenn man sich selbst in die Thematik einarbeitet. Was möchtest du vielleicht dem Gespräch noch hinzufügen, bevor wir den Haken an unseren Hauptteil machen?

Hendrik: Ich glaube, jeder, der dieses Gefühl in der Magengegend hat, dass er sich ein bisschen verloren fühlt, wenn er ein Produkt bauen soll, weil er es nicht selber tun kann. Für den ist es etwas, was er unbedingt tun muss und wo so eine Woche, zwei Wochen Urlaub genau das Richtige sind. Also, das machen ist in dem Fall das absolut Wichtigste. Und das ist immer schwierig, weil es gibt diese Diskussion, wie technisch muss ein Produktmanager sein. Das geht jetzt nämlich genau in die Richtung. Es ist eine Art technisch, nicht so technisch, dass man selber einen Syntax von einer Programmiersprache und so weiter mit kennen muss. Aber es ist schon ein wichtiges Tool. Und gerade sind die Tools für Produktmanager eher Miro, Jira und whatever es noch für Mindmapping-Tools gibt, für irgendwelche Canvases und so weiter. Aber das ist ein Toolstack, der bisher neu ist und den noch zu wenig Leute nutzen. Und ich glaube, wenn man es nutzt, hat man jetzt noch die Möglichkeit, von anderen ganz klar abzuheben. Dann auch jetzt mal auf den nächsten Job geschielt. Jeder, der irgendwo neu einsteigt. Wir sind gerade nicht in der optimalsten Umgebung für tolle Schritte. Jeder kann sich überlegen, wenn ich ein Unternehmen im Kopf habe, wo es mich hintreiben würde, was ich unglaublich spannend finde. Was so einen Unterschied macht, ist, wenn ich mit einem CV hingehe und sage, ich bin irgendwie interessiert, habe tolle Motivation mit teilzunehmen, oder man baut einfach irgendein Tool, von dem man weiß, weil man eine Passion für das Thema hat, was irgendeinen Use-Case abdeckt. Damit bewirbt man sich. Das ist eine ganz andere Diskussion. Du bist in einer Use-Case-Diskussion und weniger in einer sehr abstrakten. Könnte das was sein für ein Unternehmen mit einem Anschreiben, wo jeder weiß, wie ekelhaft Anschreiben sind? Das ist ein schreckliches Mittel und das würde viele Diskussionen, das nehme ich so ein bisschen mit aus meinem Scraper damals, wo ich mit Python diesen Scraper gebaut hatte. Das ist eine andere Diskussion, in der man dann ist.

Jan: Ja, fantastische Idee. Danke für den Gedanken. Wollen wir in die schnellen Schlussfragen übergehen?

Hendrik: Ich bin gespannt.

Jan: Alles klar. Nummer eins. Welches Produkt, digital oder physisch, hatte ich zuletzt so richtig begeistert?

Hendrik: Ich würde jetzt sagen, es ist schwierig und verlockend zu sagen, diese ganzen No-Code-Tools sind einfach gerade diese Dinge. Und da ist das Problem, da kommt jede Woche ein neues raus, was einen begeistert, ob das jetzt die neue GPT-Version ist oder sowas. Das ist mein Problem. Ich bin gerade begeistert, mich zu viele Produkte und jede Woche neu, weshalb ich nicht dazu komme, die gut genug auszuprobieren. Von daher, wenn das die Frage beantworten würde.

Jan: Es ist ein Technologiestrang, der dich im Moment am stärksten begeistert.

Hendrik: Es ist irre und ehrlich gesagt, ist das gerade das Management von diesen, also das persönliche Mindset-Management dieser neuen Tools, die aufploppen, im Wochentakt ist das die größte Herausforderung für mich persönlich, sich da zu fokussieren und das ist das Richtige. Es sollen schnelle Fragen sein, ne?

Jan: Jaja. Insofern weiter. Welcher private Bereich deines Lebens ist am stärksten durch die Produktarbeit beeinflusst?

Hendrik: Im Grunde, ich baste privat auch so viel, das geht. Also das ist wirklich ein Hobby für mich und ich nutze da alles, alle Tools, mache ein bisschen Freelancing und baste da irgendwas auch da auf dem Laufenden zu bleiben. Das ist im Grunde, ja, das würde ich als privat bezeichnen.

Jan: Was ist das beste Fachbuch, das du je gelesen hast?

Hendrik: Das ist eine gute Frage. Ehrlich gesagt, die sind alle okay. Es ist keins, was mich jetzt richtig von den Socken haut. Alle haben eine Aussage, die sie treffen. Da ist man bei der Hälfte ungefähr dabei und danach nimmt die Spannungskurve hart ab. Ich lese Fachbücher selten durch. Ich kann mich ehrlich gesagt an keins erinnern, was ich wirklich von vorne bis hinten durchgelesen habe, weil ich dachte, die Story ist so gut. Fachbücher hält sich in Grenzen. Also könnte ich dir keinen Beispiel geben.

Jan: Also auch hier gilt einfach machen.

Hendrik: Ja, genau. Und auch aus der Hand legen, wenn es scheiße ist.

Jan: Fairer Punkt. Es sind ja auch wirklich nicht alle gut. Wie steigt man heute am besten ins Produktmanagement ein?

Hendrik: Indem man selber irgendwas baut, und tatsächlich die Founder's Journey erlebt und ein Produkt sowohl baut als auch sich überlegt, wie man es vermarktet und das im Gespräch erzählt. Habe ich letztens, ich habe ein Gespräch mit jemandem geführt, wo ich glaube, die Person hat eine kolossale Chance, als Produktmanager erfolgreich zu sein, weil er genau das gemacht hat. Und nicht dieses verkopfte Produktmanagement, welche KPI ist jetzt die relevanteste und wie kriege ich jetzt diesen Discovery-Prozess perfekt hin. Wie baue ich ein Produkt from scratch? Nicht bauen im Sinne von wie setze ich es zusammen, sondern was bedeutet das alles? Community, wie begeister ich Leute, wie ist die Brand davon und so weiter und so fort.

Jan: Okay. Und wenn wir jetzt mal raussoomen von den Themen, die wir heute besprochen haben, also wir lassen mal No-Code und Vibe-Programming außen vor. Was sind die wichtigsten Dinge, die ich berücksichtigen kann, um langfristig als ProduktmanagerInnen erfolgreich zu sein?

Hendrik: Das ist eine gute Frage. Ich glaube, das spricht jetzt auch genau für diese Themen. Du musst am Nabel der Zeit sein. Also gerade, also als Produkt, es ist eher, je höher man aufsteigt in einem Job und je weiter weg man vielleicht auch von den eigentlichen Discovery-Delivery-Themen ist, desto mehr geht es darum, sich genau zu überlegen, wie baue ich morgen und in der Zukunft Software und nicht nur Software, sondern wie baue ich in der Zukunft Produkte und bringe die an den Mann. Und da passiert halt kolossal viel. Wir sind in einer Zeit, die letzten zehn Jahre oder letzten, was weiß ich, viele Jahre nicht da gewesen ist. Aber du musst dir an der Stelle die Zeit nehmen, in verschiedene Themen tiefer einzusteigen, wenn du siehst, dass es gerade relevant wird. Also lifelong learning.

Jan: Lifelong learning, nehmen wir mit. Vorletzte Frage. Was ist der beste Ratschlag, den du je bekommen hast professionell?

Hendrik: Das ist von meinem Vater, der gesagt hat, bilde dich so, und das passt so ein bisschen zu dem, was ich davor gesagt habe, bilde dich so gut, es geht fort. Das heißt also auch so ein bisschen lifelong learning. Also das scheint sich irgendwo verfestigt zu haben.

Jan: Okay, sehr schön. Und die letzte. Gibt es eine Frage, die ich dir nicht gestellt habe heute, von der du aber gewünscht hättest, dass ich sie dir gestellt hätte?

Hendrik: Ach, das ist eine gute Frage. Ich glaube, wir haben über vieles gesprochen. Hm, nee, ich glaube, das kann ich mit Nein erst mal beantworten. Ich glaube, in viele dieser Themen kann man unglaublich tief einsteigen. Und da gibt es genug Raum für Diskussionen und Erfahrungsberichte. Das ist, glaube ich, das Spannendste dabei. Aber wir haben, glaube ich, eine ganz gute Ebene.

Jan: Alright. Ja, damit sind wir am Ende unseres Gesprächs, Hendrik. Vielen herzlichen Dank von meiner Seite. Ich habe auf jeden Fall einiges mitgenommen. Ich werde auch einiges ausprobieren und ich kann mir gut vorstellen, dass das auf unsere HörerInnen ebenso zutrifft. Wenn sich jemand zu dem Thema mal mit dir austauschen möchte, kann man sich dabei melden?

Hendrik: Unbedingt. Wie man gemerkt hat, bin ich Überzeugungstäter und spreche da unglaublich gerne drüber. Und ich habe auch einen eigenen Nutzt. Das heißt, wenn mir jemand erzählt, ich habe das und das probiert und ausprobiert und das hat funktioniert, dann nehme ich das mit und muss es nicht selber oder weiß, dass es funktioniert und kann es nachbilden vielleicht und für uns anwenden. Von daher habe ich da auch einen Nutzen. Freue mich, darüber zu diskutieren, neue Tools zu entdecken und von Use Cases zu hören. Also richtig gerne spreche ich mich gerne an.

Jan: Klasse. Ich bin gespannt, was du baust.

Hendrik: Ich bin gespannt, was du am Ende baust. Davon wollen wir auch alle hören.

Jan: Ja, danke. Also vielen lieben Dank, Hendrik und allen da draußen. Schönen Tag noch.

Hendrik: Macht's gut.

Jan: Das war die sechste Produktkraft-Folge. Vielen Dank nochmal an Hendrik. Und vielen Dank natürlich auch an Tim Nippert, der wie immer das Audioengineering dieser Show übernommen hat und nebenbei gesagt auch deine Audio-Produktion unterstützen kann. Ganz zum Schluss sei noch angemerkt, dass ich selbst auch freiberuflich Hilfe im Produktmanagement anbiete. Wenn du also ein Projekt hast, bei dem du Support brauchst, melde dich gerne unter jan@produktkraft.com und wir schauen, ob wir da einen Fit haben. Macht's gut!