Product Mindset in großen Organisationen etablieren: SAPs Weg von 30 auf 3.000

Robert Weller, Global Content Officer bei SAP, hat ein vollständig neues Produktportfolio — das heutige Transformation Management Portfolio — von einem 30-köpfigen Team zur Organisationseinheit mit knapp 3.000 Mitarbeitenden skaliert. In 4–5 Jahren. Mit einer einzelnen Produktvision als Startpunkt.

Das ist kein Wachstumsmythos. Es ist das Ergebnis eines konsequent etablierten Product Mindsets, das emotionale Trigger, klare Teamrollen und eine skalierbare Fehlerkultur verbindet. Und es löst ein Problem, das fast jede Enterprise-Organisation kennt: Produktportfolios wachsen, aber das Mindset der Teams hält nicht Schritt.

„In der Software Branche ist deine große Investition neben den Infrastrukturen, die Menschen. So, die Menschen sind ein extremes Vehikel, um großartige Produkte zu bauen. Und das bedarf natürlich dann auch gute operative Modelle, ein gutes Mindset.”

Was Weller in diesem Gespräch liefert, ist keine inspirierende Führungstheorie. Es sind operative Frameworks, konkrete Rollendefinitionen und psychologisch fundierte Prinzipien — anwendbar für Führungskräfte und Produktverantwortliche in Organisationen ab 1.000+ Mitarbeitenden.

Die wichtigsten Erkenntnisse

• Produktvisionen sind keine Roadmaps — sie sind emotionale Ziele, die ein Kundenproblem lösen und durch Autonomie-Trigger (SCARF-Modell) Anziehungskraft erzeugen.
• Das DVF-Framework (Desirability, Viability, Feasibility) strukturiert MVP-Entwicklung über drei spezialisierte Rollen — und alle drei müssen in der Team-DNA verankert sein.
• 70 % Qualität beim Release ist kein Fehler — es ist die einzige Methode, schnell genug zu lernen, um Perfektion irgendwann zu erreichen.
• Coaching schlägt Replacement — Menschen zu ersetzen kostet unverhältnismäßig viel; kontinuierliche Skill-Entwicklung für Product Manager, Designer und Tech Leads ist der nachhaltigere Hebel.
• Kultur entsteht durch Leadership-Verhalten, nicht durch Werte-Poster — Empowerment und Cross-Funktionalität müssen Führungskräfte täglich vorleben.
• Psychologische Sicherheit ist ein Produktivitätsfaktor: Teams ohne Angst vor Konsequenzen bei Fehlern iterieren schneller und liefern bessere Produkte.
• KI-Agenten-Transformation erfordert denselben Mindset-Unterbau — wer Product Mindset heute nicht etabliert, ist für die nächste Welle nicht gerüstet.

Deep Dive

Enterprise-Produktteams verwechseln regelmäßig Roadmaps mit Produktvisionen – mit erheblichen Konsequenzen für Umsetzungsgeschwindigkeit und Mitarbeitermotivation. Während Roadmaps taktische Planungsdokumente sind, ist eine Produktvision ein emotional wirksames Ziel, das ein echtes Kundenproblem löst und Teams täglich antreibt. Diese Unterscheidung ist entscheidend für schnellere Strategieumsetzung.

Was eine Produktvision wirklich ist — und was sie nicht ist

Die häufigste Verwechslung in Enterprise-Produktteams: Roadmap = Vision. Weller trennt diese Konzepte scharf.

Eine Roadmap ist ein taktisches Planungsdokument. Eine Produktvision ist ein emotionales Ziel, das ein echtes, verifizierbares Kundenproblem adressiert — und Menschen täglich antreibt, morgens aufzustehen und daran zu arbeiten.

„Produktvisionen sind nicht nur Roadmaps. Visionen sind schon sehr motivierende Ziele, die ich in der Organisation haben möchte, wo ich weiß, dass das löst ein Problem.”

Die praktische Konsequenz ist entscheidend: Die Vision bleibt konstant, die Lösungsoptionen iterieren. Ob ein Kundenproblem durch ein Dashboard, einen KI-Agenten oder einen Digital Twin gelöst wird — das entscheidet sich im Laufe der Entwicklung. Die Vision selbst ist nicht verhandelbar.

