10 Mythen der Software-Entwicklung und was dran ist

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von digital kompakt und heute durften wieder der liebe Till und der gute Björn zum Spielen rauskommen. Das sind ja meine Go-To-Guys, wenn es um Tech geht. Weil der liebe Till, der ist ja VP Product bei SAP Signavio und Björn VP Engineering und die nehmen mich immer so ein Stückchen an die Hand und erklären mir mal, wie das eigentlich läuft. So, und heute haben wir uns ein schönes Listicle-Thema gesucht, nämlich 10 Mythen aus der Softwareentwicklung. Die einen mehr Richtung Product, die anderen mehr Richtung Engineering. Ich mache hier mal so halbwegs den Schiedsrichter. Das heißt, ich werde die Mythen immer vorlesen und die beiden werden dann jeweils ihre Perspektive geben. Also Till aus Product-Sicht und Björn aus Tech-Sicht, also Engineering. Und dann gucken wir mal, vielleicht haben wir ja so einen gemeinsamen Nenner, ihr beiden, oder? Moin, moin.

Björn Wagner: Moin.

**Till Reiter: **Moin.

Joel Kaczmarek: Ja, cool. Wollen wir direkt rein starten von den 10 oder vielleicht mal so als kleines Vorspiel. Wie viel von den 10 habt ihr sozusagen, fühlt ihr oder ist da irgendwie etwas dran?

Björn Wagner: Glaube ich schon. Also wir haben lange drüber nachgedacht und ich würde sagen, wir können zu allen stehen. Mal schauen, wer am Ende vorne liegt.

Till Reiter: Man hört es auf jeden Fall irgendwie Tag ein, Tag aus, den einen oder anderen Mythos, die wir heute hoffentlich bereinigen können.

Joel Kaczmarek: Okay, na gut, also ich lese vor. Wir haben hier englische Sprache gewählt. Ich werde jetzt auch mal versuchen, hier und da einzudeutschen. Also das erste dreht sich aus dem Bereich Product, wo es lautet Product Manager are just glorified notetakers, also glorifizierte Mitschreiberlinge. So, Till, du fängst an. Was macht das mit dir?

Till Reiter: Naja, das wäre so ein Mythos, der vom Engineering zu uns rüber geworfen wird. Woher er kommt, kann ich schon verstehen. Eigentlich sind gute Produktmanager immer am Schreiben. Ich denke aber, das kommt eher daher, dass man immer ein bisschen als Detektiv unterwegs ist. Was kann ich aus der Konversation rausnehmen? Was will ich später intern weiterführen, weiter verarbeiten? Weil die Aufgabe ist ja irgendwie die Stimme des Kunden und des Marktes zu sein und deswegen Ist man viel am Not-Taken, aber am Ende dient das dazu, eine Vision aufzubauen und die dann auch ins Engineering zu tragen. Björn, was sagst du dazu?

Björn Wagner: Ja, ich muss dem Till leider zustimmen. Also grundsätzlich natürlich zuhören, Notizen machen, Sachen verstehen, vor allem Kunden zuhören, ist glaube ich eins der Key-Themen. Und sonst, die guten Produktmanager, mit denen ich mal zusammengearbeitet habe, haben einen super starken Fokus auf Wert, wirklich Kundenwert verstehen. auf dem Markt verstehen, wie kann man das Ganze kommerzialisieren und sind auch dann sehr gut darin, die Sachen halt zu kommunizieren. Das ist, glaube ich, der Teil, der beim Note-Tacking ein bisschen untergeht, nicht nur zuhören, das ist wichtig, dann aber auch, hey, wie kann man jetzt die Vision, die Strategie halt kommunizieren und damit sowohl die Kunden als auch andere Leute, Engineers in der Organisation mitnehmen.

Joel Kaczmarek: Ich meine, wo wir mal eine kleine Mini-Debatte noch starten können, so könnt ihr mal euren Take drauf geben, ist die Unvorhersehbarkeit eigentlich, die bei Product Development dann ja auch so drin steckt, weil das hört man ja so ein bisschen raus, wenn man immer nur am Schreiben ist und Gespräche führt, das Ganze ist ja dann gar nicht so planbar.

Björn Wagner: Ja, Planung ist natürlich ein wichtiger Teil, also wenn es dann vor allem um die Umsetzung geht, aber der wichtige Teil ist ja Vorbereitung, Verstehen, weil bevor man lieber mit drei Kunden mehr redet, mehr Notizen nehmen, bevor wir anfangen, die falschen Sachen zu bauen, ist auf jeden Fall vorab wertvoll investierte Zeit, würde ich sagen.

Till Reiter: Ja, und eins der Key-Skills, die ich bei guten PMs sehe, aber auch grundsätzlich im Job, ist Active Listening. Und mir hilft es zum Beispiel persönlich auch zu schreiben, weil es sich zwingt irgendwie zu denken und es nochmal zu formulieren. Also, erster Mythos, unwahr.

