Stories Connecting Dots with Markus Andrezak

Agenten bauen dir in einer Nacht mehr Software, als dein Markt in einem Jahr verdaut. Wer sagt ihnen, wann's genug ist?

Benedikt bringt Firmen bei, Software Factories zu bauen. Er macht das mit so viel Überzeugung, dass er dafür mit Freunden eine Firma gegründet hat: hackers&wizards. Die beste Adresse in Deutschland, um zu lernen, wie man eine Agenten-Factory aufbaut und betreibt. Factories sind Maschinen, in die man Requirements reinwirft und hinten kommt Software raus. Die Agenten schnappen sich Tickets, finden Bugs, fixen sie und rufen den Menschen nur noch dann, wenn sie ihn brauchen.

Während die einen sagen, dass es das nicht gibt oder es nicht funktioniert, sitzen Benedikt und Co. mitten in dieser Welt, machen das und zeigen Firma für Firma, wie es geht.

Im Podcast reden wir darüber, wie er da hingekommen ist und warum er sich genau das ausgesucht hat. Pentium 4 mit Turbotaste, Visitenkarten-Websites mit zwölf, und dann war er bei Otto, wo es Entwicklern immer gut ging. Im Dezember 2025 haben sich die Anfragen nach agentischer Entwicklung überschlagen und dann kam die Gründung.

Bei Loops wird er grundsätzlich. Wie viele Loops gibt es eigentlich? Wie baut man Vertrauen in etwas, das man nicht mehr Zeile für Zeile liest? Warum Spec-Driven Development das alte Pflichtenheft-Problem nur schneller macht. Und warum die Factory uns nicht seltener zusammenbringt, sondern – gegen jede Intuition – sogar öfter.

Am Ende die Gretchenfrage, aus der unser gemeinsamer Artikel „Breaking the Loop" entstanden ist: Die Maschine ist schnell. Der Markt ist träge. Und Agenten hören von allein nicht auf. Wie geht man damit um?

Kapitel

00:00:00 Cold Open: 2.000 Pull-Requests

00:00:56 Normale Leute, abgefahrene Dinge: Software Factories

00:02:39 Wer ist Benedikt? Pentium 4, Turbotaste, Dreamweaver

00:04:25 Otto: wo es Entwicklern immer gut ging

00:05:23 Developer Experience und der erste AI-Moment

00:07:10 Wie aus Trainings eine Firma wurde

00:09:56 Dezember 2025: Die Anfragen überschlagen sich

00:11:09 Raus aus dem Chat: Ordner, Outcome, Kontext

00:13:35 Cline, die erste Loop, Subagenten

00:18:42 Die Bubble ist winzig

00:23:21 Einer macht 2.000 PRs pro Woche. Und das Team?

00:24:43 Templates erzwingen Einigung

00:28:00 Vertrauen: wie bei einem neuen Kollegen

00:32:15 Erst mal alles zutrauen

00:34:24 Kontext-Engineering ohne Hochglanz

00:38:12 "Ich glaub dir nicht, dass du vertraust": Loops auf allen Ebenen

00:44:41 Was eine Factory physisch ist

00:47:03 Weniger coden, glücklicher sein

00:49:36 Prozessverbesserung ohne ITIL

00:51:05 Linter, gehackte Metriken, Habit Hooks

00:55:51 Code war nie das Problem

00:59:01 Warum Spec-Driven Development nicht reicht

01:01:42 Probefahrt statt Prospekt

01:04:48 Zwei Arten, mit AI zu arbeiten

01:07:19 Die Gretchenfrage: Der Markt ist träge

01:09:48 Wann hört der Agent auf?

01:12:54 Das Halteproblem und das "gut genug"

01:14:44 "Ich wusste nicht, dass ich das kann"

Gast

Benedikt Stemmildt ist Founder & Co-CEO von hackers&wizards in Hamburg. Mit neun der erste Computer, mit zwölf die ersten Websites. Danach Studium und viele Jahre bei Otto, mit CI/CD und TDD, lange bevor es normal war. Developer Experience ist schon immer sein Thema. Jetzt bringt er Engineering- und Produktteams bei, wie man mit Agenten arbeitet und Software Factories baut. Man trifft ihn auf fast jeder Konferenz und jedem Meetup zum Thema.

Erwähnt

- hackers&wizards: hackersandwizards.dev - Unser Artikel: „Breaking the Loop" – Benedikt Stemmildt & Markus Andrezak: ueberproduct.de/breaking-the-loop - Markus Andrezak: AI Flow Dynamics – The Loops Don't Get Faster On Their Own - Markus Andrezak: Option Storming – The 3D Chess Behind Claude Code - Habit Hooks: github.com/habit-hooks/habit-hooks - Eliyahu M. Goldratt: *The Goal* / Theory of Constraints - Dan Shapiro: The Five Levels: From Spicy Autocomplete to the Software Factory - Boris Cherny / Claude Code: claude.ai/code - Cline, Aider, GitHub Copilot, Microsoft Copilot (erwähnt)

Ein ganz normales Softwarehaus in Regensburg. 50 bis 75 Leute. Und dort schreiben LLMs den Code. Für Mission-Critical-Software. Ursprünglich für Banken.

Die meisten Firmen fragen sich noch, ob generierter Code überhaupt produktionsreif sein kann. Die knowis AG hat ihr ganzes Produkt darauf umgebaut. Und arbeitet selbst genau so.

Warum fällt denen das so leicht? Weil Code-Generierung für sie nie ein Wunder war. Seit 20 Jahren machen sie aus Modellen lauffähige Software. Die LLMs haben nur den starren Generator ersetzt. „So betrachtet war es gar kein großer Change", sagt CTO Johannes Boßle.

