No-Code & Citizen Developers: Die Zukunft der Produktentwicklung?

No-Code-Tools wie Bubble verändern die Art, wie Produkte gebaut werden – aber wo liegen die Chancen, wo die Grenzen? In dieser Episode von Becoming CTO Secrets sprechen Philipp Deutscher und Hendrik Hemken darüber, wie No-Code Produktmanager dabei unterstützt, Prototypen und MVPs schneller auf die Straße zu bringen.

Hendrik teilt seine Erfahrungen aus der Praxis und zeigt, wann No-Code wirklich sinnvoll ist – und wann es besser ist, doch mit Entwicklern zu arbeiten. Außerdem diskutieren die beiden, was das für die Zusammenarbeit zwischen Produktmanagement und Technik bedeutet und warum der Citizen Developer immer mehr an Bedeutung gewinnt.

Auch die Rolle des CTOs in einer Welt, die immer stärker auf No-Code und KI setzt, kommt zur Sprache. Welche Erwartungen gibt es, welche Herausforderungen entstehen, und wie verändert das die Denkweise von Tech-Leadern?

Ein ehrlicher und praxisnaher Talk über No-Code, Produktmanagement und die Skills, die man braucht, um als CPO oder CTO erfolgreich zu sein. Perfekt für alle, die wissen wollen, wie sich Softwareentwicklung weiterentwickelt – und ob No-Code wirklich die Zukunft ist.

Keywords:
Fintech, No-Code, MVP, Prototyping, E-Commerce, Produktmanagement, Digitalisierung, Technologie, Hendrik Hemken, Philipp Deutscher, No-Code, Softwareentwicklung, Citizen Developer, KI, Produktmanagement, CTO, Low-Code, Entwickler, Technologie, Tools, CTO, No-Code-Tools, Bubble, Produktmanagement, 360° Produktmanager, CPO, Führungskompetenzen, Rapid Prototyping, Skalierbarkeit, Technologie

Transcript

Philipp Deutscher (00:00)
Hallo und herzlich willkommen zu einer weiteren Ausgabe ... Becoming CTO Secrets Podcasts. Mein Name ist Philipp Deutscher und wir reden heute mal wieder ... mit einem Executive aus der Tech-Branche. Zu Gast bei mir heute ist Hendrik Hemken. Hendrik ist CPO und Digital Product Specialist. Er hat über 10 Jahre Erfahrung in der Fintech-Branche ... ... und Unternehmen dabei geholfen, ihre Produkte ...

durch bessere Nutzer-Erfahrungen, ... durch Monetarisierungen und auch durch ... die Team-Agilität auf das nächste Level zu heben. Und wir sprechen heute über verschiedene Punkte ... unter anderem über ein Thema, ... weswegen wir uns bei LinkedIn über den Weg gelaufen sind, ... nämlich No-Code und wie man mit No-Code ... auch MVPs und Proof of Concepts bauen kann ... ... und warum man es vielleicht sogar nur noch damit tun sollte. Hendrik, es freut mich außerordentlich, dass du heute da bist und ja, vielleicht willst du noch ein, zwei Sätze ... zu dir sagen oder zu Deal Circle.

Hendrik (00:52)
Erstmal danke für die Einladung und die Einleitung. Das war iScout, mein LinkedIn-Profil. Ich bin aktuell bei Deal Circle, als CPU-Octid, du gesagt hast. Wir machen Käuferlisten für &A-Transaktionen. Das heißt also, wenn du ein Unternehmen verkaufen möchtest...

Zusammenarbeit ist, dann liefern wir dem Berater und damit auch dir als Verkäufer eine schicke Liste mit potenziellen Käufern, die die Wahrscheinlichkeit erhöhen, du und dem auch zum besten Preis los bist. Vielleicht zu mir noch ein bisschen, dass die erste Station, die erwähnenswert ist, so in der Digitalbranche, wie du das eingeleitet hast, war ein Gaming-Unternehmen, nämlich Good Game Studios, was immer noch eins der großartigsten

Netzwerke ist, was man aktuell in Hamburg haben kann, zähle ich immer noch von. Tolle Leute damals und habe da damals sehr früh ein komplett digitales Unternehmen mit skalierten Performance-Marketing kennengelernt und da auch den Einstieg ins Produktmanagement gefunden und bin dann durch die verschiedenen, durch verschiedene Fintechs durch, verschiedene Aspekte von der Fintech-Branche mitgenommen, also von Banking-Apps über

Apps, Kreditportale und jetzt auch Corporate Fintech, wie man so schon sagen könnte. Und bin jetzt im &A gelandet. ist alles alles kolossal spannend, sehr nerdy. Man muss das mögen, hat halt seine Höhen und seine Tiefen. Aber ja, finde ich irres spannend, immer noch und wird wahrscheinlich auch eine ganze Weile bleiben.

Philipp Deutscher (02:34)
Und was fasziniert sich so daran? An Fintech, an &A, an all diesen nerdy Themen?

Hendrik (02:38)
Ich bin ein bisschen Finanznerd auch. selber für mich, auch im Privaten. ist, weiß ich auch nicht, finde ich spannend zu planen, zu...

bestimmt viel im Alltag. Geld brauchst du an unglaublich vielen Punkten in deinem Leben und du solltest darüber an verschiedenen Punkten die Kontrolle haben und du musst damit planen für die Zukunft. Irgendwann bin ich auch mal kleiner Bankkaufmann gewesen und habe eine Hausbildung bei der Hasba gemacht und da merkt man halt wie tief auch im täglichen Doing Geld die Leute

das Leben der Leute beeinflusst, also sowohl den positiven als auch negativen und alles, das sind Schicksale und an dem Geld hängen viele Entscheidungen, hängen viele Chancen, hängen viele Möglichkeiten und ich glaube, ist so bisschen so die Breite, die Geld als Spektrum oder im Spektrum abbildet. Das ist einfach unglaublich spannend und dass man unglaublich viel mit tun kann.

Haupttauschmittel.

Philipp Deutscher (03:46)
Es hat mal

ein sehr weiser Mensch zu mir gesagt, man die Welt nur dann verstanden hat, wenn man Ökonomie verstanden hat.

Hendrik (03:54)
Ja, Mikroökonomie ist im Grunde viel Psychologie, viel logisches Denken oder die Übertragung von der Meinung auf das andere und was es bedeutet. Also gehe ich absolut mit, genauso wie Statistik. Statistik ist ja auch im Grunde jede Entscheidung, die wir am Tag treffen, irgendwie einen statistischen Hintergrund, weil wir der Meinung sind, die Entscheidung, die wir treffen, ist mit einer hohen Wahrscheinlichkeit die richtige. Und da zieht man verschiedene Variablen.

und trifft dann seine Entscheidung. Also das wird am Ende rationell runtergebrochen auf

Ja, und endet vielleicht in einer oder vielleicht monetären Entscheidung und ist dann wieder in Geld zu messen. Deswegen spannende Perspektiven, deswegen bin ich immer noch Fan. Und es tut sich gerade viel, auch gerade so die Kryptorichtung, wo dann meine Tech-Ader mit der Finanzader zusammenkommt. Ganz, spannend. ist irre gerade.

Philipp Deutscher (04:52)
Sehr

schön. Sehr schön. Ein großes Thema, was wir heute mitgebracht haben, ich habe es auch, ich, in der Einleitung schon mal angeteasert, es geht No-Code-Tools. Und wir sind über das Thema eigentlich gestolpert. Ich hatte auf LinkedIn eine Survey gestartet zum Thema, ein MVP soll entwickelt werden, du hast noch zwei Wochen Zeit, aber dir rennt irgendwie die Zeit davon, was machst du? Und mir war, ich wollte wissen, welche Antworten Entwickler mir liefern.

Da waren sehr, sehr gute dabei, sehr viele sehr, sehr gute. Und eine Antwort ist besonders herausgestochen, nämlich das war deine. Du hast nämlich als Einziger dann gesagt, naja, mach doch das Ganze mit No-Core-Tools und hier ist Bubble und damit mach ich das. Solche Tools sind anscheinend auch ein großes Thema für dich, haben wir dann auch im Vorgespräch festgestellt. Was fasziniert dich denn besonders daran?

Hendrik (05:40)
Nichtentwickler, der da geantwortet hat, bin ja auch hier in Kognitur unterwegs. Also was fasziniert mich daran? Im Grunde, dass ich endlich mal auch als Nichtentwickler mit Dingen bauen kann. Ich kann ein bisschen entwickeln, obwohl ich das nicht entwickeln im Unternehmenskontext jetzt bezeichnen würde, aber ein bisschen coden. Aber was das tatsächlich ermöglicht, ist, du erste Prototypen, erste

Philipp Deutscher (05:44)
Das kann sein, ja.

Hendrik (06:08)
Ich immer sagen, mehr als Click Dummies, also erste MVP's, selber bauen und erschaffen kannst. Im Grunde ist das, wo Produktmanager immer ein Problem mit haben, sie sind nur die Leute, sagen, dass was gebaut werden sollte, aber gefühlt nie die, die es wirklich ausführen könnten. Das nagt an mir, dass ich immer nur sagen konnte, baut das doch so und kann man das nicht einfach so.

dass es gebaut wurde und jetzt in der Lage zu sein tatsächlich ein Tour zusammen zu bauen, visuell zusammenzusetzen, fühlt sich schon irre an. vielleicht da, wo kommt das her? Wir haben vor ein paar Jahren

mal versucht, eine erste Website als Directory aufzusetzen, wo du dich durchklicken konntest durch verschiedene &A-Tools. Und das muss doch eigentlich schnell machbar sein. hat ja keine Tiefe. Es ist ja nicht besonders komplex. Du hast halt irgendwo eine Übersicht, die du vielleicht filterbar machst, und dann klickst du drauf und siehst danach eine Detailübersicht mit einem bisschen Text und vielleicht einem Link. Und das haben wir in einem Tool.