Joel Kaczmarek: Gut, Mythos Nummer zwei, eher in Richtung Engineering, also jetzt ist mal der Björn betroffen. Engineers hate dealing with product managers. Stimmt das?

Björn Wagner: Würde ich pauschal nicht so sagen. Wir beschreiben das häufig als gesunde Konflikte, die man hat oder auch Optionen, die man quasi gegenseitig versucht auszuwerten und quasi die beste Lösung für den Kunden zu finden. Ich glaube, man kann nur erfolgreich sein, wenn man zusammenarbeitet. Das Thema cross-funktionale Teams, Leute mit einem starken Product-Background, Leute mit einem starken Tech-Background und Leute mit einem starken Design-User-Experience-Background, die müssen zusammenkommen und die müssen gemeinsam Kundenprobleme verstehen und dann Lösungen entwickeln. Das ist, glaube ich, der Kern. Gibt es Spannungen? Gibt es häufiger andere Mindsets oder andere Arbeitsweisen? Absolut. Aber zum gewissen Teil ist das auch gesund. Ich glaube, was wichtig ist, man muss sich gegenseitig vertrauen und man braucht ein gemeinsames Ziel, auf das man hinarbeitet. Und wenn man das hat, dann lassen sich so Konflikte auch relativ gut lösen.

Till Reiter: Ja, auch wieder Umwahr meiner Meinung nach. Ich glaube, am Ende, die erfolgreichen Teams, Björn, wir sehen es bei uns auch, haben starke Relationships. Und ich glaube, ein gewisser Faktor an Likeability gehört immer dazu. Also jeder kennt, glaube ich, die Leute, die Exzellenzen, Data Collection, Interpretation etc. haben, wenn die einfach mit der Brechstange sozusagen auf Engineering und Design zugehen, ohne da ein funktionierendes Relationship aufzubauen, funktioniert das nicht. Und diese Typen gibt es logischerweise auf beiden Seiten vom Gewässer oder wie man sagt.

Joel Kaczmarek: Ich weiß auch nicht, wie das Zitat heißt. Auf beiden Seiten der Gleichung? Aber gut, ich meine, was ich jetzt auf gut Deutsch mitnehme, also es ist so ein bisschen notwendiges Übel, dass man cross-funktional arbeitet in eurem Bereich. Von daher Wäre jetzt ein bisschen undankbar, wenn Engineering die wirklich nicht mag, die Product Guys, oder?

Björn Wagner: Absolut, ja.

Joel Kaczmarek: Gut, also auch falsch. Mann, na mal schauen. Zweimal falsch schon von 10. Let's see. Dritter Mythos richtet sich wieder in Richtung Product. The best product ideas come from the top. Stimmt das, Till?

Till Reiter: Leider auch schon wieder falsch. Ist natürlich so formuliert, dass man das relativ schnell raushört. Es gibt viele Unternehmen, wo sie denken, okay, die beste Produktidee kommt vom CEO. Kann auch oft mal wahr sein, vor allem bei jungen Startups, wo der Produktmanager eigentlich der CEO ist. War bei uns auch so. Aber wenn man dann anfängt, die Organisation größer aufzubauen und zu skalieren, muss man die Ideen aus dem Unternehmen rausfischen, von den Kunden sich einholen und vom Markt. Björn, wo denkst du kommen die besten Ideen her?

Björn Wagner: Also ich würde sagen, es ist halb wahr, sowohl von oben, aber halt auch von unten. Einer der spannendsten Tage für mich im Jahr ist immer, wenn wir, wir machen einmal im Jahr bei Signavio einen Strategiezyklus, wo wir uns quasi anschauen, wo stehen wir heute, was ist der Status, wo wollen wir in drei Jahren sein, wo wollen wir nächstes Jahr sein. Und da gibt es natürlich sehr viel vom Product Management so Top-Down-Input, da gibt es dann aber auch immer einen Tag, wir nennen das Pitch-Day, wo wir dann wirklich alle 10, 15 Teams die Möglichkeit haben, ihre eigenen Ideen zu pitchen, quasi sie sind ja auch Sender am Kunden, wissen, was die Probleme, die Herausforderungen sind. Und am Ende des Tages ist es dann, sag ich mal, ein Wettbewerb der Ideen. Dann packt man das alles in eine Liste, versucht es anhand seiner Ziele zu priorisieren und natürlich schafft es nicht jede Idee, egal wo sie herkommt, dann ins Produkt. Aber ich glaube sowohl, dass man halt auch von den Teams Bottom-Up-Ideen quasi in das Produkt einfließen lässt, als auch irgendwie eine Top-Down-Perspektive. Das trifft sich eigentlich immer ganz gut und man muss halt dann ein Mix and Match machen.

Joel Kaczmarek: Also die Gegenthese wäre ja sonst, die besten Ideen kommen von den Usern. Also ich kenne immer diesen schönen Spruch, the best ideas come from talking to users until your ears bleed. Sagt man das auf Englisch eigentlich? Bis dir die Ohren bluten, würde man auf Deutsch sagen. Was ist da dran?