Wir reden über Spec-Driven Development mit Modellen statt endloser Textdokumente. Über Guardrails und Skills, die generierten Code verlässlich machen. Warum Banken und Agenten dieselbe Präzision brauchen. Und warum bei so einem Pivot die Software der einfachere Teil ist.

Kapitel

00:00:00 Intro: Die Software ist der einfachere Teil

00:01:03 Eine ganz normale Firma macht Ungeheures

00:03:46 Johannes Boßle: Java, Waldhorn und 20 Jahre knowis

00:12:35 Was die knowis AG macht

00:13:50 Spec-Driven Development: Präzision statt AI-Slop

00:25:41 Teams, Silos und regulierte Umfelder

00:29:30 Amazon und knowis: zwei Enden des Spektrums

00:31:59 Warum der Sprung zu LLMs „gar kein großer Change" war

00:35:24 Code-Generierung war nie ein Wunder: Vertrauen, Guardrails, Skills

00:42:54 Nicht nur für Banken: raus aus der Nische

00:46:20 Was Banken und KI-Agenten gemeinsam haben

00:54:04 Das eigene Tool benutzen

00:56:48 Shift Left und neue Jobs

00:59:59 Token-Kosten, Provider und lokale Modelle

01:03:41 Bei einem Pivot, und generell selbst für Softwareunternehmen: Software der einfachere Teil

01:08:00 Woher der Mut und die Selbstverständlichkeit kommen

01:13:08 Ethik, Grenzen und das Tempo der Entwicklung

01:21:39 Wie gut ist generierter Code wirklich?

01:27:15 Was als Nächstes kommt

Gast

Johannes Boßle, CTO der knowis AG, Regensburg.

Erwähnt

• knowis Cloud Solution Workbench
• Kent Beck: User Stories
• Boris Cherny (Claude Code)
• Benedict Evans
• „Java ist auch eine Insel" (Christian Ullenboom)

Mehr von Markus: ueberproduct.de. Strategie machen.

Dr. Else van der Berg is a one of a kind Product Manager. Deeply knowledgable and experienced in traditional product theory and practice but curious enough to be one of the most knowledgable AI native PMs in Germany.

How this conversation came about: Engineers are building loops that write their own prompts and ship overnight. Product managers stare at the same tools and can't find a single task to hand over. Why? That question kicked off this spontaneous recording.

Our answer, in short: software spent sixty years building a second loop that checks the first — compilers, linters, tests. Product never defined what "correct" even means. So the industry retreats to its last line of defense: taste and judgment.

Which sounds noble, until you look at the numbers. Kohavi spent a lifetime on research, some famous numbers: At Microsoft, a third of tested features create value, a third do nothing, a third destroy value. That's not judgment. That's rolling the dice. Not a high bar exactly.

So, we both ran an experiment each, anyway:

Else built a pipeline that pulls opportunities out of interview transcripts — and it picked the same #1 opportunity five times in a row.

Markus built a two-hour business-case agent whose results his clients call mind-boggling.

Both hit the same wall: the output isn't the problem. Trusting a result you didn't witness is. Combining skills and observing them build a thing and influencing it makes sense. An agent just doing it - not in our life.

Along the way: Bell Labs and idealized design, Pixar's hit machine, why three people take three different notes in the same interview, what a B2B marketplace for car dealers taught us about completeness, why CEOs hire loyalty instead of correctness — and how taste sneaks right back in through the back door.

Discovery is the bottleneck. Judgment is our moat. Pick one.

Dr. Else van der Berg on LinkedIn: https://www.linkedin.com/in/dr-else-van-der-berg-42b8b6a2/

On substack: https://elsevanderberg.substack.com

• 0:00:00 Why can't PMs build autonomous loops?
• 00:05:49 Taste, judgment, and how good humans actually are
• 00:12:10 Two experiments: skills, agents, and the definition of done
• 00:22:34 The artificial cut: correctness vs. completeness
• 00:40:00 Get the voodoo out: what humans are still for
• 00:53:15 Trust, loyalty, and humans on the loop
• 01:12:01 Taste comes back through the back door

On youtube: https://youtu.be/EU6duyZnQSM

In dieser Episode ist Lars Giere mein Gast.

Lars und ich kennen uns schon ewig, auch wenn wir nie direkt zusammengearbeitet haben - aber an denselben Stellen hintereinander.

Lars hat mit 15 seine erste Firma gebaut, Mathematik und Informatik studiert, dann Produktrollen bei ImmoScout und mobile.de, danach global neue Geschäftsbereiche bei der eBay Classifieds Group aufgebaut.

Später hat er FELMO gegründet, den mobilen Tierarzt-Service.

Jetzt baut er mit qlaris.ai ein neues Startup.

Wir reden über seinen ganzen Werdegang und landen dann tief bei AI.

Highlights:

• Warum manche Themen emotional so viel mehr Impact haben als andere.
• Was mit einem passiert, wenn einem Entscheidungen abgenommen werden
• Und warum das erstmal wehtut, bis man merkt, dass man einfach eine Ebene höher rutscht.
• Vom Probleme-selber-lösen zum Maschinen-bauen-die-Probleme-lösen.
• Lars erzählt, wie sein Team mit qlaris.ai synthetischen User-Research baut
• Und warum Kontext-Engineering gerade das große ungelöste Problem ist.
• Wir sprechen über Judgment & Taste als Buzzword, das oft nur schickeres Bauchgefühl ist,
• über Accountability wenn AI die Entscheidung trifft und der Mensch dafür geradestehen muss,
• und warum Claude Code für viele schon zum eigentlichen Betriebssystem geworden ist.

Links:

