Meine These: Die stärksten Produktteams bestehen nicht aus Menschen, die nur exakt das tun, was in ihrer Stellenbeschreibung steht. Sie bestehen aus Spezialisten, die Verantwortung übernehmen, Komplexität erkennen, unter Unsicherheit entscheiden und sich fehlende Fähigkeiten aneignen können, wenn das gemeinsame Ziel es verlangt.
Der Vergleich mit Navy SEALs und anderen Spezialeinheiten klingt zunächst martialisch. Deshalb ist mir die Grenze der Analogie wichtig: Es geht hier nicht um Kampf, militärische Hierarchien oder die Romantisierung gefährlicher Einsätze. Mich interessieren die Organisationsprinzipien hinter kleinen, hoch spezialisierten Teams, die unter unvollständigen Informationen funktionieren müssen, mit Abhängigkeiten umgehen, Risiken früh erkennen und trotzdem zuverlässig liefern sollen.
Genau diese Situation kennen Produktorganisationen in deutlich harmloserer Form jeden Tag. Anforderungen ändern sich. Daten fehlen. Eine technische Annahme erweist sich als falsch. Eine Deadline bleibt trotzdem bestehen. Ein neues regulatorisches Thema taucht auf. Ein zentraler Experte fällt aus. Das Produkt wird komplexer als das ursprüngliche Konzept.
Interessant ist deshalb weniger, was Spezialeinheiten können, sondern wie sie Teams aufbauen, Lernen organisieren und Verantwortung verteilen. Auf der offiziellen Navy-Seite wird die SEAL-Ausbildung aktuell mit 62 Wochen initialem Training und weiteren 18 Monaten Pre-Deployment- und Spezialtraining beschrieben. Im offiziellen SEAL Ethos stehen Sätze wie „We expect to lead and be led“ und „My training is never complete.“ Eigeninitiative, technische Kompetenz, Innovation und Aufmerksamkeit für Details sind dort ausdrücklich Teil des Selbstverständnisses.
Der Kern in 30 Sekunden
- Nicht jeder muss alles können. Aber das Team als Ganzes muss handlungsfähig bleiben.
- Mission schlägt Stellenbeschreibung. Ziele, Risiken und Erfolgskriterien müssen wichtiger sein als Übergaben zwischen Rollen.
- Lernfähigkeit ist eine Kernkompetenz. Fehlende Skills sollten nicht automatisch eine neue Abhängigkeit erzeugen.
- Reliability ist Teil von Produktqualität. Gute Teams liefern nicht nur Ideen, sondern verlässlich Ergebnisse.
- Komplexität wird aktiv gesucht. Gute Teams sehen nicht nur den Happy Path, sondern das System dahinter.
Tiefe Kompetenz in einer Disziplin bleibt entscheidend.
Das Team versteht genug voneinander, um nicht an Rollengrenzen zu scheitern.
Entscheidend ist nicht, wer zuständig ist, sondern ob das Problem gelöst wird.
1. Nicht Generalisten: adaptive Spezialisten
Ein verbreitetes Missverständnis lautet, Mitglieder von Spezialeinheiten könnten irgendwie alles. Genau das ist nicht der Punkt. Auch dort existieren tiefe Spezialisierungen, unterschiedliche Verantwortungsbereiche und Menschen mit deutlich mehr Erfahrung in bestimmten Disziplinen. Entscheidend ist etwas anderes: Spezialisierung darf nicht zu organisatorischer Hilflosigkeit führen.
Ein hoch qualifiziertes Team darf nicht zusammenbrechen, nur weil exakt die Person mit dem passenden Jobtitel gerade nicht verfügbar ist. Das gilt auch für digitale Produktteams. In vielen Organisationen sieht die Realität noch immer ungefähr so aus:
- Product versteht das Problem, kann aber technische Konsequenzen kaum einschätzen.
- Engineering kennt Architektur und Code, aber nur einen Ausschnitt des eigentlichen Kundenproblems.
- UX kennt Nutzerfluss und Interaktion, aber kaum Umsatzmodell, Produkt-KPIs oder technische Constraints.
- Analytics besitzt die Daten, sitzt aber organisatorisch weit entfernt.
- Security, Legal oder Operations werden erst kurz vor dem Release involviert.
Dann hat die Organisation viele Spezialisten – aber das Produktteam selbst besitzt keine vollständige Handlungsfähigkeit.
Ein gutes cross-funktionales Team funktioniert anders. Der Engineer muss kein UX Designer werden. Der Designer muss keinen produktionsreifen Backend-Service bauen. Der Product Manager muss nicht plötzlich Data Engineer sein. Aber alle drei sollten genug von den angrenzenden Disziplinen verstehen, um gemeinsam gute Entscheidungen zu treffen.
Was ein guter Product Designer deshalb zusätzlich verstehen sollte
- Business: Welche Kennzahl soll sich verändern? Wo entsteht wirtschaftlicher Wert?
- Engineering: Welche Konsequenzen hat eine Interaktion für Datenmodell, Performance oder technische Komplexität?
- Product: Welches Problem lösen wir eigentlich – und für wen?
- Analytics: Woran erkennen wir später, ob die Lösung funktioniert?
- Operations: Was passiert außerhalb des idealen Happy Paths?
Diese Breite ersetzt Spezialisierung nicht. Sie macht Spezialisierung wirksamer.
Genau deshalb ist die Analogie interessant: Ein autonomes Produktteam bedeutet nicht, dass es alles selbst können muss. Es bedeutet, dass es weiß: Was können wir selbst? Was können wir kurzfristig lernen? Wann brauchen wir Hilfe? Und von wem?
Team Topologies beschreibt ein ähnliches Prinzip. Stream-aligned Teams sollen möglichst viel Wert End-to-End liefern können. Fehlt eine Kompetenz, können Enabling Teams gezielt unterstützen und Fähigkeiten aufbauen, ohne daraus automatisch eine dauerhafte Übergabe oder organisatorische Abhängigkeit zu machen.
Cross-Functionality heißt für mich deshalb nicht: Jeder kann alles. Sondern: Das Team kann die Mission erfüllen.
2. Mission vor Stellenbeschreibung
Spezialeinheiten können nicht für jede mögliche Situation einen vollständigen Ablaufplan besitzen. Die Realität verändert sich schneller als jeder Plan. Eine zentrale Fähigkeit ist deshalb, das eigentliche Ziel zu verstehen und innerhalb klarer Grenzen selbst entscheiden zu können.
Das SEAL Ethos formuliert diesen Gedanken erstaunlich direkt: Wenn konkrete Anweisungen fehlen, wird erwartet, Verantwortung zu übernehmen, zu führen und das gemeinsame Ziel weiterzuverfolgen. Gleichzeitig soll jedes Teammitglied führen und geführt werden können.
Übertragen auf Produktentwicklung bedeutet das: Ein Team braucht mehr als Tickets. Es braucht Intent.
„Baut einen Filter mit fünf Kategorien.“
„Nutzer mit großen Ergebnislisten finden relevante Produkte zu langsam.“
„Wir reduzieren die Zeit bis zu einer brauchbaren Auswahl messbar.“
Mit dem ersten Auftrag kann ein Team hauptsächlich umsetzen. Mit dem zweiten und dritten kann es denken. Vielleicht ist ein Filter die richtige Lösung. Vielleicht bessere Suche. Vielleicht intelligentere Defaults. Vielleicht ist die eigentliche Ursache schlechte Produktdaten und überhaupt nicht das Interface.
Ein Team kann nur dann eigenständig gute Entscheidungen treffen, wenn es vier Dinge versteht:
- welches Nutzer- oder Geschäftsproblem gelöst werden soll,
- welche Constraints und Risiken gelten,
- welche Entscheidungen das Team selbst treffen darf,
- woran Wirkung später gemessen wird.
Das passt erstaunlich gut zu Erkenntnissen aus Googles Project Aristotle. Neben psychologischer Sicherheit identifizierte Google Dependability, Structure & Clarity, Meaning und Impact als zentrale Faktoren wirksamer Teams. Menschen müssen also nicht nur wissen, was sie tun, sondern auch verstehen, wie ihr Beitrag mit dem größeren Ziel zusammenhängt.
5Psychological Safety · Dependability · Structure & Clarity · Meaning · Impact
Viele Unternehmen sprechen von Empowerment, während Entscheidungen gleichzeitig über mehrere Ebenen eskaliert werden. Dann entsteht Scheinautonomie: Das Team darf die UI gestalten, aber nicht Scope, Priorität, Lösungsweg oder Erfolgskriterien beeinflussen.
DORA beschreibt leistungsfähige Softwareorganisationen deutlich konsequenter: Teams sollten Änderungen entwickeln, testen und deployen können, ohne für jeden Schritt feingranulare Koordination oder Genehmigung durch andere Teams zu benötigen.
Für Produktteams lässt sich das auf eine einfache Formel reduzieren: Mission klar. Grenzen klar. Entscheidungskompetenz klar. Dann los.
3. Die eigentliche Superkraft ist Lernfähigkeit
Was passiert, wenn während eines Projekts eine Fähigkeit benötigt wird, die im Team niemand ausreichend besitzt?
Die klassische Unternehmensantwort lautet häufig: Ressource beantragen. Danach folgen Kapazitätsplanung, Budget, Priorisierung, Abteilungsleiter, Briefing und Übergabe. Wochen später hat das Team vielleicht Zugriff auf die richtige Person.
Ein adaptives Team stellt vorher eine andere Frage: Können wir diese Fähigkeit schnell genug selbst aufbauen?
Genau hier wird das SEAL Ethos für Produktorganisationen interessant. Training wird dort ausdrücklich als niemals abgeschlossen verstanden. Die offizielle Navy-Seite beschreibt nicht nur die initiale Ausbildung, sondern danach weitere 18 Monate intensiven spezialisierten Trainings vor dem regulären Einsatz. Das Teammodell baut also nicht auf statischem Wissen auf, sondern auf permanenter Weiterentwicklung.
Auf Produktteams übertragen kann das sehr pragmatisch aussehen:
- Ein Designer lernt, einfache SQL-Abfragen oder Analytics-Events zu verstehen.
- Ein Product Manager schaut sich mit Browser DevTools einen API-Response an.
- Ein Engineer begleitet Nutzerinterviews und beobachtet reale Arbeitsabläufe.
- Ein UX Researcher lernt, Funnel- und Retention-Daten selbst zu explorieren.
- Ein Product Designer baut mit AI und Low-Code einen funktionierenden Test statt nur einen klickbaren Screen.
- Ein Engineering Lead verbringt Zeit im Support und sieht, was nach dem Release tatsächlich passiert.
Nicht, weil danach alle dieselbe Rolle haben. Sondern weil die gemeinsame Problemlösungsfähigkeit steigt.
Gerade AI beschleunigt diesen Effekt. Grenzen zwischen Disziplinen verschwinden nicht, aber sie werden durchlässiger. Designer können schneller funktionierende Prototypen bauen. Product Manager können Daten explorieren oder kleine Automationen erstellen. Engineers können schneller UX-Varianten oder Content-Hypothesen testen.
Die wertvollste Person im Team ist deshalb langfristig nicht zwangsläufig diejenige mit dem größten statischen Wissensvorrat. Häufig wertvoller ist eine Kombination aus tiefer Kernkompetenz, Lernfähigkeit, analytischem Denken, Neugier, Ownership und Zusammenarbeit.
Das verändert auch Recruiting. Die Frage lautet nicht mehr nur: „Beherrscht diese Person Tool X?“ Sondern zusätzlich: „Wie reagiert diese Person auf ein Problem, für das sie noch keine Lösung kennt?“
4. Reliability schlägt Genialität
Ein weiteres Missverständnis leistungsfähiger Produktteams ist die Vorstellung vom brillanten Einzelkämpfer: Rockstar Developer, Design Genius, Product Visionary. In kritischen Situationen ist eine langweiligere Eigenschaft häufig wertvoller: Zuverlässigkeit.
Google nennt Dependability ausdrücklich als eine der fünf Säulen wirksamer Teams: Menschen erledigen qualitativ gute Arbeit wie vereinbart und rechtzeitig. Das klingt selbstverständlich. Im Alltag ist es das nicht.
Produktorganisationen verlieren enorme Mengen Energie durch Sätze wie:
- „Ich dachte, das macht jemand anderes.“
- „Das Backend ist fertig, aber niemand wusste, dass Mobile noch fehlt.“
- „Analytics kommt später.“
- „Wir haben nicht getestet, was bei einem Fehler passiert.“
- „Das Design funktioniert nur mit perfekten Daten.“
- „Legal hat es noch nicht gesehen.“
- „Wir deployen nächste Woche, weil heute niemand aus DevOps verfügbar ist.“
Ein Hochleistungsteam betrachtet Delivery deshalb als System – nicht als letzten Schritt nach Discovery und Design.
Reliability-Fragen, die vor dem Release beantwortet sein sollten
- Was kann realistisch scheitern?
- Welche Annahmen haben wir getroffen?
- Welche Abhängigkeiten existieren außerhalb des Teams?
- Wer entscheidet bei einem Konflikt?
- Wie erkennen wir Fehler im Betrieb?
- Wie können wir zurückrollen oder korrigieren?
- Wer übernimmt, wenn eine Schlüsselperson ausfällt?
- Was passiert nach dem Release – Support, Analytics, Optimierung?
Das hat wenig mit Heroismus zu tun. Es ist Disziplin. Eine weitere SOF Truth lautet deshalb sinngemäß, dass leistungsfähige Special-Operations-Einheiten nicht erst nach Eintritt einer Krise erzeugt werden können. Die Fähigkeit muss vorher aufgebaut sein.
#4Competent Special Operations Forces cannot be created after emergencies occur.Übertragen auf Produktteams: Resilienz, Delivery-Routinen und Ownership müssen existieren, bevor es brennt.USSOCOM ↗
Produktorganisationen merken das meist beim ersten größeren Zwischenfall: Produktionsausfall, Security Incident, unerwarteter Nutzungspeak, fehlerhafte Migration, regulatorisches Problem oder eine Abhängigkeit, die plötzlich nicht verfügbar ist. Dann zeigt sich, ob das Team wirklich ein Team ist – oder nur eine Gruppe von Fachkräften mit demselben Jira Board.
DORA empfiehlt in diesem Zusammenhang unter anderem kleine Batch-Größen. Kleine Änderungen erzeugen schnellere Feedbackzyklen, erlauben frühere Korrekturen und reduzieren das Risiko großer, schwer reversibler Releases.
Das Prinzip lautet also nicht: Nie Fehler machen. Sondern: Fehler früh erkennen, Auswirkungen begrenzen und schnell reagieren können.
5. Komplexität sehen, bevor sie zum Problem wird
Ein außergewöhnliches Team zeichnet sich nicht nur dadurch aus, Probleme gut zu lösen. Es erkennt Probleme früh. Im Produktkontext würde ich das Product Situational Awareness nennen.
Ein Feature sieht beispielsweise zunächst trivial aus: „Wir brauchen einen Delete-Account-Button.“ Ein gutes Team sieht sofort weitere Ebenen:
- Was passiert mit offenen Transaktionen, Rechnungen oder laufenden Verträgen?
- Welche personenbezogenen Daten müssen gelöscht und welche rechtlich aufbewahrt werden?
- Was passiert in Backups und verbundenen Systemen?
- Brauchen wir Re-Authentifizierung?
- Kann die Aktion rückgängig gemacht werden?
- Was passiert, wenn nur die Hälfte der Systeme erfolgreich löscht?
- Welche Support- und Audit-Prozesse hängen daran?
Ähnlich bei einem vermeintlich simplen neuen Filter: Welche Datenqualität besitzen die Attribute? Welche Filter hängen voneinander ab? Was passiert bei null Treffern? Wie verhält sich das mobil? Ist die Interaktion barrierefrei? Wie wird Nutzung gemessen? Wie funktioniert Internationalisierung? Was passiert bei schlechter Performance?
Ein mittelmäßiges Team sieht den Screen. Ein gutes Team sieht das System.
Wo entstehen kognitive Last, Fehlinterpretationen, Sackgassen oder Vertrauensprobleme?
Welche Abhängigkeiten, Daten- oder Performance-Risiken stecken hinter der Oberfläche?
Welche Risiken sind wirtschaftlich relevant und welche Trade-offs akzeptieren wir bewusst?
Dazu kommt Data: Wie messen wir überhaupt, ob ein Problem auftritt und wie häufig? Erst aus diesen Perspektiven entsteht ein vollständigeres Lagebild.
Das Ziel ist ausdrücklich nicht, jeden denkbaren Sonderfall vorab zu lösen. Das wäre Analyseparalyse. Gute Teams unterscheiden vielmehr zwischen drei Kategorien:
Diese Fähigkeit wird mit wachsender Produktkomplexität wichtiger: Payments, Healthcare, AI, Enterprise Software, Identity, Fintech oder Marktplätze. Überall dort reicht Happy-Path-Design nicht. Produktqualität zeigt sich zunehmend an Randfällen, Abhängigkeiten und daran, wie ein System reagiert, wenn etwas nicht wie geplant funktioniert.
6. Wie baut man ein „Special Operations“-Product-Team?
Die wichtigste Lektion aus der Analogie ist nicht, Produktteams härter arbeiten zu lassen. Im Gegenteil. Es geht darum, Organisationen so zu bauen, dass gute Menschen effektiv handeln können.
USSOCOM bringt das mit der ersten SOF Truth sehr klar auf den Punkt: „Humans are more important than hardware.“ Tools kompensieren kein schwaches Team. Das gilt auch für Produktentwicklung.
Figma macht kein gutes Designteam. Jira macht kein gutes Product Management. GitHub macht kein gutes Engineering-Team. Und AI macht keine gute Produktorganisation. Entscheidend sind Menschen, Verantwortlichkeiten und das gemeinsame Arbeitsmodell.
Neun Prinzipien für ein adaptives Product-Team
- Kleine, stabile, cross-funktionale Teams: Product, UX und Engineering arbeiten dauerhaft zusammen – nicht als wechselnde Service-Provider.
- Tiefe Spezialisten mit breitem Systemverständnis: Jeder besitzt eine Kernkompetenz, versteht aber genug vom Ganzen, um nicht isoliert zu entscheiden.
- Mission statt Ticketfabrik: Teams bekommen Probleme, Ziele, KPIs und Constraints – nicht nur vorgefertigte Lösungen.
- Lernen ist Teil der Arbeit: Fehlende Fähigkeiten werden nicht automatisch durch neue Übergaben oder zusätzliche Rollen gelöst.
- Entscheidungen nah am Problem: Wer den besten Kontext besitzt, soll innerhalb klarer Grenzen entscheiden können.
- Delivery ist gemeinsame Verantwortung: Design „übergibt“ nicht an Engineering. Das Team liefert gemeinsam ein Ergebnis.
- Risiken werden aktiv gesucht: Security, Accessibility, Datenschutz, Edge Cases und operative Folgen gehören zur Produktarbeit.
- Fehler erzeugen Lernen: Dafür braucht es psychologische Sicherheit, offene Reviews und die Möglichkeit, schlechte Nachrichten früh auszusprechen.
- Externe Spezialisten verstärken das Team: Security, Legal, Research oder Plattformteams helfen gezielt, ohne jede Entscheidung dauerhaft zu zentralisieren.
Psychologische Sicherheit ist dabei kein weiches Kulturthema. Wenn Menschen Angst haben, eine falsche Annahme, einen Bug oder ein Risiko früh anzusprechen, wird das Team nicht robuster, sondern blinder. Genau deshalb war Psychological Safety in Googles Project Aristotle der stärkste Faktor der untersuchten Teamdynamik.
Führung verändert sich in einem solchen Modell ebenfalls. Gute Team Leadership bedeutet nicht, jede Entscheidung selbst zu treffen. Sie schafft Kontext, setzt Qualitätsmaßstäbe, entwickelt Menschen weiter und sorgt dafür, dass Verantwortung tatsächlich übernommen werden kann. Mentoring wird damit zur Skalierungsstrategie: Je mehr Menschen im Team gute Entscheidungen selbst treffen können, desto weniger wird Leadership zum Bottleneck.
Das Ziel ist dabei nicht ein Team, das alles kann. Das wäre weder realistisch noch sinnvoll.
Das Ziel ist ein Team, das bei einem unerwarteten Problem nicht sofort handlungsunfähig wird. Ein Team, das sagen kann:
- Wir verstehen das Problem.
- Wir wissen, was wir noch nicht wissen.
- Wir können uns fehlendes Wissen aneignen.
- Wir erkennen Risiken früh.
- Wir wissen, wann wir Spezialisten brauchen.
- Wir treffen Entscheidungen.
- Und wir liefern.
Vielleicht ist das der interessanteste Gedanke aus dem Vergleich mit Spezialeinheiten. Ihre eigentliche Stärke liegt nicht darin, für jede denkbare Situation bereits die perfekte Fähigkeit mitzubringen. Ihre Stärke liegt darin, Menschen, Training, Verantwortung und Zusammenarbeit so zu kombinieren, dass das Team auch dann funktioniert, wenn der ursprüngliche Plan nicht mehr funktioniert.
Genau das brauchen auch moderne Produktorganisationen: nicht immer größere Departments, nicht immer mehr Rollen und nicht immer mehr Tools. Sondern kleine, leistungsfähige Teams aus Product, Engineering und UX, die ein gemeinsames Problem wirklich besitzen.
Spezialisten in ihrer Disziplin. Generalisten im Denken. Und Experten darin, sich anzupassen.
Quellen & weiterführende Links