Till Reiter: Ich glaube, du kannst daraus Ideen entwickeln, aber üblicherweise sind die Kunden relativ schlecht, in dir die besten Lösungen vorzuschlagen. Du musst ja dann auch noch abwägen, kann ich das hier mit meinem Tech-Stack entwickeln, funktioniert die Lösung für mein Business? Und du musst eigentlich zwischen den Zeilen lesen, was für Probleme da oft existieren. Manchmal sagen die, ich will genau dieses Feature, aber am Ende geht es darum, dass man intern sich für irgendeinen Sponsor rechtfertigen kann etc. Da muss man also zwischen den Zeilen lesen.

Joel Kaczmarek: Da gibt es ja auch mal so diesen schönen Spruch, wenn Guttenberg irgendwie die Mönche, die damals viel geschrieben haben, gefragt hätte, wie kann ich das verbessern, dann hätten sie gesagt, mach uns schneller schreiben, befedern. Anstatt einer Druckmaschine. Der vierte Mythos, der ist spannend, weil der bringt nochmal einen anderen Dreh rein. Also wir haben jetzt gesagt, dass im Product die besten Ideen entweder vom The Top kommen oder vom Besprechen mit den Usern. Und das ist ja mal ganz interessant. Data is the only thing that matters. Also die Rolle von Daten mal noch reingebracht in den Product-Bereich. Till, was sagst du?

Till Reiter: Ja, ich sage ganz so hart kann man es nicht mehr formulieren. Es gab aber die Phase, wo es, glaube ich, in der Industrie so gemacht wurde, wo man immer gesagt hat, okay, wir machen Data-Driven-Development. Das Pendulum schwingt wieder so ein bisschen zurück. Aktuell höre ich oft Data-Inspired-Product-Development. Und das heißt, natürlich muss man die Daten nutzen, aber die dann auch im Kontext von qualitativen Ergebnissen etc. stellen können. Und was hier wichtig ist, ist halt die eigene Intuition. Und daran merkt man auch oft, wer hat schon mehr Erfahrung gesammelt. Intuition basiert ja sozusagen auch auf meinen persönlichen Daten und was für Schlussfolgerungen ich daraus ziehen kann. Also kann man auch nicht ganz so halten. Was sagst du dazu, Björn?

Björn Wagner: Ja, also ich würde schon sagen, es ist nicht das Einzige, aber mit das Wichtigste eigentlich. Ich glaube, man trifft einfach bessere Entscheidungen, wenn man eine solide Datengrundlage hat. Natürlich darf man nicht vergessen, die Welt ist komplex und man kann nicht alles in irgendwelchen datenmetriken Modellen abbilden und das muss man dann halt immer abwägen. Für mich ist so die Grundregel Bauchgefühl, qualitative Sachen und dann quantitative Sachen von der Prion. Also dass das Quantitative schon auf jeden Fall mit das Wichtigste ist. Was sehr spannend ist, gerade in größeren Organisationen, Daten alleine helfen ja nicht. Man muss halt auch die, sage ich mal, Erfahrungen oder die Prozesse entwickeln, dass man halt aus Daten auch die erstmal richtig analysiert und dann die richtigen Schlussfolgerungen zieht. Plus. man muss halt die Organisation und die Leute dorthin entwickeln, dass sie zum einen den Daten vertrauen, das ist so die erste Hürde, das ist halt, was ist das für eine Metrik, verstehe ich nicht, vertraue ich nicht, lass mich in Ruhe so nach dem Motto, da muss man die Leute mitnehmen. Und halt auch ein starkes Transparenz-Mindset haben, weil mit Daten kommt man auch schnell rein, gerade in größeren Organisationen, dass man dann sagt, hey, möchte man jetzt Teams verschiedene Produkte gegeneinander messen, benchmarken? Und da muss man halt schauen, dass man das sauber auch in die Kultur reinbekommt und dass man nicht nur tolle Dashboards hat, sondern halt auch wirklich saubere Schlussfolgerungen zieht. Und ganz wichtig, die richtigen Sachen messen. Ich habe es ganz häufig gesehen, Leute versuchen wahnsinnig komplexe Metriken zu definieren und zu erfinden. Ich glaube, Einfachheit und dann ein bisschen in die Breite gehen hilft da am Anfang sehr, um halt so eine solide Foundation zu haben, aber es wird immer Sachen geben, die kann man nicht messen und dann muss man dann entweder auf qualitative Sachen oder halt auf Intuition zurückgreifen.

Joel Kaczmarek: Na gut, also so halb wahr. Data is not the only thing that matters, but it's an important thing. Gut, Nummer 5, wieder im Product-Bereich. Shipping a product is the finish line. Ist dem so, Till?