Und sie muss in 3–4 Sätzen formulierbar sein. Knapp, emotional kompellierend, sofort verständlich für jeden im Team.

Das SCARF-Modell als Werkzeug für emotionale Produktvisionen

Weller nutzt David Rocks SCARF-Modell (Status, Certainty, Autonomy, Relatedness, Fairness) nicht als Führungsinstrument — sondern als Formulierungswerkzeug für Produktvisionen.

Das Kernprinzip: Kunden treffen Entscheidungen emotional, bevor rationale Überlegungen einsetzen. Eine Produktvision, die Autonomie und Kontrolle als Grundbedürfnis anspricht, erzeugt eine andere Anziehungskraft als eine Vision, die Features auflistet.

„Wenn du in der Produktvision Werte einbringst, wie wir bringen dich wieder in den Fahrersitz — das spricht Autonomie an, das spricht Kontrolle an, das triggert diese Grundwerte.”

Das SAP-Beispiel aus dem Transformation Management Portfolio: Statt „wir bauen ein Prozessmanagement-Tool” lautete die Vision sinngemäß: Wir bringen Führungskräfte zurück in die Steuerungsfähigkeit ihrer eigenen Unternehmensprozesse. Verben wie „steuern”, „verstehen”, „kontrollieren” aktivieren den Autonomy-Trigger im SCARF-Modell — und machen die Vision sticky, auch bei 3.000 Mitarbeitenden.

Die operative Anleitung in fünf Schritten:

1. Kernproblem des Kunden identifizieren — z. B. fehlende Prozesstransparenz
2. Vision mit Autonomie-Fokus formulieren — „Wir bringen dich zurück in den Fahrersitz”
3. Bewegungsverben verwenden — steuern, kontrollieren, verstehen
4. 3–4 prägnante Sätze — keine Feature-Liste, kein technisches Glossar
5. Lösungsoptionen offenlassen — Dashboard, Agent, Digital Twin: Die Lösung kann iterieren, die Vision nicht

Empowered Teams: Die drei Rollen, die kein Unternehmen überspringen kann

Weller beschreibt den Aufbau empowerter Produktteams über das DVF-Framework — Desirability, Viability, Feasibility — als strukturgebendes Prinzip.

Jede Dimension gehört einer spezialisierten Rolle:

Der entscheidende Punkt: Diese drei Perspektiven müssen simultan in die Produktentwicklung einfließen, nicht sequenziell. Wenn der Tech Lead erst am Ende des Prozesses eingebunden wird, entstehen Produkte, die technisch umsetzbar, aber wirtschaftlich nicht tragfähig oder emotional nicht anziehend sind.

„Leute ersetzen ist ganz schwierig, das kostet unglaublich viel Geld. Deswegen als Führungspersonen und als Leader muss man da in das Thema Coaching extrem einsteigen heutzutage.”

Die Implikation für Cross-funktionale Teams ist direkt: Führungskräfte, die diese Rollen schwach besetzen und dann schnell ersetzen wollen, zahlen einen unverhältnismäßig hohen Preis — finanziell und kulturell. Coaching als Standard ist die Alternative. Kontinuierliche Skill-Entwicklung für alle drei Rollen, regelmäßige Feedback-Loops, keine Bestrafungskultur bei Entwicklungsdefiziten.

Wie man Agilität wirklich skaliert — jenseits von Scrum-Zeremonien

Der häufigste Fehler bei der agilen Transformation in Enterprise-Organisationen: Unternehmen implementieren Scrum-Rituale (Standups, Sprints, Retrospektiven), aber behalten eine Null-Fehler-Kultur bei. Das Ergebnis ist Pseudoagilität — die Form ohne die Substanz.

Weller benennt das Kernproblem direkt:

„Das Schlimmste bei einer Softwareentwicklung ist auf Perfektion zu setzen. Es geht um Agilität. Agilität, die ich durch ständiges Lernen, durch Weiterentwicklung, durch Iterationen, durch Testen, Validieren…”