Also habe ich mit dem Marketingkollegen am Wochenende damals mal zusammengeklickt und das Tool ist heißt immer noch softer. Haben mit einem Airtable dahinter zusammen gebunden und haben in ein paar Stunden halt so den ersten Prototypen von einem Tool zusammengebaut und haben das dann dem einen Kollegen gezeigt, einen Geschäftsführer und gesagt, war das das was du meintest? So die Richtung?

Ja, das passt ganz gut. Hat natürlich dann ganz viele Wünsche gehabt, wie wir es besser machen könnten. Aber es hat genau das getan, was wir erreichen wollten, Diskussionen über was ist der Zweck des Tools, wo soll es hingehen und vielleicht auch vor allem, was soll es nicht können und was brauche es noch nicht zu können. Im Grunde, das ist ja mit das Wichtigste auch im Produktmanagement, du musst Hypothesen

vertesten können oder du willst Hypothesen vertesten, weil jedes Produkt ist in einer frühen Phase immer eine Hypothese und du weißt nicht, das sinnvoll ist, das Produkt zu bauen, die Ressourcen dafür aufzuwenden, das Produkt zu bauen. Und du bist im Grunde immer auf der Suche nach Antworten auf die Frage, bringt das nächste Feature etwas, bringt das nächste Produkt etwas. Und bisher, auch in meiner Vergangenheit, mussten wir oder sind wir immer mit

stufigen Nutzer-Tests ins Rennen gegangen. Wir haben Paper-Prototypes, wir haben mit Figma später viele tolle Sachen gemacht, weil es später in der Lage war, auch Click-Dummies zu anzuzeigen. Da hatten wir noch ein andere Tools, man auch wirklich ein paar Sachen mit Klicks dann einfügen konnte. konntest du dann irgendwie auf den Knopfdruck wird das angezeigt, aber halt ohne Daten. Ich weiß gar nicht mehr, wie das heißt. Und das ist aber immer so, du weißt

Wenn der Nutzer wirklich das Tool Vorsicht hätte, das Produkt Vorsicht hätte, würde er das vielleicht nicht sagen oder würde er so nicht agieren. Weil in diesen User Interviews ist es halt alles extrem. Es ist sehr hypothetisch und du musst die Fragen genau stellen, es ist eine Kunst auch in der User Experience, die Fragen genau zu stellen, sodass du die richtigen Antworten bekommst. Gerade wenn du halt nur einen zweidimensionalen nicht-klickbaren oder maximal vielleicht klickbaren

Brayper-Prototypen hast. Es ist sehr viel Arbeit gewesen für einen Output, der mir persönlich immer bisschen zu wenig war, für gewisse Entscheidungen. Und jetzt, nachdem man gemerkt hat, wie gut das doch geht mit aktuellen Tools, dann fühlt sich das schon sehr nach Magic an und auch, dass man viele Schritte davor vielleicht gar nicht brauchen kann.

braucht in Zukunft. würde nie wieder ein MVP oder neues Produkt starten oder auch Andenken in Discovery geben, das nicht mit No Code gebaut wurde.

Philipp Deutscher (10:09)
Aber jetzt lass

uns mal noch bei den Begrifflichkeiten ... nochmal bleiben, weil du hast gesagt Prototyping ... und dann redest du auch von MVP. Also ich bin jetzt nicht der Product Manager, aber für mich wäre das ja eine harte Unterscheidung an der Stelle. Für Prototyping hätte ich jetzt auch wahrscheinlich ... gesagt, No Code ist eine gute Lösung, ... aber setzt du es auch ein, MVPs zu bauen?

Hendrik (10:12)
Ja.

Das ist richtig.

Superpunkt. aktuell ist das auch der nächste große Schritt, der tatsächlich möglich ist. Du hast nicht nur ein Produkt, was du vertesten kannst. ist schon mal der eine. Newscast, ich beschrieben habe, von wegen weniger Interviews, ist der eine große Vorteil. Aber der nächste große Punkt ist, dass du das Produkt an den Mann bringst, also an den Nutzer bringst.

die Use Cases abtesten kannst im Betrieb, gegebenenfalls die Monetarisierung. Du siehst, was die Leute machen und du hast alles Working Code.

Das ist weit über den Prototypen hinaus. Also wir sind bei den Tools, die wir gerade im Markt haben, sind wir bei dem einen haben wir am Backend ein bisschen rumgebastelt, aber da läuft alles noch alles noch auf der No-Code-Basis und ich kenne mittlerweile viele, die auch wirklich reine No-Code-Applikationen laufen haben und immer noch laufen haben und da nicht skalieren brauchen.

Daher kommen wir vielleicht noch auf ein paar Themen. Wo sind die Grenzen von NoCoTools? Aber auch die wachsen ja immer mit. Du kannst an viele NoCoTools auch wunderbare SQL-Datenbanken anbinden. sind indexiert. Da ist ein Elasticsearch dran. Das geht mittlerweile alles. Bei manchen bedeutet das ein bisschen extra Arbeit, aber das würde es auch in einer Produktivumgebung von Custom Code

Von daher ja, nicht nur Prototypen, definitiv in Richtung MVP hinaus, denn was du vertesten willst, ja nicht nur, was finden die Leute den ersten Use-Case interessant, sondern nutzen die das Tool optimalerweise auch im Daily Doing, für den Task, den du dir für das Tool überlegt hast. Oder das Problem, was es lösen soll. Und da würde ich ganz klar sagen, mit den Tools heutzutage kommt man genau auf den Stand.

Philipp Deutscher (12:27)
Ich habe immer die Frage gestellt, wenn ich jetzt mit dem No-Code-Tool anfange. Also klar, für Prototyping ist es für mich ein No-Brain als Techie. Dafür nutze ich doch am besten ein Tool, mit dem ich mir das zusammenklicken kann. Aber spätestens, ich dann ein tatsächliches Produkt baue, dann möchte ich doch wahrscheinlich dann eher früher als später auf die richtig entwickelte Lösung umsteigen, weil ich da später gegebenenfalls sowieso hin muss. Jetzt sagst du aber, dass für euch da raus, naja, es gibt aber auch Beispiele da draußen, die sind

Produktiv mit ihrer No-Code-Lösung, mit ihrem MVP und die haben vielleicht auch gar nicht die Ansprüche, das jemals irgendwie von einem Entwickler nochmal neu bauen zu lassen, sondern die würden das gegebenenfalls weiter mit dem No-Code-Tool ausbauen.

Hendrik (13:08)
Ja, ganz genau so. Bei manchen Produkten brauchst du über die gewisse Grenze nicht hinausgehen, wenn es dann eine gibt. Und die laufen dort genauso gut wie ein Tool, das du mit jeder nativen Programmiersprache rausbringst. Absolut. Und das ist große Learning auch heutzutage. ich meine, No-Code-Tools gab schon, als ich damals angefangen habe zu programmieren. Damals noch sehr

sehr rudimentär. Aber das, was jetzt neu ist, die Möglichkeiten, die Tools zu deployen, zu verknüpfen mit anderen Tools, zu verknüpfen mit Datenbanken, mit anderen Produkten und auch zu skalieren bis zu gewissen Punkten. Der gewisse Punkt ist oftmals bei Casual-Applikationen ziemlich hoch. das ist, ich, das, ich... Ich würde sagen...

Philipp Deutscher (14:02)
Das ist für dich eine Casual-Applikation?

Hendrik (14:06)
E-Commerce Store mit mehreren Millionen Hits im Monat wäre keine Casual Applikation mehr. Also da muss man sich überlegen, welcher Menge Nutzer und Interaktion würde ich denn umsteigen und sagen, okay, da brauche ich jetzt etwas, was wirklich skaliert. Aber viele Marken

Plätze, Apps, ganz corporate Apps, interne Apps, die würde ich ohnehin glaube ich immer noch mit solchen Tools bauen, aber auch viele User-Facing Apps, die casual genug sind, die halt eben nicht diese harte Skalierung haben, die lassen sich ohne weiteres mit No-Code aufsetzen und auch skalieren bis zu dem Punkt, zu dem sie skalieren müssen. Nicht alle Produkte müssen bis in die Millionen hoch skalieren. Also ich glaube,

Es gibt da wenige, die wirklich das so ausreizen, dass man sagt, hier komme ich jetzt wirklich nicht weiter.

Philipp Deutscher (15:04)
Genau, und du hattest auch im Vorgespräch gesagt und hast das vorhin auch nochmal aufgegriffen. Du würdest nie wieder einen Prototypen bauen ohne No-Code-Tool. Was waren deine ersten Erfahrungen mit Bubble und Co? Und was war für dich das einschneidende Erlebnis, das dich dann zu dieser Erkenntnis gebracht hat? No-Code-Tools sind aus Produktmanagementsicht ...

Du, ja, State of the Art, oder das ist das einzige, du irgendwie brauchst, tatsächlichen Prototypen zu bauen, dass du nichts anderes mehr anfasst.

Hendrik (15:35)
Vielleicht zu der ersten Frage mit Bubble. Wir haben hier vor einem Jahr, vor eineinhalb Jahren, glaube ich, angefangen, erste NoCo-Tool, wie du gesagt hast, Bubble, zu testen. Damals und heute glaube ich immer noch der Platz ist unter den NoCo-Toolen, auf was von den Möglichkeiten.

Was ich gemacht habe, ich habe selber mitgetestet. Ich habe dafür auf den Deckel gekriegt, wegen, warum setzt du dich hier ran und bist hier die ganze Zeit am Basteln. Aber wir haben im Grunde einen Dashboard gebaut, was jetzt keine Komplexität hatte, nicht unglaublich tief von Richtung Workflows gegangen ist und keine komplexe Logik, sondern im Grunde einen Blick auf unsere Daten, auf unser CRM. Und das habe ich mit einem Kollegen selber gebaut, der

Entwickler war, der war Junior Entwickler.