Till Reiter: Ja, es ist eher ein Milestone. Also ich glaube, jeder kennt es, wenn man irgendwie Crunch-Phase hat vor dem Release, man will es jetzt irgendwie rausbringen, Product-Marketing steht bereit und man denkt, ab nächster Woche ist mein Leben wieder entspannt. Ist es meistens nicht. Oft gehen die Probleme dann erst los. Du hast echte User auf dem Produkt, du entdeckst deine ersten Bugs, du weißt, wo du Adjustment machen musst etc. Wichtiger Milestone, aber es geht um Continuous Improvement etc. und ganz wichtig natürlich, dass auch angenommen wird das Produkt. Haben gerade von Daten gesprochen. Retention und Engagement, das ist eigentlich, was ein Business am Laufen hält und das ist das Ziel von Releases.

Joel Kaczmarek: Ja. Also vor dem Spiel ist nach dem Spiel.

Till Reiter: Vor dem Spiel ist nach dem Spiel und oft, haben wir auch schon gemacht, heißt dann nach dem Release auch, wenn es nicht die gesteckten Ziele erfüllt, das soll auch wieder zu Sunsetten.

Joel Kaczmarek: Da wirst du wahrscheinlich nicht großartig widersprechen, vermute ich, oder Björn?

Björn Wagner: Ja, würde ich auch vollkommen zustimmen. Man sollte nicht nach dem Release Mission Accomplished verkünden und feiern. Es geht wirklich eher darum, dann geht es eigentlich richtig los. Man hat A sehr lange entwickelt, man hat vorher noch mit viel mehr Hypothesen, Analysen, Konzepte entwickelt und dann geht das Produkt live und dann kann man wirklich sehen, wie verhält es sich denn so. Welche Hypothesen werden erfüllt, welche nicht. Wir hatten ja schon mal in früheren Folgen darüber gesprochen, das Thema Hardmetrik. Also gibt es auch bestimmte Praktiken, wie man das denn genau misst und welche Ziele man sich denn halt auch setzen sollte. Aber nach dem Release beginnt eigentlich der spannendste Teil.

Joel Kaczmarek: Na gut, Halbzeit und wir haben schon mal vier widerlegt. Also wir sind heute eher Mythbusters. Kommen wir zu Nummer sechs. Das Produkt sagt, Agile ist just a buzzword. Was würdest du da entgegnen, Björn?

Björn Wagner: Das ist ein Thema, da könnte ich zwei Stunden drüber reden. Ich glaube, agil ist wirklich ein, viele verwenden das als Buzzword, aber die eigentliche Intention dahinter geht in vielen Fällen verloren. Also man ist halt der Meinung, wenn ich irgendwie meine Arbeit in Tickets aufteile und in einen Scrum-Backlog packe und irgendwie die Zeremonien des Scrum-Buchs irgendwie ausführe, dass ich dann agil arbeite. Was ja eigentlich nicht stimmt. Und was ich ganz häufig sehe ist, viele Leute verwenden Agile auch als Synonym von wegen, ich habe keinen genauen Plan, aber lass einfach mal anfangen, wird schon so werden. Und zum gewissen Teil kann man das machen, aber eigentlich ist ja die Idee dahinter vom Agilen, dass man möglichst schnell in möglichst kleinen Schritten Sachen releast. Dass man halt nicht irgendwie ein Jahr am ersten großen oder am nächsten großen Release arbeitet, sondern möglichst schnell in den Markt geht, möglichst schnell Feedback bekommt und dann halt kontinuierlich besser wird. Und das ganze Scrum-Tooling ist glaube ich hilfreich, auch gerade wenn man damit anfängt und das machen möchte, aber das ist jetzt nicht nur, wenn man das Meeting so abhält, heißt das nicht, dass man sonderlich agil ist oder auch den eigentlichen Intentionen und Wert folgt.

Joel Kaczmarek: Also eher falsch, oder siehst du das anders?

Till Reiter: Ich sehe das anders. Für mich ist Agile mittlerweile zu einem Buzzword für Common, ja. Hätte ich jetzt noch Zeit gehabt in der Vorbereitung, ich vermute, es gibt keine Job-Ausschreibungen im Tech-Bereich, wo das Wort nicht drin vorkommt, weil es eigentlich für mich bedeutungslos geworden ist. Keiner wird für sich sagen, komm in unser unagiles Team, um XYZ zu bauen. Und teilweise, es gibt ja auch andere Entwicklungsarten, wie zum Beispiel Waterfall, aber teilweise machen die immer noch Sinn, wenn du schon genau weißt, was du bauen musst und zu welcher Zeit das kommen muss. Deswegen hat der Term für mich nicht mehr so viel Aussagekraft.

Joel Kaczmarek: Was sagst du da?

Björn Wagner: Also ich glaube, ich würde ihm auch zustimmen. Also ich glaube, da haben wir uns vielleicht gerade falsch verstanden. Also ich würde auch sagen, es ist ein Buzzword, es wird überverwendet. Und wie gesagt, ich glaube, die Intention dahinter, wenn man sich dieses Akile Manifest anschaut, die fünf Core Values oder wieviel auch immer das genau sind, dann machen die schon Sinn. Aber das hat halt häufig relativ wenig damit zu tun, wie es dann in der Realität gelebt wird. Also das würde ich sagen.