• Lars auf LinkedIn: https://www.linkedin.com/in/lars-giere/
• qlaris: https://qlaris.ai
• felmo: https://felmo.de/

Kapitel

• 00:00:00 - Vorstellung Lars, Intro
• 00:04:15 - Start als Entrepreneur
• 00:06:56 - Gründung FELMO, Tiergesundheit und Skalierung
• 00:10:53 - Impact emotionaler Themen
• 00:34:31 - Enter KI und LLMs
• 00:49:09 - Neue Systeme und neue Rollen durch KI
• 00:59:03 - Synthetischer Research und Grenzen davon für Product Teams
• 01:22:06 - Operating System, Kontext und Zukunft der Arbeit
• 01:32:05 - What's next für Lars?

In dieser Episode ist Lars Giere mein Gast.

Lars und ich kennen uns schon ewig, auch wenn wir nie direkt zusammengearbeitet haben - aber an denselben Stellen hintereinander.

Lars hat mit 15 seine erste Firma gebaut, Mathematik und Informatik studiert, dann Produktrollen bei ImmoScout und mobile.de, danach global neue Geschäftsbereiche bei der eBay Classifieds Group aufgebaut.

Später hat er FELMO gegründet, den mobilen Tierarzt-Service.

Jetzt baut er mit qlaris.ai ein neues Startup.

Wir reden über seinen ganzen Werdegang und landen dann tief bei AI.

Highlights:

• Warum manche Themen emotional so viel mehr Impact haben als andere.
• Was mit einem passiert, wenn einem Entscheidungen abgenommen werden
• Und warum das erstmal wehtut, bis man merkt, dass man einfach eine Ebene höher rutscht.
• Vom Probleme-selber-lösen zum Maschinen-bauen-die-Probleme-lösen.
• Lars erzählt, wie sein Team mit qlaris.ai synthetischen User-Research baut
• Und warum Kontext-Engineering gerade das große ungelöste Problem ist.
• Wir sprechen über Judgment & Taste als Buzzword, das oft nur schickeres Bauchgefühl ist,
• über Accountability wenn AI die Entscheidung trifft und der Mensch dafür geradestehen muss,
• und warum Claude Code für viele schon zum eigentlichen Betriebssystem geworden ist.

Links:

• Lars auf LinkedIn: https://www.linkedin.com/in/lars-giere/
• qlaris: https://qlaris.ai
• felmo: https://felmo.de/

Kapitel

• 00:00:00 - Vorstellung Lars, Intro
• 00:04:15 - Start als Entrepreneur
• 00:06:56 - Gründung FELMO, Tiergesundheit und Skalierung
• 00:10:53 - Impact emotionaler Themen
• 00:34:31 - Enter KI und LLMs
• 00:49:09 - Neue Systeme und neue Rollen durch KI
• 00:59:03 - Synthetischer Research und Grenzen davon für Product Teams
• 01:22:06 - Operating System, Kontext und Zukunft der Arbeit
• 01:32:05 - What's next für Lars?

Wir wissen: AI macht gute Produkt Manager besser, mittelmässige bleiben stehen. Echte Education darüber, was Product Management ist, bleibt also so wichtig wie vorher.

AI bringt Slop an den Kompetenzgrenzen.

Umso wichtiger, dass Lust Göcke und Michael Schultheiß in den letzten Jahren ein fundamentales Buch zu Product Management geschrieben haben. Ihr ca. 700 Seiten dickes Buch bietet ein Meta-Modell zum Produktmanagement: Das 6D-Modell.

Es beschriebt, welche grundlegenden Disziplinen und Fähigkeiten es gibt und ein PM beherrschen muss und wie diese zusammenhängen.

Dazu ordnet es die populären Modelle ein: Welche Bereiche werden z. Bsp. von den Büchern von Marty Cagan gecovered und welche nicht, welche von Theresa Torres? Wo gibt es Überschneidungen dun Abgrenzungen.

Zusammen ergibt sich ein Überblick in Breite und Tiefe über unsere Aufgaben und unseren Job, der dabei hilft, das alles einzuordnen und sich auszurichten.

Der Hintergrund: Lutz ist Professor an der Hochschule Nordhausen, Michael aktiver Produktmanager, u.a. bei remarkable. Alles dazu, zum Hintergrund und der Entstehungsgeschichte hier im neuen Pod. Links

• Das Buch bei amazon
• Das Buch bei Springer
• Lutz bei LinkedIN
• Lutz' Institutsseite (Hochschule Nordhausen)
• Michael bei LinkedIn

Kapitel

00:00 – Das 6D-Modell: ein Meta-Modell für Produktmanagement

02:23 – Motivation hinter dem Buch: Lücken schließen, Praxisnähe sichern

04:45 – Organisationen verstehen: Funktionen vor Strukturen

09:02 – Produktstrategie in unterschiedlichen Kontexten

13:16 – Einfluss von AI auf Produktentwicklung und Organisationen

19:32 – Erfolgsmessung: Viability, Desirability, Integrity & Feasibility

24:03 – Überlappungen und Blindstellen in Modellen: das Beispiel Discovery & Delivery

34:37 – Organisationen und ihre Muster: Was funktioniert in verschiedenen Branchen?

43:12 – Rollenkompetenzen im Produktmanagement: Business, Technik, Stakeholder

53:23 – Der Umgang mit Komplexität: Modelle, Klarheit und Anpassungsfähigkeit

64:34 – Prinzipien in der neuen AI-Welt – was bleibt, was ändert?

72:42 – Strategien für Organisationen im Zeitalter von AI & schnelllebigen Märkten

82:54 – Erfolgskriterien: Design Thinking und Produktvielfalt

88:02 – Herausforderungen der Anforderungen, AI-unterstütztes Requirements Engineering

