Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#86 - Ist No-Code ein Must-have für die Produktentwicklung? - mit Tim Klein von Die Produktwerker
387 Plays1 year ago
Adriano im Gespräch mit Tim Klein.
Bevor sich Tim 2015 selbständig machte, hatte er bereits Stationen bei Sopra Steria, HRS und Bayer durchlaufen. In dieser Folge teilt Tim diese langjährige Erfahrung in der Produktentwicklung mit uns. Dabei geht es vor allem darum, wie er die heutige Nutzung von No-Code für Product Owner und Product Manager einschätzt, wann er No-Code dafür empfehlen würde und wann eher nicht. Wir hören außerdem, wie sein Einsteig in No-Code lief und wie Tims Erfahrung in unserem Rapid Prototyping mit No-Code Bootcamp war.
Die Produktwerker haben übrigens ihren eigenen Podcast, in dem Lilith bereits zu Gast war. Die Folge und den Podcast findet ihr hier: https://produktwerker.de/no-code-tools/
Links zur Folge:
Podcast: https://produktwerker.de/podcast2/
POEM Tool: https://produktwerker.de/POEM/
Tim's LinkedIn: https://www.linkedin.com/in/timklein-de/
Das Tool der Woche: https://www.weweb.io/
////////// Gefällt dir unser VisualMakers Content? Werde selbst zum VisualMaker mit einem unserer vielen kostenlosen Kurse. Starte jetzt durch und werde NoCode Profi https://www.visualmakers.de/academy
////////// Folge uns auf
LinkedIn: https://bit.ly/3SfL6oO
Youtube: https://bit.ly/3OF5jBj
Instagram: https://bit.ly/3cMYH6N
Slack: https://bit.ly/3cMNJhC
////////// Jetzt Newsletter abonnieren und keine NoCode News mehr verpassen! https://bit.ly/3cMYNeF
Recommended
Transcript
Die Notwendigkeit von Prototyping
00:00:00
Speaker
Das ist ja der Punkt. Wenn wir nicht im Komplexen wären, wenn wir wüssten, wir brauchen genau das und genau das wird uns der Markt abnehmen, dann brauchen wir nicht Prototypen. Dann sollten wir es einfach direkt bauen. Es ist Donnerstag und das ist eine neue Folge vom Visual Makers Podcast. Heute im Gespräch mit Tim Klein von Die Produktwerke.
00:00:28
Speaker
Tim ist seit vielen Jahren im Produktbereich unterwegs, vorher bei Firmen wie Supra Stereo Consulting, HRS Group oder auch Bayer und seit einigen Jahren auch selbstständig als agiler Produktcoach bei die Produktwerke.
Vorstellung von Weweb als No-Code-Tool
00:00:44
Speaker
Tool of the Week.
00:01:15
Speaker
Das Tool der Woche heute ist Weweb. Weweb ist ein No-Code-Bilder für Web-Apps. Dort angesiedelt, wo zum Beispiel auch Bubble.io angesiedelt ist, also für etwas leistungsstärkere Web-Apps. Der Vorteil von Weweb gegenüber Bubble, und deshalb Weweb selbst, ist, dass der Editor zum einen userfreundlicher ist und man damit eine nicht ganz so schwere Zeit hat, vor allem am Anfang, ein schönes Frontend zu bauen.
00:01:42
Speaker
Außerdem hat WeWeb bereits existierende Integrationen zu anderen Tools wie Airtable, SuperBase oder Xano, also Backends, aber auch PostgresQL, MySQL oder GraphQL als Inhouse Integrationen. Das ist natürlich ein Vorteil gegenüber von der Community gebauten Plugins, wie es bei Bubble auf der Fall ist.
Tim Kleins Hintergrund in IT und Produktmanagement
00:02:05
Speaker
Und last but not least, kann man bei Weweb am Ende des Tages auch den Code ganz einfach exportieren und macht sich dementsprechend nicht 100% von der Plattform abhängig. Also, falls ihr eine Alternative zu Bubble.io sucht, dann schaut vorbei bei weweb.io. Hallo Tim, wie geht's dir?
00:02:29
Speaker
Hallo Adriano, ja danke. Schön hier zu sein und mit dir über das Thema zu quatschen. Insgesamt ein bisschen gestresst gerade, aber der Termin stand, also Commitment zählt. Wir machen das jetzt hier.
00:02:40
Speaker
Sehr gut, dann kann ich dich vielleicht für die Folge so ein bisschen aus dem Stress herausholen. Tut ja manchmal ganz gut, dann doch irgendwie sich in was anderes reinzufuchsen. Ja, super schön, dass du jetzt auch mal dabei bist. Vielleicht kannst du dich ja mal kurz vorstellen, wer bist du und was machst du, bevor wir auch über das reden, was du eben machst.
00:03:02
Speaker
Ich versuch's mal in aller Kürze, mal gucken, ob's gelingt. Zum Kleinen, 52 Jahre, bald alt diesen Monat noch. Also, alter Sack von Hause aus, ein blöder BWLer. Hab aber immer mein Leben lang in der IT gearbeitet. Viele Jahre als klassischer Projektmanager und Wasserfall so richtig. Und bin dann irgendwann vor gut zehn Jahren, ja, elf, zwölf Jahren, jetzt in die agile Bubble reingerutscht, in die agile Szene. Hab das Thema Produktmanagement für mich lieben und, ja, lieben gelernt.
00:03:32
Speaker
Ich habe lange Jahre als Product Owner gearbeitet und diese Rolle rund um die Product Owner begeistert mich jetzt immer noch so sehr, dass ich jetzt seit einigen Jahren als Freelancer unterwegs bin, als Product Owner, Coach und Trainer. Das heißt, alles rund um agiles Produktmanagement ist, wo man stecken fährt. Ja, und in der Form begleite ich ziemlich viele verschiedene Unternehmen und
00:03:57
Speaker
Versuch so die Impulse zu setzen, um zu verstehen, dass die Product Owner-Rolle, wie man sie aus der Verantwortlichkeit, wie man sie aus Scrum kennt, bedeutet, dass man vor allem erst mal Produktmanagement lernen muss. Und das mache ich zusammen mit zwei Kollegen Oliver Winter und Dominik Winter unter dem Namen Die Produktwerker.
Rolle und Verantwortung eines Product Owners
00:04:16
Speaker
Und da haben wir auch einen Podcast, ziemlich erfolgreich, unter dem Namen Die Produktwerker seit dreieinhalb Jahren.
00:04:23
Speaker
Ja, von daher freue ich mich, mal auf der anderen Seite des Mikros im Podcast zu sitzen. Genau. Wo Lilith ja auch schon Gast war vor einiger Zeit oder vor kurzem, gar nicht mal so lange her, ist das richtig? Das ist richtig, das stimmt. Lilith und ich kannten uns aus den Pandemiezeiten von irgendeiner Aktion am Startplatz.
00:04:45
Speaker
wo es so eine Feedback-Runde gab für die Founder. Founders Feedback oder irgend sowas. Und ich liebe Feedback. Und natürlich auch lieb Feedback zu geben. Und hab mich als Startplatzmember da so eingewählt. Und da hab ich sie damals kennengelernt. Wir haben uns dann irgendwann so ein bisschen wiedergefunden auf LinkedIn tatsächlich. Hab sie dann zu uns eingeladen. Und danach war ich dann bei euch am Wickel. Und bei dir. Und bei euch im Bootcamp.
00:05:15
Speaker
Genau, dazu kommen wir später auch nochmal. Aber genau, du hast ja gerade schon erwähnt, in welchem Bereich du unterwegs bist und genau darum wird es eben heute gehen. Product Ownership und wie das irgendwie mit No Code zusammenhängt oder zusammenhängt kann. Und genau, zu dem Thema gleich aber mehr. Ich würde gerne aber erstmal so ein bisschen mehr verstehen, was es mit der Welt von
00:05:38
Speaker
Produkt irgendwie auf sich hat. Du hast ja gerade schon gesagt, Product Management, Product Ownership. Ich glaube, jeder, der so ein bisschen in Start-ups und Companies arbeitet, hat das alles schon mal gehört und irgendwie Produktentwicklung. In meiner Anfangszeit nach dem Studium war immer ein bisschen so, was sind das für Leute, was machen die eigentlich? Ich kann mir nicht wirklich vorstellen, dass es eine eigene Rolle an sich ist, bis man dann selber mal ein Produkt entwickeln möchte und merkt, oh wow, das ist
00:06:04
Speaker
Nicht ganz ohne, da sollte jemand im Lead sein. Genau, vielleicht kannst du uns da mal ein bisschen erleuchten. Ja, Produktmanagement ist tatsächlich gerade auch im deutschsprachigen Raum ein hinreichend unklar definierter Job lange Zeit gewesen. Also viele Menschen nennen sich Produktmanager oder machen angeblich Produktmanagement und was das genau ist, da wird es schwer. Tatsächlich kommt das aus einer Vermarktungsecke. Eigentlich ist diese Rolle mal ganz früher bei Procter & Gamble.
00:06:34
Speaker
rund um die Camea-Seife entstanden, wenn man sich ein bisschen in die Historie guckt, tut aber heute nichts zur Sache. Tatsächlich, jetzt Sprung nach heute, finde ich, der große Unterschied, den man machen muss, ist zwischen projektgetriebener Vorgehensweise und produktzentrierter Vorgehensweise und da, wo ein Projekt eben schon nach dienen und so, klar definierten Start, klar definiertes Ende hat und auch ein dafür definiertes Budget.
00:07:00
Speaker
ist ein Produkt halt wesentlich lebenslang lebensfähiger. Also man kann es vielleicht mit einem Projekt starten, das schon, aber danach geht es durch den ganzen Produktlebenszyklus. Und ich frage immer ganz gerne so in den Trainings, naja, wie lange läuft ein Produkt? Und dann gucken immer alle ganz komisch. Und ja, es ist halt, bis es vom Markt genommen wird, so wie jetzt zum Beispiel letztes Jahr im Herbst bei Xing die Gruppen- und Eventsbereiche vom Markt genommen wurden, dann ist ein Produkt tot. Und als Produktmanager
00:07:28
Speaker
Oder auch in dieser Scrum-Rolle oder Verantwortlichkeit des Product Owner bist du eben für die Maximierung des Wertes des Produktes verantwortlich. Meistens dann mit einem Team. Und zusammen mit dem Team würde ich das dann eben auch als Product Ownership, also als Produktverantwortung beschreiben. Die sehe ich nicht nur in der persönlichen Rolle des Produktmanagers oder der Produktmanagerin.
00:07:51
Speaker
Und ja, was macht man da so? Ich würde sagen, den ganzen lieben langen Tag lang Entscheidungen treffen ist so das Wesentliche. Und zwar Entscheidungen rund um Risiken. Also Produktrisiken. Die kennt man klassisch aus dem Design Thinking vielleicht als desirable, feasible und viable. Genau so.
00:08:13
Speaker
Und in den moderneren Produktmanagementsachen wird das sogar als vierer, wenn Diagramm, als vier Dimensionen gesehen, valuable. Also hat das Produkt einen Wert? Löst es ein Problem unserer Zielgruppe? Usable? Ist es nutzbar? Also komme ich da dran, kann ich es benutzen? Da gibt es genug Fails in dieser Welt.
00:08:37
Speaker
Beispielsweise ein schönes Restaurant, teure Sachen, hat aber nur Kartenzahlungen anzubieten. Tja, kann ich halt leider nicht nutzen, wenn ich kein Bargeld dabei habe. Obwohl das Produkt also valuable ist, ist es nicht usable für mich. Die dritte Dimension ist dann Feasibility. Da kommt, glaube ich, No-Code ganz, ganz stark ins Spiel. Werden wir gleich noch darüber sprechen. Machbarkeit auf Deutsch.
00:08:57
Speaker
Und die vierte Dimension ist Business Viable, also das Risiko, ob es wirtschaftlich tragfähig ist.
Bedeutung von Produktentdeckung und Geschäftsmodellen
00:09:04
Speaker
Und dieser Frage sollten sich viele Start-ups natürlich und Gründerinnen auch stellen. Das heißt, das sind so die Dimensionen, um die dann ein Product Owner, eine Product Ownerin herum eigentlich alles entscheidet oder eng dran arbeitet? Ja, ich würde zumindest sagen, modernes Produktmanagement oder moderne Produktentwicklung
00:09:28
Speaker
handelt eben darum, diese eben vier genannten möglichen Risikobereiche möglichst frühzeitig zu erkennen. Englisch würde man sagen, zu discoveren. Und da kommt dann auch der Begriff Product Discovery her, den man abgrenzen kann, von der Product Delivery, also Dinge umzusetzen. Und ich unterteile das eigentlich immer, dass man sagt, in der Discovery muss ich Wissen erwerben, Wissen über Risiken heben.
00:09:53
Speaker
Und wenn ich dann genug Sicherheit, es gibt keine absolute Sicherheit, habe, dann kann ich in der Delivery Sachen liefern, also dieses Wissen nutzen. Und das soll jetzt bitte nicht als neuer Wasserfall verstanden werden, sondern es ist als Continuous Discovery Habits, sagt man ganz gerne, diesen zu entwickeln, dass ich stetig, und jetzt sind wir ganz nah an dem Thema Prototyping und No-Code schon dran, dass ich stetig
00:10:17
Speaker
eine Hypothese aufstelle, dadurch, auf der Basis einer Hypothese, erstmal überlege, ist das die wichtigste Annahme, die wir jetzt testen, Stichwort Assumption Mapping, mache dann ein Experiment.
00:10:28
Speaker
Und gerade dort kann mir No-Code helfen, die Feasibility-Risiken, die Value-Risiken, die Usable-Risiken gut mit diesem Experiment schnell zu verproben, um vielleicht danach zu wissen, okay, ist das Risiko gering genug, in Anführungsstrichen Full-Stack richtig teure Entwicklerinnen draufzuschmeißen und das Ding richtig zu bauen. Oder vielleicht ist es ja schon gut genug mit dem No-Code-Ansatz.
00:10:58
Speaker
Genau, und das war das, was wir, das wissen ein paar vielleicht, die Lilith und Visual Makers auf LinkedIn folgen, aber viele nicht, weil wir das lange auch nicht als offizielles Produkt gelauncht hatten, weil das eben auch noch so in der Entwicklungsphase war, Produkte zu entwickeln, wissen wir jetzt, ist nicht ganz so einfach, ist das Rapid Prototyping Bootcamp mit No-Code, wo Tim eben von Ende März bis Ende Mai
00:11:23
Speaker
Teil der ersten Kohorte war. Und ganz am Anfang der zwölf Wochen, in der das Ganze ging, stand ja auch viel von dem im Fokus, was du ja täglich in deiner Arbeit machst, oder was ihr bei den Produktwerkern macht. Das waren die Business Model Canva, das war die Proposition Canva, wobei du ja auch da nämlich eingebracht hast, dass es ja auch alternative Methoden gibt, die vielleicht sogar agiler sind, oder die du auf jeden Fall präferierst.
00:11:51
Speaker
bevor wir überhaupt an das Bauen gegangen sind oder an das näher kennenlernen von No-Code, wozu wir gleich kommen. Aber ja, könntest du uns einmal in dieser Journey mitnehmen. Jetzt, ich höre hier immer viele zu, die entweder selber schon dabei sind, irgendwie was zu bauen, was zu gründen, oder Leute eben eine Idee haben und vielleicht mit No-Code anfangen möchten. Aber wichtig ist ja eben dieser ganze Prozess davor. Wie du schon gesagt hast, bevor man jetzt einfach was baut, sollte man eben diese ganzen Risiken im Blick haben.
00:12:21
Speaker
Was ist da die Herringensweise, die du da den Zuhörern denn an nahelegen würdest als Agila-Coach? Ja, genauso als Product-Coach würde ich halt immer fragen, wie sind unsere Ressourcen, die wir einsetzen können? Und jetzt nicht nur im Sinne von Geld, sondern auch und Personal, sondern auch im Sinne von Zeit. Und ist no-brainer, dass man sagt, wir sollten jetzt nicht blind irgendwie die Ressourcen rausfeuern
00:12:49
Speaker
Und dann, wenn wir es gebaut haben, gucken, ob es der Markt, der Nutzer, die Nutzerin annimmt oder nicht. Das heißt, das ist genau das Thema mit den Risiken, was ich vorher ansprach. Es geht darum, frühzeitig zu entscheiden, was ich nicht tue. Weil unser Hauptproblem, gerade auch als Start-up-Founder oder so, ist, dass wir zu schnell in unsere Lösungsideen verliebt sind und uns zu wenig mit, meistens zumindest, mit der Problemsituation
00:13:17
Speaker
und den Zielgruppen beschäftigen. Und da helfen eben solche Sachen wie ein Lean Startup Canvas, ein Business Model Canvas, manchmal auch ein Value Proposition Canvas, das ist ein Teil des Business Model Canvas von Alex Osterwalder, um überhaupt sich in der Gruppe, nicht allein auf dem weißen Blatt Papier, sondern in der Gruppe mit meinem Team drüber zu unterhalten und ein
00:13:38
Speaker
Naja, ein gemeinsames Verständnis heraus zu prägen. Wir sprechen dann immer gerne vom gemeinsamen mentalen Modell, sodass wir am Tisch sitzen im Team und ungefähr das Gleiche denken. Das heißt, man muss sich erstmal drüber unterhalten, was will ich denn. Eine Produktvision ist das zum Beispiel, was ich immer sehr empfehle. Das ist wie so ein, ich sage mal analog zu einem Kompass, um klar zu haben, in welche Richtung wollen wir denn den Karren ziehen.
00:14:05
Speaker
Weil ohne Produktvision sind wir sehr Opportunity getrieben. Also, oh, wir könnten den Kunden mitnehmen, oh, wir könnten das Feature einbauen. Das ist gerade am Anfang, glaube ich, bei einem Start-up besonders schwierig, weil du natürlich im Zweifel denkst, ja, da muss ich halt pivotieren. Aber wo ist die Klarheit, die dich in die eine Richtung bringt, damit du
00:14:26
Speaker
Man sagt dann, im Blue Ocean unterwegs bist, also wo nicht so viele Haie unterwegs sind wie im Red Ocean, wo schon alle sich tummeln. Das heißt, Ausrichtung, Businessmodell, Produktvision, um klar zu haben, in welche Richtung wir ziehen, weil wenn wir sonst ohne Produktvision würden fünf Leute in fünf unterschiedliche Richtungen ziehen. Und in welche Richtung geht dann der Karren? In kein Airblatt stehen. Das heißt, Produktvision ist so der Kompass für die Richtung.
00:14:51
Speaker
Man würde dann eine Produktstrategie aufbauen. Das haben wir jetzt hier nicht gemacht im Bootcamp. Das geht nochmal sicherlich alles ein bisschen tiefer. Und auf der Basis, das haben wir, oder habt ihr sehr schön da auch reingebaut, ein Assumption Mapping zu machen. Das heißt, welche, also wie viel Evidenz, auf Deutsch Beweise, haben wir für unsere Annahmen und gleichzeitig zu gucken, wie businesskritisch wäre es, wenn unsere Annahmen nicht zuträfe.
00:15:19
Speaker
Um danach eigentlich rauszufiltern, welche dieser vielen, vielen, vielen Annahmen, die wir haben, sollten wir dann als erstes und vordringlichst mit einem Experiment überprüfen, um da mehr Evidenz zu
Erfahrungen aus dem Rapid Prototyping Bootcamp
00:15:32
Speaker
erlangen. Und je mehr Evidenz wir haben, umso mehr Confidence, also Zutrauen in das Ding haben wir. So, kurzum.
00:15:38
Speaker
Wir haben nicht beliebig viele Ressourcen und meistens ist es zumindest uns unsere Zeit, die wir bitte auch als Ressourcen andenken sollten, einfach mal alles zu machen, auszuprobieren und dann am Markt zu vertesten. In der Wasserfalllehre wird das so gemacht und ich habe leider sehr viele, sehr miese Erlebnisse schon in meinem längeren Berufsleben miterlebt, wo das so passiert ist und sehr, sehr viel Geld versenkt wurde.
00:16:00
Speaker
Man baut ein halbes Jahr lang irgendwas und merkt dann, ups, es braucht keiner. Und von daher finde ich zum Beispiel das Beispiel, was du hattest mit eurem Bootcamp total richtig, dass ihr erstmal eine Produktentwicklung vertestet, viele User-Feedbacks reinholt, bis ihr rauskommt und das Produkt komplett an den Markt stellt. Ja, erstmal gucken, was so geht und wie es funktioniert.
00:16:23
Speaker
Genau, und Storymapping hatte ich jetzt mit reingebracht, weil das mein absolutes Leidenschaftsthema ist. Das ist meine absolute agile Lieblingspraktik, um Klarheit im Sinne einer outcomeorientierten Vorgehensweise zu machen. Auf Deutsch würde ich sagen,
00:16:42
Speaker
Klarheit zu bekommen, welche Wirkungsschritte ich nacheinander gehen muss in Richtung meiner Produktvision. Das geht dann Richtung Agile Roadmap. Also wer sich da mehr interessiert, folgt gerne unserem Podcast oder unserem YouTube, also Produktwerke auf YouTube. Da gibt es einiges von uns dazu oder von mir auch Videos, um sich da ein bisschen tiefer reinzugraben. Und genau, so eine Session habe ich dann einfach, ich habe mich an angeboten, das für die gesamte Kohorte zu machen. Und es kam ganz gut an, glaube ich.
00:17:11
Speaker
Ja, auf jeden Fall. Auch in den eben erwähnten Feedbacks war das eine der beliebteren Sessions in den zwölf Wochen des Bootcamps. Wahrscheinlich nicht nur, weil du das gut gemacht hast, sondern weil es einfach ein sehr nützliches Tool ist in dieser ganzen Anfangsphase von Produkten. Und genau, der Link zu dem Podcast, der Produktwerker, der ist auch in der Podcast-Beschreibung unten zu finden, sowie alle weiteren wichtigen Links.
00:17:40
Speaker
Jetzt aber nochmal zum Bootcamp und vor allem zum Teil des Rapid Prototyping, was ja jetzt vor allem in den letzten Jahren dank dem Rise of NoCo sozusagen ja nochmal neuen Wind bekommen hat. Du bist aber auch schon länger im Produktbereich unterwegs. Wie war deine Erfahrung vorher oder wie ist schon immer so deine Arbeit mit Prototyping gewesen in der Produktentwicklung?
00:18:09
Speaker
Also da ich selber nie eine Hand an Zeilen und Code anlege, weil ich, wie gesagt, eingangs blöder Bewähler bin und weiß, dass ich keine ITler und keine Programmierung kann, also ja, ein bisschen HTML, ein bisschen CSS, aber das ist nicht ernsthaft als Programmierung zu sehen, hatte ich persönlich wenig Erfahrung mit Fullstack-Prototyping.
00:18:31
Speaker
Und ich hätte gesagt, dass ich auch gar keine Erfahrung mit No-Code hatte vorher, außer, dass wir bei den Produktwerkern Make, das frühe Integromat, einsetzen, um Anmeldungen für unsere Live-Events von Eventbrite in unser CRM und unser Slack und so rüber zu schießen. Ja, da wusste... Also, das habe ich nicht tatsächlich spannenderweise nie als No-Code verstanden, sondern als Automatisierungstool.
00:18:57
Speaker
Also es ist mir dann erst durch einen Podcast von euch klarer geworden, dass Automatisierung ist einer der Cluster im Rahmen der NoCo-Thematik. Und das zweite, das auch erst eigentlich über euren Podcast gelernt, aha, ja, ich habe natürlich schon viele viele Jahre mit WordPress und dort eben mit Bildern, Website-Bildern, also sowas wie Beaver, Divi, Elementa gearbeitet.
00:19:22
Speaker
Das hätte ich nie als No-Code verstanden, aber ich habe gelernt bei euch, dass das auch eine Spielwiese, ein Cluster von No-Code ist. Also wenn du so willst, an der UI-Ebene hatte ich dann auch No-Code-Erfahrung. Aber da drunter, insbesondere Richtung Datenbanken, also mit Airtable hatte ich mal einen sehr gescheiterten Versuch, weil die Lernkurve da einfach oder weil die Hürde zu hoch war. Und von Bubble hatte ich vorher noch gar nichts gehört, außer bei euch im Podcast.
00:19:51
Speaker
schien mir auch zu weit weg, zu nerdy, zu, also eher Low-Code als No-Code und bei Low-Code steige ich dann schon aus. Von daher, ja, Automatisierung, das finde ich logisch, das finde ich gut, da kann ich verknüpfen. UI-Narr-Sachen, weil ich sehr lange eben auch
00:20:08
Speaker
Ich war mal Head of Product bei HS und das ist ein sehr marketing- und frontentlastiges Ding natürlich auch, mit viel, viel Backend unten drunter. Aber da wurde sehr pixelgenau gearbeitet. Auf der Schicht kannte ich mich gut aus, aber je weiter es Richtung Datenbanken geht, bin ich raus. Dachte ich, spannende Erkenntnisse während des Bootgames, das kann ich gleich nochmal teilen.
00:20:31
Speaker
Genau, können wir gleich noch mehr zu hören. Nochmal zum Prototyping, weil bevor ich dann selber irgendwie vor einiger Zeit zu No-Code gekommen bin, war für mich Prototyping immer eigentlich nur verbunden mit so haptischen Produkten.
00:20:47
Speaker
Und das ist natürlich, ja, weit weg von dem, was man alles irgendwie prototypen kann. Und dann habe ich mich eben mit den ganzen Low-Fidelity-Sachen beschäftigt und wie schnell und wie leicht man ja sozusagen Produkttypen, wenn man die schon so nennen kann, bauen kann. Machst du oder macht ihr das bei den Produktwerkern in so einer Form auch, also alles, was noch vor den Technischen kommt, in dem Prototyping-Space?
00:21:15
Speaker
eigentlich nicht, weil man muss aber auch sagen, wir bauen keine
Herausforderungen beim Prototyping in komplexen Umgebungen
00:21:18
Speaker
Wir bauen persönlich keine digitalen oder auch keine physischen Produkte. Unsere Produkte sind unsere In-House-Trainings oder seit diesem Jahr auch öffentliche Trainings. Unser Produkt ist der große Podcast. Unser Produkt sind die Live-Events, einmal im Monat kostenfrei zwei Stunden. Und unser weiteres Produkt sind Coachings, also Product-Coachings, One-on-One- und Team-Coachings. Plus halt so Workshop-Facilitation für sowas wie diese Produktvision etc.
00:21:47
Speaker
Da, wo wir dann prototypen, ist eher so, dass wir zum Beispiel ein Training ausschreiben und es buchbar machen. Da steckt dann schon relativ viel Arbeit drin. Aber es noch nicht auskonzipieren. Und es erst dann konzipieren, wenn es auch wirklich stattfindet. Zweitens, vielleicht können wir uns auch als Prototyping nennen, bevor wir die ersten Podcasts veröffentlicht haben, haben wir eine Folge aufgenommen und das erst mal Leuten in eine Art User-Test gegeben.
00:22:13
Speaker
Na gut die allererste folge die wir aufgenommen haben die haben wir noch nicht mal mehr leute gegeben weil wir sofort merken ist so schrecklich geht gar nicht. Also ich komme mir aus der ecke user feedback einsammeln wir sind sehr feedback driven.
00:22:26
Speaker
Das muss aber nicht immer mit Prototypen geschehen. Das kann auch mit Cardsorting, mit Interviewtechniken, mit, oh Gott, es gibt so viele Techniken, das schreibt man sich am Buch. Am besten das Buch von David Bland und Alex Osterwalder, Testing Business Ideas. Ich glaube, das sind 44.
00:22:47
Speaker
Testgeschichten drin und genau wann wo was man am besten einsetzt. Und da ist Prototyping jetzt im digitalen meiner Sicht nur ein Bereich von vielen Möglichkeiten. Feedback jetzt wieder zu den möglichen Risiken und damit mehr Evidenz, ob ich denn falsch liege zu bekommen. Weil das ist für mich das, was immer unten drunter steht. Es könnte ja sein, dass wir uns täuschen. Wir sind verliebt in unsere Idee, in unsere Lösungsidee.
00:23:14
Speaker
Aber wahrscheinlich im komplexen Umfeld täuschen wir uns. Das ist ja der Punkt. Wenn wir nicht im Komplexen wären, wenn wir wüssten, wir brauchen genau das und genau das wird uns der Markt abnehmen, dann brauchen wir
No-Code in der Produktentwicklung
00:23:27
Speaker
nicht Prototypen. Dann sollten wir es einfach direkt bauen.
00:23:31
Speaker
Klar, wenn es nur so einfach wäre, natürlich. Aber wie du schon sagst, es liegt meistens noch nicht mal daran, dass man nicht irgendwie die richtigen Features oder ein cooles Produkt baut, sondern der Pain gar nicht so da ist, wie man sich das selber irgendwie vorstellt. Oder dann irgendwie, man hat doch auf Feedback gehört, aber man hat nicht richtig hingehört. Also da gibt es ja so viele Stellen, an denen es irgendwie schief laufen kann. Aber genau. Und ja, No Code, wie du schon gesagt hast, ist einer,
00:23:57
Speaker
von vielen Tools, um eben sowas zu realisieren oder auf jeden Fall das Tool, das dabei hilft, dass viele Teile des Prototypen und des Product Launching sozusagen zu verschnellern oder zu verbessern, zu vereinfachen. Aber ja, das ist halt nur eins von vielen Tools.
00:24:17
Speaker
Womit du, wie du ja gerade gesagt hast, früher nur wenig Erfahrung hattest oder wenn es nach dir ginge gar keine, aber ja, alles, was ja irgendwie irgendwas Digitales bauen, ohne dass man codet, ist sehr streng genommen No-Code, wenn man so will. Und da gehören eben natürlich die ganzen Website-Bilder, aber auch Automatisierungen dazu.
00:24:36
Speaker
Wie kam es dann dazu, dass du gesagt hast, hey, Rapid Prototyping Bootcamp mit No-Code? Ich weiß, Lilith hatte dich dann auch eingehen eingeladen. Was hat dich daran gereizt, zu sagen, okay, ich möchte mehr mit dem Thema arbeiten?
00:24:51
Speaker
Tatsächlich 100 Prozent das Interview mit Lilith in unserem Podcast. Weil wir suchen Gäste, jede zweite Woche haben wir eine Folge mit Gast. Und auch ja, No-Code klingt spannend, weiß ich so gut wie nichts drüber und wir laden uns ja auch deshalb Gäste ein, um selber dabei was zu lernen. Und dann haben wir da die Aufnahme gemacht und ich dachte so, wow, das kann ich ja gebrauchen.
00:25:17
Speaker
Und zwar genau diese fehlende Superpower als, ich denke die Businessseite vielleicht ein stärker ab. Ich kann auch darüber reden, über Tech, aber ich kann es nicht tun. Ich kann es nicht selber ausprobieren. Und dann geht es mir darum, ich will das kennenlernen. Ich muss es nicht können. Also ich habe nicht den Anspruch, No-Code-Entwickler zu werden, auch wenn ich jetzt da im Bootcamp so halb so wurde.
00:25:43
Speaker
Aber vor allem geht es für mich um Einschätzbarkeit. Was ist möglich? Also ganz konkret ging es darum, dass ich letztes Jahr im Sommer bei einem Kunden, der sehr, sehr klassisch aufgestellt ist und sehr strukturkonservativ eigentlich auch, gesagt habe, bevor wir das und das, ja ein einfaches Formular, das alles bauen, lass uns das doch mal mit No-Code machen.
00:26:06
Speaker
Da habe ich zu den falschen No-Code-Tools gegriffen, also irgendwas mit Erbtable oder so versucht, was dafür völlig ungeeignet war. Und ich merkte, ich bin nicht gut genug darin, meinem Kunden sozusagen das Richtige zu präsentieren oder zu zeigen, was mit No-Code möglich ist. Und das war nach dem Gespräch mit Lilith so mein Hook, dass ich sagte, okay, ich möchte dieses Spielfeld besser kennenlernen.
00:26:33
Speaker
um besser einschätzen zu können, gerade in der Beratung, gerade im Coaching Mentoring von Produktorganisationen, that's my job, sagen zu können, an der Stelle holen wir uns jetzt mal eine No-Code-Agentur oder No-Code-Freelancer, könntet auch ihr sein künftig, kann passieren, und lasst die mal machen. Also ich bin der Letzte, der richtige Code-Entwicklung, also No-Code-Entwicklung da machen wird.
00:27:00
Speaker
Aber ich wollte mal ausprobieren, wie einfach ist das, wie schmerzhaft ist das und das Ziel ist 100% erreicht nach dem Bootcamp. Ja, das höre ich natürlich sehr gerne. Du hast ja gerade schon gesagt, du hast dann auch schon dich ordentlich reingefuchst, und zwar dann mit Bubble. Da sprechen wir gleich auch noch drüber, was du dann nämlich gebaut hast.
00:27:22
Speaker
Aber mich würde es noch mal interessieren, wie siehst du No-Code jetzt, nachdem du dich viel damit beschäftigt hast, im Vergleich zu deiner Erwartungshaltung vorher? Was ist dir irgendwie ein zu verschwommenes Bild? Was kann man damit eigentlich machen, was nicht? Und was hat sich jetzt irgendwie da ausgestellt? Genau, verstehst du die Frage?
00:27:44
Speaker
Ich würde sagen, ich kombiniere mal meinen Erfahrungsaufbau vom Bootcamp und den Masterclasses, die ich damit auch mitgemacht habe im Rahmen des Bootcamps. Das bietet ihr
Einfluss von No-Code auf Agile Entwicklung
00:27:55
Speaker
ja an. Also zumindest die Bubble- und Make-Masterclass habe ich da mitgenommen. Und vorher habe ich halt viel euren Podcast gehört. Also ich glaube, das war... Also es gab im Ende Januar Anfang Freiburg, also noch weit vor dem Bootcamp,
00:28:12
Speaker
Auf einer sehr langen autofahrt habe ich glaube ich mal so quasi 16 folgen am stück gehört und hat mich ziemlich gefangen der podcast und dabei habe ich halt vieles gelernt zum einen zum beispiel.
00:28:24
Speaker
dass ich No-Code ganz klar für produktive Systeme im internen Gebrauch empfehlen würde. Also das kann ich mir sehr gut jetzt vorstellen. Ich hätte vorher immer gesagt, no, no, no, nicht für produktive Systeme, bitte No-Code oder Low-Code, aber für interne Systeme, für die sonst ja sowieso immer viel zu wenig Zeit und Ressourcen eigentlich da sind und wenn, binden die halt sehr viel Kapazitäten, sprich, Opportunitätskosten.
00:28:52
Speaker
entstehen. Dafür finde ich das genial als Idee, sehr vieles mit No-Code abzubilden oder Low-Code. Und der zweite Bereich ist Prototyping. Das ist eigentlich das, was auch meine Erwartung war, dass es damit gut geht im Sinne keine High-Fidelity-Sachen, sondern möglichst schnell an eine Version, auf die jemand Feedback geben kann. Weil das ist für mich
00:29:19
Speaker
Wir sagen im Agil so Inspect and Adapt oder die drei Prinzipien der
00:29:28
Speaker
Von Scrum sind eben auch Transparenz, Inspektion und Adaption, die sogenannte empirische Prozesssteuerung. Das kannst du halt damit total gut machen, weil du hast sonst oder ich kenne so viele Teams, die jammern, wir können in den zwei Wochen Scrum-Sprint das und das gar nicht schaffen. Wir können kein Increment herstellen, auf das wir im Sprint Review Feedback von Stakeholdern und uns selber und sowas und so bekommen können. Und diese Ausrede, die fällt halt weg mit No Code. Ich finde, dass man
00:29:59
Speaker
durch No Code, also wenn man jetzt nicht Anfänger ist da drin oder sich zumindest ein bisschen im Team und das muss nicht der Product Owner sein, der das kennt, sondern irgendwo im Team muss No oder Low Code Expertise heutzutage vorhanden sein. Das würde ich so auf jeden Fall festhalten wollen, weil es neben Full Stack Developer Fähigkeiten, weil es dir eben
00:30:21
Speaker
die Möglichkeiten für Product Ownership in einem Team gibt, gerade dieses Thema Product Discovery, was ich zuvor genannt habe, frühzeitig mit leichtgewichtigen Prototypen anzugehen, sprich Feasibility,
00:30:38
Speaker
Testing im Rahmen der Product Discovery ist nichts anderes, als dass ich Tech-Prototypen schnell erzeuge, um damit so was wie Valuable und Usable-Risk möglichst schnell anzugehen. Vielleicht das noch, für eine produktive, nach außen gewandte B2C- oder B2B-Nutzung habe ich noch keine Leidenschaft im Thema Low-Code und Low-Code für mich zu misserkannt.
00:31:06
Speaker
sehe ich nicht. Also eher so Prototypen bauen, ausprobieren wird es angenommen. Also habe ich einen Product Solution Fit, habe ich dann vielleicht auch weiter, vielleicht könnte man noch bis zum Product Market Fit gehen, aber dann muss ich auch die Kapazitäten einplanen, das auch in Anführungsstrichen richtig zu bauen. Also mit stabiler skalierbarer Lösung.
00:31:32
Speaker
Klar, in Unternehmen ist genau das Problem. Das ist das Problem, dass wenn man einmal sozusagen einen Problem-Solution-Fit hat oder vielleicht sogar Product-Markt-Fit, dann nicht mehr Zeit investiert wird, es dann da unter der Haube richtig zu machen. Nach dem Motto läuft doch, nee, läuft nicht gut genug. Aber das ist genau das Umdenken, was wir brauchen. Wir müssen weg von dieser alten Denke.
00:31:54
Speaker
Wir müssen erstmal total saubere Datenbasis und irgendwie mit Layer und Services und so weiter und ganz am Ende zaubern wir dann irgendwie die UI oben drauf, um dann ganz am Ende festzustellen, ups, das wird sogar nicht genutzt oder führt gar nicht zu einer Conversion-Erhöhung, alles erlebt.
00:32:13
Speaker
Sondern genau diese Logik muss man umdrehen. Erst möglichst schnell, quasi so Hello World-mäßig, erste, also insbesondere entlang der größten Risiken, Dinge vertesten. Wenn ich merke, okay, trägt, okay, wird angenommen, dann kann man sich um die Stabilität unten drunter kümmern. So, in dem Kontext würde ich No-Code und Low-Code aktuell zumindest sehen. Also, meine Lernreise ist jetzt auch noch nicht so lang, gerade mal ein halbes Jahr, wie du hörst.
Vertrauensbildung durch No-Code-Prototypen
00:32:40
Speaker
Kann sein, dass sich das noch ändert.
00:32:44
Speaker
Ja, aber deine Perspektive ist ja vor allem sehr interessant eben aus dieser Produktrichtung, weil das ist auch, glaube ich, jeder, der jetzt zuhört und sich schon länger mit No Code beschäftigt, hat auch, egal mit welchen Tools er oder sie sich beschäftigt, hat auch wahrscheinlich schon gemerkt, dass sehr häufig die ganzen Templates, die es bei Tools gibt,
00:33:07
Speaker
richten sich eigentlich fast immer auf companyinterne Anwendungen. Weil das natürlich, wie du schon gesagt hast am Anfang, das ist was relativ Simples, wo aber eben häufig, wenn man jetzt irgendwie die IT-Abteilung oder die Inhouse-Developer dafür, dessen Zeit irgendwie versuchen würde zu kriegen,
00:33:28
Speaker
wird man die wahrscheinlich nicht dafür bekommen, weil da eben meistens am Produkt gearbeitet wird, was eben nach außen Geld reinbringt. Und wenn ich jetzt als HALA sage, hey, ich hätte gerne irgendwie ein besseres System, um meine Bewerber zu, also in Haushalt zu managen, ohne mir jetzt eine externe Lösung zu holen,
00:33:49
Speaker
Ja, dem wird sich wahrscheinlich keiner mit viel Zeit annehmen, obwohl es ja aber trotzdem, wie du schon gesagt hast, viel Reibung auch innerhalb der Company verursachen kann. Aber genau, dafür gibt es ja eben diese ganzen No-Code-Tools, die entweder schon fertige Templates für genau diese ganzen Bereiche haben. Und wenn es das nicht gibt, kann man gerade sowas, wenn die Komplexität noch recht überschaubar ist, mit ein wenig Stunden und vielleicht ein paar Tage Input selber
00:34:16
Speaker
selber bauen und ja, irgendwie so ein bisschen sich da reinfuchsen. Während das externe ja auch noch, noch mal wesentlich komplexer sein kann, eben ein Produkt, was irgendwie in den Apps, in den Apps zur Säule oder wie ich in der Web-App, was einfach,
00:34:32
Speaker
auch abhängig von dem ganzen User-Feedback, was da in die ganze Zeit reinkommt, halt, hey, dieses Feature, und wenn dann ein No-Code-Tool, mit dem du arbeitest, dieses Feature nicht erlaubt, dann bist du halt draußen. Deswegen, wir da, glaube ich, das könnte ich so auf jeden Fall unterschreiben, für das Prototyping von Produkten, die wirklich auf den Markt sollen, ist No-Code halt optimal. Kann man da wirklich einzelne Features einfach bauen und vertesten in wenigen Tagen.
00:34:55
Speaker
oder wirklich ein ganzes Produkt bauen, bis man eben merkt, alles klar, Product Market Fit ist da, jetzt lohnt es sich, statt 10.000 Euro auch mal eine halbe Million in die Hand zu nehmen und das hier wirklich umzusetzen. Das, ja, ich glaube, das kann man auf jeden Fall so. Naja, gerade im Start-up-Bereich, Adriano, im Endeffekt geht es ja darum, auch Vertrauen für Investoren zu finden und Vertrauen finde ich damit, wenn ich etwas zeigen kann, wo ich Marktsignale drüber abgreifen kann, also echtes Feedback,
00:35:24
Speaker
sehe und ich glaube, dann kriegst du auch die Kohle für die richtige Umsetzung. Und allein dafür ist es gut. Du kannst dir eben gerade im Start-up-Bereich das relativ schnell drauf schaffen, mal was ausprobieren und dann vielleicht auch schön auf die Nase fallen. Aber das würde ich halt total feiern in dem Moment, weil, hey, lass uns froh sein, dass wir es so früh gelernt haben und nicht viel Geld verbrannt haben.
00:35:50
Speaker
Und in dem Sinne geht es halt mit No Code auch neben Feedback um Vertrauensaufbau. Klar, weil es ist ja auch einfach eine komplett andere Validität, die du vor Investoren oder irgendwer anderen hast, zu sagen, hey, wir haben jetzt hier in zwei Tagen eine App mit Glide gebaut und die hat irgendwie schon 500 User und dieses Feedback ist so und so. Selbst wenn du vielleicht besseres Feedback auf deine Low-Fidelity-Figma-Prototypes hättest,
00:36:15
Speaker
Es ist halt, genau, es ist eine ganz andere Qualität zu sagen, naja, aber die haben die App wirklich benutzt auf dem Handy und haben sich am Desktop nicht einfach nur durchgeklickt. Und genau, also dementsprechend, was das angeht, ist No-Code und vor allem diese ganz einfachen Tools wie eben Software Glide, da kann man echt sehr schnell sehr coole Sachen mitbauen, um eben einfach Sachen zu vertesten und nach zwei Tagen
00:36:35
Speaker
Du kannst auch schon sagen, hey, das war es doch nicht. Ja, ist schade, aber du hast halt nur zwei Tage dran verloren und nicht irgendwie sechs Wochen oder vielleicht sogar ein halbes Jahr, um irgendwie eine Idee festzuhalten, die vielleicht gar nichts wäre. Ja, der Zauber, einer der vielen Vorteile von No-Code. Aber genau, hat natürlich auch seine ganzen Grenzen, vor allem, wenn es dann sehr komplex werden soll. Da kann man sicherlich mit ein paar Low-Code-Tools arbeiten. Die größeren, die es da draußen gibt, die dann irgendwie
00:37:04
Speaker
die Microsoft-Geschichten, Mendix oder Outsystems, aber im No-Code-Bereich unsere Go-To-App, mit der wir natürlich arbeiten und in der du ja jetzt auch schon, ja, mit arbeiten durftest und vielleicht sogar schon Junior-Developer sein könntest.
00:37:25
Speaker
Ich glaube, jeder, der schon mal mit Bubble gearbeitet hat, weiß einfach, wie schwer es ist, irgendwie da ordentlich reinzukommen, weil es fällt dann irgendwie unter denselben Schirm, wie dann, ja, wie sowas wie Glide als No Code oder Adalo,
00:37:41
Speaker
Aber ist es halt einfach nicht. Ich glaube, No Code ist halt eine sehr breite Spanne von, ja, ich kann jetzt Wordpress irgendwie zwei Sachen aneinander schieben oder halt wirklich mit Bubble einen Analytics Dashboard bauen.
00:37:55
Speaker
Genau, aber damit haben wir eben im Bootcamp gearbeitet, unter anderem mit Bubble, hauptsächlich für die Produktentwicklung. Willst du uns, den Zuhörenden, mal ein bisschen deine Erfahrung mit Bubble teilen, bevor wir gleich darüber reden, was du denn da genau gebaut hast? Wie war das für dich, damit anzufangen? Wie würdest du das überhaupt einschätzen?
00:38:14
Speaker
Ich gehe nochmal einen ganz halben Schritt zurück. Ich glaube, du hast jetzt ganz viele Produktnamen zum Beispiel genannt von den verschiedenen No-Code-Frameworks und das alleine einordnen zu können. Was ist denn jetzt Bubble im Vergleich zu Airtable, im Vergleich zu Glide, zu Software? Die, die hier zuhören, kennen die Begriffe alle. Aber ich kann sagen, vor einem Jahr stand ich da,
00:38:35
Speaker
wie klein dummerchen und wusste nur ja no code könnte helfen aber was davon und klar diese tools verändern sich auch schnell aber das wäre so meine empfehlung auch für produktentwicklerinnen für product owner und product owner für startups einfach da diesen überblick sich zu verschaffen das heißt da nicht dass du als product owner hinter selber den kram bauen muss aber du
00:38:59
Speaker
Bekommst auch mehr Verständnis, ob diese Hypothese, das geht mit No-Code, denn überhaupt möglich ist und vielleicht mit welchem Tool. Und jetzt in Bubble mal so einzusteigen, im Rahmen des Bootcamps war für mich eine riesen Chance, weil
00:39:15
Speaker
Ja, ich hatte auch durch den Podcast hier vorher schon gelernt. Bubble, das ist echt eine Hürde. Und ganz ehrlich, dafür habe ich oder nehme ich mir nicht die Zeit. Wenn ich schon weiß, das ist schwierig. Make habe ich mir so drauf geschafft für das bisschen, was wir da brauchen. Da geht bestimmt auch noch mehr.
00:39:35
Speaker
bubble war ja dann zunächst mal so was heißt gesetzt aber das war so ein bisschen das versprechen in der bootcamp rapid prototyping arbeiten wir mit bubble und das war für mich so die challenge gegen mich selber und dann habt ihr genau noch direkt am anfang sagt jetzt sucht euch mal ein projekt aus wir haben hier ein paar beispiele das war auch
00:39:56
Speaker
gut oder gut gemeint, aber mit den Beispielen, mit den Beispielanwendungen, die es da so gab, die ihr so hattet, konnte ich irgendwie nichts anfangen. Das war, also da konnte ich mich nicht zu motivieren. Und ich weiß, ich lerne sowas nicht alleine, so to say, alleine mit einer Masterclass. Das ist sehr hilfreich, aber ich brauche die Challenge an einer Entwicklung, an einem wirklichen, also wie
00:40:21
Speaker
Besondere Excel-Funktionen kapiere ich auch erst nur dann, wenn ich wirklich sie mal einsetzen muss oder möchte. Und genau das war der Grund, dass ich gesagt habe, ganz ehrlich, ich muss mir irgendwas anderes überlegen, irgendein Case, ein kleines Projektchen, wo ich auch eine Leidenschaft drin habe, damit es mich auch motiviert, mich in Bubble reinzugraben und das nicht so Shishi-mäßig nur auf Masterclass-Ebene bleibt.
Digitalisierung des POEM Tools
00:40:47
Speaker
Sei dazu gesagt, die Masterclasses sind super. Wirklich, kann ich nur empfehlen zum Lernen. Aber die Masterclass vermittelt Wissen, sag ich immer. Und im Bootcamp haben wir angefangen oder habt ihr Können vermittelt. Oder ich bin, wie gesagt, jetzt kein großer Entwickler geworden, aber ich habe es anwenden müssen, mir die Hände schmutzig machen müssen.
00:41:12
Speaker
Bubble war dann für mich so im Erleben, so die erste, die oberste Schicht. Och ja, hier UI-Ebene, pff, das ist ja fast wie WordPress, ne? Also wie Beaver oder Elementos. Ja, hier ein bisschen Padding und da ein bisschen, äh, Div und, pff, okay.
00:41:30
Speaker
Und dann kam so die Datenbank-Ebene, die hab da dann irgendwann eingeführt. Da hat's mich so ein bisschen gerissen, muss ich sagen. Warum? Weil ich von meinem Glaubenssatz natürlich immer von mir her trage, ja, ich bin ja blöd der BWLer, ich kann das ja nicht, ich kann ja nicht programmieren.
00:41:45
Speaker
Und da habe ich aber gemerkt, dass die Logik von Bubble auf der Datenbank-Ebene so anders ist zu all dem, was ich offensichtlich dann doch schon weiß über relationale Datenbanken oder mitgekriegt habe im Rahmen der Entwicklung bei Kunden oder meinen vorherigen Arbeitgebern, dass es da für mich manchmal echt schwierig war, diesen Knoten im Kopf oder das Habit aus der klassischen Datenbank-Entwicklung,
00:42:11
Speaker
abzulegen und diese Logik, diese für mich sehr krumme Logik in Bubble erstmal zu kopieren oder mich darauf einzulassen.
00:42:20
Speaker
Und so ging das dann weiter mit dem, ich sage jetzt mal, dem dritten Part von Bubble, so verstehe ich es, die Workflows. So, und das war dann genau der Punkt bei den Workflows, wo ich merkte so, wow, da geht es ja im Endeffekt so um if this, then that, also so logische Verknüpfung zu bauen. Das liegt mir total, ich bin mathematischer Typ, also so Logik und so finde ich total geil.
00:42:42
Speaker
Aber da brauchte ich dann sehr viel Hilfe, unter anderem auch von dir, um an dem Projekt, an dem ich gearbeitet habe, wirklich weiterzukommen. Dann erzähle ich mal kurz, was wir da gemacht haben. Wir haben so ein Coaching-Tool mal entwickelt, Oliver Winter und ich, 2017 schon, das sogenannte POEM.
00:43:01
Speaker
Product Ownership Evolution Model, kurz P-U-E-M. Wenn das mehr interessiert, einfach auf Produktwerker.de slash poem nachgucken. Das ist eine Art Self-Assessment rund um das Thema Entscheidungsverantwortung und Entscheidungsverantwortung explizit machen, also Ownership. Und das ist eigentlich so ein Ding, das druckst du aus. DIN A4 ist eine Art Template. Jeder füllt das aus mit einem dicken Filzstift.
00:43:29
Speaker
Positioniert da die verschiedenen Rollen oder so.
00:43:33
Speaker
Personen wie Product Owner, Scrum Master, das Entwicklungsteam, vielleicht Head of Product oder andere Stakeholder. Wer hat hier eigentlich was mitzuquatschen? So ungefähr. Wie sehen wir das im Ist, in der Ist-Situation? Und wie sehe ich das in der Soll-Situation? Wo möchte ich eigentlich hin? Es ging immer um diese Grundfrage. Hey, ich bin als Product Owner hier nur so ein Story-Schubser und Backlog-Verwalter. Ich will aber doch eigentlich viel eher taktisch und strategisch in dem Produkt mitarbeiten.
00:43:59
Speaker
Aber die anderen lassen mich nicht, da kommt immer so ein Chef, der grätscht mir da rein oder so. Also so ein Tool ist das, sprich, man hat eigentlich, ist das ein Pen and Paper Tool. Ein Ausdruck, jeder geht da mit dem Kugelschreiber und deckt ein Filz rein, malet was drauf rum, positioniert so kleine Männchen, wir haben es dann hier Avatare genannt, und visualisiert damit was, macht also etwas explizit und hinterher
00:44:25
Speaker
geht man dem Team hin und legt die alle zusammen oder hängt die zusammen am Whiteboard auf und bespricht, was jeder so einzeln sieht, wo jeder so einzeln hin will und damit werden Missverständnisse aufgedeckt. So, das mal in aller Kürze. Das heißt Herausforderung, das bitte einmal digitalisieren als Web-App. Also sowohl dieses sehr leichtgewichtige Ausfüllen, was du sonst wo rumkritzeln würdest mit dem Filzstift,
00:44:51
Speaker
Wie kriegt das hin in digital? Geht das mit Bubble? Also ich weiß noch, als ich mir überlegt habe, das könnte ich ja mal angehen, das zu digitalisieren, sodass man das auch asynchron in der Gruppe ausfüllen kann und dann wiederum zur Auswertungssession zusammenkommt. Da habe ich euch gefragt, Alex und ich und Lilith, nach dem Motor ist das.
00:45:10
Speaker
Ist das überhaupt denkbar, so was mit Bubbles zu machen? Und ihr sagt so, ja, doch, müsste gehen, also klingt gut. Und es war aber für mich so, das schaff ich nie. Na ja gut, wenn ihr mir hilft, dann muss das so gehen. Und ja, genau über dieses Thema Assumption Mapping und Co., was wir gesagt hatten, also Zielgruppen, was sind die größten Hypothesen und so, bin ich dann eben dazu gekommen, eine der größten Hypothesen war, hey, krieg ich das mit diesem Positionieren dieser, nennen wir sie mal, Avatare, dieser Rollen,
00:45:39
Speaker
so hin, dass sich das sehr leichtgewichtig anfühlt, dass man also mehr inhaltlich überlegt, übernimmt der diese Person jetzt hier die finale Verantwortung für Sprint Goal oder wie viel machen die Developer, machen die nur User Stories und Product Badgar Items oder
00:45:59
Speaker
gehen die auch bis zu Sprints hier, wie Cratch da so ein Business Owner rein, also so ein Synonym für Head of Product oder Chief Product Owner oder C3PO. So, das heißt, hey, per Web App so kleine Männer können auf dem Spielfeld hin und her schieben, jetzt mal ganz vereinfacht gesagt. Hätte ich mir nicht vorstellen können, aber geht mit Babel. Das habe ich gelernt.
00:46:26
Speaker
Genau, und das ist ja das Schöne an Bubble. Es lässt sich in den vielen Funktionen, die es sowieso schon hat, ja auch nochmal extrem erweitern mit Plugins und das war in diesem Fall genauso eine Lösung. Bubble hat nämlich einen Drag-and-Drop-Plugin.
00:46:40
Speaker
mit dem man dann eben, ja, eine Drag-and-Drop-Funktion nutzen kann. Sei es für irgendwelche Kanban-Boards, die man sich da irgendwo reinbauen will, oder eben für sowas ganz Bestimmtes wie die Pro-M-App. Genau, und das er ja echt dann auch gut funktioniert und eigentlich so, wie man es sich vorgestellt hatte, wie es dann
00:46:58
Speaker
dann aussieht. Aber ja, also dein Start war auf jeden Fall, glaube ich, nicht so, wie du dir das vielleicht vorgestellt hattest, wobei man auch sagen muss, der Bubble ist eben nicht so leicht. Und ich glaube, ein paar Sachen, gerade das auch mit den Datenbanken haben wir vielleicht zu Beginn des Bootcamps, glaube ich, ein bisschen zu
00:47:18
Speaker
grundlegend gemacht, weil wir es schon nochmal abdecken wollten, diese ganze Theorie der Datenbanken.
Zukunftspläne bei Produktwerkers mit No-Code
00:47:23
Speaker
Aber in den No-Go-Tools, um es eben zu vereinfachen, ist ein Abstractionslevel ja nochmal drin, das dann nicht unbedingt was mit dem zu tun hat, was man irgendwie über Datenbanken mal Theorien gelernt hat, vor allem relationale Datenbanken. Aber ja, dementsprechend muss man sich da so ein bisschen umdenken.
00:47:45
Speaker
Jetzt, wo du mit Bubble vor allem gearbeitet hast, hast du auch die anderen No-Code-Tools kennst. Was sind so deine größten Learnings daraus, vor allem für Product Manager und oder Product Owner? Generell ist da heute mit No-Code und auch so ein bisschen zu der Frage, wer sollte das können und wer sollte das nur kennen?
00:48:08
Speaker
Also ich glaube, Agile-Produktmanager in der Verantwortlichkeit als Product Owner, für uns ist immer Product Manager der Job, Product Owner ist die Rolle, die sollten es kennen. Sie müssen es nicht können, weil mit dem Können würden sie ja in das Wie eingreifen und sie sind eher dafür ja da, das Was zu definieren.
00:48:32
Speaker
Kennen sollten es Developerinnen im Team und damit meine ich jetzt nicht Software-Engineers, sondern irgendwelche Menschen im Team. Könnte man also gut vorstellen, dass UX-Expertinnen oder auch Business-Analysten, dass sie dieses Menschen sind, die das können sollten. Sodass insgesamt sichergestellt ist, dass wir die Kompetenz für No-Code in unserem Produktentwicklungsteam haben.
00:49:02
Speaker
Und der oder die PO sollte dann zumindest grob wissen, was es für Tools gibt, für was ist Make, für was sind Bubble Software, Glide & Co. Am ersten finde ich als PO noch, glaube ich, Make sinnvoll zu können oder da ein bisschen stärker zu sein, weil ich glaube, über Make gibt es ganz viele Effizienzvorteile zu heben.
00:49:29
Speaker
Und und sei es nur auch im im Rahmen einer Fulstech Entwicklung vielleicht ja so Sachen Schnittstellen zum Mocken oder so auch das kann ich mir vorstellen habe ich nicht ausprobiert mein Fazit ist.
00:49:47
Speaker
Bubble ist schon echt ein Brett. Man muss sich Zeit nehmen dafür. Ich habe gemerkt, wenn ich mir immer nur so alle paar Tage Zeit dafür genommen habe, habe ich unwahrscheinlich große Schwierigkeiten gehabt, diesen Kontextwechsel immer wieder hinzukriegen und mich wieder reinzudenken. Das heißt, tatsächlich in größeren Blöcken sich da reinarbeiten ist mein Tipp.
00:50:10
Speaker
um dann peu à peu das zu verstehen, mit Hilfe von Expertinnen wie euch. Das würde ich auch als Tipp sehen. Ist es wichtig, sich da reinzuarbeiten? Ja, und ich würde es nicht unterschätzen, mit No-Code zu arbeiten. Also, es ist kein No-Braner, würde ich sagen. Das Wort No-Code ist so ein bisschen misleading vielleicht an der Stelle.
00:50:39
Speaker
Aber unterm Strich hat das für mich einen totalen Gewinn gebracht, dieses Spielfeld des No Codes und Low Codes ein bisschen besser abgemessen zu haben, jetzt für mich besser zu verstehen, welche Player da so unterwegs sind drauf. Ja, und in diesem Sinne würde ich es auch POs und PMs raten, sich da so einzuarbeiten.
00:51:00
Speaker
Ja, ich glaube, das sind auf jeden Fall gute Learnings dabei. Wie sieht denn die Zukunft von No-Code bei den Produktwerkern aus, jetzt wo du das Bootcamp gemacht hast?
00:51:12
Speaker
Ja, wir werden jetzt natürlich eine No-Code-Company, klar. Nein, Spaß. Tatsächlich ist es so, also mit der poem-App, über die wir gerade sprachen, bin ich noch nicht fertig. Also weniger mit dem No-Code-Teil, würde ich sagen, als mit dem Texten drum herum. Und das ist aber ein klares Ziel, das jetzt möglichst bald fertigzustellen. Da kam zeitlich ein bisschen was dazwischen. Und dann ist es, wie ich gerade vorhin schon sagte, immer dieser Angang wieder, mich reinzuarbeiten.
00:51:40
Speaker
und das Ding mal fertig zu machen, ist es aber schon so weit, dass wir es einfach mal bis in eine MVP-Phase rausrollen können, um das dann eben, also dieses Paum auch für unsere Nutzerinnen und Nutzer digital verfügbar zu machen und hier, da schließt sich der Kreis, Feedback drauf einzusammeln und ob es, wenn das Feedback positiv ist, dass die Hypothese, dass diese Paum-App überhaupt digital genutzt wird,
00:52:04
Speaker
Wenn sie das zutrifft, na dann würde ich da weiterarbeiten mit No-Code. Ansonsten eben nicht, weil darum geht es ja ein bisschen Aufwand reinzustecken, soweit, dass ich Feedback kriege und wenn wir feststellen, dass wir darüber zum Beispiel viel Value generieren, dass wir Leads einsammeln und so.
00:52:19
Speaker
Dann geht's an der Stelle weiter. Mit Make sind wir auf jeden Fall weiterhin unterwegs. Ich kann mir vorstellen, dass wir mehr machen mit Make. Ich hab mich bewusst erst mal fokussiert auf Bubble, aber ich weiß, dass ich noch mal tiefer in die Make-Masterclass reingucken werde und Make selber mehr explorieren werde, als ich das bislang getan habe.
00:52:42
Speaker
Ansonsten, wenn das tatsächlich mit der POM-App einschlägt, könnte ich mir weitere Coaching-Tools oder so schon sehr gut vorstellen, die dann auch auf No-Code zu machen.
00:52:55
Speaker
Sehr schön. Bisher gibt es wahrscheinlich schon wieder 30 neue No-Code-Tools auf dem Markt. Aber ja, da versuchen wir irgendwie dran zu bleiben und alles mal auszuprobieren. Also vielleicht gibt es beim nächsten Bootcamp dann schon wieder ganz andere Tools. Sehr schön. Dann, ja, an dieser Stelle möchte ich mich bedanken für deinen ganzen Input. Natürlich einmal, dass du beim Bootcamp dabei warst und auch,
00:53:18
Speaker
Viele Feedback, was wir von dir und deiner Erfahrung in dem Bereich kriegen durften, was wir dann hoffentlich zur neuen Kohorte, die auch kommen wird, also für alle Zuhörenden, die daran interessiert sind, würde es eine neue Kohorte geben. Viel wird sich da auf jeden Fall verändert haben, weil wir eben auch viel gelernt haben aus der ersten Produkt-Iteration. Genau, und dann auch viel aus dem Feedback von und mit Tim.
00:53:42
Speaker
Ja, jeder, der in die Produktwelt gucken möchte oder auch hören. Genau, Produkte, Werke, Podcasts in den Show Notes.
00:53:54
Speaker
Tims LinkedIn ist da auch drin, genauso wie der Link zu der Webseite, als auch zum ProAmp Tool an sich. Und ja, vielleicht sehen wir ja auch bald dann die digitale Version vom ProAmp Tool in Aktion. Da bin ich auf jeden Fall sehr gespannt. Es wird auf dem Link, den es jetzt gibt, irgendwann die digitale Version dahinter geschaltet. Und insofern, der Link bleibt gültig, egal wann ihr jetzt diesen Podcast hört.
00:54:19
Speaker
Wie du gerade schon sagtest, verknüpft euch gerne mit mir per LinkedIn. Gerne vielleicht ein kurzes Stichwort, wenn ihr einen Text reinschreiben könnt. Hier gehört bei Visual Makers. Das ist natürlich zum einen für die Nachverfolgbarkeit immer spannend und zum anderen, wenn man viele Anfragen kriegt, auch so ein bisschen Trust Building. Von daher freue ich mich, euch auf LinkedIn zu lesen oder wenn ihr mir dort folgt rund um unsere Themen Agila Produktentwicklung, Hypothesenbasierter Entwicklung und ja, Product Discovery.
00:54:48
Speaker
Klasse. Danke, dass du dabei warst, Tim. Und wir sehen uns bestimmt bald wieder.