Joel Kaczmarek: Also Agile in der Grundsache ist richtig wichtig, aber wie man es sozusagen anwendet, es wird eher exponentiell verwendet, ohne richtig zu leben. Na gut, na guck mal, haben wir doch noch einen hier belegt. Okay, gut, kommen wir zu Mythos Nummer 7. Jetzt fliegen gleich die Fetzen und zwar sagen hier die Product Guys über Engineering, they just write code. Oha, was ist da los, Till?

Till Reiter: Das würde ich natürlich nie so sagen.

Joel Kaczmarek: Nur denken? Ja.

Till Reiter: Nee, ich glaube, es gibt Unternehmen, wo das noch so gelebt wird. Das ist jetzt eigentlich so die gegenteilige Definition von so Empowered Teams. Ich glaube, wir haben es schon vorhin gesprochen. Björn und ich sind uns da eigentlich einig. Mich würde eher interessieren, wie Björn damit jetzt eher in der Vergangenheit umgegangen ist. Wenn deine Stakeholder das eher so sehen.

Björn Wagner: Also ich würde sagen, Engineers, und das ist ja auch allein von der Terminologie her sehr spannend. Es gibt ja irgendwie den Begriff Developer, Entwickler und dann halt Software-Ingenieur. Und ich glaube, der Ingenieuranteil ist da halt sehr, sehr wichtig. Das heißt, für mich ist der Kern nicht Codeschreiben, sondern der Kern ist Probleme lösen, Kundenprobleme lösen und dann halt eine technisch feasible, wie man so schön sagt, also gut umsetzbare Lösung entwickeln, die am Ende die Kunden spannend finden und gerne nutzen. Das steht für mich im Kern des Ganzen. Und das sieht man halt auch, dann ist natürlich quasi das Toolkit, man schreibt Code, man entwickelt Code, aber der Kern der Sache ist, wie lösen wir Kundenprobleme, technisch spannende Probleme, das ist der Kern, nicht Code schreiben, um Code zu schreiben. Und es ist auch sehr wichtig, du hast gerade schon angesprochen, Till, das Thema Empowerment. Man sieht das ja schnell, wenn man sich so Teams in der Entwicklung anguckt. Wie gesagt, wir haben gerade schon über Scrum-Zeremonien gesprochen, wenn halt der Product-Owner, da sitzt und quasi jedes Ticket einzeln ausdefiniert, jedes Feature bis ins Letzte niederschreiben muss und dann die Entwickler quasi gar nicht mehr mitdenken, sondern einfach nur noch das runterprogrammieren. Das ist halt ein Modell, von dem wir weg wollen. Wir wollen halt schon dahin, dass die Leute mitdenken, dass sie eigene Ideen entwickeln, weil a, wird das Ganze viel effizienter, man bekommt mehr Diversität, man bekommt bessere Ideen rein und man kann am Ende halt auch eigentlich sich viel, viel schneller nach vorne bewegen. Als wenn irgendwie irgendjemand eine Produktdefinition macht, die über den Zaun schmeißt und sagt, jetzt lieber Entwickler, programmiere das noch, ohne halt zu verstehen, was dort eigentlich passiert. Man bekommt dann auch viel weniger, sage ich mal, Bugs, Fehler später im Prozess, weil die Leute dann halt auch selber verstehen, was machen sie denn und dann vielleicht auch Ungereimtheiten, die vielleicht vorher gar nicht aufgefallen sind, schon selber mit im Prozess identifizieren können. Das ist, glaube ich, wichtig und dieses Mindset hilft halt auch, sehr spannend finde ich das ja nicht nur beim Entwickeln, dieses Problemlösen, ja, das ist ein Mindset, was man auch, wenn man im Bereich Leadership geht oder halt auch, selbst wenn man sich Fauna anschaut, es gibt sehr, sehr viele Fauna mit einem Engineering-Background, weil die halt genau dieses Problemlösen, das Kundenproblem verstehen, lösen und eine gute Lösung entwickeln, das halt quasi verinnerlicht haben und das halt der Kern ist und auch, wenn man gar keinen Code mehr schreibt später, hilft, glaube ich, dieses Mindset ungemein, dann halt auch eine Vision aufzubauen, Leute mitzunehmen und zu führen an der Stelle. Also ich würde sagen, nein, im Kern steht Problem lösen.

Joel Kaczmarek: Gut. So, unser achter Mythos dreht sich um den Produktbereich. Hatten wir eigentlich schon fast ein bisschen heute angerissen, nämlich vorhin mit den Mönchen. Customers always know what they want.

Till Reiter: Ja, kann man jetzt eigentlich nur ergänzen. Dieses klassische Beispiel hättest du vor 100 Jahren gefragt, wie Leute von A nach B wollen. Hätten sie gesagt, ich brauche ein schnelleres Pferd. Deswegen die Lösung sollte man den Empower Teams überlassen.

Joel Kaczmarek: Hast du noch was zu ergänzen? Eigentlich schon klar, ne?