98:02 – Die Bedeutung von Klarheit in der Kommunikation & Organisation

103:44 – Wie liest man das Buch? Tipps für Einsteiger und Profis

109:33 – Zukünftige Schritte: Übersetzungen, Forschung, Community-Engagement

In dieser Episode ist Oliver Schwarz mein Gast. Ein guter Freund seit Jahren. Wir haben getwitched, über AI und Spiele diskutiert, stundenlang. Drum wurde es auch dieses mal lang.

Oliver teilt seine praktischen Erfahrungen beim Aufbau von AI-gestützten Systemen für persönliche und berufliche Produktivität. Privat und bei beruflich, bei Testo. Das Gespräch führt uns zu vielen Aspekten: wie AI Arbeitsprozesse, Entscheidungsfindung und Organisationsstrukturen umgestalten kann, ein Schwerpunkt ist verantwortungsvolle Innovation und menschliche KI-Zusammenarbeit.

Wir gehen dabei in die Tiefe anhand eines umfangreichen Assistenten, den Oliver gebaut hat. Dabei interessiert uns garnicht so sehr das Agentensystem, dass gebaut wurde (obwohl das sehr spannend ist und auch versucht LLM-unabhägig zu sein). Uns interessieren vielmehr die Learnings und Beobachtungen die dabei gemacht wurden.

Wie beherrscht man die Claws? Wie eng muss man sie führen, harnessen? Warum hilft es Oliver, seinen Agenten zu „vermenschlichen"? Warum ist Oli aber Openclaw zu wild?

Was passiert ausserhalb des persönlichen Umfelds, z. Bsp. bei der Einführung der neuen Technologien bei Oli's Arbeitgeber - Testo - wo genau das in seinen Verantwortungsbereich gehört? Was heisst das in Bezug auf Fürsorgepflicht?

Highlights

• Von Chat über Kontext-Engineering zum Dark factory Pattern - was sind die Unterschiede?
• Der transformative Einfluss von KI-Systemen in der Softwareentwicklung, Projektmanagement und Wissensarbeit.
• Praktische Strategien zum Aufbau zuverlässiger, vertrauensbasierter KI-Tools, einschließlich Kontextmanagement und Regelsetzung.
• Die Bedeutung menschlicher Rollen, insbesondere Kommunikation und Entscheidungsfindung, in einer von KI erweiterten Welt.
• Herausforderungen bei Kostenmanagement und verantwortungsvollem Skalieren von KI-Integrationen.
• Das Konzept einer „Dark Factory", in der KI die Qualitätssicherung autonom ohne menschliche Überprüfung übernimmt.
• Organisation von KI-Interaktionen durch strukturierte Rahmenwerke wie Projektordner und semantische Hierarchien.
• Die psychologischen Aspekte des Vertrauens in KI, der Aufgabenübertragung und des Umgangs mit emotionalen Reaktionen.
• Kosten- und Risikobetrachtungen bei KI-Infrastruktur

Kapitel

00:00 - Einführung in KI, agentische Entwicklung und gesellschaftliche FOMO 02:12 - Oliver Schwarz' Hintergrund und Erfahrungen mit KI in der Software 05:09 - Wie KI die Wahrnehmung technologischer Grenzen verändert hat 08:46 - Der Wendepunkt der KI für Oliver im letzten November 13:35 - Vertrauen in KI-Systeme aufbauen und psychologische Barrieren überwinden 15:00 - Nutzung von KI zur Strukturierung von Daten und Workflows in realen Projekten 20:00 - Strategien zur Einbettung von KI in organisatorische Routinen 25:52 - Mensch-KI-Zusammenarbeit in Projekt- und Entscheidungsunterstützung 32:19 - Die Bedeutung ergebnisorientierter Interaktionen 37:38 - KI in der Softwarequalitätssicherung: der „Dark Factory"-Ansatz 43:50 - Aufbau komplexer Multi-Agenten-Systeme für strategische Aufgaben 51:07 - Die Rolle semantischer Hierarchien und strukturiertes Kontextmanagement 57:33 - Schnittstellen und Kommunikationskanäle für KI-Systeme 60:57 - KI-Infrastrukturkosten, Anbieterökosysteme und Skalierbarkeit 70:53 - Veränderung der Entwicklerrollen: vom Codieren zur Kommunikation 78:50 - Organisationskultur, Rhythmus und Umgang mit KI-getriebenem Wandel 93:36 - Kundenakzeptanz, Marktstrategien und verantwortungsvolles Skalieren 98:56 - Zukünftige Berufsfelder, die durch die KI-Evolution geprägt werden 107:24 - Der Wandel in der Softwareentwicklung und Qualitätssicherungspraktiken 113:36 - Sozio-technische Herausforderungen, gesellschaftliche Reaktionen und historische Parallelen 118:39 - Abschließende Überlegungen zu verantwortungsvoller Innovation und kollaborativer KI

Ressourcen & Links:

• Oliver Schwarz - LinkedIn
• Chester, Oliver's Assistent
• Lawrence, Oliver's Lernsystem
• StrongDM's Dark Factory AI Artikel
• Kathrin Passig - "Neue Technologien, alte Reflexe"

Nico Noll: ProductAnalyst.ai - Produktdaten wirklich nutzen

Was für ein Gespräch! Nico Noll ist seit Jahren Produktspezialist. Er hat Hunderte von PMs trainiert – in Unternehmen, in Workshops, als Coach. Und baut jetzt sein eigenes Ding, lebt den Traum vom eigenen Produkt: ProductAnalyst.ai. Ein Tool, das aus dem eigenen Schmerz entstanden ist: jahrelang als PM in Firmen gesessen, Daten eigentlich vorhanden, in der Praxis aber doch unerreichbar und nicht actionable.

