Der Produktentwickler - Podcast

Der deutsche Podcast zum englischen Newsletter von Uwe Mierisch

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

Folgen

  1. vor 9 Std.

    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

    16 Min.
  2. 25. Mai

    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 · uwemierisch.com Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

    12 Min.
  3. 4. Mai

    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

    24 Min.
  4. 6. Apr.

    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

    16 Min.
  5. 23. März

    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

    15 Min.
  6. 5. März

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

    Braucht es noch Projekte – oder sind Projekte ein alter Zopf von gestern? In dieser Episode geht Uwe Mierisch dem großen Dilemma der Mechatronikentwicklung auf den Grund: klassisches Projektmanagement auf der einen Seite, agile Methoden auf der anderen. Anhand einer typischen – und schmerzhaft vertrauten – Geschichte aus der Fahrzeugentwicklung zeigt er, warum weder der rein klassische noch der rein agile Ansatz für mechatronische Produkte funktioniert, und was stattdessen die Lösung ist. Das lernst du in dieser Episode: Warum mechatronische Projekte immer wieder in die gleiche Stressfalle tappen Was ein mechatronisches Produkt grundlegend von rein mechanischen oder rein digitalen Produkten unterscheidet Warum klassisches Projektmanagement in der Mechatronik strukturell scheitert Warum rein agiles Arbeiten ebenfalls keine Lösung ist – und wo es seine Grenzen hat Welche zwei konkreten Merkmale der Hardwareentwicklung ein rein agiles Vorgehen verhindern Wie das hybride Modell des New PDP funktioniert und aus welchen vier Ebenen es besteht Warum die Umsetzung des New PDP eine klare Führungsaufgabe ist Inhalt der Episode Das typische Szenario (ca. Min. 0–5) Uwe schildert den klassischen Ablauf eines Fahrzeugprojekts: monatelange Verhandlungen, ein zusammengestauchter Zeitplan, teure Hardware-Prototypen – und dann der Schock, wenn das Fahrzeug nicht fährt, weil die Software nicht fertig ist. Die darauffolgende Heldenphase kurz vor dem Serienanlauf, in der alle zusammenrücken und die Krise mit letzter Kraft abwenden, ist symptomatisch für eine strukturell fehlerhafte Vorgehensweise. Was ist ein mechatronisches Produkt? (ca. Min. 5–8) Hardware und Software sind untrennbar miteinander verbunden. Erst gemeinsam liefern sie den Kundennutzen. Am Beispiel des modernen LKW – mit Systemen zur Verbrauchsoptimierung, Fahrerassistenz und Flottenmanagement – wird deutlich, warum solche Produkte ohne Software schlicht nicht mehr denkbar sind. Warum klassisches Projektmanagement nicht ausreicht (ca. Min. 8–11) Das sequenzielle Aneinanderreihen von Hardware- und Softwareentwicklungsphasen führt zu Projektzeitplänen, die wirtschaftlich unrealistisch sind. Die Folge: Pläne werden gestaucht, was kein echtes Projektmanagement mehr ist – und dessen Erfolg von Zufall abhängt. Warum rein agiles Vorgehen ebenfalls scheitert (ca. Min. 11–14) Zwei grundlegende Merkmale der Hardwareentwicklung verhindern ein rein agiles Arbeiten: Hardware ist nur eingeschränkt inkrementell entwickelbar – ein halbfertiges Produkt kann nicht an Kunden übergeben werden. Hardwareentwicklung braucht langfristige Planung – Fertigungseinrichtungen, Werkzeuge, Validierungsumgebungen (Sommer/Winter-Tests, geteilte Ressourcen) müssen weit im Voraus koordiniert werden. Die Lösung: Der New PDP (ca. Min. 14–17) Das hybride Modell besteht aus vier Ebenen: Programmmanagement – alle Produktveränderungen werden aufeinander abgestimmt und in einen gemeinsamen Rhythmus gebracht Projektebene – der essentielle Ablauf vom Start bis zur Kundenauslieferung mit klaren Meilensteinen Drum Beat – ein kurzzyklischer Rhythmus für Detailplanung, Ergebnisreviews und die Reaktion auf Unvorhergesehenes Wochensprint-Umsetzung – Teams erledigen Aufgaben, das Management steuert Ressourcen Der entscheidende Punkt: Führung ist gefragt (ca. Min. 17–18) Der New PDP funktioniert nur, wenn Hardware- und Softwareentwickler gemeinsam und konsequent den gesamten Prozess leben. Das ist eine Umgewöhnung für beide Seiten – und damit eine klare Führungsaufgabe. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

    19 Min.
  7. 12. Jan.

    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

    19 Min.

Info

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