Björn Wagner: Ne, absolut. Also ich glaube, es ist halt auch ganz wichtig, gar nicht die Erwartungshaltung, dass einem die Kunden die Lösung sagen. Dafür hat man ja die Teams, davon hat man ja die Leute, die die Technologie verstehen und den halt auch verstehen. Wie kann ich denn jetzt die Technologie, die wir haben, konkret nutzen, um irgendwie ein Problem zu nutzen? Vielleicht, um es nochmal ein bisschen greifbarer zu machen. Ich finde es immer sehr, sehr spannend. Wir haben ja, wenn man so Cloud-Anwendungen, Web-Anwendungen oder auch Mobil-Anwendungen entwickelt, dann kann man sehr, sehr schnell in Features denken. Wir bauen irgendwie ein neues Feature, einen neuen Screen, eine neue Visualisierung, um den Kunden halt irgendwas darzustellen. Und wenn man jetzt in den Bereich AI reingeht, Generative AI, dann ist es komplett neue Spielregeln eigentlich. Hier kann man dann nicht mehr sagen Irgendwie der Kunde hätte halt gern was. oder ich denke mir halt jetzt aus, oh wir können ja dieses tolle Feature kann mir AI irgendwie automatisiert oder das Problem kann mir AI automatisiert lösen. Dann geht es halt wirklich darum hier auch zu schauen, die Technologie, was kann sie wirklich sehr stark validieren, funktioniert das denn? und was sind dann halt auch die ganzen Shortcomings an der Stelle, was funktioniert denn nicht mit der AI. Content ist sehr günstig geworden, aber Qualität ist halt sehr, sehr schwierig geworden. Und man braucht dann halt schon die Leute, wo man sagt, okay, vielleicht hat der Kunde eine gute Idee, eine Lösung, was zu lösen mit Generative AI, das dann aber zu testen, zu validieren und sicherzustellen, dass dem Ergebnis vertraut werden kann. Das ist halt der Kern. Und deshalb, wie Till gesagt hat, liegt es beim Team und ist auch gar nicht die Erwartungshaltung, dass der Kunde die Lösung quasi vorgibt.

Joel Kaczmarek: Gut, Mythos Nummer 9, wieder bezogen aufs Product Development. Marketing can sell anything. Is that true, Tim?

Till Reiter: Ich glaube, man kann sagen, ja. Also umgekehrt gibt es ja auch die Ansicht, dass man sagt, if you have a good product, the customers or buyers will follow. Aber es gibt halt auch sehr famose Gegenbeispiele von relativ schwachen Produkten, die einfach durch extrem smarte Marketing- und Growth-Mechanismen gewachsen sind und sich da auch halten. Ich will jetzt keine Namen nennen, aber da sind bekannte Enterprise-Lösungen dabei. Also das typische Tool, das jeder hat zu benutzen, aber das einfach gut verkauft wurde und sich sozusagen bestimmte Stickiness-Effekte hat, dass es auch nicht mehr weggeht. Deswegen starkes Marketing ist schon stark, würde ich stehen lassen.

Joel Kaczmarek: Du auch?

Björn Wagner: Ja, würde ich voll und ganz zustimmen. Ich glaube noch, was wichtig ist auch wieder, dass man den Effekt von Marketing nicht unterschätzt und halt gerade, wenn man komplexe Produkte verkauft, technische Produkte, technische Lösungen, dass es sehr, sehr wichtig ist, wenn quasi die Market Message stark sein soll, dass dort auch eine sehr enge Kollaboration von den technischen Experten halt mit Marketing stattfinden muss, damit halt quasi das Marketing nicht nur fluff ist, sondern halt auch wirklich den Kern verkauft. der technischen oder des technischen Produkts adressiert. Das ist, glaube ich, noch ein wichtiger Punkt, also dass man Marketing nicht irgendwie als die Landingpage sieht, die irgendwie komplett losgelöst ist vom Produkt. Deshalb gibt es ja auch mehr und mehr oder schon sehr lange Product Marketing als genau eine Funktion, die dort die Brücke baut, dass es halt nicht nur ums Verkaufen geht, sondern halt auch dann ein starker Bezug zum Produkt da ist und zum Wert des Produkts. Weil wenn die Marketing am Ende was anderes verkauft oder positioniert als das, was das Produkt eigentlich kann, dann ist einem auch nicht geholfen an der Stelle.

Joel Kaczmarek: Gut, kommen wir zu unserem letzten Mythos, diesmal bezogen auf Engineering. We're always on call.