Die Grundidee ist einfach und gleichzeitig strukturell: Produktdaten sind in fast jeder Firma vorhanden. Aber niemand nutzt sie wirklich für Entscheidungen. Der Bottleneck ist nicht die Datenmenge – sondern der Zugang und die Interpretation.

Die Datenlücke im Produktmanagement

Das racking läuft, die Events werden geloggt - sehr viele sogar. Mixpanel, Amplitude, PostHog, Google Analytics – irgendeins davon ist fast immer vorhanden. Aber wenn ein PM wirklich wissen will, welche Verhaltensmuster Churn vorhersagen, welche Nutzer nach dem Onboarding abspringen, welche Segmente sich grundlegend anders verhalten – wartet er auf einen Data Analyst, ein Dashboard oder beides. Beide Optionen: langsam, teuer, oft nicht vorhanden.

Nico hat das als PM bei Xing noch als Luxus erlebt: Frontend-Analyst und BI-Analyst ständig verfügbar. Das ist die Ausnahme. Die Regel: entweder kein Datenteam, oder eines das permanent überlastet ist.

These 1: Die meisten Produktentscheidungen passieren ohne aktuelle, granulare Daten – nicht weil die Daten fehlen, sondern weil der Zugang zu aufwändig ist. Granulare Fragen kosten Wochen. Und bleiben deshalb meistens ungestellt, erst recht unbeantwortet.

These 2: Das eigentliche Problem ist kein Technologie-Problem. Das Zugangsproblem tut so als sei es ein Analyseproblem.

Was Product Analyst AI macht – und was nicht

Kein "Vibe Analytics" – kein CSV in ChatGPT werfen und hoffen. Stattdessen ein System mit klaren Guardrails: Generalisierte statistische Funktionen auf der einen Seite. Firmenspezifischer Kontext auf der anderen.

Der Ansatz: Man trennt, was generalisierbar ist (statistische Methoden, Berechnungslogik, Segmentierungs-Funktionen) von dem, was firmenindividuell ist (Event-Namen, Business-Definitionen, Segment-Strukturen). Beides zusammen ergibt ein System, das verlässliche Antworten liefert.

Was aktuell funktioniert: Alltagsfragen im Produktmanagement. Wie viele Nutzer zeigen dieses Verhaltensmuster? Wie unterscheidet sich die Churn Rate zwischen unseren Segmenten? Was passiert im Durchschnitt in den ersten 30 Tagen nach Anmeldung?

Was noch nicht geht: Die explorativen Zwei-Stunden-Sessions mit einem Senior Data Analyst. Die komplexen strategischen Analysen. Das ist bewusst kein Ziel – Pareto-Logik. 80 % der Fragen, die sich Teams täglich stellen, sind gut beantwortbar. Damit fängt man an.

These: Wenn dieselbe Frage vom CEO und vom PM ins System kommt, muss dieselbe Antwort rauskommen. Das ist der Unterschied zwischen einem Tool für echte Entscheidungen und einem, das nur das gute Gefühl liefert, irgendwas analysiert zu haben.

Context Engineering – der eigentliche Unterschied

Hier wird's technisch. Aber lohnt sich.

Ein LLM ohne Kontext macht Annahmen. Und tut das mit erschreckendem Selbstbewusstsein. Markus bringt ein gutes Beispiel: ein Bootcamp-Curriculum reviewen. ChatGPT spuckt ohne spezifischen Kontext generisches Zeug aus. Dann die tiefen fachlichen Fehler benennen, nochmal fragen – plötzlich sagt das Modell, es habe jetzt erst das nötige Wissen aktiviert und kann tatsächlich tief reingehen.

Das LLM weiß, was es braucht. Es bekommt es nur meistens nicht.

Was Product Analyst AI deswegen baut: einen Kontext-Layer. Was bedeuten die Event-Namen wirklich – denn die heißen oft nicht "conversion_event", sondern irgendein kryptischer String. Wie wird Churn Rate in dieser Firma berechnet? Welche Segmente gibt es, die immer wieder auftauchen? Welche Metriken sind already definiert?

Das alles wird einmal erarbeitet – aktuell noch manuell im Onboarding – und dann dem Agent als strukturierter Kontext zur Verfügung gestellt. Der Agent zieht sich Kontext und ruft deterministische Berechnungsfunktionen auf. Kombiniert beides. Gibt verlässliche Antworten.

These 1: Prompt-Qualität ist weniger wichtig als Kontext-Management. Wer Kontext strukturiert einbaut, kriegt dramatisch bessere Ergebnisse.

These 2: Die Leute, die heute schon großen Wert aus AI ziehen, und die, die sagen "ist ja alles generisch" – die unterscheiden sich fast ausschließlich darin, wie gut sie Kontext managen.

Datenzugang für alle – nicht nur Produkt

Customer Success fragt sich, ob der Upsell vom letzten Quartal bei einem Account überhaupt genutzt wird. Sales will wissen, welche Kunden Absprungs-Signale zeigen. Marketing würde gerne sehen, welche Features tatsächlich zur Aktivierung führen. All das steckt in den Daten.

Aber Mixpanel-Zugang hat meist nur Produkt. Und selbst dort weiß oft keiner wirklich, was in den Daten steckt.

Das ist das größere Bild hinter Product Analyst AI: nicht nur PMs bedienen, sondern Datenzugang für alle Teams im Unternehmen ermöglichen. Ohne dass jeder Mixpanel lernen muss. Ohne Ticket an das Datenteam. Ohne drei Wochen warten.

These: Die meisten Firmen haben ein Datenzugangs-Problem – und halten es für ein Datenanalyse-Problem. Der Fix ist nicht mehr Dashboards bauen. Der Fix ist, Fragen direkt beantwortbar zu machen.