Wenn man innerhalb dieser NoCoTools baut, auch bei Bubble trifft das zu, dann ist es relativ fix, dass du was zusammenbauen kannst mit Bubble als Datenbank. Aber was wir gemacht haben, ist, wir sind komplett auf die API gegangen, haben uns mit HubSpot, unseren CRM, verbunden oder auf die API zugegriffen und da die Daten reingeladen.

Stat gehalten und im Grunde dann darauf abfragen gemacht. Und das war für mich der Punkt, wo ich gemerkt habe, okay, geht über diesen, die Daten bleiben im Tool, werden dort verarbeitet hinaus und du kannst damit auf andere Endpunkte, auf andere Tools zugreifen und dann mit den Daten arbeiten, die Anzeigen, Filtern und so weiter und natürlich auch zurück spielen.

Das war glaube ich der Punkt, wo ich gesagt habe, okay, überzeugt. Davor hatte mein Bruder schon mal, der ist auch Produktmanager, Gruß an der Stelle, mit dem Tool oder mit Bubble ein eigenes Produkt gebaut. Das war für Remote Work, wo man gute Spots zum Remote Work eingeben konnte, also auf einer Karte und dazu Beschreibungen.

und weiter und so fort. Und hat das auch komplett von Scratch gebaut. Der auch kein Programmierer von Haus aus. Und das war irre beeindruckend. Von daher hatte ich da schon mal eine gute Erfahrung im Hinterkopf. Und wir haben einen neuen Kollegen bekommen, der auch Bubble mitgebracht hat. Das heißt also drei Datenpunkte, nachdem ich gesagt habe, das hat überzeugt an der Stelle.

Philipp Deutscher (18:09)
Und wo stößt denn der No-Code deiner Meinung nach ... noch an seine Grenzen? Oder was müsste denn passieren? Welche Anforderungen müssten denn an dich ... gestellt werden als Produktmanager? Dass du sagst, selbst nach dem, was du jetzt ... gerade gesagt hast, ich baue es jetzt doch nicht ... ... mit No-Code-Tools, sondern ich gebe es erst mal ins Dev Team.

Hendrik (18:27)
Für neue Tools und in der Prototypingphase würde ich sagen, würde ich fast alles erstmal versuchen mit NoCo zu bauen, auch weil du dadurch Use Cases gut abbilden kannst, die du danach wunderbar nachbauen kannst. Vor allem Bestandsapplikationen, die sind schwer erweiterbar. Das ist jetzt nichts Überraschendes.

Wir haben einen ganz klaren Use-Case oder ein Beispiel, was für uns nicht passen würde. Wir haben selber ein großes internes Tool gebaut, dem wir unsere Listen, unsere Käuferlisten erstellen, was viele Interaktionen in viele verschiedenen Richtungen hat und wo wir sehr detaillierte Kontrolle über States brauchen, über Statusübergänge, was ist erlaubt, was nicht.

diese Kontrolle über komplexe Systeme ab einer gewissen Größe, gewissen Logik, gewissen Tiefe sehe ich dann immer doch lieber in der Hand von Entwicklern, die da nochmal eine ganz andere Kontrolle drüber haben, als du bei einer gewachsenen No-Code-Applikation haben kannst. das ist Kontrolle, es auf Stichworte zu reduzieren, Kontrolle.

große Datenmengen und Datenmigration, die gegebenenfalls notwendig sind an verschiedenen Stellen. Datenmigration hat jeder schon mal gemacht und das ist immer unangenehm und es wird immer unangenehmer, je weniger Kontrolle man hat. Und wenn man eine No-Code-Datenbank hat, vielleicht sogar eine native, wo man schon weiß, dass man da mehrere Migrationen vornehmen muss, dann fühlt sich das wahrscheinlich nicht so gut an. Und dann hat man lieber eine Datenbank, der man weiß, okay, jeder

halbwegs kompetente Backendentwickler weiß, umzugehen. Und das ist, glaube ich, ganz großer Punkt.

Philipp Deutscher (20:25)
Ich habe dich eben danach gefragt, nachdem ... welche Form von Applikationen denn so casual ist, dass sie mit No-Code gemacht werden sollen. Dann hast du angefangen zu sagen, ... jetzt von E-Commerce Applikationen zu reden. Und ich dachte so, ja, ja, genau, E-Commerce ... ist ja eigentlich schon casual. Aber dann machst du gleich die Einschränkung, du sagst, ja, mit einer Million User drauf, ... das wäre dann irgendwie keine casual Applikation. Ich hätte jetzt aber trotzdem angenommen, E-Commerce mit all dem, was dazugehört, ist doch mittlerweile, ... da ist ja nichts mehr Cutting Edge Technology, ... das ist ja eigentlich recht ...

Natürlich musst du verschiedene Dinge anbinden, ... musst Zahlungsanbieter anbinden und so weiter. Aber wenn du sagst, No-Code kann skalieren ... und No-Code kann Casual-Applikationen, ... dann sollte es doch eigentlich auch E-Commerce können.

Hendrik (21:09)
Ja, fairer Punkt. E-Commerce, nicht jeder E-Commerce-Store ist so skaliert, dass du da wirklich an Grenzen kommst. Das ist schon richtig. Also ein kleiner E-Commerce-Store oder auch ein mittlerer E-Commerce-Store kannst du ohne Weiteres auch mit No-Code abbilden. was ich damit meinte, dass E-Commerce-Stores schnell die sind, die schnell sehr, groß werden und schnell viele Transaktionen gleichzeitig abwickeln müssen. Und das ist...

bei einigen Plattformen, wo du gegebenenfalls hin und wieder mal drauf gehst oder anderen Applikationen vielleicht nicht so. Also das war eher auf die wirklich skalierten E-Commerce-Systeme gemünzt.

Philipp Deutscher (21:49)
Okay, verstanden. Und kommen wir nochmal zu dem Punkt, zu den Alternativen zu Bubble. Gab es da welche, die du ausprobiert hast, die du explizit auch noch erwähnen kannst an der Stelle? Oder hast du das Feld soweit abgegrast und musst sagen, naja, Bubble ist für dich the way to go?

Hendrik (22:10)
Wir sind nicht tief. Baba ist eine große Applikation und hat viel, wie gesagt, der platz-ish und es gibt natürlich noch viele andere große No-Code-Tools, die andere Sachen besser können oder dieselben Sachen ähnlich gut können. Du musst halt bei jedem dieser Tools auf eine gewisse Tiefe kommen, um eine gute Entscheidung treffen zu können, ist das jetzt viel besser als das andere oder nicht und lohnt sich der Umstieg.

Wir haben uns ein paar Sachen angeguckt, aber nicht in der Tiefe. Es war schon so ein bisschen die Wette, wir starten jetzt mit Bubble, entweder funktioniert das oder nicht. Also wenn das nicht funktioniert hätte damals, als wir angefangen haben, dann hätten wir glaube ich da auch nicht viel weiter geguckt. Also nicht nochmal die dritte angeguckt, weil wenn der Platzhirsch das schon nicht kann, wie gut kann denn ein anderer...

Der zweite ist ein. Davor hatten wir mit Software und Airtable rumgespielt. Software ist dann eher das Frontend, was so bisschen User Management, Login auf seiner Seite hatte und Airtable als Datenbank. So bisschen Excel auf Steroiden mit Datenbankfunktionen. Das war wunderbar für einige Use Cases, aber das kam doch ziemlich schnell dann an die Grenzen.

Es gibt da einige auch gerade in mobile Richtung, also viele App-Bilder gibt es, die mobile Apps gut können. Flutterflow ist da was, Adalo. Mit Flutterflow sind wir gerade, müssen rum experimentieren, wie sehr, sehr gut es gehört. auch da, wir uns jetzt oder inwieweit wir uns ein zweites Tool auch reinholen, also auch gerade weil der

prüfen müssen, passt das von den Anforderungen auch was Datenschutz angeht, haben wir die Skills in house, weil auch dafür gibt es nicht so ohne weiteres Entwickler auf dem Markt oder No-Code-Entwickler auf dem Markt. Da bin ich vielleicht mal angucken, aber ob wir dann wirklich noch mal eine neue Applikation der Direktoren umsetzen, muss ich dann zeigen.

Philipp Deutscher (24:17)
Dieser Podcast richtet sich natürlich vornehmlich an Softwareentwickler oder Technologie-Attackies, die ambitioniert sind, die vielleicht auch schon den Weg Richtung Führungskraft gemacht haben oder Richtung CTO gehen wollen. Wenn die sich das natürlich jetzt alles hören, dann sagen sie, ach du meine Güte, auf der einen Seite kommt die AI und knabbert mir den Teil der Softwareentwicklung weg. Von der anderen Seite kommen No-Code oder Low-Code-Applikationen oder Frameworks. Wie sieht die Zukunft von

von No-Code und Low-Code aus und glaubst du, ... dass es die klassische Softwareentwicklung ... ... in bestimmten Bereichen ersetzen wird ... oder wird es immer komplementär sein?

Hendrik (24:55)
Menge Fragen hintereinander. Du hast am Anfang gesagt, den Beisatz mit KI, was KI gerade macht, das ist unglaublich spannend. Zusammen mit No-Code bietet es Möglichkeiten, Sachen, die sonst wirklich eklig sind, zu programmieren oder auch in No-Code abzubilden wie Parsing und Formatierung und solche Sachen, das im Grunde mit einem LLM machen zu lassen.

Das ist wirklich ein interessanter Use-Case, dem du gerade auch den No-Code-Use-Case unglaublich viel spannender machst und auf ein höheres Level hebst. Nur das mal erwähnt zu haben, das hat dem ganzen extrem geholfen, auch weil du eine JetGBT-RP halt schneller anbinden kannst.

Wie sieht die Zukunft aus? Ja, also ich würde auf jeden Fall sagen, ein Kollege meines Bruders sagte das letztens, als er den gezeigt hat, das löst eine ganze Menge Monkey-Work. Also so ein bisschen die Sachen, die easy zu machen sind. Logins, Passwort vergessen und ein Dashboard anzeigen und so was. Ich glaube, es ist wie ein