Björn Wagner: Yes, we are. Klingt pathetisch. Genau, aber das stimmt auf jeden Fall. Also wir haben ja, haben wir glaube ich auch schon mal vorher drüber gesprochen, es gibt ja dieses DevOps-Mindset, wie man so schön sagt, you build it, you run it. Das heißt, es ist häufig nicht mehr so, dass man sagt, es gibt ein Team, was den Feature entwickelt und das dann quasi an ein Team übergibt, was sich dann darum kümmert, dass halt der Cloud-Betrieb funktioniert zum Beispiel, sondern es wird halt von einem und demselben Team gemacht. Es gibt dann natürlich nicht jedes Problem, wird direkt in On-Call durchgereicht. In der Regel gibt es dann so eine Hierarchie, also wenn der Kunde ein Problem auftritt. Vom Kunden, dann geht es so durch den First- und Second-Level-Support und dann je nach dem Third-Level-Support, dann werden halt wirklich Engineers des Teams involviert. Das ist so ein typisches Modell. Natürlich gibt es, also das ist quasi, wenn das Problem vom Kunden kommt, aber natürlich gibt es auch ganz viel automatisiertes Monitoring. Ja, On-Call getriggert wird an der Stelle und das heißt dann wirklich, da bekommen Leute nachts SMS, werden angerufen, automatisiert, müssen dann aufstehen, auch am Wochenende, wenn es halt nicht läuft und dann das Problem sich angucken und beheben. Also das ist die Idee, da wird man in der Regel noch extra für bezahlt, da gibt es so Stand-by-Modelle natürlich auch an der Stelle. Aber das ist schon ein sehr wichtiger Punkt und sorgt dann für eine intrinsische Motivation, einen guten Code zu schreiben und gutes Monitoring zu haben, dass man nicht falsch gemacht wird und das möglichst selten passiert. Das ist noch so ein Nebeneffekt dabei.

Till Reiter: Ihr habt also dann so richtige Schichtpläne sozusagen? Und wie sieht das so aus von, das muss ja wahrscheinlich nicht jeder Ingenieur machen, ist die Motivation hoch oder musst du da starke Reden halten, um die Leute zu finden?

Björn Wagner: Sehr unterschiedlich. Was wir machen, wir sprechen das ganz offen schon im Bewerbungsprozess auch an, wenn wir Leute halt irgendwie dazu holen, dass das erwartet wird. Man kann halt die Leute nicht zu zwingen, aber wie gesagt, es gibt eine kleine finanzielle Inzentivierung. Es machen meistens nicht alle Leute im Team, aber schon eine Anzahl, dass man eine gute Abdeckung hat. Manchmal kann das auch geteilt werden, dass nicht von jedem Team jemand on-call sein muss. Kann man so ein bisschen optimieren. Aber in der Regel gibt es dafür schon ein Verständnis, weil halt genau dieses DevOps-Mindset halt schon sehr weit verbreitet ist.

Joel Kaczmarek: Da kann man so ein bisschen über Work-Life-Balance von Engineers mal reden, oder? Weil da bist du ja auch immer on call im Kopf sozusagen.

Björn Wagner: Genau, aber es ist halt, also in der Regel, ich glaube, man hat das vielleicht eine Schicht im Monat oder so mal ein paar Tage, also jetzt nicht, dass man permanent On-Call ist, sondern es ist wirklich so eine Art Schichtsystem und das rotiert dann durch und viele Leute finden das auch, wie gesagt, aufgrund der finanziellen Incentives, glaube ich, gut und grundsätzlich, natürlich, erzeugt mehr Menschen Lot, wenn man On-Call ist und man kann halt, ja, ein bisschen mehr Stress auf jeden Fall, aber wie gesagt, je besser, je stabiler das Produkt läuft, desto weniger passiert während On-Call.

Joel Kaczmarek: Na gut, also von unseren ersten fünf war einer so halb wahr, nämlich bezogen auf Product Data is the only thing that matters. It's an important thing, but not the only one. Und bei den zweiten immerhin drei. Also Agile is just a buzzword, Marketing can sell anything and we're always on call. Mögt ihr, ich hätte noch zwei Mythen, weil ich mag ja auch immer gerne mal so die Gründersicht, wenn Leute jetzt nicht so tech-affin sind, dass ihr da vielleicht mal mit zwei, drei Sachen noch aufräumt. Deswegen zwei Mythen fallen mir hier noch ein. Nämlich das eine, also dieses typische Featureitis, so in Bezug auf Engineering, the more features, the better. Würdest du zustimmen oder nicht?

Björn Wagner: Auf gar keinen Fall. Manchmal sind auch weniger Features besser. Ganz wichtig ist hier wieder das Thema Wert. Welchen Wert schafft man für den Kunden? Es gibt häufig Beispiele, wo irgendwie konkurrierende Anwenderungen, die, die eigentlich einfacher zu bedienen sind, weniger Features haben, weil sie wirklich auf den Kern des Problems fokussieren. deutlich besser, beliebter sind als Anwendungen, die halt mit Featuren überladen sind. Also mehr Feature ungleich, mehr Value. Natürlich muss man mal schauen, es gibt schon eine gewisse Grundanforderung des Kunden, gerade wenn man sich jetzt zum Beispiel auch mit der Konkurrenz vergleicht, bestimmte Sachen werden halt einfach erwartet und die muss man dann halt auch liefern. Aber der Fokus sollte halt nicht sein, sich auf Features zu fokussieren. Und das eine Sache, da streiten wir uns ja manchmal so ein bisschen vielleicht im Strategie-Cycle, wenn man halt so wirklich dieses Mindset hat, okay, welche Feature bauen wir denn nächstes Jahr und sich nicht eher die Frage stellt, welche Ziele haben wir denn, welche Metrik wollen wir denn beeinflussen und dann das nutzt, um halt zu priorisieren, welche Features denn jetzt die wichtigsten sind. Also wenn man immer denkt, okay, das ist meine Liste an Features, die müssen wir jetzt bauen, das ist das nächstwichtigste, ist glaube ich ein Mindset, was relativ schwierig ist und wo ich sagen würde, lass uns lieber über Ziele, über Outcome reden, weil am Ende ein Feature ist ja Output, wie gesagt, ob es dann genutzt wird, adoptiert wird und wirklich den Wert schafft, ist ja immer eine zweite Frage. Das heißt, ich würde sagen, ganz klar, nein, mehr Features, ungleich, mehr Value. und ja, lass uns über Value reden und über Impact.