AI im Unternehmer-Alltag – was sich wirklich verändert hat

Als Zweier-Founding-Team können Nico und sein Co-Founder heute Arbeit tun, die früher entweder liegengeblieben wäre oder externe Ressourcen erfordert hätte, die man als kleines Team schlicht nicht hat.

Konkret: Aus der LinkedIn-Connection-Liste 5.000 relevante Unternehmen herausfiltern. Neue Anmeldungen automatisch qualifizieren – bei welcher Firma arbeiten die, welches Problem könnten sie haben, passen die zu uns? Ein Python-Script, das früher einen halben Tag manueller Arbeit bedeutet hätte, entsteht jetzt in Minuten.

Nico sagt es direkt: Das revolutioniert jeden Teil seiner Arbeit. Nicht im Sinne von "ich muss nicht mehr denken". Im Gegenteil – die Qualität der eigenen Gedanken ist jetzt der Bottleneck, nicht die Umsetzbarkeit manueller Aufgaben.

These 1: KI nimmt keine Jobs weg. Sie ermöglicht Arbeit, die vorher schlicht nicht stattgefunden hat – weil die Ressourcen fehlten.

These 2: Mit AI-Unterstützung wird man als Unternehmer nicht effizienter in dem, was man schon gemacht hat. Man kann plötzlich Dinge tun, die vorher schlicht nicht im Bereich des Möglichen lagen.

Der Suchtfaktor – und warum Abstand wichtig bleibt

Nico läuft. Viel. Idealerweise Trailrunning in den Bergen. Und er reist. Montenegro, Bali. Nicht als Auszeit, sondern als notwendiger Kontrastwechsel.

Der Hintergrund: Wenn repetitive Arbeit wegfällt und fast nur noch strategisches Denken übrig bleibt, wird mentale Klarheit zum eigentlichen Bottleneck. Früher konnte man "Kopf ausschalten und einfach machen". Das geht jetzt nicht mehr.

Gleichzeitig: AI-Tools haben einen extremen Suchtfaktor. Schnelle Ergebnisse, ständige Dopaminstöße – Bumm, Ergebnis. Noch eine Iteration, bang, besser. Markus vergleicht das direkt mit Social Media. Und trifft damit einen Nerv.

Naval Ravikant hat dazu einen passenden Tweet: "Play long-term games with long-term people." Das ist genau das Gegenteil vom Hustle-ADHS, das gerade in AI-Kreisen kursiert.

These 1: Je mächtiger AI-Tools werden, desto wichtiger wird der Rhythmus drumherum. Wer das nicht aktiv gestaltet, verbrennt.

These 2: Außerhalb der eigenen Bubble bleiben ist gerade strategisch wichtig – nicht nur persönlich. Wer nur innerhalb der AI-Early-Adopter-Welt lebt, verliert das Gefühl dafür, was die Mehrheit der Menschen braucht und versteht.

Signal vs. Noise – wie man nicht den Überblick verliert

Alle haben FOMO gerade. Die Größten der Szene inklusive. Die Frage ist nicht mehr, ob man was verpasst – sondern wie man trotzdem handlungsfähig bleibt.

Nicos Antwort: Drei, vier Leute finden, die nicht Meinungen teilen, sondern zeigen, wie sie es machen. Denen folgen. Den Rest ausblenden.

These: Taktisch in AI-Tools einzutauchen ist gerade einer der strategischsten Schritte, die man machen kann. Wer versteht, wie diese Werkzeuge wirklich funktionieren, hat einen fundamentalen Vorteil – genau wie beim Aufkommen des Internets oder von Mobile.

Links

Gast:

• Product Analyst AI → https://productanalyst.ai
• Nico auf LinkedIn → https://linkedin.com/in/niconoll
• Nico auf Twitter/X → https://twitter.com/niconoll

Im Gespräch erwähnte Tools:

• Amplitude → https://amplitude.com
• PostHog → https://posthog.com
• Mixpanel → https://mixpanel.com
• Google Analytics → https://analytics.google.com
• ChatGPT → https://chat.openai.com
• Tweet von Naval Ravikant

Mein nächster AI Augmented PM Kurs, Start 18.05.2026

Kapitel

00:00 Einführung in Product Analyst AI 03:31 Die Lücke im Datenmanagement 06:16 Die Rolle der AI in der Datenanalyse 09:35 Komplexität der Datenfragen 12:19 Parametrisierung und Kontextualisierung 15:25 Herausforderungen der Dateninterpretation 18:32 Die Zukunft der Datenanalyse mit AI 21:23 Demokratisierung von Datenzugang 27:52 Die Herausforderungen der Datenanalyse 31:56 Die Entstehungsgeschichte des Produkts 35:13 Die Rolle von AI im Unternehmertum 38:13 Technologische Einflüsse auf Produktentwicklung 41:07 Intelligente Nutzerinteraktionen mit AI 43:22 Das Leben außerhalb der Arbeit 48:26 Langfristige Perspektiven in einer schnelllebigen Welt 52:46 Outro

Matthias Lübken. Zwei Jahre deep in AI. AI Revolution Isights Wo man Mathias erreicht:

Matthias' Angebot: tavon.ai - Put AI Agents To work AI education and deplyoment

LinkedIN: https://www.linkedin.com/in/luebken/

Community: AI Tinkerers Cologne

Matthias ist Produktmanager, Softwareentwickler, Rheinländer aus Bonn. Seit gut zwei Jahren macht er nichts anderes als AI-Tools studieren und anwenden. Er hat die Welle vor zwei Jahren auf sich zukommen gesehen hat und ist reingesprungen.

