エピソード

  • Wie wissenschaftlich sollte Produktarbeit sein?

    Wie wissenschaftlich sollte Produktarbeit sein?
    2026/10/19
    Wie wissenschaftlich muss Produktarbeit eigentlich sein? Dieser Frage gehen Oliver und Dominique in der aktuellen Folge nach. Denn Product Owner verlassen sich häufig auf Erfahrung, bewährte Methoden und Bauchgefühl. Doch wie belastbar sind Entscheidungen, die vor allem auf Intuition beruhen? Wissenschaftliches Arbeiten kann helfen, bessere Entscheidungen zu treffen, ohne gleich jedes Product Backlog Item zur Forschungsstudie zu machen. Dazu gehört, selbst Erkenntnisse durch User Research, Datenanalysen und Experimente zu gewinnen, aber auch vorhandene Forschung kritisch zu nutzen. Dabei lauern zahlreiche Denkfallen. Aus einzelnen Erfolgsgeschichten werden vermeintliche Best Practices, Korrelation wird mit Kausalität verwechselt und persönliche Überzeugungen verdrängen belastbare Erkenntnisse. Gleichzeitig halten sich längst überholte Modelle wie Persönlichkeitstypologien mit Farben hartnäckig in der Praxis. Doch wissenschaftliche Genauigkeit hat auch ihren Preis. Nicht jede Produktentscheidung rechtfertigt aufwendige Untersuchungen. Entscheidend ist vielmehr, wie hoch das Risiko einer Fehlentscheidung ist und wie viel Evidenz benötigt wird, um dieses Risiko verantwortungsvoll einzugehen. Oliver und Dominique diskutieren deshalb, wie evidenzinformierte Produktarbeit gelingen kann, warum kritisches Denken wichtiger ist als die perfekte Methode und wie Product Owner mit HIPPOs, ZEBRAs und organisatorischem Gegenwind umgehen können.
    続きを読む 一部表示
    35 分
  • Hackathons bei OBI: Was Product Owner daraus mitnehmen

    Hackathons bei OBI: Was Product Owner daraus mitnehmen
    2026/10/12
    Hackathons bieten Product Ownerinnen und Product Ownern einen geschützten Rahmen, um Ideen jenseits des Sprintalltags zu erproben. Oliver spricht mit Andrea aus dem IT-Portfoliomanagement und Tech Lead Lukas über die internen Hackathons bei OBI: Wie entstehen aus Ideen Prototypen, welche Rolle übernehmen Product Owner und was lässt sich in die tägliche Produktentwicklung mitnehmen? Außerdem geht es um die Weiterverfolgung der Ergebnisse und praktische Learnings zu Organisation, Kommunikation und Verpflegung.
    続きを読む 一部表示
    42 分
  • Wenn KI unsere Juniors ersetzt, wo kommen dann zukünftige Seniors her?

    Wenn KI unsere Juniors ersetzt, wo kommen dann zukünftige Seniors her?
    2026/10/05
    Tim und Dominique werfen in dieser Folge die Frage auf was passiert, wenn KI unsere Juniors ersetzt und wo dann die Seniors von morgen herkommen. Recherche, Protokolle, Backlog-Pflege und erste Analysen übernimmt eine KI heute schnell und schon recht brauchbar. Genau diese Aufgaben waren lange der Einstieg für Berufsanfänger:innen auf dem Weg hin zum Product Owner oder Product Manager (genauso in der Projektarbeit). Solche zuarbeitenden Aufgaben und Rollen boten Gelegenheit, eine Fähigkeit nach und nach zu durchdringen, Fehler zu machen und zu beobachten, wie andere auf Basis der eigenen Arbeit entscheiden. Fällt dieser Einstieg weg, bleibt offen, wie Erfahrungen im Berufseinstieg überhaupt erworben werden kann. Irgendwann gehen dann die heutigen Seniors in Product Leadership und C-Level (oder auch in Rente). Und was passiert dann? Senior wird niemand durch die nächste Weiterbildung. Erfahrung wächst durch viele kleine Entscheidungen, durch Feedback und durch Fehler. Man kann sie weder herunterladen, noch per Knopfdruck abrufen. Das Wissen dahinter ist implizit, ähnlich wie beim Fahrradfahren, denn wer das Gleichgewicht hält, kann kaum erklären, wie er das macht. Mit explizitem Wissen geht eine KI natürlich souverän um. Sobald Menschen zusammenarbeiten, braucht es aber ein Gespür für Kontext, für Konflikte mit und zwischen Stakeholdern und dafür, Unsicherheit auszuhalten. Dazu kommt ein leicht zu übersehendes Risiko: Wer neu im Beruf ist, erzeugt mit KI in kurzer Zeit User Stories, Konzepte, Interview-Leitfäden und Protokolle, die erstaunlich gut aussehen mögen. Ob sie taugen, beurteilt nur, wer solche Arbeit schon einmal selbst gemacht hat. Der Automation Bias verschärft das Problem nochmal, denn Menschen vertrauen automatisierten Ergebnissen schnell und prüfen sie zu selten. Brüche und offene Schnittstellen fallen dann spät auf und kosten richtig Geld. Wenn KI unsere Juniors ersetzt, braucht es einen neuen Weg, um Erfahrung aufbauen zu können. Der Ausweg liegt im Wechsel von der Produktionskompetenz zur Entscheidungskompetenz auf Basis von Urteilsvermögen. Ein Ansatz könnte der folgende sein: Berufseinsteiger bekommen besser echte, klar abgesteckte Probleme statt billiger Zuarbeitsaufgaben. Sie nutzen die KI als Werkzeug, begründen ihre Entscheidungen und vergleichen Alternativen. Die Verantwortung wächst Schritt für Schritt, ähnlich wie bei Delegation Poker: erst beobachten, dann mitreden, schließlich selbst entscheiden. Dafür eignen sich kleinere Produkte mit wenigen Stakeholdern. Zwei Jahre als Junior abzusitzen und nur AI-Tools zu bedienen, garantiert dagegen keine Reife. Damit verändert sich die Rolle von Seniors und Führungskräften. Unser Rat: Sie delegieren nicht alle lästige Aufgaben und machen stattdessen ihr Denken sichtbar. Sie fragen die Juniors, warum eine Lösung gut ist, welche Alternativen existieren und was dagegen spricht und sie erklären ihre eigenen Entscheidungen ganz explizit. Das kostet natürlich Zeit, denn über ein Ergebnis nachzudenken dauert länger, als es zu erzeugen. Die Juniorphase wird kürzer, das Mentoring dafür intensiver. Organisationen müssen Nachwuchsentwicklung deshalb als bewusste Investition begreifen, auch wenn der wirtschaftliche Druck zu kurzfristiger Produktivität drängt. Juniors werden nicht verschwinden, es wird sich lediglich ihr Einstieg verändern. Statt kleiner Aufgaben bekommen sie Entscheidungsräume und dazu Reflexionsräume, in denen sie mit erfahrenen Kolleginnen und Kollegen auswerten sollten, was funktioniert hat. Die Leitfrage für jedes Unternehmen lautet daher: Wer ist in drei bis fünf Jahren unser Senior? Folgende ältere Episoden unseres Podcasts passen zu diesem Thema: - Karrierepfad als Product Owner - Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern Wird KI via Automatisierung den Einsteigern wichtige Erfahrungen rauben und dadurch das Wachstum bzw. die Lernreise von Juniors behindern? Was glaubt Ihr?
    続きを読む 一部表示
    43 分
  • Hilfe, mein Team arbeitet dauernd an Stories, die gar nicht wichtig sind!

    Hilfe, mein Team arbeitet dauernd an Stories, die gar nicht wichtig sind!
    2026/09/28
    Oliver und Tim sprechen in dieser Folge über ein Problem, das vermutlich viele Product Owner kennen: Das Team arbeitet dauernd an Stories, die gar nicht wichtig sind. Der Anlass ist ein Coachingfall. Ein Produktmensch klagt darüber, kaum voranzukommen. Sein Team hat immer zu viel zu tun. Gleichzeitig schreiben die Teammitglieder eigene Tickets ins Backlog. Oder sie ziehen sich Themen selbst von irgendeiner Stelle des Backlog. Manche Stories laufen auch gerne über mehrere Sprints weiter, ohne dass die Developer ein Störgefühl zeigen. Nur passt das selten zur eigentlich notwendigen Produktstrategie des Product Owners bzw. der Produktorganisation. Wenn Teammitglieder selbst Einträge für das Product Backlog schreiben, ist das natürlich erstmal ein absolut gutes Zeichen. Es zeigt echte Selbstorganisation. Schwierig wird es dort, wo diese Einträge ohne Absprache direkt ins Backlog wandern und die Reihenfolge verändern. Genau diese Reihenfolge liegt eigentlich in der Verantwortung der Produktverantwortlichen. Fehlen klare Working Agreements, wer Tickets erstellt und wer sie freigibt, entsteht schnell Unordnung im Backlog. Stories, die gar nicht wichtig sind, bleiben oft über mehrere Sprints liegen. Man möchte begonnene Arbeit ja zu Ende bringen… Das klingt vordergründig vernünftig, kostet aber Steuerungsmöglichkeit. Ein hilfreicher Reflex: Unfertige Einträge wandern konsequent zurück ins Product Backlog. So bleibt die Priorisierung nach Wert erhalten. Die Produktverantwortliche soll dann jederzeit neu entscheiden können, welche Themen gerade wichtiger sind. Hinter dem Punkt "Stories die gar nicht wichtig sind" stecken oft andere Gründe. Häufig fehlt eine klare Produktvision. Technisch geprägte Teams setzen dann eigene (ggf. technische) Prioritäten, weil niemand ihnen die Richtung von oben deutlich genug vermittelt hat. Aber auch andersrum mag technische Komplexität eine Rolle spielen: manche Produktverantwortliche durchdringen die technischen Zusammenhänge nicht gut genug bzw. schaffen es nicht, die fachlichen Zusammenhänge und Notwendigkeiten dem Team gut genug zu vermitteln. Entwicklerinnen und Entwickler treffen dann lieber eigene, technisch motivierte Entscheidungen - schlichtweg weil ihnen der Kontext fehlt. Fehlt zusätzlich eine Scrum Masterin bzw. Agile Coach moderiert oft niemand die nötigen Retrospektiven. Genau dort sollten solche Muster eigentlich auffallen. Auch geringe Präsenz der Produktverantwortlichen im Teamalltag begünstigt die Entwicklung. In dieser Lücke entstehen eigene Gewohnheiten und stille Freiheiten. Fehlendes Refinement und fehlende Sprintziele verstärken den Effekt zusätzlich. Ohne Sprintziel wird im Sprint Planning nie klar, warum ausgerechnet diese eine Story gerade wichtiger sein sollte als jene andere. Am Ende hilft nur Konsequenz: solche Beobachtungen dürfen nicht folgenlos bleiben. Sie brauchen Raum in Retrospektiven, im Refinement und im Sprint Planning. Dazu gehört auch eine Produktvision, die man immer wieder neu erzählt, bis sie beim ganzen Team ankommt (oder allen gefühlt schon zu den Ohren rauskommt). Wer also merkt, dass im eigenen Team dauernd an Stories gearbeitet wird, die gar nicht wichtig sind, sollte das als Alarmsignal für den gesamten Produktentwicklungsprozess verstehen. Oliver und Tim ermutigen dazu, dieses Storytelling auch mit Werkzeugen künstlicher Intelligenz auszubauen. So lässt sich die eigene Produktstrategie in einer Sprache aufbereiten, die im Entwicklungsteam wirklich verfängt. Folgende frühere Episoden werden im Gespräch genannt: - Wenn dein Team dir als Product Owner nicht folgt - Mit Storytelling andere von deinen Produktideen überzeugen - Product Backlog Refinement - Tipps für Product Owner - Product Principles (Produktprinzipien) - Verantwortung als Product Owner übernehmen
    続きを読む 一部表示
    39 分
  • Was ist eigentlich das Produkt? - Ein Erfahrungsbericht mit Philipp Weiß

    Was ist eigentlich das Produkt? - Ein Erfahrungsbericht mit Philipp Weiß
    2026/09/21
    Was ist eigentlich das Produkt? Die Frage klingt trivial, ist für viele Product Owner aber alles andere als leicht zu beantworten. In dieser Folge spricht Oliver mit Philipp Weiß, Product Owner der Website bei Transfermarkt.de, über genau diese Frage an einem konkreten Praxisfall. Transfermarkt ist seit 26 Jahren die größte öffentlich zugängliche Fußballdatenbank der Welt, mit Profilen, Marktwerten, News, Forum, Spielen und Tools, in 16 Sprachen, dazu App und B2B-Angebot. Ist bei dieser Bandbreite einfach die ganze Website das Produkt? Und wie lassen sich Produktvision, North Star Metric und Strategie auf dieser Ebene sinnvoll nutzen? Oliver und Philipp gehen mögliche Produktschnitte durch: nach Kanal, nach Inhalt, nach Teamstruktur oder nach Nutzerbedürfnissen. Sie sprechen darüber, was jede Variante für Priorisierung und Zusammenarbeit bedeutet, warum sich Organisationen so schwer von gewachsenen Features trennen und warum der Fokus auf wenige Spielfelder oft wichtiger ist als der perfekte Produktschnitt. Eine Folge für alle Product Owner mit gewachsenen, komplexen Produkten, auch für Hörer:innen ohne Fußballbezug.
    続きを読む 一部表示
    43 分
  • Tracken des Nutzungsverhalten

    Tracken des Nutzungsverhalten
    2026/09/14
    In dieser Folge sprechen Dominique und Oliver über das Tracken von Nutzungsverhalten. Dabei geht es darum, warum Produktdaten oft ehrlicher sind als das, was Menschen in Interviews erzählen. Wer Nutzende befragt, bekommt wertvolle Eindrücke, aber auch gefärbte Antworten, denn kaum jemand zeigt sich gerne von einer schwachen Seite. Das Tracken von Nutzungsverhalten liefert die quantitative Ergänzung und zeigt, was im Produkt tatsächlich passiert. Diese Lücke begegnet Produktteams ständig, gerade beim Prüfen von Hypothesen aus der Product Discovery. Nicht jede Funktion braucht die gleiche Tiefe an Beobachtung. Bevor Teams Events, Klicks oder Feldänderungen erfassen, sollten sie klären, welche Entscheidung die Daten unterstützen sollen. Eine Terminverwaltung kann etwa festhalten, wie oft Termine angelegt, verschoben oder abgesagt werden, ohne jede einzelne Eingabe zu protokollieren. Tracking funktioniert am besten, wenn zuerst der gewünschte Outcome feststeht und daraus passende Kennzahlen abgeleitet werden. Verbindet man einzelne Ereignisse über eine Sitzung hinweg, werden Nutzungswege sichtbar. So lässt sich erkennen, wo Menschen aussteigen oder welche Muster sich wiederholen. Im Onlinehandel zeigt ein Funnel beispielsweise, an welchem Schritt des Bestellprozesses Kundschaft abspringt. Auch Kohorten helfen als Unterteilung, um so beispielsweise Unterschiede zwischen neuen und langjährigen Nutzenden zu verstehen. Natürlich gibt es einige Herausforderung beim Tracken: Problematisch wird es, wenn Teams zunächst möglichst viele Daten sammeln und erst danach nach passenden Fragen suchen. Ebenso riskant ist es, Daten nur zur Bestätigung bereits getroffener Entscheidungen auszuwählen. Beides erzeugt Kennzahlen, aber kaum belastbare Erkenntnisse. Auch intensive Nutzung bedeutet nicht automatisch Mehrwert. Sie kann ebenso auf umständliche Bedienung hinweisen. Korrelationen erklären zudem keine Ursachen, und aggregierte Kennzahlen können Unterschiede zwischen Nutzergruppen verdecken. Daten müssen deshalb immer im jeweiligen Kontext interpretiert werden, etwa unter Berücksichtigung saisonaler oder externer Effekte. Entscheidend ist am Ende, ob Tracking tatsächlich Entscheidungen verändert. Werden Daten regelmäßig erhoben, aber nie genutzt, lohnt sich der Aufwand kaum. Dominique und Oliver zeigen anhand vieler Beispiele, dass gute Produktentscheidungen meist aus der Kombination qualitativer und quantitativer Erkenntnisse entstehen. Gezielt eingesetztes Nutzungstracking unterstützt damit eine evidenzbasiertere Produktarbeit. Mehr unter: https://produktwerker.de/tracken-von-nutzungsverhalten/
    続きを読む 一部表示
    38 分
  • Product Owner ohne Scrum – Widerspruch oder inzwischen oft Alltag?

    Product Owner ohne Scrum – Widerspruch oder inzwischen oft Alltag?
    2026/09/07
    In vielen Unternehmen kann man erleben, dass Menschen sich Product Owner nennen, obwohl ihr Team längst kein Scrum mehr lebt. Aber verdient ein Product Owner ohne Scrum überhaupt noch diesen Namen? Oder verliert der Titel dann seine Grundlage? In Trainings und Organisationen tauchen diese Fragen immer wieder auf. Die Rolle heißt dort dann oft weiterhin Product Owner, im Alltag bestimmt aber längst Kanban oder ein eigenes, vielleicht sogar informelles Vorgehen das Bild. Historisch wurde der Begriff Product Owner durch Scrum verbreitet und bekannt. Zusätzlich taucht er im Scaled Agile Framework auf, dort allerdings mit einer anderen Bedeutung als im ursprünglichen Scrum Guide. Verschwindet Scrum aus einer Organisation, bleibt die Bezeichnung trotzdem oft bestehen. Sie hat sich auch im deutschsprachigen Recruiting fest etabliert. Menschen suchen nach wie vor deutlich häufiger nach Product Owner als nach Product Manager. Der Rollenname überlebt also das Framework, aus dem er stammt. Wechselt ein Team beispielsweise zu Kanban, lässt sich die Rolle Product Owner meist einfach weiterführen. Kanban selbst lässt offen, wer Prioritäten setzt und Entscheidungen trifft. Schwieriger wird es, wenn mit Scrum auch die Rituale verschwinden. Dabei geben diese Rituale einer Person erst die Möglichkeit, Produktverantwortung wirklich wahrzunehmen. Ohne Sprint Review fehlt der regelmäßige Moment für Feedback und Kurskorrektur. Ohne Retrospektive fehlt der Raum für die Weiterentwicklung der eigenen Zusammenarbeit. Und ohne ein sauber priorisiertes Product Backlog tauchen schnell wieder Listen auf, in denen fast alles gleich wichtig erscheint. An genau diesen fehlenden Kadenzen zeigt sich, wie viel von der ursprünglichen Rollenidee verloren geht, sobald ein Product Owner ohne Scrum arbeiten muss und nichts Vergleichbares an dessen Stelle tritt. Zwischen Product Owner als Rollenbezeichnung und Product Ownership als eigentlicher Produktverantwortung liegt ein wichtiger Unterschied. Product Ownership beschreibt, wie viel Entscheidungsgewalt, Kundennähe und Gestaltungsspielraum ein Mensch oder ein ganzes Team für den Erfolg eines Produkts übernimmt. Das gilt unabhängig vom Framework und unabhängig vom Titel auf der Visitenkarte. Werkzeuge wie das Product Ownership Evolution Model oder eine klassische RACI Matrix machen diese Verantwortung sichtbar, statt sie stillschweigend vorauszusetzen. Wer offen mit Führungskräften und Stakeholdern klärt, wie viel Ownership das Unternehmen tatsächlich überträgt, gewinnt echte Klarheit. Das gilt ganz gleich, ob am Ende Scrum, Kanban oder gar kein Framework im Hintergrund steht. Fehlt diese Klarheit, ziehen sich viele Menschen in vertraute Muster zurück und aus ihnen werden reine Verwalter des Backlogs, obwohl der Titel eigentlich Gestaltung verspricht. Diese Lücke zwischen Erwartung und gelebter Rolle erzeugt bei Betroffenen häufig eine stille Unsicherheit. Besonders dann, wenn eine Organisation den Rollenwechsel nie bewusst und offen kommuniziert hat. Manche Unternehmen begegnen dieser Unschärfe mit einem neuen Namen, etwa Product Lead oder Head of Product. Ein neues Etikett allein schafft dabei aber noch keine Rollenklarheit. Solange niemand Entscheidungsbefugnisse, Erwartungen und den Zugang zu Kundinnen und Kunden ausdrücklich benennt, verändert sich wenig. Dominique und Tim geben eine Empfehlung an alle, die sich in genau dieser Situation wiederfinden: Die Frage nach dem passenden Titel tritt in den Hintergrund, sobald echte Klarheit über Entscheidungsrechte, Erwartungen und Handlungsspielräume entsteht. Wer als Product Owner ohne Scrum arbeitet, sollte diese Klarheit aktiv im eigenen Umfeld einfordern. Sonst bleibt oft nur die stille Anpassung an einen unpassenden Titel. Ob am Ende der Titel Product Owner bleibt oder eine andere Bezeichnung ihn ablöst, verliert dadurch spürbar an Bedeutung.
    続きを読む 一部表示
    37 分
  • Was ist ein AI Operating System?

    Was ist ein AI Operating System?
    2026/08/31
    Lilith Brockhaus spricht in dieser Folge mit Tim über das AI Operating System. Lilith war bereits vor über drei Jahren zu Gast hier im Podcast, damals ging es um visuelle Entwicklungswerkzeuge ohne Programmierkenntnisse (NoCode bzw. LowCode). Seitdem hat sich bei ihr viel verändert. Mit der neuen Marke O/WONDER beschäftigen sie und ihr Team bei VisualMakers sich jetzt mit agentischer Wissensarbeit. Genau darum dreht sich das Gespräch in dieser Folge: Wie baut man ein eigenes AI Operating System für die eigene Organisation auf, was ist ein AI OS überhaupt und warum lohnt sich das gerade für Product Owner? Ein Operating System, unabhängig von AI, ist das Betriebssystem einer Organisation, vergleichbar mit dem Betriebssystem eines Smartphones oder Macbooks, das die Apps verbindet, ihr Zusammenspiel sicherstellt und im Hintergrund alles zusammenhält. Ein AI Operating System überträgt dieses Prinzip auf eine Organisation. Es macht die DNA eines Unternehmens zugänglich und explizit nutzbar, also die Ziele, Prozesse und Werte, die sonst oft nur implizit vorhanden sind. Tim vergleicht es mit einem Notebook, dessen Betriebssystem die Hardware erst bedienbar macht. Übertragen auf KI heißt das für ihn: Ein Operating System macht das Sprachmodell in einer Organisation erst wirklich einsetzbar, für die eigene Arbeit oder für das gesamte Unternehmen. Ein AI Operating System besteht laut Lilith Brockhaus aus vier Ebenen. Die Basis bildet der Wissenslayer mit Zielen, Prozessen und dem Kontext einer Organisation. Darauf folgt die Systemebene mit den Werkzeugen, in denen Daten entstehen, etwa ein Product Management System oder ein CRM. Die dritte Ebene ist die Ausführung. Hier legt das Team fest, welche Aufgaben die KI eigenständig übernehmen darf, zum Beispiel das Schreiben von Tickets nach einem festen Format. Ganz oben liegt, als vierte Ebene, die Oberfläche, also die Touchpoints, über die Menschen mit dem System sprechen, sei es im Chat, in Slack o.ä. oder direkt im Fachtool. Das Sprachmodell selbst bleibt dabei austauschbar und ist nur die Engine hinter dem eigentlichen System. Lilith beschreibt den Wissenslayer in der Folge als wachsende Bibliothek. Ständig kommen neue Bücher dazu, und ein gutes Verzeichnis sorgt dafür, dass Mensch und KI finden, was sie suchen. KI erkennt Muster in Sprache besonders gut. Dadurch lassen sich auch bisher implizite Entscheidungen sichtbar machen, etwa das Bauchgefühl bei der Priorisierung eines Features. Darin ist auch eine Nähe zu Product Principles und zum Double Loop Learning erkennbar. Dabei trifft eine Organisation nicht nur einzelne Entscheidungen, sie entwickelt auch ihre Entscheidungsregeln selbst weiter. Für den Einstieg mit einem AI Operating System empfiehlt Lilith etwas Pragmatisches. Meetings oder Gespräche mit Stakeholdern transkribieren und sich von der KI nach wenigen Wochen zeigen lassen, welche Muster sie darin erkennt. Als erste Basisdateien nennt sie drei Dinge, den Zweck des Unternehmens, das Ideal Customer Profile und eine Beschreibung des eigenen Angebots. Bei O/WONDER aktualisiert sich das Ideal Customer Profile automatisch anhand anonymisierter Vertriebsgespräche und wächst so mit jedem echten Kundenkontakt weiter. Für die Versionierung setzt das Team auf Git. Das gesamte Unternehmenswissen wird dort wie Code behandelt, inklusive der Nachvollziehbarkeit von Änderungen. Für Product Owner gibt es zwei Rollen in diesem Zusammenspiel. Auf der einen Seite bleibt viel Raum für Stakeholdergespräche, Empathie und Entscheidungen, die ein AI Operating System nicht abnehmen kann. Auf der anderen Seite braucht es Menschen, die genau dieses System bauen, pflegen und mit neuem Kontext füttern. Tim und Lilith sind sich einig: Dafür sind Mut und Neugier nötig, gerade weil viele Organisationen noch am Anfang stehen und es kein fertiges Rezept gibt. Wer selbst ausprobieren möchte, wie ein AI Operating System die eigene Arbeit verändert, findet bei Lilith und O/WONDER einen guten Startpunkt.
    続きを読む 一部表示
    48 分