Warum PMs und UX ab einer gewissen Größe klare Spuren brauchen – und warum Generalisten trotzdem wichtig sind
„Schnitzel • Döner • Sushi.“ Wenn dein Organigramm sich so liest wie diese Speisekarte, dann wahrscheinlich auch dein Produkt.
Fairerweise: Vielfalt ist nicht die Sünde – fehlende Köche sind es. Mich beunruhigt Döner-Schnitzel-Sushi als Kombi weniger als die Frage, ob der Laden von einem PM oder TikTok-Influencer geführt wird statt von echten Köchen. Trotzdem: Wenn eine Karte 27 verschiedene „Specials“ hat, schlagen meine Risikosensoren an.
These. PMs optimieren Warum/Was/Wann fürs Business; UX optimiert das Wie für Menschen. Wer diese Perspektiven in großen Orgs zusammenfallen lässt, bekommt Politik statt Zusammenarbeit. In kleinen Teams kann dasselbe Zusammenfallen produktiv sein – wenn man es bewusst macht.
Hey there! 👋 I'm Phil, and I love sharing my thoughts on innovation, design, and the future of technology.
Join my newsletter for insights on innovation, design, and the future of technology—straight to your inbox.
Persönliche Anmerkung. Mein Werdegang verbindet UX, Code, Daten und Mobilität. Diese Mischung führt dazu, dass mein Input früh gefragt ist – vom Problem-Framing mit PMs bis zum Stresstest der Machbarkeit mit Engineers. Es geht nicht darum, jede Spur zu besitzen; es geht darum, die Konsequenzen über alle hinweg zu kennen.
Ja, Rollen sind wichtig. Genauso wahr: Indie Hacker bringen echte Produkte und echten Umsatz an den Start – mit einem Gehirn und strengen Constraints. Denk an einen Foodtruck – nicht an ein Buffet.
Googles Project Aristotle hebt Struktur & Klarheit als zentrale Zutat effektiver Teams hervor – klare Verantwortung dafür, wer was macht und wie Erfolg gemessen wird. Das ist kein Gedöns; das ist operative Hygiene. (Genauer gesagt: Google nennt psychologische Sicherheit als wichtigsten Faktor; Struktur & Klarheit ist einer von fünf – aber der, den Organisationsdesign am direktesten steuert.) Quelle:re:Work by Google - Project Aristotle
Adam Smiths Stecknadelfabrik ist die Ur-Fallstudie zur Spezialisierung: Arbeitsteilung vervielfacht den Durchsatz. Im Produktkontext heißt das: PMs rahmen Probleme und Wetten, UX verantwortet evidenzbasiertes Design, Engineering verantwortet Machbarkeit/Qualität – enge Schleifen, saubere Übergaben. Quelle:Der Wohlstand der Nationen (1776)
Conways Gesetz: Produkte spiegeln die Kommunikation der Organisation. Schwammige Schnittstellen zwischen Rollen → schwammige Produktarchitektur. Quelle: Melvin Conway, „How Do Committees Invent?“ (1968)
Escoffiers Brigade de Cuisine zeigt, warum Posten und klare Rollen eine Küche schnell und sicher machen.
„Wir machen keinen Prozess, wir viben.“ Übersetzung: Wer am lautesten ist, shippt zuerst. Eine Silent Disco, deren Soundtrack Jira ist.
Rollen abzulehnen schafft keine Gleichheit; es schafft versteckte Hierarchien. Jo Freeman nannte das die Tyrannei der Strukturlosigkeit: Unklare Autorität lädt zu informeller Macht und Entscheidungen des geringsten Widerstands ein. Auf Produkt übertragen: Wenn PM und UX „wer halt gerade da ist“ sind, shippst du die lauteste Idee, nicht die beste. Quelle:Jo Freeman - The Tyranny of Structurelessness
IDEO hat T-shaped Talente populär gemacht – Tiefe in einem Bereich, Breite in anderen. Kent Beck erweitert das um „Paint-Drip People“: Mit der Zeit bilden sich mehrere Tropfen an Tiefe. In Startups und kreativen Labs gedeihen diese Profile, weil Constraints ständiges Hutwechseln verlangen. In Konzernen zählen sie weiterhin – nur eben innerhalb klarer Schnittstellen. Quellen: IDEO zu T-shaped Talent; Kent Beck, „Paint-Drip People“
Drei glänzende Farbtropfen in Petrol, Magenta und Orange, eine Anspielung auf Paint-Drip People
Notiz aus der Praxis. Weil ich sowohl den Designer- als auch den Engineer-Hut trage, konnte ich funktionierende Prototypen in Tagen statt Wochen liefern – Design Systems mit echten Daten verdrahtet, KI-gestützte Flows und echte APIs. Diese Geschwindigkeit schafft Vertrauen, aber nur in Kombination mit einem Ritual, das Exploration von Commitment trennt.
KI sind vier Praktikanten in einem Trenchcoat. Großartig für Entwürfe – furchtbar als CEO.
„Wenn ich mit ChatGPT rede, gebe ich ihm nicht immer ein Label – aber es funktioniert trotzdem als PM, Developer, Designer und Coach für mich.“
GenAI macht Cross-Funktionalität billiger. Ein PM kann prototypen; eine Designerin kann Daten abfragen; ein Engineer kann Werthypothesen testen – schneller. Das Risiko ist Bias-by-Prototype: Eine schnelle KI-Skizze tarnt sich als Strategie und verankert Entscheidungen. Nutze KI zum Erkunden, nicht zum Vorentscheiden. Behalte das Ritual bei, das Ideen von Commitments trennt.
Wie ich heute arbeite. Ich fahre einen parallelen Konzept-Track mit einem Coding-Agenten (Claude Code) direkt im echten Repo, mit halbwegs echten Daten (kein Lorem Ipsum), Erkenntnissen aus Research/Benchmarks und expliziten Constraints, aufgeschrieben als Vertrag, den der Agent erfüllen muss – mehr dazu in ein Skript, elf Sprachen. So habe ich schnell ein laufendes Frontend, sodass FE/BE-Probleme früh auftauchen. Ich iteriere, bis die ersten ~80 % „gut genug“ sind, und investiere die letzten 20 % in Marke, Interaktion und Barrierefreiheit.
Ich nenne das scherzhaft den „Creative AI Director“-Modus: voller wilder, spannender Konzepte – aber wie jeder übermotivierte Praktikant braucht er trotzdem Eingriffe, Dinge, die aufgeschrieben werden, und Gespräche mit echten Nutzern
KI-Beschleunigung, neue Risiken:
Halluzinationen/Bias: Outputs als Hypothesen behandeln; mit Nutzern und Daten validieren.
Security: Geschwindigkeit ist der Feind von Qualität; Security ist ein Kind der Qualität. Ein menschliches Code-Review im Loop behalten.
Meine Haltung: Ich kann die Codebase über FE/BE hinweg tragen, aber ich bin kein Security-Schwarzgurt – also baue ich ein leichtgewichtiges Threat Model, Dependency-Scans, ein Review von Auth/Rollen und einen OWASP-Top-10-Stichprobencheck ein, bevor ich etwas „fertig“ nenne.
Ein Laufband mit Kanban-Board. „Wir haben 18 Karten geshippt!“ Cool – hat eine davon eine Metrik bewegt?
Wenn PMs „Vibe-Design“ betreiben und Designer zu Auftragsannehmern werden, driften Teams in Feature Factories ab – sie shippen Output, ohne zu lernen. Der Notausgang: Outcomes messen, Pre-Mortems machen und Discovery am Leben halten. Weiterlesen: John Cutler, „Feature Factory“ (Cutlefish Substack)
Montesquieu argumentierte, Freiheit sei geschützt, wenn sich Gewalten gegenseitig kontrollieren und ausbalancieren. Produktorganisationen sind keine Staaten, aber die Analogie trägt: PM (Agenda/Priorität), UX (Evidenz/Erlebnis) und Eng (Machbarkeit/Qualität) kontrollieren und balancieren sich gegenseitig. Zentralisiere alle Macht – und die Fehler konzentrieren sich gleich mit. Quelle:Vom Geist der Gesetze (1748)
Historischer Rückgriff. Der „Mailbox“-Fix bei Apollo 13 funktionierte, weil Mission Control klare Entscheidungsrechte, enge Feedbackschleifen und disziplinübergreifendes Vertrauen hatte – ein Beleg dafür, dass Struktur und Zusammenarbeit unter Stress Missionen retten.
Microservices + Feature-Teams: Cross-funktionale Squads verantworten Services End-to-End; modulare Organisationen shippen tendenziell modulare Systeme (im Sinne von Conway).
Cross-funktionale Teams in komplexen Domänen (z. B. Automotive/Embedded) haben die Integrationszeit verkürzt, indem sie von isolierten Komponenten zu Feature-Ownership gewechselt sind. Weniger Übergaben; weniger Überraschungen.
Titel sind Theater; Ergebnisse sind das Abendessen. Menschen sind vielfältig: Dieselbe Person kann montags PM sein, dienstags Moderatorin und samstags Fahrradmechanikerin.
Hätte ich vor 100, 1.000 oder 1.000.000 Jahren gelebt, hätte ich wahrscheinlich das Lager organisiert, Routen kartiert oder einen Kajakverleih betrieben – Erlebnisse im menschlichen Maßstab gestaltet und davon gelebt. Die Werkzeuge ändern sich; das Handwerk bleibt: Rahmenbedingungen setzen, Reibung reduzieren und Menschen helfen, eine gute Zeit zu haben (und sicher nach Hause zu kommen).
Viele Teams stellen dieser Tage „UX Engineers“/„Design Engineers“ ein – oder verlangen zumindest eine lange Zutatenliste. Designen können und dabei eine enge Feedbackschleife mit Frontends und APIs halten. Das ist eine pragmatische Brücke: jemand, der versteht, wie Design Tokens, Komponentenzustände, Performance-Budgets und API-Strukturen die gelebte UX beeinflussen.
Schreibt den Kollaborationsvertrag. Eine Seite dazu, wer was verantwortet, Entscheidungsrechte und Eskalationswege. RACI/DACI sparsam, aber explizit nutzen. Einstieg:RACI matrix - Atlassian
Trefft euch in der Mitte – bei den Erkenntnissen. PM bringt Geschäftsmodell + Wetten; UX bringt Verhaltensevidenz + Usability-Risiko; Eng bringt Lieferrisiko + Architekturoptionen. Gemeinsam entscheiden, getrennt verantworten. Einstieg: NN/g zu PM vs. UX responsibilities
Schützt euch vor Bias-by-Prototype. KI-Entwürfe und PM-Mockups als Hypothesen behandeln. Exploration zeitlich begrenzen; testen, bevor ihr euch festlegt.
Wählt eine Küche. Seid die Ramen-Bar, nicht „Schnitzel–Döner–Sushi“. Teams mit klarem Wertversprechen und sauberen Rollenschnittstellen servieren besseres Essen – und weniger Bauchschmerzen. Kein rohes Schweinefleisch mit Sojasoße.
Zur Klarstellung: Vielfalt ist okay, wenn es echte Köche und Mise en Place gibt; das Warnsignal sind Influencer-Karten mit Dutzenden einmaliger Specials und keinem Küchenhandwerk.
Benennt die Brücke. Wenn ihr auf ein UX-Engineer-/Design-Engineer-Muster setzt, schreibt den Vertrag: wo sie mit wem pairen (PM, UX, Eng), ihre Entscheidungsrechte und die Übergabe zurück in die Craft-Spuren.
Spart nicht an Security-Basics. Schnelles Threat Model, Dependencies scannen, Auth/Rollen prüfen – einen Spezialisten holen, wenn viel auf dem Spiel steht.
In der Mitte treffen – bei den Erkenntnissen, nicht in der Fritteuse.
Große Orgs: starke Spuren, geteilter Kontext, explizite Entscheidungs-Frameworks.
Kleine Teams/Indie: Foodtruck-Energie. Den Stack End-to-End verantworten, aber Constraints, eine einzige KPI und ein Ritual behalten, das Ideen von Commitments trennt. KI-Agenten für Entwürfe nutzen; Geschmack und Handwerk in die letzten 20 % stecken.
So oder so: Klarheit schlägt Vibes. Wenn sich PM und UX in der Mitte bei den Erkenntnissen treffen (nicht bei der Ownership), bekommst du Tempo, Kreativität und Umsetzung. Wenn Spuren ohne Absicht verschwimmen, bekommst du Politik – und ein Produkt, das niemandem wirklich gehört.
Verwandt: Methods over tools – Überspezialisierung und Tool-Besessenheit entfernen Teams von den Grundlagen. Je größer und nischiger das Team, desto wichtiger wird ein sauberer Informationsfluss, damit jede Person ihren Teil des Produkts wirklich verantworten kann.
Fun Fact: Neulich war ich in Lwiw, Ukraine. Dort gibt es Sushi-Kebab – und er war köstlich
Schaufenster des Royal Kebab in Lwiw, das Sushi-Kebab mit Lachs oder Garnelen bewirbt