Im Gespräch versuchen wir Hintergründe zu erklären, Fomo zu nehmen und aufzuklären, Begriffe erklären.

TLDR

Agentic AI ist ein glorified while loop mit Tool Calls. Wer das einmal verstanden hat, sieht warum so absurde Sachen funktionieren — und warum die meisten Diskussionen da draußen am falschen Punkt ansetzen.

Ein paar Themen, die wir besprochen haben

Der Schalter

Der Moment, der alles verändert hat, war Claude Code und die neuen Modelle. Auf einmal konnte Matthias Sachen alleine machen, für die er vorher ein ganzes Software-Team gebraucht hätte. Good enough" - das hat bei ihm edie Frage aufgebracht, "Was mache ich denn eigentlich in Zukunft mit Teams"?

Claude Code, der wohl schlechteste Produktname aller Zeiten (weil man damit eben nicht nur coden kann). Produktmenschen, Strategen, Finanzmenschen und normale Menschen, alle können damit strukturiert arbeiten, Context aufbauen, automatisieren, … Boris Cherny hat das Claude Code am Anfang in einer Woche als Wochenendprojekt gebaut. Das Interface ist ein Terminal. Für Software-Entwickler fühlt sich das wie 1985 an und genau darin liegt der Trick.

Was darunter passiert

Ein Large Language Model schickt Tool Calls raus. Unix-Commands — list, grep, execute. Die kommen zurück. Das LLM interpretiert, schickt den nächsten Call. Und so weiter. Ein glorified while loop, sagt Matthias. Der Durchbruch, den Claude 3.7 Sonnet brachte, war dass das Modell gut genug war, eine neue Fähigkeit zu bekommen: den Aufruf von Tools. In der richtigen Reihenfolge, für lange genug, dass etwas Sinnvolles dabei rauskam.

Boris Cherny hat daraus ein Arbeitsprinzip gemacht: Feature auf funktionaler Ebene abnehmen, Code nicht mehr lesen. 60 bis 70 Prozent wirft er weg. Egal, wenn die anderen 30 Prozent funktionieren. Für die meisten Entwickler ist es psychologisch brutal, weil sie 15 Jahre gelernt haben zu coden, jeden Commit zu verstehen, jeden PR zu reviewen. Jetzt verschiebt sich der Wert dieser Skills auf genau die Stellen, die früher als "soft" abgetan wurden: Architektur, Judgment, beschreiben können wie gut aussieht. Kent Beck hat vor zwei Jahren formuliert: 90 % seiner Skills sind im Wert auf Null gesunken, 10 % haben vertausendfacht.

Und bei Cherny klappt es nicht, weil er Yolo ist, sondern weil er penibel ein System aufgebaut hat.

Was Context Engineering heißt

Ein LLM ist per se stateless. Jeder Call fängt neu an. Der Thread, den man in ChatGPT siehst, wird komplett mitgeschickt, bei jedem Request. Was das System über einen zu wissen scheint, liegt daran, was man vorher reingeschrieben hat, oder an einer internen Memory, die man kaum steuern kannst.

Claude Code funktioniert anders. Man baut Kontext auf, der bleibt. Was ist das Projekt? Was die Prinzipien? Was gibt es schon? Das steht in Markdown-Dateien. Der Agent lädt den gewünschten Kontext. Man steuert das. Metapher: Read the fucking manual vs. "das Problem, das dich betrifft, steht in Kapitel 5, Absatz 4." Der Mensch kommt mit beidem irgendwie klar- aber die Qualität des Ergebnisses ist eine andere. Auch bei der LLM: Besserer, exakterer Kontext, besseres Ergebnis.

Der eigentliche Punkt hinter allem, was Matthias als "Maschine bauen" beschreibt. Erst wenn die Maschine gut gebaut ist, kann man dem Ergebnis trauen.

Matthias' persönliches CRM

Sein CRM besteht aus einem Ordner mit Markdown-Dateien. Kontakte, Aktivitäten, eine simple Folderstruktur nach Status, E-Mail und Kalender angebunden. Wenn er wissen will, was beim letzten Gespräch mit jemandem war, fragt er den Agenten. Der durchsucht alles, antwortet, schlägt nächste Schritte vor. E-Mails lässt Matthias entwerfen, schickt sie aber immer selbst raus. Human in the loop, wieder. Das Ergebnis ist trotzdem Faktor X besser als jeder normale E-Mail-Assistent, weil der echte Kontext da ist.

Dahinter steckt eine Frage, die uns den ganzen Talk beschäftigt hat: Wie viel von klassischer SaaS-Software wird kaputtgehen, weil hyperpersonalisierte Lösungen so viel besser passen? Matthias glaubt nicht, dass SaaS grundsätzlich stirbt, er aber eine Richtung : Systems of Records, die für LLMs mit ordentlichen APIs zugänglich gemacht werden. Und für viele Use Cases, wo heute irgendwas von der Stange genommen wird, das so halb nicht passt, sind kleine eigene Lösungen auf einmal eine echte Option.

Openclaw und die Voice Message

Peter Steinberger hat OpenClaw gebaut, ein Agentsystem ,basierend auf einer anderen Agentenplattform aus Österreich: pi. Er hat WhatsApp angeschlossen. Die erste Version konnte nur Text. Irgendwann schickt jemand aus Versehen eine Voice-Nachricht. Der Agent sieht: das ist keine Text-Datei. Also: Unix-Environment, Datei aufmachen, scheint Audio zu sein, was nimmt man für Audio: Whisper von OpenAI? Wie rufe ich das auf? Token holen. API Call. Transcription. Antwort zurück. Jeder einzelne dieser Schritte ist nachvollziehbar. Zusammen sieht es aus wie Magie. Das ist das Prinzip hinter allem.