framework mit dem du mit dem also gerade auch auf entwickler gemünzt mit dem entwickler sich auf das wesentliche konzentrieren kann so sehe ich das absolut und bin natürlich auch hier nicht nur auf offene ohren gestoßen auch auch insgesamt wenn man mit leuten spricht ist das nicht unbedingt etwas wo alle sofort von überzeugt auch nachvollziehbarer weise

Aber im Grunde ist es für mich etwas, was man nutzen kann als weiteres Tool, Probleme zu lösen und wo ein Entwickler sagen kann, die Arbeit muss ich mir jetzt nicht machen, ich mache mir lieber die Arbeit an einer anderen Stelle, wo ich wirklich mehr Wert schaffen kann, den du mit No-Code-Tools nicht hinbekommst, der besonders vieles braucht und so weiter. Vor allem ...

eher ist das meiner Meinung nach in den ganzen Backend Prozessen, wo du halt große Skalierungen hast und dann brauchst du eher mal oder konzentrierst du dich erstmal darauf, schicken Endpunkt zur Verfügung zu stellen, den du dann da ansprichst mit einem Frontend, wo du dann halt Datenvoraggregate anzeigst und so was. da ist glaube ich die Liebe besser aufgehoben, wo dann Entwickler sich wirklich austoben können. Und ich glaube, das ergänzt sich unglaublich. Ich habe hier intern auch

Ich habe versucht zu veranschaulichen, wie ich mir die Zukunft vorstelle. Du hast ja im Unternehmen immer die Situation, dass du viel zu viel bauen willst und ausprobieren willst und immer zu viel zu viele Fragen von Kunden und Kollegen. Und im Grunde kannst du ja nur einen kleinen Teil damit abdecken mit dem Team, das du hast. Und im Grunde erweitert das nur oder beschleunigt das die Möglichkeit, Tools zu bauen und zu vertesten und macht Arbeit nicht überflüssig, sondern hat einfach

Möglichkeiten mehr auszutesten, zu gucken, das Unternehmen, in man aktiv ist, eine hohe Wahrscheinlichkeit hat, erfolgreich zu sein. Und das ist, glaube ich, eher wie es jetzt hier ist.

Philipp Deutscher (28:04)
Was für ein Feedback kriegst du von euren Entwicklern? Also spiegeln

die dir das gleiche auch noch mal zurück und sagen dann wirklich, ja danke, dass mir das Tool dieser Arbeit abnimmt, dann kann ich mich auf die wirklich wichtigen Probleme kümmern oder haben sie dann noch ambivalente Gefühle?

Hendrik (28:17)
ganz deutlich das zweite, was ich nachvollziehen kann. Was holt man sich dann damit rein? Eine Blackbox, von der man nicht weiß, also wenn man ein Tool integriert, dann holt man sich erstmal eine Blackbox rein, von der ein Entwickler nicht sofort weiß, wie es funktioniert. Man denkt natürlich auch vor allem an die Architektur des aktuellen Systems, wenn du was stehen hast. Du startest sehr selten auf einer From-Scratch und hast keine Architektur da und so ein Tool

Philipp Deutscher (28:30)
Ist ja richtig,

Hendrik (28:45)
geliedert sich natürlich nicht sofort wunderbar in der Architektur ein, sondern steht erstmal als Silo da. Und da muss man gucken, für welche Zwecke es dann passt. Also ich habe das ein bisschen Gereliamäßig gemacht, dass ich Bubble eingebracht habe. erstmal niemandem großartig was gesagt, weil ich auch nicht glaube, dass ein Entwickler das wirklich so gepusht hätte. Das glaube ich auch, das darf vielleicht nicht...

mit dem Willen, rangegangen worden wäre. Und wir gucken jetzt einfach zusammen als Team, welchen Use-Case können wir mit welchen Tools abdecken und welchen Use-Case bauen wir from scratch, beziehungsweise bauen erst in Version 1 vielleicht. Es gilt jetzt auch für das nächste Tool, was wir bauen wollen.

Und wie sieht dann die Version 2 aus? Das ist eher die Frage, die wir uns stellen. Und muss man eher mal weniger Angst davor haben, die Version 1 komplett wegzuwerfen, weil sie schneller auch zu bauen ist. Ich glaube, da ist dann eher der Absprung.

Philipp Deutscher (29:52)
Ein Nebeneffekt von No-Code-Tools ist, dass eine neue Begrifflichkeit entstanden ist. Die des Citizen Developers. Also ich glaube, der ist sogar in der Tech-Branche oder wenn ich mit anderen Software-Entwicklern spreche oder mit Techies spreche, habe ich das Gefühl, der ist noch gar nicht so ganz angekommen oder nicht ganz, der ist noch gar nicht so geläufig, der Begriff. Aber ich glaube, er wird immer geläufiger werden. Was ist denn ein Citizen Developer? Also aus meiner Sicht ist das jemand, der enabled wird mit No- oder Low-Code-Tools.

die Arbeit eines Entwicklers zu verrichten, ... ... bis zu einem bestimmten Grad, ... ... der normale Bürger, ... der normale Produktmanager, ... der wird jetzt enabled damit. Wie siehst du diese Entwicklung?

Hendrik (30:31)
Begriff habe ich von dir. Also tatsächlich, dass es den Citizen Developer Begriff gibt. Wir hatten immer überlegt, wie kann man das nennen. Für manche Use Cases haben wir auch Prompt Engineer, aber das ist dann nicht wirklich der No-Code.

Philipp Deutscher (30:46)
Also ich habe mir tatsächlich nicht ausgedacht, Begriff, den gibt es tatsächlich,

aber ja, genau.

Hendrik (30:51)
Ehrlich gesagt, ist auch ein Fun Fact der Kollege, mit dem ich das eine Tool gebaut habe. Der ist nicht als Entwickler zu uns gekommen, sondern der ist als Kollege zu uns gekommen, der sich die Beraterkommunikation gekümmert hat und hat in seiner Freizeit bisschen programmiert. Und wir haben im Grunde ein Tool gebaut, was seinen Job vereinfacht hat, also seinen Job, den er bei uns gemacht hat, als er eingestiegen ist.

Also hat er im Grunde oder ist er als Citizen Engineer gestartet? Das war...

Das war Grunde genau der Weg, dass du jemanden im Unternehmen hast, der seine eigenen Tools baut. Das war auch so ein Punkt, wo ich gesagt habe, das ist jetzt mal neu. Da brauchtest du keinen Produktmanager, der jetzt zwischen Tech und der Fachabteilung kommunizieren musste, der dann übersetzen musste, sondern du hast jemand aus der Fachabteilung, der gesagt hat,

Philipp Deutscher (31:32)
Hm.

Hendrik (31:50)
Ich brauche das, also brauche ich mir. Ich gucke mir jetzt Bubble an und weiß jetzt schon, wie Feature XY aussehen muss, weil ich genau weiß, wie der Painpoint aussah, den ich in meinem täglichen Arbeitsabläufe immer hatte.

Philipp Deutscher (32:07)
Welchen neuen Skillsets sind dann gefragt für so eine Rolle? Also du hast jetzt ja das lebende Beispiel. hast zwar die Begrifflichkeit bis zu unserem Vorgespräch ... auch nicht gekannt, allerdings hast du jetzt ja ... genau so einen Citizen Developer ja eigentlich schon im Team. Was für Anforderungen hast du an denen? Oder welche Anforderungen braucht ... oder muss er erfüllen, um diese Rolle ausfüllen zu können?

Hendrik (32:20)
Ja.

Du schon technisch sein, du viel mit Apikor als agieren Du musst wissen, man Authentication, Authorization, solche Geschichten macht. Du hast eine gewisse technische Tiefe, auf die du kommen musst, aber die ist wesentlich schneller zu erreichen als Also du brauchst dazu kein Studium oder auch keine langjährige Erfahrung. Und vor allem kannst du dir ab einer gewissen Tiefe auch einfach

Unterstützung von Kollegen holen, es vielleicht besser können. Aber bis zu der Tiefe kannst du eine ganze Menge schon mit soliden ersten technischen Basiswissen einfangen. Der Kollege hatte ein bisschen mehr, hat auch schon mit Python ordentlich programmiert und für uns auch tatsächlich schon interne Tools gebaut, die uns Arbeitsprozesse erleichtert haben. Aber das war ...

glaube, wenn man genug Interesse hat und motiviert genug ist, dann kann das jeder hinbekommen, der Lust hat. Denn es ist sehr visuell, ist sehr what you see is what you get. Du klickst dir die Sachen zusammen.

Du hast eine Lernkurve, aber das hat man auch bei Toolsy Photoshop. Das vergleite ich immer gerne, weil es komplex genug ist. Du kannst es öffnen und ein kleines Bild bearbeiten, du kannst aber auch verschiedene Ebenen einfügen und du dann irgendwie ganz, ganz tolle Ergebnisse. Aber du musst dich ja trotzdem ordentlich mit beschäftigen. Ja, uns gilt es und braucht Motivation, Zeit und vielleicht ein gutes Barringspartner.

Philipp Deutscher (33:58)
Und wie reagieren andere Entwickler auf ihn? Also nehmen die ihn ernst im Sinne von, das ist jetzt einer, der ist nah an dem dran, was wir tun? Oder nehmen sie ihn eher als Fremdkörperbar und sagen, das ist ja eigentlich nur so ein Hampelmann, der, ich übertreibe jetzt natürlich, der einfach sich ein paar Dinge zusammenklickt und ein besserer Praktikant ist.

Hendrik (34:15)
vielleicht ein schlechtes Beispiel, weil er tatsächlich mehr Entwickler ist und sich auch mehr als Entwickler fühlt. ist tatsächlich jetzt bei uns auch Entwickler, weil er komplett auch in die Entwicklerrichtung gehen wollte. Aber wenn wir jetzt mal jemanden nehmen, der im Grunde nicht das Ziel hat, Entwickler zu sein, sondern eher was zu bauen, was funktioniert.