Till Reiter: Ja, vielleicht könnte man, die Aussage wäre für mich wahr, wenn es so im Testing-Bereich wäre, the more features you test, the better. Alles auf die Kunden loslassen, auf keinen Fall. Ist so ein bisschen wie bei einer Kuchenglasur oder Deko, je mehr du draufklopfst, irgendwann wird es ungenießbar.

Björn Wagner: Ich glaube vielleicht noch eine Geschichte dazu, die ist schon etwas älter. Und Microsoft hat irgendwann mal, die haben irgendwann mal angefangen, die Menübars zu ändern. Damals so Anfang der 2000er gab es ja noch so ganz viele kleine Icons und diese klassischen Menübars. Und ich erinnere mich, die hatten damals User Research gemacht und haben gefragt, welche Features fehlen euch denn im Produkt? Und irgendwie, ich weiß nicht die genaue Zahl, aber ich sage mal 80% waren eigentlich im Produkt, hat nur keiner gefunden. Und das ist dann natürlich auch nochmal eine Sache, also wenn wir nur Features haben, hilft das nicht, die Leute müssen sie auch finden und nutzen können. und deshalb gab es dann große Redesigns damals auch, um halt das Produkt benutzbarer zu machen. und man hat gemerkt, wir müssen eigentlich gar nicht mehr Features bauen, Word, Excel, die haben schon so viel und wir müssen nur die Kunden das einfacher machen, das auch zu nutzen am Ende des Tages.

Joel Kaczmarek: Gute Bilder habt ihr heute, sehr schön. Mein zweites Addendum wäre noch, auch in Bezug auf Engineering, Technical Debt is always bad.

Björn Wagner: Ist das so? Nein, also grundsätzlich ist es natürlich nicht gut, Technical Debt zu haben, aber warum hat man das? Man muss natürlich immer einen Kompromiss finden. Also man muss ja nicht nur gute, stabile Software bauen, sondern auch erfolgreich im Markt sein. und ein wichtiger Ansatz ist halt, wie schnell können wir halt bestimmte Sachen in den Markt bringen? und ab und zu ist man dann halt in der Realität gezwungen, ein paar Abkürzungen hier und da zu nehmen und die dann halt auch für Technical Debt sorgen. oder es gibt halt zum Beispiel teilweise auch, wenn man neue Technologien einführt, fehlt ein bestimmtes, fehlt so die Erfahrung. Und wie gesagt, wenn dann nochmal der Product Manager Till einem im Nacken sitzt und sagt, das hätten wir jetzt aber schon letzten Monat releasen sollen. Ne, kleiner Spaß. Also es ist, ich glaube es wichtig ist, man sollte es vermeiden, das wird nicht immer gehen, aber man muss es halt aktiv managen und man muss halt aufpassen, dass man halt nicht irgendwie dass die Technical Debt so groß wird, dass man irgendwann gar keine neuen Sachen mehr bauen kann und dann erstmal sich in einem riesigen, jahrelangen Refactoring oder in einem Limbo befindet, wo man quasi dann relativ wenig Wert machen kann und dann zieht die Konkurrenz vorbei, wenn man halt keine neuen Features, keinen neuen Wert machen kann, sich auch Veränderungen im Markt ergeben kann. Also ich würde sagen, grundsätzlich ist es nicht gut, man soll das vermeiden, man muss es aktiv managen an der Stelle, das ist wichtig.

Till Reiter: Aber es ist halt normal und man muss es immer in Bezug nehmen. Es gibt ja diese schöne Aussage, Tech Debt ist so wie eine Kreditkarte. Everyone loves to swipe und wenn die Rechnung kommt, rennen die Leute weg. Es ist zunächst die angenehmere Lösung und dann muss man das halt abwägen mit den restlichen Prios.

Joel Kaczmarek: Ja, sehr schön. Haben wir heute sogar so 10 plus 2 Mythen gemacht. Hervorragend. Auch immer schön, euch beide dabei zu haben. Sehr, sehr gut. Bis zum nächsten Mal, würde ich sagen.

Björn Wagner: Alles klar. Schönes Wochenende euch.

Till Reiter: Bis dann.

Björn Wagner: Ciao. Ciao.