Was Matthias gerade macht

Unter anderem: Eine Menge Community-Arbeit, Wissen unter die Leute bringen. Er baut AI Tinkerer Cologne (als Bonner), Teil eines globalen Netzwerks, Tüftler zusammenbringen, konkret ausprobieren was geht. Workshops mit HR-Teams, die Workflows automatisieren wollen. In ein paar Wochen London, AI Engineering Konferenz, wo er über seinen Coding Agent Pi spricht. Sein Fokus für die nächsten Wochen: rausfinden, wie weit Non-Coding-Workflows mit Cowork und ähnlichen Tools wirklich tragen.

Sein Aufruf: Schickt die harten Use Cases rüber. Die, bei denen ihr nicht weiterkommt. UNd das meinen wir ernst: Schickt sie uns! Challenge accepted!

Kapitel

00:00 Einführung in die Themen von AI und Unsicherheit

02:09 Matthias' Erfahrungen mit AI

08:14 Die Entwicklung von Software-Tools und deren Einfluss

12:10 Der Paradigmenwechsel in der Softwareentwicklung

17:40 Vertrauen in AI-gestützte Systeme und deren Nutzung

23:33 Die Anpassung an sich verändernde Technologien

24:55 Einführung in Agenten und Modelle

27:30 Erfahrungen mit Software-Entwicklung und LLMs

29:58 Anwendungen und Entdeckungen mit Claude

32:48 Kontext-Engineering und CRM-Entwicklung

34:33 Unterschiede zwischen ChatGPT und Claude

38:46 Tool-Calling und seine Bedeutung

42:33 Praktische Anwendungen von LLMs in Unternehmen

50:11 Philosophische Überlegungen zu LLMs und menschlicher Arbeit

53:33 Die Herausforderung der Spezifikation

55:07 Die Bedeutung von Kontext und Anweisungen

56:59 Zugriffsrechte und Sicherheit in der KI

59:02 Die Unterschiede zwischen Cloud Code und Desktop-Tools

01:01:01 Hyperpersonalisierung in der Softwareentwicklung

01:03:30 Die Zukunft von SaaS und hyperindividualisierte Software

01:06:15 Prototypen und agile Entwicklung

01:09:01 Das Innovationsdilemma großer Unternehmen

01:13:24 Herausforderungen bei der Implementierung neuer Technologien

01:14:07 Herausforderungen der KI-Nutzung

01:16:50 Kosten und Ressourcenmanagement bei KI

01:20:10 Abonnements und Token-Management

01:22:34 Die Bedeutung des Experimentierens

01:27:13 Die Rolle der KI in der Zukunft

01:33:41 Bildung und die Zukunft der Arbeit

With product managers (and other knowledge workers) as well getting over the barrier to adopt the command line of Claude Code (probably the worst product name ever), everything changes. Roles, responsibilities, the requirements for an org to align. So, I am happy to in this episode to speak with Dr. Else van der Berg, a self employed product manager living in Berlin. Else in working in AI native companies, so she knows something about the evolving landscape of product management in AI-native environments.

'The way I work has changed more in the last six months than in the last five years.' - Dr. Else van der Berg

Else writes about this shift in our role and in our environments a lot on LinkedIn and on substack.

Read Else's content on LinkedIn: https://www.linkedin.com/in/dr-else-van-der-berg-42b8b6a2/

And on substack: https://elsevanderberg.substack.com Get infected! I really enjoy Else's refreshing perspective, knowing all the depth of our "old styles" of working, carrying all the influences from Marty Cagan, Teresa Torres etc. - but being full of energy to embrace all the tools and thus discovering all the new possibilities but also the new frictions. She shares her journey from traditional product management roles to embracing AI tools that enhance evidence-based decision-making. Else emphasizes the importance of understanding technology, especially in AI-driven products, and how this knowledge can empower product managers to make informed decisions. The discussion also touches on the shift from rigid Agile methodologies to more flexible, adaptive approaches that prioritize collaboration and rapid iteration, reflecting the changing dynamics of tech companies today. Else enjoys the shift from more specialised to more generalist roles that the new technology allows for. She argues that a broader skill set allows for better integration of technology and user experience. She also highlights the need for product managers to engage deeply with both customers and how the technology buys us that time. The conversation concludes with insights on how to navigate the challenges of communication and collaboration in fast-paced environments, emphasizing the value of transparency and shared goals among team members. The main point, though, is: This new technology augments us, helps us to get rid of "boring" work through atomisation and thus helps us find time to do what only humans can do - connect with other humans: clients, stakeholders, engineers.

Takeaways

'The way I work has changed more in the last six months than in the last five years.' 'We need to understand the technology behind AI products.'

'Everything is a test because you're just trying to collect data to see if your assumptions were true or false.'

'The smaller you are, the cooler it is.'

'We need to embrace failures and be transparent about them.'

Soundbites

'The way I work has changed more in the last six months than in the last five years.' 'I think there's a strong case being made for strict specializations and boundaries.' 'Launching an MVP or launching a feature is a test method.'

Chapters

00:00 Introduction to AI Native Product Management

02:28 Dr. Else Van Der Berg's Journey in Tech

04:49 The Role of Generalists in Product Management

11:25 Shifts in Validation and Testing Methods

20:32 The Impact of Automation on Product Management

30:27 The Future of Product Development Teams

38:19 Proactive Product Management Strategies

40:17 The Role of AI in Understanding Problems

43:13 Communication Challenges in Product Management

45:26 Maintaining Context and Consistency

48:37 The Future of Work and Team Dynamics

55:49 Cultural Shifts in Organizations

01:00:28 Embracing Change and Innovation