dann könnte es schwierig sein. dann hast du immer noch bisschen Übersetzungsthemen, aber grundsätzlich spricht man ja ohnehin auch im Alltag mit Kollegen und Stakeholdern. Du ein ähnliches Vokabular, hast du immer schon. Ob du jetzt als Entwickler wirklich mit wahrgenommen werden?

Willst, auch oder musst, ist vielleicht eine Frage. Also was ist ein Citizen Developer, musst du jetzt wissen, wer jetzt welche Endpunkte gerade baut und wo jetzt gerade was schwierig ist und wie das sich in die Architektur einbettet. Da ist die Frage, wie sieht die Organisationsstruktur insgesamt aus und was wird dazu gepackt. Also ich würde gerade

Fall jemanden nehmen, ganz klar schon technische Erfahrung hat. ja, Punkt.

Philipp Deutscher (35:33)
Sehr gut. Und die Entwickler, die jetzt noch skeptisch gegenüber No-Quotes sind, ... du, oder wie gehst du mit denen Hast du ein Rat für die, wie sie damit umgehen sollen? Oder wie sie das integrieren? Können sie das irgendwie integrieren in ihre eigene Arbeit?

Hendrik (35:49)
zu sagen, ja, wäre jetzt, glaube ich, anmaßend, weil es da natürlich immer drauf ankommt. Aber was ich sehe, ist gerade für

Für erste Prototypen freut sich, glaube ich, ein Produktmanager und auch jede Führungskraft, wenn man sagt, wir können das mal zusammenklicken. Das ist dann noch nicht skalierbar, das ist vielleicht eher das Schwierige oder die Tatsache, die man rüberbringen muss, dass das dann vielleicht noch nicht das finale Produkt sein kann oder ab da sich dann Gedanken gemacht werden muss, wie kriegen wir das jetzt auf das nächste Level. Aber dass man da sagt, wir bauen hier was zusammen, was schon mal funktioniert, was wir Kunden zeigen können und Feedback ansammeln können.

Das ist, ich, ein Skill oder eine Möglichkeit, die sich jeder Entwickler auf jeden Fall, die er parat haben sollte, was das Leben einfacher macht. Vorsichtig gesagt, was die Kommunikation auch mit Produktmanagern angeht und vielleicht Führungskräfte. Natürlich bringt das seinen ganzen, seinen eigenen Rattenschwanz ein Thema mit. Okay, jetzt können wir da jetzt auf einmal das und das möglich machen.

können wir jetzt Wünsche und Anforderungen, dann reinkommen, denen man dann vielleicht nicht sofort weiß, wie man die beantworten kann. Aber als Entwickler zu sagen, das baue ich jetzt mal nicht neu oder dafür nutze ich jetzt Tool und NoCoTool XY, das ist glaube ich wichtig in der Zukunft. Weil es geht immer mehr darum, dass man

Use Cases vertestet und Hypothesen vertestet und schnell auch Dinge wieder verwirft. Da muss natürlich auch ein Unternehmen in der Lage sein, Dinge zu verwirfen und sagen, okay, das hat nicht funktioniert. Das ist wichtig. Ansonsten hast du da ein paar Zombie-Produkte stehen. Aber dafür ist es, glaube ich, hervorragend geeignet und auch gerade in den Händen von Entwicklern richtig.

Philipp Deutscher (37:39)
Also es gibt ja immer so ein Spannungsfeld zwischen Produktmanagement und Softwareentwicklung. Wir haben das im Vorgespräch auch noch ein bisschen herausgearbeitet, dass Softwareentwicklung ja eigentlich gerne für das Wie verantwortlich sein möchte und die Erwartung hat, dass das Produktmanagement eigentlich ja nur das Was vorgibt und das Wie liegt dann komplett bei der Softwareentwicklung. jetzt noch die Überleitung dazu schaffen von No-Code, hast du das Gefühl, in diesem Spannungsfeld

eine No-Code-Tool etwas verändert, sei es jetzt ... in die positive wie in die negative Richtung? Ist es etwas, was beide Seiten mehr zusammenbringt ... ... oder spaltet es noch vielleicht etwas mehr ... dadurch, dass es auf der einen Seite mehr Akzeptanz hat ... wie auf der anderen? Das ist eine sehr hypothetische Frage, aber trotzdem ... ... spannendes Thema in diesem Spannungsumfeld.

Hendrik (38:27)
Also hat auf jeden Fall eine Spannungserzeugende Wirkung im ersten Schritt, weil du ja im Grunde, wie du sagst, dass WIE nicht mehr kommt. Also in unserem Fall war es zumindest so, weil ich das als Gherilia-mäßig selber aufgezogen habe. Das ist natürlich nicht der nette Weg, aber da waren bei uns auch völlig zu Recht auch irgendwie die Meinung, okay, das hätten wir gerne irgendwie mitbestimmt.

was ich nachvollziehen kann und wo auch genau die Spannung herkommt, wenn man da wirklich etwas in die Organisation reindrückt.

Am Ende ist es, glaube ich, etwas, wo beide voneinander lernen können. Wir haben ein kleinen Hackathon gehabt letztes Jahr, wo wir ein Tool gebaut haben, was sowohl aus No-Code als auch aus bestehenden Komponenten unserer anderen Applikation bestand. Und das war unglaublich verbindend, weil auf einmal die Leute miteinander arbeiten konnten und zusammen gearbeitet haben, die davor nicht direkt was miteinander zu tun hatten. Das war ...

Das war irre zu sehen und auch war dann eher wieder verbindend. Ja, so ein bisschen wieder, es kommt drauf an. Man muss halt von beiden Seiten aus offen sein. Gerade aus Entwickler, ist es schwieriger aus Entwicklerseite offen zu sein. ist es einfach aus meiner Perspektive aus da zu sagen, so und so stelle ich mir das vor. Aus Entwicklersicht und auch gerade jemand, der dann die Architektur verantwortet, stelle ich mir schon vor, okay, das ist

Das würde ich auch nicht einfach so abnicken und hinnehmen und sagen, das ist jetzt halt so. Sondern da würde ich schon gerne darüber diskutieren und schauen, wo passt das und wie passt das in den Gesamtkontexten.

Philipp Deutscher (40:09)
Ja, sehr richtig. Und die Zusammenarbeit zwischen Produkt und Tech, ... wie sieht die idealerweise für dich aus? Also, weil die meisten Leute, hier in dem Podcast sitzen, ... wir hatten zwar auch schon mal einen anderen CPO hier, ... das meiste sind allerdings CTOs ... ... und da gibt es ja durchaus ... verschiedene Perspektiven, ... und da hast es ja eben auch noch mal herausgearbeitet, ... es gibt ja durchaus verschiedene Perspektiven darauf, ob und wie etwas gemacht werden sollte.

Wenn du jetzt mal guckst auch auf das Unternehmen, dem du jetzt bist ... und mit den Leuten, mit denen du zusammenarbeitest, ... wie sieht für dich so eine ideale Zusammenarbeit aus ... ... zwischen Produktentwicklung oder Produktmanagement ... und Tech und Engineering?

Hendrik (40:44)
Ich versuch's anderen Leuten, die auch fragen, was machst du eigentlich, immer zu sagen, dass es halt so zwei sich sehr überlappende Wenn-Diagramme sind. Also du musst einfach die meisten Themen zusammen angehen und beleuchten und dir gemeinsam Gedanken machen, wie lösen wir es. Auf Produktseite kommen vielleicht eher mit dem Problem und Anforderungen in noch so bisschen in der Sprache.

bringt das dann mit ins Team rein oder gerade zu einem CTO und wir überlegen uns dann, wie wir es lösen können.

Zusammenarbeit. Am Ende müssen beide Seiten damit happy sein, schnell und in welcher Qualität etwas umgesetzt wurde. ist halt immer bei jedem Feature, geht es darum, welchem Scope.

Baust du etwas und least du etwas. Die Diskussion hast du ja auch auf der Feature-Ebene jeden Tag und das ist ja nichts anderes für komplette Produkte oder MVPs. Und im Grunde ist eine No-Code-Lösung halt ein anderer Scope für ein Feature. Und was du machen kannst, du kannst halt in der Diskussion

zusammen auch mit dem CTO sagen, okay, haben wir hier eine Tiefe erreicht und im Grunde so in die Richtung verhandeln, okay, reicht das noch, brauchen wir das oder reicht das noch in dem Scope und mit dem Toolset oder müssen wir da oder wollen wir da in eine Custom-Lösung gehen. Das ist halt eher so die Verhandlungsmasse, die man da hat. Aber am Ende ist es halt etwas, was beide tun.

Philipp Deutscher (42:16)
dann stellt sich

ja irgendwann auch die Frage, ... braucht dann jedes Unternehmen noch ein CTO? Also vor allen Dingen, du ein gewisses Subset an Produkten ... allein mit No-Code-Lösungen erstellen und betreiben kannst, ... ... auch weil vielleicht das alles casual ist und alles schon 100-mal entwickelt wurde ... ... und du kannst das wirklich mit ... you see is what you get ... editoren kannst du das zusammenklicken ... und das kannst du ausrollen ... ... und das läuft und das kannst du auch skalieren.

Und da ist kein Deep-Tech irgendwo mit drin. Also jedes Unternehmen wird irgendwann ja mal ... Tech-Unternehmen sein, weil es irgendwo mit ... Technologie und Berührung kommt. Die Frage ist dann nur, braucht dann jedes ... Unternehmen dann überhaupt ein CTO oder reicht dann ... oft nicht auch der CPO, der genau mit diesem ... Mindset, das du hast, reingeht und genau das vorlebt. Und jetzt kriege ich wahrscheinlich die ganzen ... Hasskommentare. Nein, keine Ahnung. Nein, aber ernste Frage. Also das macht ja unter Umständen in bestimmten ... Unternehmenskonstellationen und Technologiekonstellationen machst du die Rolle des CTOs obsolet.