Die 70%-Regel ist die operative Konsequenz: Ein MVP mit 70 % Qualität zu releasen und aus echtem Customer Feedback zu lernen ist systematisch wertvoller als ein Produkt mit 95 % Qualität, das sechs Monate später kommt. Der Lernzyklus ist schneller, die Iterationen relevanter, das Risiko kalkulierbarer.

„Man sollte sich nicht schämen mit seinem 70%-Produkt. Es ist wichtig, dass man damit rausgeht.”

Für die Strategieumsetzung auf Portfolioebene bedeutet das: Release-Entscheidungen müssen entkoppelt werden von Perfektion. Teams brauchen explizite Ermächtigung — von Führungskräften schriftlich und mündlich verankert — dass iterativer Release kein Zeichen von Schwäche ist, sondern methodische Stärke.

Die Mechanismen für skalierte Agilität laut dem Product Mindset-Modell:

• Sprint-basierte Delivery mit echten Feedback-Loops nach jedem Zyklus
• Fehlerkultur ohne Konsequenzen — Experimente sind Learning, keine Haftungsfragen
• Psychologische Sicherheit als Voraussetzung für ehrliches Feedback nach innen und außen
• Coaching statt Replacement als Standard-Reaktion auf Leistungsdefizite

Kultur als Skalierungshebel: Von 30 auf 3.000 ohne Mindset-Verlust

Das Transformation Management Portfolio bei SAP wuchs von 30 auf knapp 3.000 Mitarbeitende — in einem Zeitraum von 4–5 Jahren. Die Frage, die sich jede wachsende Organisation stellen muss: Skaliert der kulturelle Kern mit, oder verwässert er?

Wellers Antwort ist eindeutig: Kultur und Verhalten sind bidirektional verbunden. Werte beeinflussen Verhalten, aber Verhalten prägt Kultur genauso stark zurück. Leadership hat hier eine Multiplikator-Funktion.

„Wenn meine Leader zusammenarbeiten, wenn meine Leader auf Empowerment abzielen, wenn meine Leader Cross-Funktionalität lieben und greifen — dann ist das eine gute Unterstützung.”

Die Werte-Kultur-Modell-Logik für Skalierung sieht so aus:

1. Werte explizit definieren: Kollaboration, Lernen aus Fehlern, Agilität, Kundenorientierung — nicht als Dekoration, sondern als operative Leitplanken
2. Leadership-Alignment sicherstellen: Führungskräfte aller Ebenen müssen Empowerment und Cross-Funktionalität täglich demonstrieren
3. Agile Prozesse institutionalisieren: Sprint-Zyklen, iterative Validierung, schnelle Feedback-Loops als Standard — nicht als Ausnahme
4. Coaching als Führungsinstrument: Produktmanager, Designer und Tech Leads kontinuierlich entwickeln, nicht austauschen
5. Psychologische Sicherheit strukturell verankern: Fehler sind Learning-Events, keine disziplinarischen Vorfälle

Der Unterschied zwischen Unternehmen, die diesen Kulturkern aufrechterhalten, und denen, die ihn auf dem Wachstumspfad verlieren: Die erste Gruppe kann die nächste Transformation — KI-Agenten, automatisierte Prozesse, neue Produktparadigmen — auf bestehendem Fundament aufbauen. Die zweite muss von vorn anfangen.

AI-Agenten: Warum Product Mindset heute die Grundlage für morgen legt

Die nächste Welle der digitalen Transformation — der Einsatz von KI-Agenten in Organisationen — setzt exakt denselben Unterbau voraus wie jede vorherige Transformation: starke Teamzusammensetzung, klare Produktvisionen, Kollaborationswerte.

„Wenn man so Produktsachen aufbaut und auch Veränderungen — dann hilft es immer, wenn Teams gut zusammengesetzt sind, wenn sie empowert sind. Das ist ein extremes Vehikel.”

Wer heute kein Product Mindset in seiner Organisation verankert, baut keine Grundlage für KI-gestützte Produktentwicklung. Die Herausforderung ist nicht technisch — sie ist kulturell und strukturell. Empowered Teams, die Fehler als