Der Produktentwickler - Podcast

About Der Produktentwickler - Podcast

Prozesse, Menschen, Produkte. Der Podcast für eine schnelle, effiziente und zukunftsfähige Produktentwicklung. In dieser Audio-Edition übersetze ich die Analysen und Strategien meines englischsprachigen Newsletters ins Deutsche. So erhältst du alle Insights bequem in deiner Muttersprache – optimiert für das Hören unterwegs. Den englischen Newsletter mit allen Grafiken und Quellen findest du unter https://uwemierisch.substack.com/ uwemierisch.substack.com (https://uwemierisch.substack.com?utm_medium=podcast)

Publisher

Der deutsche Podcast zum englischen Newsletter von Uwe Mierisch

Category

business · technology

Language

de

Explicit

No

First episode

12 Jan 2026

Latest episode

9 Nov 2026

Latest episodes

16 episodes in the feed.

1. 

   9 Nov 2026

   Die Matrix meistern

   Solange jeder jeden kennt und jeder das Produkt bis ins Detail versteht, ist Teamarbeit leicht zu organisieren. Erfolgreiche Firmen wachsen aber. Irgendwann ist die Gruppe zu groß und das Produkt zu kompliziert für den hemdsärmeligen Weg. Dann kommt oft die Matrixorganisation. Sie ist sehr verbreitet und gleichzeitig sehr umstritten. Seit langer Zeit wird sie in vielen großen und erfolgreichen Unternehmen eingesetzt. Und genauso lange wird beklagt, dass sie unklare Verantwortlichkeiten, zu viele Kommunikationswege und hohe Ineffizienzen erzeugt. Uwe Mierisch zeigt, welches Problem die Matrix löst, warum sie zu Recht als schwer führbar gilt und mit welchen Regeln sie beherrschbar wird. Wo Fachkompetenz auf Projektarbeit trifft. Themen dieser Episode Welches Problem muss gelöst werden? Ein Produkt braucht viele Kompetenzen. Mit dem Wachstum arbeiten plötzlich viele Mitarbeiter im selben Fachgebiet, und auch sie müssen koordiniert werden. Kompetenzbezogene Strategien: Einkaufs-, Produkt-, Entwicklungs- und After-Sales-Strategie betreffen die Zukunft des ganzen Unternehmens, nicht nur ein einzelnes Projekt. Zwei Dimensionen, eine Matrix: Prozessorganisation (Ablauforganisation) und Funktionalorganisation (Aufbauorganisation) betreffen dieselben Mitarbeiter. Ein zweidimensionales Problem lässt sich als Matrix darstellen. Der Mitarbeiter als Integrator: Er bekommt Aufgaben und Ziele vom Projektleiter und vom Fachvorgesetzten und muss beiden gleichzeitig gerecht werden. Die offene Frage der Personalführung: Wer sie in Doppelrolle übernimmt, bekommt automatisch mehr Gewicht. Die Gleichrangigkeit der beiden Dimensionen ist dahin. Die komplexe Matrix: Mitarbeiter in mehreren Projekten gleichzeitig haben nicht zwei, sondern eine Vielzahl von Führungsbeziehungen. Die Projektorganisation steuert. Die Funktionalorganisation liefert. Der Projektleiter ist verantwortlich für das Was und Warum, nicht für das Wie. Wer verantwortet das Gesamtergebnis? Die Führungskraft, an die Projektleiter und Fachvorgesetzte berichten. Ohne besondere Regelung ist das der Vorstandsvorsitzende. Delegieren ja, aber nicht an den Projektleiter. Klare Eskalationsregeln: Szenariobeschreibungen, welches Problem welchen Eskalationsweg nimmt. Selten definiert, sofort wirksam. Zeitlicher Fokus: Drei Kategorien von Projektmitarbeitern reduzieren die Zahl der Führungsbeziehungen zu jedem Zeitpunkt. Schlanke Projektorganisation: Wer Ergebnisse liefern soll, bleibt in der Funktionalorganisation. Warum „lieber schnell selbst machen“ das Steuerungsmodell untergräbt. Key Takeaways ✓ Die Matrix entsteht, weil zwei Dimensionen gleichzeitig organisiert werden müssen: der Ablauf im Projekt und die Fachkompetenz ✓ In der Matrix kümmert sich jede Führungskraft um eine Dimension. Der Mitarbeiter integriert beide in einer gemeinsamen Lösung ✓ Die Projektorganisation steuert. Die Funktionalorganisation liefert ✓ Die ganzheitliche Verantwortung des Projektleiters gibt es in der Matrix nicht ✓ Verantwortlich für das Gesamtergebnis ist die Führungskraft, an die beide Dimensionen berichten ✓ Klare Eskalationsregeln, zeitlicher Fokus und eine schlanke Projektorganisation machen die Matrix beherrschbar Für wen ist diese Episode relevant? Führungskräfte und Fachvorgesetzte in der Produktentwicklung Projektleiter, die ohne Personalverantwortung Ergebnisse steuern müssen Mitarbeiter, die in mehreren Projekten gleichzeitig arbeiten Geschäftsleitungen wachsender Unternehmen, deren Organisation an ihre Grenzen stößt Alle, die ihre Matrix neu aufstellen wollen Weitere Informationen Arbeiten Sie in einer Matrixorganisation? Und ist bei Ihnen klar, welches Thema zum Projektleiter gehört und welches zum Fachvorgesetzten? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. In der nächsten Episode geht es um die Organisationsstruktur für softwaredefinierte Produkte. Auch dort spielt die Matrix wieder eine Rolle. Newsletter oder Podcast abonnieren, um die ganze Geschichte mitzubekommen. Zum Nachlesen: der Blogartikel zur Funktionalorganisation auf uwemierisch.com (http://uwemierisch.com) (https://uwemierisch.com/functional-organization/ (https://uwemierisch.com/functional-organization/)). Hashtags #Matrixorganisation #Organisation #Projektmanagement #Funktionalorganisation #Projektorganisation #Führung #Verantwortung #Eskalation #Produktentwicklung #NewPDP #SystemsEngineering Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

2. 

   26 Oct 2026

   Clausewitz und Moltke haben unser Führungsproblem gelöst. Wir haben es nur nicht gelernt.

   „Baut mal schnell einen Prototypen mit dem neuesten Motor. Macht euch sonst keine weiteren Gedanken.“ Mit diesem Satz hat ein Chef ein Produkt gerettet, dessen Produktion schon zur Diskussion stand. Für Uwe Mierisch war das der Moment, in dem er Führungskraft werden wollte. In dieser Episode geht es um Leadership, den ersten der drei Enabler des NewPDP. Klare Richtung, ein Team. Führung wird leicht mit Management verwechselt. Und die Frage, wer eigentlich was entscheidet, bleibt in den meisten Unternehmen offen. Die Antwort kommt ausgerechnet von zwei preußischen Generälen: Carl von Clausewitz und Helmuth von Moltke dem Älteren. Themen dieser Episode Führung ist nicht Management: John P. Kotter, Harvard 1990. Management bewältigt Komplexität, Führung bewältigt Veränderung. Viele Unternehmen sind overmanaged and underled. Drei Ebenen statt zwei: Clausewitz unterscheidet Taktik, Strategie und Zweck. Warum Preußen 1806 bei Jena und Auerstedt mit nur zwei Ebenen gescheitert ist. Der Zweck ist groß und er bleibt stehen: Was das Unternehmen werden will, entscheidet die Geschäftsführung als Treuhänder der Eigentümer. Und sie hält es stabil. Die Taktik gehört dem Team: Moltkes Auftragstaktik. Was und warum kommt von oben, das Wie entscheidet, wer vor Ort ist. Das funktioniert nur mit einem System wie dem Drum Beat. Der Stratege sitzt dazwischen: Strategie ist kein Fünfjahresplan, sondern ein System der Aushilfen. Nach jedem Zug neu bewerten und den nächsten wählen. Der Generalstab zeigt, dass das keine Frage des Rangs ist. Wer führt? Peter Drucker: Führer ist, wem gefolgt wird. Führung ist eine Tätigkeit, keine Position. Was ist denn ein Chef? Chef ist, wer Verantwortung für das Tun anderer übernimmt. Und das geht nur mit einem eigenen Beitrag. Nicht aus dem Elfenbeinturm: Clausewitz verlangt, dass die Strategie mit ins Feld zieht. Entschieden wird sofort, nicht in der nächsten Lenkungskreissitzung. Management ist der Aufmarsch: Gutes Management reduziert die Komplexität der Ausführung auf das unvermeidbare Maß. Tracking, Überwachung und Rechtfertigung gehören nicht dazu. Key Takeaways ✓ Führung ist nicht Management. Management bewältigt Komplexität, Führung setzt eine Richtung. ✓ Führung findet auf drei Ebenen statt: Zweck, Strategie und Taktik. ✓ Den Zweck setzt die Geschäftsführung, und sie hält ihn stabil. ✓ Strategie ist kein Plan. Sie ist das ständige Neubewerten der Lage auf dem Weg zum Zweck. ✓ Führung ist eine Tätigkeit, keine Position. ✓ Chef ist, wer Verantwortung für das Tun anderer übernimmt. ✓ Management schafft Voraussetzungen. Tracking stellt fest, was nicht erledigt wurde. Für wen ist diese Episode relevant? Geschäftsführer und Bereichsleiter, die eine Richtung über Jahre halten müssen Führungskräfte in der Produktentwicklung, deren Kalender vom Management aufgefressen wird Projektleiterinnen, Systemarchitekten und Experten, die strategisch arbeiten, ohne Chef zu sein Alle, die vor einer Transformation ihres Entwicklungssystems stehen Weitere Informationen Wie viel von dem, was in Ihrem Unternehmen Management heißt, schafft Voraussetzungen? Und wie viel stellt nur fest, was nicht erledigt wurde? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. In den nächsten Episoden geht es weiter mit den beiden anderen Enablern des NewPDP: Organisation und Architektur. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Zum Nachlesen: der Artikel zu dieser Episode auf Substack. Quellen Clausewitz, Carl von: Vom Kriege. Hinterlassenes Werk des Generals Carl von Clausewitz. Berlin: Dümmler, 1832–1834. Hier: Buch 1, Kap. 1, Nr. 24 (Fortsetzung der Politik mit anderen Mitteln); Buch 2, Kap. 1 (Taktik und Strategie); Buch 3, Kap. 1 (die Strategie muss mit ins Feld ziehen). Drucker, Peter F.: Foreword. Not Enough Generals Were Killed. In: Hesselbein, Frances; Goldsmith, Marshall; Beckhard, Richard (Hrsg.): The Leader of the Future. New Visions, Strategies, and Practices for the Next Era. San Francisco: Jossey-Bass, 1996. Kotter, John P.: What Leaders Really Do. In: Harvard Business Review 68 (1990), Nr. 3, S. 103–111. Kotter, John P.: A Force for Change. How Leadership Differs from Management. New York: Free Press, 1990. Moltke, Helmuth von: Über Strategie (1871). In: Großer Generalstab (Hrsg.): Moltkes Militärische Werke, Abt. II, Teil 2: Moltkes taktisch-strategische Aufsätze aus den Jahren 1857 bis 1871. Berlin: Mittler, 1900, S. 287–293. Moltke, Helmuth von: Aus den Verordnungen für die höheren Truppenführer vom 24. Juni 1869. In: ebd., S. 171–215. Hashtags #NewPDP (#NewPDP) #Leadership (#Leadership) #Führung (#Führung) #Management (#Management) #Strategie (#Strategie) #Auftragstaktik (#Auftragstaktik) #Clausewitz (#Clausewitz) #Moltke (#Moltke) #Produktentwicklung (#Produktentwicklung) #Transformation (#Transformation) #SystemsEngineering (#SystemsEngineering) Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

3. 

   12 Oct 2026

   Predictive Technology Readiness - Reif, wenn es gebraucht wird.

   Episode-Beschreibung Produktentwickler lieben Innovationen. Controller lieben einen positiven Business Case. Und Innovationen sind eine Wundertüte: Was drin ist, weiß man erst, wenn man sie öffnet. Genau dieses Öffnen kostet Geld. Im alten System wartet die Innovation deshalb auf ein passendes Projekt und wird erst dort untersucht. Mit Schleifen, Überraschungen und verschobenen Terminen. Im NewPDP mit 48 Monaten für ein komplett neues Fahrzeug und ohne Erprobungsflotte im Reifegrad B ist dafür kein Platz. Uwe Mierisch stellt das vierte Element des NewPDP vor: Predictive Technology Readiness (PTR). Die Wundertüte muss offen sein, bevor das Projekt startet. Woher das Geld dafür kommt, wofür es ausgegeben wird, wer darüber entscheidet — und warum am Ende Entwickler und Controller zufrieden sind. Themen dieser Episode Die Wundertüte wird zu spät geöffnet: Ohne Business Case kein Geld, also wartet die Innovation auf ihr Projekt. Erst dann wird sie geöffnet, ganz langsam. Diese Vorgehensweise muss sich ändern. Viel Feind, viel Ehr: Warum die PTR zuerst Entwickler und Controller gleichzeitig gegen sich hatte Es geht nicht um Tempo, sondern um den Zeitpunkt: Gesetzestermine, Kundenbedarf, Wettbewerb, Kostendruck, neue Märkte. Je schneller ein Projekt, desto später kann es starten und desto sicherer baut man das Richtige. Darum ist Geschwindigkeit doch wichtig. Wo kommt das Geld her?: Ohne Projekt gibt es keinen Business Case. Darum ist das Innovationsbudget eine unternehmerische Entscheidung, keine Berechnung — und muss in jeder Budgetrunde verteidigt werden Budget fix, Inhalt folgt: Der grundlegende Unterschied zum klassischen Vorentwicklungsprojekt Technologiemonitoring: Alle relevanten Trends auf den Radar, Produkt- wie Produktionstechnologien. Ziel ist nicht, eine Technologie fertig zu entwickeln, sondern sie besser einschätzen zu können Das Innovationsteam: Klein, interdisziplinär, mit dem Controlling am Tisch. Entscheidet eigenständig innerhalb des Budgets, im Takt des Drum Beat Systems Das Korrektiv: Öffentliche Retrospektiven und Lessons Learned. Einmischen ist erwünscht, Meckern im Nachgang nicht Warum „predictive"?: Vorbereiten, nicht vorhersagen — wie bei der prädiktiven Instandhaltung Warum am Ende alle zufrieden sind: Entwickler bekommen Geld für Innovationen ohne warten auf ein Projekt, Controller bekommen Projekte ohne Wundertüte. Am Ende geht es schneller und ist billiger. Key Takeaways ✓ Innovationen, die erst im Projekt bearbeitet werden, machen Projekte langsam und unberechenbar ✓ Nicht Schnelligkeit entscheidet über den Markterfolg, sondern der richtige Zeitpunkt. Schnelle Projekte brauchen bekannte Inhalte ✓ Das Innovationsbudget ist eine unternehmerische Entscheidung, keine Berechnung. Seine Höhe richtet sich danach, wie innovativ das Unternehmen sein will ✓ Ein kleines, interdisziplinäres Innovationsteam entscheidet im Takt über die Verwendung ✓ Das Korrektiv ist Transparenz ✓ Ein billiges Nein vor dem Projekt ist besser als ein teures Nein mitten im Projekt ✓ PTR ist die Voraussetzung dafür, dass Learning Standard Routines und Hardware Light Development funktionieren Für wen ist diese Episode relevant? Führungskräfte in der Produktentwicklung mechatronischer Produkte Mitarbeiter und Leiter von Vorentwicklung und Innovationsmanagement Controller und Finanzverantwortliche, die über Innovationsbudgets entscheiden Produktmanagement und Vertrieb, die den richtigen Markteintrittszeitpunkt mitbestimmen Geschäftsleitungen, die festlegen müssen, wie innovativ ihr Unternehmen sein will Weitere Informationen Diese Episode ist Teil der Serie zum NewPDP. Zuvor erschienen: der Überblick zum NewPDP, das Drum Beat System, die Learning Standard Routines und Hardware Light Development. In den nächsten Wochen geht es mit den drei Voraussetzungen weiter: Führung, Organisation und Architektur. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Wie wird in Ihrem Unternehmen über Geld für Innovationen entschieden? Gibt es ein festes Budget, oder muss jede Idee ihren eigenen Business Case mitbringen? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. Hashtags #PredictiveTechnologyReadiness (#PredictiveTechnologyReadiness) #NewPDP (#NewPDP) #Produktentwicklung (#Produktentwicklung) #Innovation (#Innovation) #Innovationsmanagement (#Innovationsmanagement) #Technologiemonitoring (#Technologiemonitoring) #Vorentwicklung (#Vorentwicklung) #BusinessCase (#BusinessCase) #Controlling (#Controlling) #Fahrzeugentwicklung (#Fahrzeugentwicklung) #LeanDevelopment (#LeanDevelopment) #Agil (#Agil) Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

4. 

   28 Sept 2026

   Hardware Light Development, ein Zyklus, vier Phasen.

   Episode-Beschreibung Im NewPDP Pilotprojekt habe ich die komplette Reifegrad B Prototypenflotte gestrichen. Über Nacht wurde aus dem Projekt, bei dem alle mitmachen wollten, ein Feindbild. Der Widerstand kam nicht von einzelnen Bedenkenträgern, er kam aus der Breite der Belegschaft. Und er war berechtigt. Hardware ist nicht nur ein Erprobungsmittel. Sie ist ein Hygienefaktor und ein Führungsinstrument. Sie zeigt unmissverständlich, was fehlt, und sie setzt einen Termin, den jeder ernst nehmen muss. Hardware Light Development, das dritte Element des NewPDP, heißt deshalb nicht, Hardware wegzulassen. Es heißt, sie zu ersetzen. Virtuell vor materiell. Diese Episode beschreibt, wie das geht: mit demokratisierten virtuellen Prototypen und mit dem universellen 4 Takt Zyklus, der einmal statt viermal durchlaufen wird. Definition, Creation, Validierung, Implementierung. Inhalt der Episode Hardware ist teuer, knapp und trotzdem beliebt. Sie ist konkret, anfassbar und brutal ehrlich. Was fehlt, sieht jeder sofort. Das erzeugt den Eindruck von Effizienz. Der übersehene Nutzen: Hardware ist Hygienefaktor und Führungsinstrument. Die Prototypenliefertermine sind der Meilenstein, den jeder ernst nehmen muss. Der Preis dafür: Reifegradflotten sind teuer, knapp und nie auf Anhieb funktionsfähig. Fällt ein Entwickler aus dem Plan, bricht der Prototypen-Verwendungsplan zusammen. Das ist keine Volatilität, das ist eine Eigenschaft der Vorgehensweise. Der universelle 4 Takt Zyklus wird einmal durchlaufen, nicht viermal. Eine Art Supersprint, dafür mit harten Definition of Done Meilensteinen. Demokratisierung der virtuellen Prototypen ist die Voraussetzung für alles Weitere. Zugang für jeden Projektmitarbeiter, vom ersten Tag an, so einfach wie der Gang in die Werkstatt. Ohne sie ist der virtuelle Prototyp ein Werkzeug für Spezialisten. Definition: Systems Engineering in Reinform. Alle Schnittstellen und Anforderungen werden vollständig beschrieben, von allen Fachdisziplinen gleichzeitig und ohne eine einzige Hardware. Der Business Case ist ein Meilenstein mittendrin, nicht das Ziel. Creation: die Zeit der Lösungsfindung. Am Ende ist der neue Entwicklungsstand vollständig im virtuellen Prototypen abgebildet. Hardware nur als zugeschnittener Entwicklungsträger, als „Mule", nie als vollständiges Projektfahrzeug. Bündelung von Umfängen bündelt auch Risiko. Validierung: jetzt fließen große Summen ab. Die Prototypen bestätigen einen fertigen Stand, sie entwickeln ihn nicht. Keine neuen Umfänge, keine Optimierungen mehr. Implementierung: fließender Übergang, von hinten geplant und so spät wie möglich gestartet, damit Erkenntnisse aus der Validierung nichts umwerfen. Die Lektion: Der Ersatz muss vor der Streichung da sein. Wer die Flotte streicht, streicht Ehrlichkeit und Termindisziplin, solange der virtuelle Prototyp beides nicht übernehmen kann. Für wen ist diese Episode relevant? Entwicklungs- und Projektleiter, die Prototypenflotten planen und verantworten. Führungskräfte, die Zeit und Kosten in der Produktentwicklung senken müssen. Verantwortliche für Virtualisierung, Simulation und digitale Zwillinge. Prozess- und Methodenverantwortliche, die den Reifegradprozess nach VDA anwenden. Alle, die eine Transformation vorbereiten und wissen wollen, in welcher Reihenfolge sie die Schritte gehen müssen. Weitere Informationen Hardware Light Development ist das dritte der sieben Elemente des NewPDP. Das Motto lautet: virtuell vor materiell. Zu den ersten beiden Elementen, dem Drum Beat System und den Learning Standard Routines, gibt es eigene Episoden. Zum universellen 4 Takt Zyklus und zum Granatapfelbaum-Modell gibt es ebenfalls eine eigene Episode. Die Reifegradphasen A, B, C, D des VDA sind in einem eigenen Artikel erklärt: https://uwemierisch.substack.com/p/from-concept-to-bestseller-how-products (https://uwemierisch.substack.com/p/from-concept-to-bestseller-how-products) In den nächsten Wochen folgen Episoden zur vollständigen Beschreibung der Ausgangssituation und zu den Methoden der Definitionsphase. Hashtags #HardwareLightDevelopment (#HardwareLightDevelopment) #NewPDP (#NewPDP) #Produktentwicklung (#Produktentwicklung) #VirtuellePrototypen (#VirtuellePrototypen) #Simulation (#Simulation) #Prototypen (#Prototypen) #Reifegrad (#Reifegrad) #VDA (#VDA) #SystemsEngineering (#SystemsEngineering) #Fahrzeugentwicklung (#Fahrzeugentwicklung) #DigitalerZwilling (#DigitalerZwilling) #LeanDevelopment (#LeanDevelopment) Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

5. 

   14 Sept 2026

   Learning Standard Routines, in drei Schritten zu Perfektion

   Episode-Beschreibung „Andere entwickeln komplett neue Fahrzeuge in 48 Monaten. Finde heraus, wie das geht, und führe es bei uns ein." Dieser Auftrag führte mich zu einer Erkenntnis, die mich selbst überrascht hat: Für ein komplett neues Fahrzeug in 48 Monaten gibt es genau eine mögliche Vorgehensweise. Eine einzige. Wenn das aber so ist, dann kann man sie aufschreiben und immer wieder anwenden. Daraus entstehen die Learning Standard Routines, das zweite Element des NewPDP. Nicht der Inhalt definiert das Projekt, sondern die Zeit. Und was stabil und wiederholbar ist, wird nicht jedes Mal neu erfunden, sondern standardisiert, kontinuierlich verbessert und von zugeordneten Experten erledigt. In drei Schritten zur Perfektion: Templates, standardisierte Prozesse, zugeordnete Experten. Und am Ende die Frage, was das alles mit KI zu tun hat. Die Antwort fällt anders aus als erwartet. Inhalt der Episode Zwei Wirkprinzipien stehen hinter allem: Standardisierung ermöglicht Verbesserung, und Fokus schafft Professionalität. Für einen festen Zeitraum gibt es nur eine sinnvolle Vorgehensweise. Diese wird aufgeschrieben und immer wieder anwenden. Umkehr der Planungslogik: Nicht der Inhalt definiert das Projekt, sondern die Zeit. Zeit und Geld stehen zuerst fest, der Inhalt wird passend dazu ausgewählt. Standardvorlagen statt Einzelfallplanung: Mit jedem Durchlauf sinkt die Fehlerwahrscheinlichkeit, steigt die Liefertreue und wächst der realisierbare Inhalt. Der Zeitplan wird nicht mehr verhandelt, sondern angewandt. Zweigeteiltes Vorgehen: Volatiles wird kurzzyklisch und situationsbezogen entschieden, Stabiles wird standardisiert und kontinuierlich verbessert. Ein hybrides System aus agilen und klassischen Prinzipien. Ebene 1, Projekt- und ITEM-Templates: ein Katalog von Zeitvorgaben, zum Beispiel 48, 36, 24 und 12 Monate. Ein Template ist ein Gerippe, kein Masterplan. Es enthält, was zum Erreichen der Zeitvorgabe nötig ist, und nichts weiter. Die Feinplanung bleibt beim Drum Beat. Ebene 2, standardisierte Prozesse: aus den Templates herausgelöst und eigenständig gepflegt. Aufnahmekriterium ist wiederholtes Auftreten bei stabilem Umfeld. Fehlt eines von beidem, gehört der Ablauf ins Drum Beat System. Abgrenzung zum Agilen: Agil standardisiert den Meta-Prozess und lässt den Fachprozess offen. Im hybriden System standardisieren wir beides. Wiederholbare Fachprozesse jedes Mal neu zu erfinden ist keine Anpassungsfähigkeit, sondern Verschwendung. Ohne Standard kein KVP. Der Standard ist verbindlich, aber nicht endgültig. Weiterentwickelt wird er von denen, die mit ihm arbeiten. Ebene 3, zugeordnete Experten: feste Gruppen für einen oder mehrere Standardprozesse, idealerweise in eigenen Organisationseinheiten. Wiederholung erzeugt Professionalität. Der Abbau von Expertengruppen ist eine Scheineinsparung. Die Stelle verschwindet, die Arbeit nicht. Sie wandert zu Laien, und der Mehraufwand taucht in keinem Budget auf. Ebene 3 dreht das um und macht die Arbeit wieder sichtbar. Zuordnung und Dokument gehören zusammen: Die Zuordnung der Mitarbeiter erzeugt die Verbesserung, das Prozessdokument sichert sie ab. Keine der beiden Hälften funktioniert allein. KI-Assistent: Die Standardroutinen liefern die Datenbasis. Der Assistent senkt die Hürde, den passenden Standard zu finden und anzuwenden, und macht Lessons Learned praktikabel. KI-Agent: dokumentiert, immer gleich ablaufend, einer festen Gruppe zugeordnet. Das sind genau die Bedingungen, unter denen KI einen Ablauf vollständig übernehmen kann. Die Reihenfolge ist entscheidend: erst der Standard, dann die Automatisierung. Wer es umgekehrt versucht, automatisiert das Chaos. Für wen ist diese Episode relevant? Entwicklungs- und Projektleiter. Führungskräfte, die Effizienz in den Projekten und Abläufen schaffen wollen. Prozess- und Methodenverantwortliche. Alle, die KI in der Produktentwicklung einsetzen wollen und sich fragen, wie das geht. Organisationen, die agile und klassische Prinzipien nicht gegeneinander ausspielen wollen Weitere Informationen Die Learning Standard Routines sind das zweite der sieben Elemente des NewPDP. Sie bauen auf dem Drum Beat System auf, zu dem es eine eigene Episode gibt. In den nächsten Wochen folgen Episoden über die weiteren Elemente. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

6. 

   31 Aug 2026

   Das Drum Beat System produziert Innovationen.

   „Warum schlagen die mir das alles zur Entscheidung vor, wenn sie es dann doch nicht schaffen?" und gleichzeitig: „Wenn der Chef nicht weiß, was wichtig ist, dann mache ich eben irgendwas." Beide Sätze hat Uwe Mierisch gedacht. In derselben Firma, zur selben Zeit, in zwei Rollen. Aus diesem Dilemma ist das Drum Beat System entstanden — das erste Element des NewPDP. Innovationen entstehen nicht durch Eingebung. Innovationen zu entwickeln ist Handwerk, das man lernen kann und muss. Und deshalb funktionieren viele Methoden aus der Produktion auch in der Entwicklung. Diese Episode beschreibt das Problem, bevor sie die Lösung beschreibt: das Auftragsdauerfeuer, die Illusion der Priorisierungsliste und warum kein Chef diese Entscheidung allein treffen kann. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

7. 

   17 Aug 2026

   NewPDP - Mehr Entwickeln ohne mehr zu brauchen.

   Episode-Beschreibung „Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg." — dieser Satz fiel im Hinterhof eines italienischen Restaurants in Untertürkheim. Er ist der Anlass für diese Episode. Uwe Mierisch gibt den Überblick über den NewPDP, ein Entwicklungsmodell für mechatronische Produkte: vier Arbeitsweisen, drei Voraussetzungen, vier Jahre Arbeit. Warum jedes einzelne Element gebraucht wird, in welcher Reihenfolge es drankommt — und warum nichts davon weggelassen werden kann. Der Auftrag der Old Economy ist unbequem: heute Rendite liefern und gleichzeitig die Zukunft finanzieren. Mehr entwickeln ohne mehr zu brauchen. Themen dieser Episode Das doppelte Problem: Wir sind nicht nur zu langsam — wir fangen auch zu spät an. Langsamkeit lässt sich bekämpfen, verlorene Zeit nicht zurückholen Der Sandsack der Old Economy: Warum Wettbewerber ohne Profitabilitätsdruck einen strukturellen Vorteil haben — und welche Vorteile dagegen stehen Der Aufbau des NewPDP: Vier Practices (Arbeitsweisen) in bewusster Reihenfolge, drei Enablers (Voraussetzungen) parallel Drum Beat System (DBS) — Im Takt zusammenarbeiten: Das fehlende Wort für den Zeitraum zwischen den Quality Gates. Granatapfelbaum-Modell und universeller 4-Takt-Zyklus. Die eine Regel: Ein Drum Beat wird nie gedehnt Learning Standard Routines (LSR) — Fokus schafft Professionalität: Können entsteht durch Wiederholung. Warum das nur zur Hälfte Taylorismus ist Hardware Light Development (HLD) — Virtuell vor materiell: Nicht Hardware abschaffen, sondern mit minimalstem Hardwareeinsatz dieselbe Qualität erreichen Predictive Technology Readiness (PTR) — Reif, wenn es gebraucht wird: Zu spät entscheiden ist teuer, zu früh investieren erzeugt Bestand. Und Bestand verdirbt Leadership (L) — Klare Richtung, ein Team: Führung heißt mitarbeiten. Wer nur entscheidet, führt nicht Organisation (O) — Struktur folgt dem System: Die Matrix überlebt keine dritte Achse. Welches Prinzip führt künftig? Architektur (A) — Modularer Fortschritt: Was die Hardware von der objektorientierten Programmierung noch lernen muss Warum nichts weggelassen wird: Die sieben Elemente stehen nicht nebeneinander, sie greifen ineinander Key Takeaways ✓ Zu spät anfangen ist schlimmer als zu langsam sein — vergangene Zeit holt niemand zurück ✓ Der Auftrag lautet: mehr entwickeln ohne mehr zu brauchen. Das geht nur mit grundlegender Transformation ✓ Priorisiere die Themen mit dem höchsten Wertzuwachs jetzt — und die mit dem größten Wertverlust, wenn sie liegen bleiben ✓ Der Drum Beat ist der Schmierstoff für alles andere. Darum kommt er zuerst ✓ Ein Drum Beat wird nie gedehnt. Sonst verhandeln wir wieder Termine statt Inhalte ✓ Man kann mit einem Element anfangen — man muss sogar. Aber mit einem allein kommt man nicht ans Ziel Für wen ist diese Episode relevant? Führungskräfte und Manager in der Produktentwicklung mechatronischer Produkte Alle, die vor einer Transformation ihres Entwicklungssystems stehen Prozess- und Methodenverantwortliche, die über Quality Gates hinausdenken wollen Systems Engineers, die um die Rolle der Funktionalität in der Organisation ringen Unternehmen der Old Economy im Wettbewerb mit Start-ups und geförderten Playern Weitere Informationen In den nächsten Wochen nimmt Uwe Mierisch jedes der sieben Elemente einzeln auseinander. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Welches der sieben Elemente ist in Ihrer Organisation das größte Problem? Und welches wäre am schnellsten zu haben? Schreiben Sie es in die Kommentare oder direkt als Nachricht. Hashtags #NewPDP #Produktentwicklung #DrumBeat #Transformation #SystemsEngineering #HardwareLightDevelopment #TechnologyReadiness #Leadership #Organisation #Architektur #Mechatronik #Effizienz Verwandt: [[P11 - NewPDP]] · [[NewPDP - Drum Beat System (DBS)]] · [[NewPDP - Learning Standard Routines (LSR)]] · [[NewPDP - Hardware Light Development (HLD)]] · [[NewPDP - Predictive Technology Readiness (PTR)]] · [[NewPDP - Enabler Führung]] · [[NewPDP - Enabler Organisation]] · [[NewPDP - Enabler Architektur]] · [[Show Notes - Der blinde Fleck]] Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

8. 

   3 Aug 2026

   Der blinde Fleck: Wirkungsgrad in der Wissensarbeit

   Effizienz in der Wissensarbeit ist ein blinder Fleck. Warum können Ingenieure den Wirkungsgrad einer Maschine präzise messen und optimieren, während Manager in der Entwicklung völlig im Dunkeln tappen? In dieser Episode erklärt Uwe Mierisch, wie die beiden Modelle Granatapfelbaum-Modell und Universeller 4-Takt-Zyklus Effizienz und Effektivität in Organisationen messbar und steuerbar machen. Ein Ingenieur-Ansatz für das Management: Struktur statt Glück. Erfolg, der reproduzierbar ist. Themen dieser Episode Wirkungsgrad: Der grundlegende Begriff aus dem Ingenieurwesen und seine Anwendung auf Wissensarbeit Effizienz vs. Effektivität: Der kritische Unterschied zwischen "die richtigen Dinge tun" und "Dinge richtig tun" Das Granatapfelbaum-Modell: Wie man die Effektivität in einer Organisation erhöht durch bewusste Priorisierung Der Universelle 4-Takt-Zyklus (DCVI): Die Methode, um Fehler zu vermeiden und effizienter zu arbeiten Das Zusammenspiel: Warum beide Modelle zusammen funktionieren und sich gegenseitig verstärken Ressourcen-Management: Wann und wie man Ressourcen wirklich reduzieren kann Arbeitskultur & Systeme: Warum Logik allein nicht reicht — es braucht implementierte Systeme und Gewohnheiten Key Takeaways ✓ Effizienz und Effektivität sind zwei verschiedene Fragen — beides ist notwendig für Erfolg ✓ Das Granatapfelbaum-Modell schafft Transparenz über alle Aktivitäten einer Organisation ✓ Der 4-Takt-Zyklus reduziert systematisch Fehler und unnötige Schleifen ✓ Zusammen schaffen die Modelle Struktur, die Erfolg reproduzierbar macht ✓ Erfolg ist kein Glück — es ist ein System, das implementiert werden kann Für wen ist diese Episode relevant? Manager und Führungskräfte in Entwicklung, Innovation und indirekten Bereichen Produktleiter, die ihre Teams effizienter machen wollen Organisationen, die zwischen Chaos und Überplanung stecken Alle, die lernen wollen, wie Engineering-Prinzipien im Management funktionieren Unternehmer und Geschäftsführer, die ihre Ressourcen optimal nutzen wollen Weitere Informationen Dieser Podcast basiert auf einer Serie von Artikeln und tiefer gehenden Analysen zum Thema Wirkungsgrad in der Wissensarbeit. Mehr über die beiden Modelle erfahren Sie in den erweiterten Artikeln zum Granatapfelbaum-Modell und zum Universellen 4-Takt-Zyklus. Hashtags #Effizienz (#Effizienz) #Effektivität (#Effektivität) #Wirkungsgrad (#Wirkungsgrad) #Wissensarbeit (#Wissensarbeit) #Management (#Management) #Produktentwicklung (#Produktentwicklung) #Leadership (#Leadership) #Organisation (#Organisation) #SystemsThinking (#SystemsThinking) #Engineering (#Engineering) #Produktmanagement (#Produktmanagement) Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

9. 

   13 Jul 2026

   Der universelle Viertakt-Zyklus - DCVI

   Der universelle Viertakt-Zyklus In dieser Folge stelle ich ein Prinzip vor, das ich seit vielen Jahren in Projekten jeder Größenordnung einsetze: den universellen Viertakt-Zyklus, kurz DCVI. Es beschreibt vier Phasen, die jedes Projekt und jede Aufgabe strukturell tragen, egal ob in der Produktentwicklung, in der Organisation, bei Kostensenkung oder im ganz normalen Alltag. Die vier Phasen: Definition: Klarheit schaffen, bevor die eigentliche Arbeit beginnt. Was ist gegeben, was wird gesucht, welche Voraussetzungen müssen erst geschaffen werden, und vor allem: Wie soll das Ergebnis am Ende aussehen und für wen? Diese Phase wird am häufigsten abgekürzt, dabei zahlt sich Sorgfalt hier besonders aus. Creation: Die Lösung wird Schritt für Schritt entwickelt. Schleifen und mehrere Anläufe sind hier ausdrücklich erlaubt und gehören dazu, ebenso wie enge Teamarbeit statt Alleingänge. Validierung: Der Beweis, dass die Lösung unter realen Bedingungen tatsächlich funktioniert. Änderungen sind an dieser Stelle nur noch erlaubt, um echte Probleme zu beheben, nicht mehr um zu optimieren. Umsetzung: Das Ergebnis wird in die Realität geliefert. Eine Lösung zählt erst, wenn sie bei den Menschen ankommt, die sie brauchen, und dort auch wirkt. Kernaussage: Mit diesem Prinzip wird Erfolg keine Frage von Glück, sondern etwas, das sich gezielt steuern lässt. Das erfordert allerdings Übung und konsequente Anwendung, kein einmaliges Abhaken der vier Phasen. Nächste Folge: Wie der universelle Viertakt-Zyklus und das Granatapfelbaum-Modell als komplettes System zusammenwirken. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

10. 

    15 Jun 2026

    Der Tag an dem ich das Shop Floor Management abgeschafft habe.

    ToDo Management – Die vierte Ebene des Granatapfel-Baum-Modells Zusammenfassung Shopfloor Management ist kein Nice-to-have. Das lernte ich auf die schmerzhafteste Art. Vor Jahren – es wird mir nicht leicht, das zuzugeben – traf ich eine Entscheidung, von der ich genau wusste, dass sie falsch war. Und ich tat sie trotzdem. In dieser Episode erzähle ich Ihnen, warum ein ganzes Unternehmen in die Krise läuft, wenn man sein Shopfloor-Team streicht. Und warum ToDo Management – die unterste, konkreteste Ebene des Granatapfel-Baum-Modells – das Fundament ist, auf dem alles andere ruht. Hier entstehen die Ergebnisse. Hier wird der Wert generiert. Hier, in den Fruchtkernern des Granatapfels. Kapitel 00:00 – Einstieg Die Geschichte der falschen Entscheidung und ihre Konsequenzen 05:30 – Die Lehre aus dem Fehler Warum Shopfloor Management unersetzlich ist 08:20 – Das Granatapfel-Modell und die ToDo-Ebene Die vierte Ebene und die DCVI-Phasen 12:45 – Die fünf Regeln des ToDo-Managements Ergebnisorientierung Organisatorische Verantwortung Interdisziplinarität Ergebnisüberprüfung Methoden-Support 22:10 – Die konkrete Vorgehensweise Wie sieht es in der Praxis aus? 26:30 – Soll der Chef eingebunden sein? Transparenz und Verantwortung 29:15 – Abschluss und Call to Action Was nehmen wir heute mit? Shopfloor Management schafft die Struktur, die Ergebnisse überhaupt erst möglich macht. Es ist nicht Bürokratie, es ist Fundament. Die fünf Regeln sind nicht optional. Ergebnisorientierung, organisatorische Verantwortung, Interdisziplinarität, Ergebnisüberprüfung und echter Methoden-Support – alle fünf müssen gelten. Dedizierte Ressourcen sind essentiell. Eine Methode verschwindet, wenn man aufhört, in sie zu investieren. Das gilt auch für kleine Unternehmen. Der Manager muss wissen, wie es läuft. Nicht aus Misstrauen, sondern aus Verantwortung. Transparenz schützt alle. Jeder ist der Projektmanager seines eigenen Verantwortungsbereichs. Das bedeutet nicht alles selbst zu machen – aber sicherzustellen, dass alles organisiert ist. Weiterführende Ressourcen Granatapfel-Baum-Modell: Das Kernmodell für strukturierte Produktentwicklung Drum Beat: Die dritte Ebene des Modells (vorherige Episode) DCVI-Phasen: Definition, Creation, Validation, Implementation – der Rhythmus, der auch in ToDo Management gilt Scrum und Lean Management: Die beiden Quellen, aus denen ToDo Management schöpft Ihre nächsten Schritte Haben Sie Fragen oder eigene Erfahrungen mit ToDo Management? Schreiben Sie mir einen Kommentar hier auf Substack, schicken Sie mir eine Nachricht, oder lassen Sie uns in den Kommentaren chatten. Nicht verpassen: In der nächsten Episode gehe ich ins operative Detail und zeige Ihnen anhand meiner Datenbank, wie alles konkret funktioniert. Das ist der praktische Teil – die Vorlagen, die Struktur, die Tools. Abonnieren Sie meinen Podcast oder Newsletter, damit Sie es nicht verpassen. Falls Ihnen dieser Podcast gefällt: Empfehlen Sie ihn bitte weiter. Das ist für mich das beste Feedback, das es gibt. Vielen Dank fürs Zuhören. Ich freue mich schon, Sie bei der nächsten Episode wiederzusehen. Bis dahin: Passen Sie auf sich auf und bleiben Sie innovativ. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

11. 

    25 May 2026

    Sachen fertig machen! Das Wichtigste zuerst.

    Drum Beat – Sachen fertigmachen Aktivität ist keine Lieferung. Und Berichterstattung ist kein Ergebnis. Wer das nicht versteht, wird ewig Zwischenstände präsentieren – aber nichts fertig bekommen. Das Shop-Floor-Experiment und sein Scheitern Uwe hatte einen ungewöhnlichen KPI erfunden: die Aufgabenabarbeitungsgeschwindigkeit. Die Idee war simpel – lieber eine kleinere Aufgabe wählen und abschließen, als an einer großen ewig herumzudoktern. Das Ergebnis? Der KPI lag wie ein Fels auf dem Meeresgrund. Woche für Woche dieselben Punkte, derselbe Status: „in Arbeit." Der Fehler war nicht der KPI – sondern die fehlende Deadline. Eine Lieferung ohne fixiertes Lieferdatum ist keine Lieferung. Es ist nur eine Bestellung. Der Drum Beat: drei Monate, dann ist Schluss Der Drum Beat ist die dritte Ebene im Neuen Produktentwicklungsprozess. Wie ein Schlagzeuger, der den gleichmäßigen Takt vorgibt, setzt der Drum Beat einen festen Rhythmus: alle drei Monate werden definierte Ergebnisse geliefert – ohne Ausrede. Drei Monate sind lang genug für etwas Substanzielles und kurz genug, um relevant zu bleiben. Das Granatapfel-Modell Der NewPDP hat vier Ebenen – alle im Granatapfel sichtbar: Der Baum steht für die Programmebene, die Frucht für das einzelne Vorhaben (ITEM), die Kammern für die Drum Beats, und die Fruchtkerne für die einzelnen ToDos. Jede Ebene bricht Komplexität auf und macht sie beherrschbar. Was in den Drum Beat reinkommt – und was bewusst nicht Deliverables sind keine Aktivitäten, sondern konkrete Ergebnisse. Ausgewählt wird nach zwei Kriterien: Was bringt den größten kurzfristigen Wertzuwachs? Und was verursacht das größte Problem, wenn es jetzt nicht erledigt wird? Wichtiger als die Frage „Was machen wir?" ist: „Was machen wir bewusst nicht?" – denn nur so weiß jeder, worauf er warten kann und worauf nicht. Planung ist kein Luxus – sondern Pflicht Die Drum-Beat-Planung findet am Anfang jedes Zyklus statt, mit allen Beteiligten. Am Ende steht ein Commitment: auf die Deliverables, auf das Weggelassene und auf den Liefertermin. Wer nicht mitdenkt, wird zum Problem. Danach gilt: liefern – kein Umplanen, kein „ist mir was dazwischengekommen." Mehr von Uwe Mierisch: uwemierisch.substack.com (http://uwemierisch.substack.com) · uwemierisch.com (http://uwemierisch.com) Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

12. 

    4 May 2026

    Der Plan zeigt die Route, nicht die Reise.

    ITEM-Planung „Der Plan zeigt die Route, nicht die Reise." 🗺️ Worum geht es in dieser Episode? In dieser Episode tauchen wir eine Ebene tiefer in die Welt der Work-ITEMs ein. Während der Überblick über alle ITEMs Orientierung, Priorisierung und Verständnis von Abhängigkeiten ermöglicht, brauchen wir genau das auch innerhalb der einzelnen ITEMs. Wir schauen uns an, wie ITEMs geplant werden sollten — und warum weder zu viel noch zu wenig Planung zum Ziel führt. 🔑 Kernthemen Planung — ja oder nein? Ein höchst kontroverses Thema: Manche treiben Planung ins Extrem, andere lehnen sie als unnötige Bürokratie ab. Die Wahrheit liegt — wie so oft — in der Mitte. Was Helmuth von Moltke uns lehrt Der preußische Generalfeldmarschall und Erfinder der Auftragstaktik liefert die perfekte Denkgrundlage. Sein berühmtes Zitat: „Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus." — Keine Absage an die Planung, sondern ein Plädoyer für ihre richtige Anwendung. Aufmarsch vs. Auftragstaktik Moltke unterscheidet zwei Phasen: die präzise Vorbereitungsplanung (Aufmarsch) und die flexible Ausführung im Angesicht der Realität (Auftragstaktik). Beides übertragen wir auf modernes Projektmanagement. Die eigentliche Funktion von Planung Planung ist Vorbereitung, nicht Kontrolle. Sie liefert den theoretisch besten Ansatz und schafft die Voraussetzungen für erfolgreiche Ausführung. Je größer das ITEM, desto mehr Planung ist erforderlich. Meilensteine statt Aktivitäten Ein Plan beschreibt das Was und das Wann, nicht das Wie. Termine und Ziele bleiben stabil; der Weg bleibt flexibel. 📦 ITEM-Typen & ihre Planungslogik ITEM-Typ: Projekte Klare Fristen & Ziele, Fokus auf Meilensteine statt Aktivitäten Technologieentwicklung Größere Volatilität einplanen, kein lückenloses Anschluss-Projekt Features & Funktionen Sprint-Planung + DCVI-Meilensteine (Definition, Erstellung, Validierung, Implementierung) Kundensegmente Projektcharakter, negatives Ergebnis muss einkalkuliert sein Problemlösung Inkrementell starten, Meilensteine planbar (Ursachenanalyse → Maßnahmen → Wirksamkeit) Prozessentwicklung Analog zu Projekten, auch ohne formale Struktur mindestens mit Plan Mitarbeiterentwicklung Quartalsziele im Fokus, Langfristplan nur bei klar definierter Zielrolle 📌 Die 5 Planungsregeln Plane, um Erkenntnisse zu gewinnen – der Planungsprozess schafft das vollständige Bild Schaffe die Voraussetzungen – erst starten, wenn die Grundlagen bereit sind Halte die Richtung – Plan als Orientierung, nicht als starre Einschränkung Vertraue den Handelnden – das Wie liegt bei denen, die die Realität sehen Bewertet die Lage – Fortschritt kontinuierlich mit der Realität abgleichen 💡 Das nimmst du heute mit Planung ist notwendig — immer. Sie darf weder zu detailliert noch zu vage sein. Die richtige Balance ist entscheidend. Die Art der Planung hängt stark vom ITEM-Typ ab und muss auf den Kontext zugeschnitten sein. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

13. 

    6 Apr 2026

    Die Komplexität im Tagesgeschäft beherrschen

    Die Komplexität im Tagesgeschäft beherrschen Wie man den Überblick behält und das richtige Timing trifft. In dieser Folge zeige ich dir, wie du die wachsende Komplexität im Tagesgeschäft besser in den Griff bekommst – und gleichzeitig deinen Projekten mehr Raum gibst. Dafür führe ich einen neuen Begriff ein: das ITEM – ein Sammelbegriff für alles, was erledigt werden muss. Als Orientierungshilfe dient das Granatapfelbaum-Modell: Alles, was auf deinem Schreibtisch liegt, entspricht einem Granatapfel an einem Baum – unterschiedlich groß, unterschiedlich reif. Die wichtigsten Themen der Episode: Warum klassisches, agiles und hybrides Projektmanagement allein nicht ausreicht – und warum das wahre Leben sich nicht in Schubladen pressen lässt Was ein ITEM ist und welche Kategorien darunter fallen: Projekte, Features & Funktionen, Technologieentwicklung, Kundenapplikationen, Probleme, Prozesse und Mitarbeiterentwicklung Warum ein gemeinsames, großes Backlog für alle ITEMs mehr Transparenz schafft und bessere Priorisierung ermöglicht Wie ITEM-Management das klassische Multiprojektmanagement erweitert Warum Daten der Treibstoff für Effizienz sind – und wie eine solide Datenbasis die Voraussetzung für den sinnvollen Einsatz von KI ist Die zentrale Idee dieser Episode: Lass uns hybrides Projektmanagement nicht nur auf Projekte beschränken, sondern alles, was erledigt werden muss, in ein gemeinsames großes Backlog schreiben! Ausblick: In den nächsten Episoden zeige ich dir, wie das ITEM-Management konkret operativ umgesetzt werden kann – inklusive eines Einblicks in meine eigene Datenbank. Mach mit! Welche ITEM-Kategorien fehlen deiner Meinung nach? Schreib es in die Kommentare! Teile deine Meinung, schick mir eine Nachricht oder chatte mit mir auf Substack. Wenn dir der Podcast gefällt – empfiehl ihn weiter und abonniere ihn, damit du keine Folge verpasst! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

14. 

    23 Mar 2026

    Braucht es noch Projekte – oder sind Projekte ein alter Zopf von gestern?

    „Wenn die Software den Mehrwert des Produktes definiert" Worum geht es in dieser Episode? Die Maschinen lernen denken – und sie werden immer besser darin. Aber was bedeutet das konkret für Produkte, ihre Entwicklung und alle, die daran beteiligt sind? In dieser Episode beleuchte ich den großen Wandel, den mechatronische Produkte gerade durchlaufen, von der dominanten Mechanik, hin zu Software als zentralem Werttreiber. Und ich zeige, warum das nicht das Ende klassischer Entwicklungsmethoden bedeutet – sondern den Beginn einer neuen, parallelen Welt. Das lernst du in dieser Episode Muskeln vs. Gehirn – Wie die Mechanisierung körperlicher Arbeit die Welt verändert hat und warum die Elektronisierung kognitiver Funktionen der nächste große Sprung ist Warum Mechanik an eine Sättigung stößt – Physikalische Gesetze setzen klare Grenzen; Software hingegen steht noch ganz am Anfang Das Nervensystem der Maschine – Wie Sensoren, Mikroelektronik und Software Maschinen ein „Gehirn" geben und was das für die Systemarchitektur bedeutet Software Defined Vehicle & Co. – Was hinter diesem Begriff steckt und warum der Trend weit über die Automobilindustrie hinausgeht Parallele Entwicklungswelten – Warum es künftig sowohl hybride als auch rein agile Prozesse geben wird – und warum der klassische Ansatz nicht ausstirbt Industrie 4.0 und Maschinenkommunikation – Was passiert, wenn Maschinen in Millisekunden miteinander reden, Daten teilen und Entscheidungen synchronisieren Die 4 wichtigsten Erkenntnisse auf einen Blick Stark physische Produkte → klassischer Entwicklungsprozess bleibt das Mittel der Wahl Mechatronische Produkte (die Mehrheit) → hybride Vorgehensweise erforderlich Software Application Layer → wird zunehmend entkoppelt und agil entwickelt Vernetzte Systeme → Systems Engineering ist unabdingbar Erwähnte Konzepte & Begriffe Systems Engineering Software Defined Vehicle (SDV) Industrie 4.0 / Over-the-Air-Updates Hybride vs. agile Entwicklungsprozesse Zentralisierte Elektronik- und Softwarearchitektur Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

15. 

    29 Jan 2026

    Werden Projekte noch gebraucht oder sind sie ein altmodisches Relikt von gestern?

    Die klassische Vorgehensweise im Projektmanagement entstammt den Eigenarten und Erfordernissen bei der Entwicklung von Hardwareprodukten. Darum macht es nach wie vor Sinn, diese Vorgehensweise anzuwenden, wenn die Hardware den Schwerpunkt einer Produktentwicklung bildet. Allerdings bieten agile Projektmanagementelemente die Möglichkeit die Schwächen in der traditionellen Vorgehensweise abzustellen und damit die Entwicklung schneller und effizienter zu machen. Diese Form des hybriden Projektmanagements wird in der Zukunft bei Hardwareentwicklungsprojekten den Standard bilden. Hören sie in dieser Episode warum. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

16. 

    12 Jan 2026

    Transformation oder Untergang: Produktentwicklung neu gedacht

    Transformation oder Untergang: Produktentwicklung neu gedacht Die Welt wartet nicht darauf, dass wir unsere alten Arbeitsweisen bequem optimieren. Während neue Akteure aus Asien den Markt radikal verändern, müssen wir in Europa und Nordamerika unsere Wettbewerbsfähigkeit durch drastische Veränderungen sichern, um nicht "die Entwicklungsländer von morgen" zu werden. In dieser Episode stelle ich den NewPDP (New Product Development Process) vor – ein Framework, das auf aktuellen Marktstudien und 30 Jahren Praxiserfahrung basiert, um Entwicklungsprozesse auf Geschwindigkeit, Effizienz und Zukunftssicherheit zu trimmen. Die Kerninhalte dieser Folge: Der NewPDP: Warum wir keine schrittweise Evolution, sondern einen radikal neuen Prozess brauchen. 4 Säulen der Transformation: * Zusammenarbeit (Drum Beat): Wie wir durch Synchronisation einen maximalen „Wirkungsgrad“ menschlicher Energie erreichen. Prozesse (Evolving Standard Procedures): Warum konsequente Standardisierung die Basis für Geschwindigkeit ist. Technologie (Proaktive Technologiereifung): Der intelligente Umgang mit KI und Elektrifizierung Werkzeuge (Hardware Light Development): Die gigantischen Effizienzsprünge durch virtuelle Prototypen und das Metaverse. 3 Katalysatoren: Warum neue Organisationsformen, moderne Führung und Software-zentrierte Produktarchitekturen unverzichtbar sind. Kapitelmarken (Time-Stamps): 00:26 – Die industrielle Vorherrschaft des Westens bröckelt. 01:53 – Die Entstehung des NewPDP aus der Praxis. 04:48 – Säule 1: Zusammenarbeit & der „Drum Beat“. 06:39 – Säule 2: Prozesse & Standardisierung 08:38 – Säule 3: Proaktive Technologiereifung. 11:19 – Säule 4: Hardware Light Development. 13:08 – Die Katalysatoren: Organisation, Führung und Architektur 17:34 – Ausblick und Einladung zum Austausch. Diskutieren Sie mit! Der NewPDP ist ein lebendes Framework. Ich lade Sie herzlich ein, Ihre Perspektiven, kritischen Meinungen oder Fragen in den Kommentaren auf Substack zu teilen oder mir eine persönliche Nachricht zu schicken. Abonnieren Sie diesen Podcast, um keine der kommenden Detail-Folgen zu den einzelnen Transformationsfeldern zu verpassen. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe (https://uwemierisch.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

Contact Der Produktentwickler - Podcast

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.