Hendrik (43:09)
ich sage obsolet, weil am Ende, was macht der CTO? Der guckt sich viele Themen aus einer Risikobrille auch viele an. ein bisschen schwarz-weißer, der muss es Ende ausbaden, wenn es am Ende nicht funktioniert. Wenn halt irgendwelche Datenbanken nicht verfügbar sind oder Sachen nicht aneinander gebunden werden können. Und das ist natürlich etwas, was unglaublich wichtig ist, gerade wenn du jetzt dein Beispiel mit einem Unternehmen mit

mit sieben Tools, sieben NoCo-Tools aufgesetzt und du willst eigentlich alle Daten an einem Fleck haben und wusstest das im Grunde schon von Anfang an, du von Anfang schon dir darüber bewusst warst, dass du keine sieben verschiedene Nutzerkategorien hattest, die aber im Grunde dieselbe Nutzerkategorie sind, nur noch bisschen fein, granular aufgedröselt und willst am Ende die Nutzerdaten zusammenführen. Wenn der Produkt oder der CPO dann da steht, ja...

ich nicht. Du brauchst die Skills von einem CTO ganz klar für alle Tech-Themen, du aufziehst. Also im Grunde ist es ein Tech-Tool. Punkt. Also es ist kein User Experience Tool. ist ein Tech-Tool. Der CPO muss damit absolut fein sein. Wenn nicht, dann sollte sowas auch nicht gemacht werden. Da muss bei jeder Entscheidung mit drin sein und es muss am Ende sich überlegt werden, wie passt das zusammen.

Das ist glaube ich, also CTOs werden wir nie zu viele haben. Ganz im Gegenteil, wir die CTOs haben dann eher das Problem, dass sie jetzt auf einmal mit sieben verschiedenen Applikationen umgehen müssen. Sie müssen sich überlegen, wie kriegen wir jetzt da die Datenbanken zusammen.

Philipp Deutscher (44:47)
Ja, richtig,

Hendrik (44:48)
Auch das muss wild skaliert werden, das funktioniert und da gibt es auch Lösungen. Es gibt auch sehr spannende No-Code-Backend-Systeme, die großartig skalieren, wo du auch das Problem nicht mehr hast. Aber das sind Themen, die Themen werden mehr und nicht weniger mit No-Code.

Philipp Deutscher (45:04)
Ja, und die Komplexität verlagert sich. Die verlagert sich auf, wie baue ich dann jetzt eine bestimmte Applikation bis hin zu, wie administriere, wie managere ich dann die verschiedenen Tools und die verschiedenen Datentöpfe, wo landen die? Du hast es ja eben selber gesagt, wo landen die denn überhaupt? Ich brauche vielleicht ja einen Datensilien, in den alle Daten dann reinlaufen und die ich dann weiterverarbeiten kann. Und Komplexität verschwindet nicht, die wandert nur an eine andere Stelle. Das sehe ich auch so.

Gibt es denn für dich dann Unterschiede in der Denkweise, die du beobachten kannst? gerade wenn du mit CTO-Kollegen sprichst, gerade über das Thema No-Code-Tools, wird das auch von der CTO-Seite als durchaus valide Option mittlerweile betrachtet?

Hendrik (45:45)
Ja, absolut. Genau nämlich für solche Themen für die Monkey-Tasks. Also für Sachen, die man im Grunde jetzt nicht das fünfte Mal nochmal neu bauen will. Und ich glaube, ist auch genau der Nutzen drin.

Aber es ist natürlich auch, es wirkt von außen vielleicht auf manche CTOs okay, wird mir da jetzt ein Stück weg genommen und muss ich jetzt auch meinen Kopf dafür herhalten, dass dieser Anbieter von einem Bubble, dass der jetzt irgendwie eine Downtime hat, an der ich nichts ändern kann, weil das alles nicht in meinem Hoheitsgebiet liegt. Das ist halt etwas, womit ein CTO dann auch umgehen muss und halt zurecht sagt, ja ich weiß nicht, ob wir Lust haben für unseren Service.

uns das Risiko reinzuholen, auch weil vielleicht zu den Punkten, an welchen Stellen No-Code-Tools dann fällt, auch oder nicht in Nutzen stiften. ist halt irgendwas, was sehr, sehr kritisch ist, von dem man eine ganze, also sehr, sehr hohe Abteilzeit braucht. Und da muss natürlich jeder CTO sagen, okay, passt das auf unseren Use-Case.

Philipp Deutscher (46:49)
Aber gibt es denn tatsächlich, also hat das tatsächlich Auswirkungen, wenn Bubble als Dienstleister oder als Service nicht vorhanden ist, dann hat das Auswirkungen auf das, was in Produktion läuft?

Hendrik (46:58)
Ja, die haben haben gelegentlich Themen, wir in Produktion merken, okay, da funktioniert gerade etwas, die werden E-Mails nicht verschickt oder sowas. Das passiert nicht oft und die haben auch, also das größte Augenmerk, was Babi gerade und auch alle größeren Anbieter oder da, die meisten Ressourcen hinfließen, sind halt genau solche Themen, Skalierbarkeit und irgendwie Deployments ohne Downtime.

immer sehr transparent mit, wo, in welchem Stadium, was gerade gegebenenfalls wenig läuft. Das passiert nicht oft, aber es passiert hin und wieder. Von daher kann man auch direkt weitergeben, okay, das und das ist gerade irgendwie down. Trotzdem ist das also aus Produkt-Sicht verschmerzbar gering und man hat halt gleichzeitig eine ganze Menge.

Logging und die Transparenz, warum was gerade nicht funktioniert, bei vielleicht etwas kritischeren Systemen. da Gesundheitsthemen und wo halt irgendwie, wo es auf Trading, wo es auf jede Sekunde ankommt, da würde ich sagen, ja okay, da baut vielleicht was anderes, mit, was den Fokus hat, oder nicht Skalibra, sondern Uptime von, was ich, nahezu 100 Prozent hat. Das wäre schon...

Also, Bubble hat genau solche Themen, so wie jedes andere No-Cook-Tool, glaube ich auch.

Philipp Deutscher (48:20)
Ja, ja, so wie der andere Trittanbieter, also für ein CTO ist das ja auch nichts Neues, ... irgendwie Jeff-Third-Parties in die Applikation einzubinden, ... auf die eine oder andere Art und Weise ... ... und dann natürlich auch davon irgendwie abhängig zu sein, ob die laufen oder nicht. Also ganz ohne geht es auch schon vor den No-Code-Tools, ... geht es ja nicht. Aber habt ihr ... Also gibt es regelmäßig Probleme aktuell noch ... mit der Verfügbarkeit? Jetzt mit Bubble in eurem Fall?

Hendrik (48:44)
Es gibt regelmäßig immer mal auch Down Times, ob das jetzt Wartungs-Down Times sind oder auch mal ein Bug. Das gibt es auch in Produktionen regelmäßig noch. Die Sache ist, dass es ja dann Problem für jeden Nutzer ist und Bubble dann ja auch wirklich alles daran setzt, das wirklich zu beheben. Deswegen ist es meistens nicht wirklich lang. Da hast du es richtig. Ja, absolut.

Philipp Deutscher (48:55)
Okay, interessant.

Hilft dir aber trotzdem nicht, wenn es dich gerade betrifft.

Das Problem kenne ich auch, wenn du zum Beispiel Web Application Firewalls von Akamai oder so etwas dann betreibst, dich gegen DDoS-Angriffe zu schützen und du hast dann im Endeffekt da alles dich herum, abgesichert zu sein. Aber wenn dann Akamai aus irgendeinem Grund natürlich ein Problem hat, schöne Grüße an der Stelle, dann hilft dir das auch nicht, weil dann bist du genauso betroffen und solche Situationen...

kenne ich aus der Vergangenheit auch nur zu gut ... und das bereitet dann sehr große Kopfzerbrechen. Und dann hilft es dir auch nicht, ... du weißt, alle anderen Akamai-Kunden ... sind davon auch gerade betroffen, ... ... weil dein Service ist down und deine Kunden sind unzufrieden.

Hendrik (49:43)
Wie stehst du denn jetzt dazu? Also jetzt haben wir uns ein bisschen darüber unterhalten. hatten ein kurzes Vorgespräch und du hast so bisschen meine Perspektive gehört als CTO, als Betroffener. Was sind deine Gedanken?

Philipp Deutscher (49:54)
Ich bin tatsächlich noch nicht so weit eingestiegen, jetzt eine finale Meinung haben zu können. Gerade auch weil ich gemerkt habe, ... dass es auch noch Bereiche gibt, die waren mir da selber noch gar nicht klar. Also mir war es nicht klar, ... dass es, wenn ich ein Produkt, eine Applikation ... einem No-Code-Tool wie Bubble selber erstelle, ... ... dass ich dann in dem Ergebnis immer noch davon abhänge, ich bin, ob Bubble als Service immer noch läuft. Weil meine Erwartung war, dass ich am Ende des Tages ... dennoch irgendwo Artefakte kriege ... ... oder deployable Code kriege, den ich irgendwo hin kopiere.

oder hinschiebe ... ... und das dann auf meinen Instanzen läuft. Und da ist die Erwartungshaltung ... war wahrscheinlich dann eine andere. Also deswegen, das hat mich gerade eben ... davon überzeugt, ... dass das doch eine Abhängigkeit ist, ... die ich ... nicht unkritisch sehe ... ... und dass ich mein Verständnis ... ... über No-Code-Lösungen da noch weiter schärfen muss. Prinzipiell sehe ich es aber auch so wie du. Also ich sehe die Vorteile ...

von Rapid Prototyping ... und Ideen schnell ausprobieren ... ... und gar nicht lange ... mit Produktteams darüber zu iterieren ... oder mit Entwicklungsteams zu iterieren, ... sondern einfach machen. Aus CTO Sicht ... hätte ich wahrscheinlich gedacht ... oder ich merke das für mich selber ... in meinem eigenen Arbeiten, ... ich greife dann eher auf ... Tools wie Cursor zurück. Also die Idee von Cursor, ... ich weiß nicht, wer sie, ... wenn die Zuhörer das nicht kennen, ist im Endeffekt eine Idee.

die von Visual Studio gefolgt wurde, ... die diverse LLMs integriert ... und mit diverse meine ich wirklich sehr, sehr viele ... ... und zwar auf eine Art und Weise, ... in der man sehr, sehr schnell ... sich Unterstützung holt. Also ähnlich wie Co-Pilot, allerdings noch wesentlich integrierter ... in das Arbeiten eines Entwicklers ... bis hin zur Kommandozeile, was Repository and Merchandise angeht, ... was Fehlerfinden angeht im Code und so weiter. Das Tool ist sehr, sehr mächtig.

Und wenn ich eine Idee ausprobieren möchte, bin ich bisher immer zu Cursor gegangen ... und habe mir da relativ schnell, mit relativ geringem Aufwand, ohne mich jetzt durch irgendwelche Dokumentationen durchwühlen zu müssen, ... kleine Tools gebaut. Mit dem Wissen, ich jetzt habe, was du mir gegeben hast, ... überlege ich jetzt aber tatsächlich, das erstmal sein zu lassen ... ... und doch mal so etwas wie Bubble auszuprobieren, ... weil ich nämlich glaube, dass ich damit doch wieder schneller bin.

und die Vorteile von ... von Copilot ... oder Cursor ... ... vielleicht erst dann so richtig zum Tragen kommen, ... wenn ich noch tiefer in die Entwicklung einsteige ... und das was ich eigentlich machen will, ... ... einfach kleine Produktideen auszuprobieren, ... dafür brauche ich sowas eigentlich gar nicht. Also kein Cursor und kein Copilot, ... sondern dafür würde tatsächlich ... ... ein Bubble reichen. So, das ist so mein aktueller State of Mind ... zu dem Thema und wie du da schon rausfährst, ... der ist noch nicht fertig, der ist immer noch ... ... sich am Formen.

Aber ich finde deinen Input dazu sehr, sehr spannend.

Hendrik (52:42)
Tatsächlich haben mein Bruder und ich, und wir sind beide kein Entwickler, letztens mit Replet ein bisschen drum gebastelt, was ähnlich ist wie ein Cursor. Du hast einen Assistenten, du hast einen Agent, der dir auch komplette Features aufsetzt. Und als Nichtentwickler fällt es uns schwerer, damit skalierbare Themen aufzusetzen als mit Bubble. Wir haben damit auch ein Tool hingekriegt, was auch wirklich angenehm zu bauen war und auch wirklich, weil es hat Features komplett für uns gebaut.

Kleinere Adjustierungen konnte man selber mit durchführen und irgendwie könnte man verstehen, das und das macht das und das jetzt. Aber ich glaube, wir hätten es nicht so genutzt, ein Tool zu bauen, was über eine gewisse Größe hinausgeht, weil uns dann natürlich auch die Möglichkeiten und Skills fehlen, da jetzt eine skalierbare Applikation draus zu machen. Da ist, glaube ich, ein Bubble wesentlich angenehmer, weil du da bis zu einem gewissen Punkt Skalierung schon mit drin hast.

Du hast als jemand, der nicht die ganze Zeit SQL-Quarries schreibt, zu gucken, wie viele Nutzer

sehr viele Quality of Life Features, sage ich mal, drin, halt bis zu einem gewissen Skalierungsgrad da wirklich was zu bauen. Also es fühlt sich für uns immer noch angenehmer an, mit Bubble was zu bauen als mit Replet. Aber das liegt natürlich bei jemandem, der jeden Tag Applikationen baut und für den ist das wahrscheinlich absolut viel einfacher, weil er sich in der Umgebung wesentlicher wohler fühlt, mit Cursor oder Replet und Co. Dinge aufzuziehen. Also das ist, glaube ich, die Brille, die dies macht.

Philipp Deutscher (54:13)
Ja absolut. Und ich glaube auch das große Missverständnis, was es auch noch gibt über Tools wie Co-Pilot oder Cursor. Ich bin nicht der Meinung, dass es einen Junior-Entwickler oder einen mit relativ wenig Entwicklungsknow-how so viel besser macht, weil der Teufel so sehr im Detail steckt. wenn du mal anfängst, also das Ding baut dir natürlich Code und zwar

nicht schlechten Code, aber auch nicht unbedingt immer sehr, sehr guten Code. Und da sind auch oftmals Fehler drin. Und du begibst dich manchmal in so ein Rabbit Hole aus Fehlern, in die du nicht rauskommst, wenn du nicht etwas mehr Entwicklungserfahrung hast und vielleicht sogar schon ein sehr, guter Senior-Entwickler bist. Für diejenigen ist dieses Tool Gold wert, weil es macht ihre einfach besser und effizienter. Und sie können damit viel mehr und viel in besserer Qualität liefern. Aber für den Junior-Entwickler ist das eine ja, eine Gratwanderung, solche Tools einzusetzen.

weil sie oftmals gar nicht verstehen, was sie da jetzt gerade bauen.

Hendrik (55:07)
Ja, kann ich absolut so widerspiegeln, uns als Junior-Entwickler hier einzustufen. Ganz klar so haben wir es auch wahrgenommen. Du fühlst dich ab einer gewissen Komplexität einfach nicht mehr wohl in deiner Haut, das jetzt darüber laufen zu lassen und von einem LLM steuern zu lassen, was halt dann die Feature baut.

Philipp Deutscher (55:25)
Genau. Du bist auch überzeugt, das haben wir auch im Vorgespräch rausbekommen, ... von der Idee des 360° Produktmanagers. Also, nicht nur Discovery machen und Evaluationen, ... sondern auch natürlich die Entwicklung mitzugehen und die Iteration dazu. Ist das für dich tatsächlich die Zukunft des Produktmanagements ... oder wie würdest du die sehen? Was ist für dich der 360° Produktmanager?

Hendrik (55:47)
ein bisschen ein griffiger Name oder Begriff für ein Konzept, aber die möglichen... Ich weiß, da war natürlich auch bisschen Sinn der Sache, dass man sagt, okay, man hat irgendwas, was man greifen kann. Und tatsächlich ist das auch ein unglaublich großer Hebel, den du dann hast, wenn du mit NoCoTools als Produktmanager einsteigst. Weil du hast immer zu Beginn von jedem Produkt

Philipp Deutscher (55:52)
Den hab ich von dir gelernt dann jetzt, du.

Hendrik (56:15)
unglaublich viele Hürden und Stolpersteine und organisatorische Herausforderungen, Teamherausforderungen, Kommunikationsherausforderungen, wenn du irgendein Produkt starten möchtest. Schon so aufgesehen, bis irgendein Produkt gestartet wird und die Entscheidung getroffen wird, das loszulegen, könntest du im Grunde schon, wenn man es selber gemacht hätte und die Möglichkeit und die Fähigkeiten gehabt hätte, das zu tun, hätte man schon mit dem ersten MVP fertig sein können. Also wir kennen es alle aus

Organisationen, das macht man nicht mal ebenso. Man fängt nicht mal ebenso ein neues Produkt an. Und das ist etwas, wo ich sage, hey, gibt es einen Produktmanager, der soll

fit gemacht werden oder soll sich optimalerweise auskennen mit irgendeinem hinreichend mächtigen No-Core-Tool, soll den ersten MVP zusammenbauen, gemeinsam mit ein paar Stakeholdern, soll das vertesten, soll die erste Iteration selber durchführen. Das ist alles machbar. Du kriegst Features tatsächlich im Stundentakt released, in einer hinreichenden Tiefe und Detailgrad. Und dann ...

Triffst du die Entscheidung, nachdem du den ersten Nutzern gezeigt hast, vielleicht die ersten Käufe drin hast und das erste deutliche Feedback, das das Produkt Sinn macht, dann kann man sich immer noch damit auseinandersetzen, jetzt ziehen wir es Wir haben noch nicht so viele Nutzer drauf, dass wir hier unglaubliche Arbeiten durchführen müssten, die Daten zu migrieren. Dann kann man die Entscheidung treffen, okay, lassen wir es auf dem Level und auf der Plattform oder gehen wir den Schritt weiter und

Im Grunde malen nur noch nach. Auch ist halt sehr angenehm. Du kannst den Weg dann genau zeigen, was man bauen muss. Und du musst da nicht irgendwelche künstlichen Workflows aufmalen und Diagramme und solche, sondern du hast, du siehst es vor dir. Und die sehen den Kontext, den du ja auch immer versuchst, in irgendwelche User Stories rüberzubringen. Damit hat man es im Grunde als Live-Demo vorliegen. Also...

Das ist ganz klar ein Konzept, was ich unterstütze. Ich versuche allen Produktmanagern, die ich hier betreue, das mit an die Hand zu geben. Ich das mal und mache das von mir aus privat für irgendwelche Hobbys. Aber das ist einfach ein irre großartiger Skill, das selber zu können und das selber starten zu können.

Philipp Deutscher (58:38)
Stichwort Leadership als in der CPO-Rolle. Was sind da für dich die wichtigsten Herausforderungen oder nicht Herausforderungen, Eigenschaften und Skills, die ein CPO mitbringen muss?

Hendrik (58:50)
Ich glaube...

Da der CEO meistens der erste Produktmanager ist, brauchst du vor allem einen guten Draht zum restlichen Management Board. Das ist, glaube ich, noch wichtiger als für den CTO, weil du im Grunde deren Gedanken mit aufnehmen musst, eigenen Gedanken dazu packen. Und das ist sehr viel verzahnter als zum Beispiel auch für den CTO, das ein bisschen zu vergleichen.

wiederum hast du auch in Richtung CTO die enge Verzahnung mit den Technologie-Themen. Also du bist halt sehr verzahnt in anderer Leute Bereich und das muss man irgendwie irgendwie hinbekommen. Also es ist nicht so trennscharf wie andere Rollen und das hat vor und aber auch deutliche Nachteile.

Philipp Deutscher (59:35)
Es gibt ja auch oft

Vermischungen der Rollen. Es gibt ja den CPTO oder CTPO, wie man es nennen möchte. Würdest du dir das zutrauen, die CTO-Rolle mit auszufüllen?

Hendrik (59:46)
Ich gut hier nicht auf den Fuß treten. Ich glaube, das würde ich auch ungern machen wollen. ist eine ganz andere Perspektive, eine ganz andere Brille, die man dann aufsetzt. Und ich glaube, es ist gut, dass es dieses Spannungsfeld gibt. Man könnte argumentieren, dass wenn du einen unglaublich starken Tech-Lead hast, unter dir, der dir dann ins Gewissen redet bei manchen Entscheidungen. Aber dann bist du auch wiederum kein CPTO, sondern bist der CPO, der irgendwie den Tech-Lead mitmanagt.

Philipp Deutscher (59:48)
Hahaha

Hendrik (1:00:16)
dass es wirklich gut sind. Es sind einfach zu viele Themen, man parat haben muss in beiderlei Welten. Also ich glaube nicht, dass ein CTO unglaublich viel Lust hat, sich durch irgendwelche User Experience Interviews zu quälen. Oder sowas mit... Ist das so?

Philipp Deutscher (1:00:29)
Ja, geht die Meinung glaube ich tatsächlich, also nicht unsere jetzt

unbedingt, ... aber die Meinungen da draußen gehen ... da auch sehr auseinander. Also es gibt hier in vielen Unternehmen ... ... gibt es auch halt die Unterscheidung ... zwischen CTO und CPO. In anderen Unternehmen gibt es das nicht. Da reported halt ... reported Produktmanagement und Entwicklung ... an die gleiche Person. Ob das jetzt der CTO ist, der CPO oder eine gemeinsame Rolle. Aber ich höre raus, ... du setzt dich sehr dafür ein, dass es beide Rollen braucht in einem Unternehmen.

Hendrik (1:00:58)
würde mal sagen, auch, es kommt so ein bisschen auf den Zeitpunkt an. Also vielleicht in einem frühen Zeitpunkt oder zu einem frühen Zeitpunkt, in einem frühen Stadium von Unternehmen macht es vielleicht Sinn, nur eine Person zu haben, die die beide so ein bisschen pusht, wo du noch nicht viel falsch machen kannst, weil du im Grunde noch kein richtiges Produkt am Markt hast. Auch da kannst du natürlich eine ganze Menge falsch machen, wenn du auf gewisse Dinge nicht achtest, aber da werden vielleicht Fehler noch leichter vergeben. Es gibt auch davor Nachteile, wenn du jemanden hast, halt oder

hast, du mehr Tech-Skalierungsthemen hast als Produktthemen oder wie ich gesagt habe auf der einen Seite ein starkes Produkt-Team, wo das CTO nicht mehr so viel machen muss, dann fine. Aber eigentlich wollen ja beide, also Produktmanager haben gerne einen CPO als Lead und Entwickler haben gerne einen CTO als Lead. Also beide haben ja auch Wünsche und Ziele, sie

Meinungen, die Sie gerne kundtun wollen. Das in einer Person zu sammeln, wie gesagt, kann am Anfang Sinn machen, weil man einfach viel spart und weniger, auch das ist ja eigentlich Argumentation für meine 360 Grad Produktmanager, weniger Kommunikation, weil du halt nur eine Person hast. Kommunikation macht immer Arbeit, ist immer aufwendig, du hast immer zwei Meinungen, oftmals mehr. Das kann man in beide Richtungen verargumentieren.

Philipp Deutscher (1:02:21)
Guter Punkt. Und in deiner Rolle als Führungskraft, als CPO, was hast du in den letzten Jahren über dich selbst gelernt? Gab es Aha-Momente oder bestimmte herausfordernde Situationen, die dich dann jetzt so im Nachhinein betrachtet besonders geprägt haben?

Hendrik (1:02:37)
Im Grunde die Erkenntnis, es nicht so, dass es viel auf den guten Draht zu dem restlichen Management ankommt. Das ist ein ganz, ganz wichtiger Faktor, es ist egal wie gut du fachlich bist und wie gut du gewisse Dinge kannst. Am Ende muss es passen und musst du kommunizieren können. Ich glaube, was ich in den letzten anderthalb Jahren gerade jetzt über diese No-Code-Geschichte mitbekommen habe,

Ich muss das selber machen, ich muss das selber sehen und ein Gefühl dafür bekommen, zu sagen, das könnte das nächste Mittel sein, gewisse Probleme zu lösen. Ich musste mich ganz tief rein buddeln, auf den ersten Stand zu kommen und ich musste mir die Zeit nehmen, allem das zu tun und auch verteidigen. Es gibt immer bessere Sachen, man machen kann.

mit irgendwelchen Okultur zu bauen. Aber mir hat das mit dieser Entscheidung, tief reinzusteigen, selber tief reinzusteigen, hat mir unglaublich gut getan, jetzt im Nachhinein. Und das hätte ich auch nicht delegieren können. Ich habe mir überlegt, wie kann man das ans Team geben. Aber du musst es selber sehen und du musst es dann auch selber als Spirit mit weitergeben und sagen, okay, ich habe dir gesehen, dass das jetzt geht und das kann man machen und hier Artikel rumschreiben.

rumschicken mit das kann jetzt das und so ein bisschen ist wie auf dem ganzen die ganzen KI-Markt. ist ja eh nicht vergleichbar. Es gibt jetzt ein Tool, das das und das kann und das problemlös. Da ist gerade irre viel los und unglaublich viele Tools kommen gerade aus den aus den aus allen Ecken des Internets und die ganzen sind immer vernetzter und immer integrierbarer ineinander.

Und damit am Ball zu sein und auch regelmäßig wieder den Research zu machen und wieder einzusteigen, ich jetzt für mich in meine Rolle mit reininterpretiert. Auch weil das nicht... Ich weiß nicht, wie viel ein CTO das auch machen würde und wie viel es lohnt, dass er das tut, da jetzt irgendwie in Tools und NoCo-Tools und was weiß ich rum zu recherchieren. Also da hat er auch andere Themen, die er...

die so sein in seinem Feed, in seinem Daily Feed zu finden sind. Und für mich habe ich jetzt ganz klar gesagt, ich mache das weiter, weil jedes Mal, wenn ich das gerade gemacht habe, als ich tiefer irgendwo eingestiegen bin, hat uns das einen großen Schritt in eine Richtung weitergebracht, dann gesagt haben, okay, wir nutzen jetzt, wir machen da jetzt nochmal vernünftig, also Hendrik hat sich das angeguckt, aber jetzt gehen wir nochmal vernünftig tiefer rein und sagen, okay, was machen wir wirklich draus? Also was ist, was können wir daraus jetzt mitnehmen und für uns anwenden?

Das macht man auch nicht immer. In einer größeren Organisation ist es kein Riesenladen. Da wird es wahrscheinlich schwieriger fallen als CPO, da tief einzusteigen und zu sagen, hier drehe ich jetzt noch mal, jetzt nehme ich mir eine Woche, zwei Wochen, da irgendwie ein Gefühl zu bekommen, dass irgendetwas funktioniert, von dem mir gesagt wurde, dass es funktioniert.

Für mich hat es hier gepasst, weil ich mir die Freiheit nehmen konnte, aber das ist wahrscheinlich, also es war auch in vorherigen Jobs nicht so, wäre nicht so einfach gewesen.

Philipp Deutscher (1:05:50)
Sehr schön. Henrik, wir sind auch fast am Ende der Aufnahme angelangt. Und falls du schon mal einer meiner bisherigen Folgen schon mal gehört hast, kannst du dir jetzt vielleicht denken, was jetzt kommt. Ich frage mich immer gerne am Schluss, ob derjenige, der bei mir zu Gast ist, besonderes Motto hat oder einen bestimmten Sinspruch, bestimmte Weisheit, Regel, irgendwas, was ihn antreibt.

was ihm hilft als Guiding Light oder als North Star in seinem Tun. Hast du irgendwas, was dir einfällt?

Hendrik (1:06:26)
so richtig als Mantra nicht, aber ich glaube viele viele Probleme können gelöst werden, indem man oder kann man lösen, indem man sich mit einem Stück Papier oder einem Block und einem Stift in ruhigen Raum sitzt und nichts anderes hat, einem irgendwie, was einen ablenkt und mit genügend Zeit kriegt man so mehr gelöst, als wenn man mitten im Daily Doing versucht, Antworten zu kommen. Von daher, das ist...

Das ist für mich etwas, was mich begleitet hat, wo ich auch immer darauf zurückgreife.

Philipp Deutscher (1:06:58)
Sehr schön. Hendrik hat mich wirklich sehr, gefreut. ich glaube, beim nächsten Mal, habe gleich zu Anfang, habe ich schon gemerkt, ich glaube, wir haben noch ein anderes Thema, was wir vielleicht mal in einer anderen Session noch mal irgendwie tiefer einsteigen können. Das Thema Technologie und Finanzen beim Thema Deal Circle. Dafür wird die Zeit heute leider nicht reichen, aber vielleicht kommst du dann einfach nochmal und dann reden wir darüber.

Hendrik (1:07:20)
Richtig gern. Ich bin da Überzeugungstäter und auch nerdig genug, Stunden zu filmen.

Philipp Deutscher (1:07:25)
Sehr gut.

Super. Vielen lieben Dank und bis bald. Ciao, ciao.

Hendrik (1:07:30)
Philipp, dank dir.