Fehler beim Aufbau der Produktorganisation

Was Sie beim Aufbau der Produktorganisation beachten sollten

Der Artikel soll Ihnen dabei, Fehler beim Aufbau Ihrer Produktorganisation zu vermeiden. Mit Fehlern meine ich vermeidbare Dysfunktionalitäten, Fehldesigns oder Falschannahmen, die z.B. dann entstehen, wenn man unreflektiert eine moderne Methode einführen möchte.

Ich möchte Sie dafür sensibilisieren, dass man viele wichtige Aspekte für den Aufbau einer erfolgreichen Produktorganisation bereits früh vorbereiten kann, etwa wenn es um die übergeordneten Zielsetzungen, Zuständigkeiten oder Budgets geht. Es lassen sich ungewollte Stolperfallen vermeiden, so dass mehr Raum für echte Weiterentwicklungen entstehen kann.

Die Produktorganisation

Einleitend soll der Begriff der Produktorganisation für den weiteren Kontext kurz konkretisiert werden.

Auf Wirtschaftslexikon24.com heißt es:

“Produktorganisation (Product-Management). Objektorientierte Organisationsform im Rahmen der Sekundärorganisation. Diese ist möglich als Stabs-Produktmanagement, als Linien-Produktmanagement, als Matrix-Produktmanagement mit funktionalen Organisationseinheiten in der anderen Dimension sowie als Gremien-Produktmanagement (Ausschuss).”

Mit einer Produktorganisation ist im Folgenden gemeint, dass Ambitionen, Ziele, Prozesse und ein organisatorischer Aufbau eines Unternehmens im Kontext eines Produktangebotes harmonisiert ausgerichtet werden. D.h., eine Organisation hat sich dahingehend zur Produktorganisation transformiert, um der Produkterstellung, der Koordination produktbezogener Aufgaben und dem Produktvertrieb sowie Kundensupport optimal nachzugehen.

Organisation entsteht nicht von alleine

Oftmals beginnt der Aufbau einer Produktorganisation mit der Erreichung von Grenzen eines bestehenden Projektgeschäfts eines Unternehmens. Nicht selten werden dann als Reaktion eines Tages Produkt Manager auf 1-2 Hierarchieebenen unter dem CEO eingestellt werden. Neben der vorliegenden Ambition zur Optimierung ist dann meist aber nicht so richtig klar, was neue Produkt Manager konkret für die Organisation bewirken sollen oder welche Aufgaben in Summe zu lösen sein werden, wenn es um mehr Produktfokus geht.

In anderen Fällen liebäugeln Unternehmen irgendwann mit der Einstellung eines Produkt Managers oder Product Owners, um bestimmte Aufgaben und Verantwortungen an die neue Rolle zu delegieren. Die neue Rolle wird z.B. ab einem gewissen Reifegrad der Organisation nötig, um der steigenden Komplexitäten zu begegnen.

Häufig sind Produktrollen zu Beginn so vorgesehen, dass sie für die Bearbeitung von bestimmten Teilaspekten auf der operativen Seite eingesetzt werden. Also ohne dass die (Produkt-) Organisation als Ganzes bereits reflektiert oder ausgerichtet wurde. Es wird etwa versucht, auf einen konkreten Bedarf oder ein Defizit zu reagieren, welches sich eine höhere Komplexität ergeben hat. Etwa, um den Disconnect zwischen Vertrieb und Entwicklung aufzulösen, um Anfragen nach einer Roadmap vonseiten der Kunden oder Stakeholder zu begegnen usw.

In agilen Entwicklungsteams (gerade im Bereich Softwareentwicklung) werden Product Owner leider sehr oft in einem fachlich isolierten Entwicklungskontext platziert und sich dann selbst überlassen. Sie sollen z.B. eine bereits strategisch beschlossene Entwicklungsinitiative begleiten, ohne dabei eine übergeordnet strategischere Anbindung zu erfahren. Dies führt etwa dazu, dass Product Owner nicht empowered sind, um die Mission wirklich durchzuführen.

Die Beispiele lassen eventuell bereits erkennen, dass Produktorganisationen in der Realität oftmals organisch-situativ entstehen, aber zu Beginn gar nicht durchdacht sind. Sie sind nicht dafür ausgestattet wirkunsvoll einem strategischen Plan zu folgen.

Somit: Allein durch die Einstellung einer Produkt-Persona zur Bewältigung bestimmter operativer Vorgänge hat man noch keine organisatorische Weiterentwicklung angestoßen. Und damit ist auch noch kein Fundament für die Entwicklung besserer Produkte, die Steigerung der Kundenzufriedenheit, Innovation oder neue Umsätze geschaffen worden. Die Organisation wird auch nicht über Nacht agil, nur weil die Rolle aus einem agilen Methodengerüst eingeführt wird.

Ferner: Ein poröses Fundament für den Aufbau einer Produktorganisation führt sogar häufig zu Kollisionen zwischen Verantwortlichkeiten, zu Dysfunktionalitäten oder redundanten Prozessen (etwa in Folge ungeklärter Kompetenzlagen). Letztlich zu mehr Frust aufseiten der Mitarbeiter. Im schlimmsten Fall führt eine schlecht etablierte Produktorganisation zur qualitativen Verschlechterung der Produktentwicklungroutinen und der Verschlechterung von Produkten. Dies kann der Grund für die Unzufriedenheit aufseiten der Kunden sein und z.B. zu Abwanderungs-Effekten führen.

Fehler sind vermeidbar

Doch die gute Nachricht ist: viele Fehler sind vermeidbar!

Wenn man bereit ist, sich frühzeitig über die Ziele, Zuständigkeiten und interdisziplinären Schnittstellen innerhalb der Organisation zu verständigen, dann kann vieles gelingen! Anders ausgedrückt: Das Einführen von Management bedarf Management. Wenn Sie Produkt Management oder weitreichendere Produktroutinen einführen, dann ebnen Sie der zukünftigen Organisation Schritt für Schritt den Weg.

Im Weiteren sollen exemplarisch typische Herausforderungen, Fehler und Chancen beim Aufbau einer neuen Produktorganisation erläutert werden.

3 Fehler bei der Einführung von Produktrollen

Um vermeidbare Stolperfallen zu illustrieren, sollen drei Beispiele herausgegriffen werden, die zu negativen Folgeentwicklungen führen können …

Fehler 1: Zielsetzung für Produktrollen unklar

Laut einem Bericht von ProductPlan, 2020 sind die wichtigsten strategischen Aktivitäten eines Product Professionals …

• Product development (priorities, sprint planning)
• Managing the product roadmap
• Getting consensus and buy-in on product direction
• Customer feedback, market validation, etc.
• Understanding market size, segments, and target market
• Setting and maintaining pricing

Warum setzen Sie Produkt Manager ein bzw. planen dies zu tun?

Welche Prioritäten sind Ihnen besonders wichtig für die neue Produktorganisation?

Wenn Sie eine direkte Zielsetzung vor Augen haben, ist das ein guter Anfang. Umgekehrt: Wenn eine Produktrolle oder die Organisation einfach so entsteht, ohne dass ein geteiltes, team-übergreifendes Bild über deren Zweck besteht, dann ist nicht so gut … Reibungs- und Effektivitätsverluste sind vorprogrammiert.

Für Softwareunternehmen ist es inzwischen relativ normal geworden, agile Entwicklungsmethoden zu praktizieren. Dies klappt mal besser und mal schlechter. In der Regel werden mit dem Etablieren von agilen Methoden, quasi als impliziter Nebeneffekt der Methode, neue Rollen eingeführt, wie z.B. die des Product Owners (in SCRUM). Was diese Rolle jedoch dann erfüllen soll, ist ja bereits in SCRUM definiert worden (also außerhalb Ihres Unternehmens!). Es muss also - so vielleicht die Annahme - nicht mehr viel gemacht werden. Dies hat aber oft zur Folge, dass die Einführung neuer Zuständigkeit innerhalb der Organisation insgesamt undiskutiert bleibt. Die Veränderungen geschehen “in der DEV Blackbox”, also etwa innerhalb der Entwicklungsabteilung, die sich auf neue Prozesse umstellt. Jedoch der Vertrieb, Marketing oder Help Desk usw. sind in diesem Moment nicht Teil dieser Umstellung. Die Potentiale bleiben dann ungenutzt und Verwirrung stellt sich ein.

Doch welche Potentiale sollen eigentlich angegangen werden? Wie kann eine neue Produktrolle eingesetzt werden und was wäre dafür nötig?

Was die Funktion eines Product Owners außerhalb der Entwicklungsabteilung ist oder sein sollte, wird leider meist nicht hinreichend reflektiert. Ein Klassiker ist deshalb, dass alle Abteilungen und Funktionen exakt so weiterarbeiten und denken wie zuvor. Die agile Methode und die neuen Schnittstellenfunktionen existieren nur “DEV-only” oder “in der IT”.

Die Entwicklungsabteilung ist im Wandel und diskutiert, wie von nun “agil gearbeitet werden soll”. Product Owner lernen dann meist schnell, was wenig Kompetenz und Alignment im Kontext des Produktes bedeutet. Denn es fehlen Schnittstellen zu Kundenstimmen, Feedbackkanäle, übergeordnete Routinen, tradierte Best Practices und vieles mehr. Das ist kein evolutionärer Schritt für die Organisation, sondern lediglich verpufftes Potential.

Isoliert aufgesetzte und damit zu kurz gedachte Rollendefinitionen machen also nicht nachhaltig Sinn für die Organisation und helfen vermutlich auch nicht dem Produkt. Product Owner, die weder Kundensichtweise, noch Probleme aus den Fachabteilungen kennen und kaum außerhalb der Entwicklung interagieren, sind letztlich wenig wertvoll für das Unternehmen. Wenn Product Owner dann zusätzlich nicht befähigt sind, Prioritäten selbst seltzen zu können (z.B. im Kontext des Product Backlogs oder für die Zielsetzung eines Sprints), dann kann die Position schnell ins Absurde abgleiten. Überraschend oft ist dies der Fall, glaubt man vielen Studien. In manch einem Unternehmen sind Produktrollen (wie die Product Owner Rolle) nicht hinreichend empowered, um ihre eigentliche Funktion auszuführen.

Schlussfolgerung: Wenn agile Methoden (wie SCRUM) einführt werden, dann empfiehlt sich hier ein teamübergreifender Dialog hinsichtlich der Anpassung von Prozessen und Zuständigkeiten - als Potential. Teamleiter und mittleres Management sollten diskutieren, welche Kompetenzen und Ziele an welche Rolle geknüpft werden kann, so dass z.B. effektive Schnittstellenarbeit möglich wird. Von einem sinnvollen Ineinandergreifen der Rollen profitiert letztlich das gesamte Unternehmen. Stellen Sie sich also immer die Frage, warum Sie eine Rolle einführen und was nötig ist, damit diese wirksam eingesetzt werden können.

Produkt Manager im klassischen Sinne sind einst aus der Idee von Brand Men hervorgegangen (bündig als historische Abhandlung von Aha! zusammengefasst). Durch die Brand Men Idee ist ein Begriff von Product Ownership mit einem traditionellen Marketing- und Brandingverständnis etabliert wurde. Dies geschah 1931. Beinahe ein Jahrhundert später gibt es noch immer vielerorts das klassisch geprägte Bild des Produkt Managers als Brand (Wo-)man - angesiedelt irgendwo im Bereich Marketing oder evtl. Business Development und Vertrieb. Für manche Branchen passt das sicherlich gut, für andere definitiv weniger. Es kann in gedanklich so konzipierten Produktorganisationen geschehen, dass sich die Botschaft (bzw. value proposition) oder Produktvision schnell zum wichtigsten Gegenstand der Aufmerksamkeit entwickelt, und irgendwann loslöst von der realen Produktwirklichkeit, den Kundenbedürfnissen oder dem Innovationsprozess. Wenn die bestehende Produkte eine phantastisches Wertversprechen aber nicht einlösen können, dann führt dies zu einer hohen Abweichung zwischen Wunsch und Wirklichkeit und im worst case zu fatalen Folgen.

Um solche Entwicklungen zu vermeiden gilt hier auch, sich früh Gedanken über die Ausrichtung der Produktorganisation und der produktbezogenen Rollen zu machen. Ist die Funktion Product vorrangig eine Schnittstellenfunktion, eine fachlich eingebettete Rolle in bestimmten Teams oder ein internes Kommunikations- oder gar Politikinstrument für die Evangelisierung der Strategie? Ob Produktrollen z.B. vornehmlich inbound oder outbound Aktivitäten verantworten sollen oder wie interdisziplinär Rollen agieren können, all das wäre letztlich zu reflektieren. Es bringt durchaus viel, wenn ein bestehendes Management grundlegende Ambitionen im Vorfeld diskutiert, Sichtweisen bzgl. neuer Funktionen austauscht und den Wandel hin zur Produktorganisation als Prozess begreift. Es ist nützlich, wenn über die ersten Ziele und Zuständigkeiten von Produktrollen Konsens besteht und die Organisation den Wandel als Chance begreift, neue Komplexitäten zu meistern. Es geht schließlich nicht um Produkt Manager, es geht um die Nützlichkeit für die Organisation, den Service am Kunden und um die Ausrichtung des Produktes.

Fehler 2: Sie sind nicht auf neue Insights vorbereitet

Wenn Sie Produkt Manager, Product Leads, CPO oder Product Owner (etc.) im Unternehmen etablieren und Talente rekrutiert haben, die Ihr Produkt nach vorne bringen wollen, dann sollten Sie mit neuen Vorschlägen und neuen Insights rechnen.

Warum? Hier ein paar Beispiele:

a) Für die Weiterentwicklung des Produktes beginnt der Produkt Manager früher oder später neue Daten und Meinungen zu sammeln. Kundenfeedback, Marktanalysen, Wettbewerbsinformationen, Nutzungszahlen, Vertriebskennzahlen etc. In diesem Kontext werden natürlich auch bislang unentdeckte Probleme aufgedeckt werden. Denn ansonsten kann man sich nicht verbessern. Sobald Produktdaten konsequent analysiert werden und Rückschlüsse gezogen werden, wird es unweigerlich zu neuen Handlungsempfehlungen kommen, die das Bestehende zunächst in Frage stellen. Eventuell wird Ihr Produkt plötzlich als weniger erfolgreich eingestuft als bislang angenommen. Eventuell werden tradierte Routinen und operative Prozesse hinterfragt. Da nun Produktzuständige den Erfolg eines Produktes anvisieren sollen, werden früher oder später eben vermutlich neue Einsichten auf den Tisch kommen. Und das ist gut so, wenn die Organisation damit produktiv umgeht.

Seien Sie also auf neue Informationen und neue Handlungsempfehlungen gefasst - oder anders formuliert - auf neue Potentiale für die Verbesserung und Weiterentwicklung!

b) Produktzuständige balancieren verschiedene Informationsquellen aus, um taktische oder strategische Ableitungen und Hypothesen für das Produkt zu erarbeiten. So liegt es in der Natur der Sache, dass Bauchentscheidungen, Einzelstimmen oder gar strategische Absichten vonseiten des Managements häufiger hinterfragt werden als zuvor. Und zwar im Sinne einer kritischen Analyse, die auf die Optimierung des Beschlusses oder der Handlungsoptionen abzielt.

Letztlich muss eine Entscheidung oder ein Veto im Sinne der unternehmerischen Rahmenbedingungen immer möglich sein, einen Produktverantwortlichen kann man hier aber zur Fundierung von Handlungsoptionen stärker integrieren. Ferner ist jedoch auch die Rollenautonomie in der Form zu beachten, dass z.B. ein Produkt Manager auch realen Spielraum für taktische Entscheidungen oder Risiken benötigt, um letztlich im Sinne des Produktes und der Unternehmung zu agieren. Ein Austausch auf Augenhöhe, wenn es um Optionen oder Argumente geht, ist hier wichtig und bildet eine Grundlage für die Zukunft.

c) Simple Meinungsdifferenzen können entstehen - z.B. hinsichtlich des Preises: Ein Produkt besitzt verschiedene Dimensionen und Eigenschaften, die insgesamt manövriert werden müssen, dazu gehört natürlich auch der Preis.

Es kann sein, dass es für ein Produkt innerhalb einer Branche oder Industrie verschiedene prominente Modelle der Preisgestaltung gibt. Die Sichtweise bei der Preisgestaltung der beteiligten Akteure innerhalb des Unternehmens basieren meist auf verschiedenen Präferenzen oder Zweckmäßigkeiten. Der eine Akteur könnte etwa eine direkte (eigene) Abhängigkeiten bzgl. des Incentive-Modells in der Vertriebsorganisation vor Augen haben. Ein anderer Akteur könnte den aktuellen Jahresabschluss bzw. die Bilanzen im Kopf haben, noch ein anderer die Preise im Wettbewerb oder in der Wahrnehmung des Kunden. Wieder ein anderer würde evtl. Produktpreise hinsichtlich des taktischen Upselling-Potentials im Gesamtportfolio einordnen. Von kurzfristig bis strategisch können die Absichten hier also weit auseinanderdriften. Differenzen und Positionen können gerade dann transparent und zur Diskussion werden, wenn interdisziplinäre Schnittstellenfunktionen wie die eines Produkt Managers eingeführt werden.

Auch hier gilt - ein Preismodell kann und sollte durch den Zugriff auf verschiedene Blickwinkel profitieren, vorher wurden bestimmte Aspekte vielleicht lediglich ausgeblendet oder sind unzureichend diskutiert worden. Der Preis ist aber ein sehr wichtiges Steuerungsinstrument und von daher ist der Austausch verschiedener Argumente und Szenarien von Vorteil. Wer letztlich die Preisentscheidung fällt ist eigentlich nebensächlich, viel wichtiger ist jedoch, dass eine Preispolitik und die Produktstrategie nicht isoliert betrachtet werden können, sondern nur im Zusammenspiel “einen Schuh ergeben”.

Die Beispiele (a-c) sollten skizzieren, dass durch den Aufbau neuer Produktverantwortlichkeiten auch zwangsläufig neue Themen, Daten oder Meinungen auf die Agenda gesetzt werden. Das ist alles andere als negativ, wenn die Organisation guten Argumenten gegenüber offen sein kann. Wenn sich Teams und Fachlichkeiten ergänzen und ein konstruktiver Diskurs möglich ist, dann werden neue Erkenntnisse zu einer besseren Strategie und adaptiveren Taktik führen. Die Organisation kann dann insgesamt kompetenter am Markt agieren und wird flexibler im Wettbewerb.

Fehler 3: Mangelnde Weiterentwicklung der Produktorganisation

Manchmal werden Produktzuständige mit einer Vielzahl an Aufgaben überschüttet, ohne dass aber die Machbarkeit ihrer Ausübung sichergestellt wird. Einige Stellenausschreibungen lesen sich wie eine Wunschliste im Bereich Produkt. Das Spektrum der Zuständigkeiten reicht von Roadmap-Maintenance, über das Einholen von Kundenfeedback, zur datengetriebenen Nutzungsanalyse, Konzeption und Designaufgaben, bis zur Backlogpflege und Testing sowie Dokumentation und Marketing- oder Vertriebssupport. Übrigens, tatsächlich habe ich diese Dinge bereits allesamt getan, d.h. dieses Wunschkonzert existiert nicht nur auf Stellenbeschreibungen, sondern ist Teil der Praxis. Es ist auch durchaus fair, von einem Produktverantwortlichen vielseitigen Einsatz und fachübergreifende Zuständigkeiten zu verlangen, aber es macht manchmal vielleicht mehr Sinn, wenn Prioritäten, Effektivität und Machbarkeiten reflektiert zusammenspielen. So ist es z.B. besser, verschiedene Produktfunktionen für verschiedene Aufgabenschwerpunkte in der Organisation zu besetzen.

Eine Produktorganisation würde ich stets als ein multi-funktionales und interdisziplinäres Konstrukt begreifen, welches in verschiedenen Richtungen wirksam sein muss. Als ein Konstrukt, welches gleichsam den Input aus verschiedenen Richtungen aufnehmen / verarbeiten und zurückspielen können muss. Wie viele Personen und Rollen man für ein gut funktionierendes Produktteam bräuchte, orientiert sich dabei an der bestehenden Komplexität Ihrer Organisation und natürlich auch an den Zielsetzungen der Produktfunktionen.

Neben der Rollenaufteilung und der Teamgröße ist es wichtig, die Produktorganisation sukzessive weiterzuentwickeln.

Sie ist nicht einfach da und dann läuft’s. Prozesse müssen eingespielt, angepasst, erneuert werden. Das Zusammenspiel mit Stakeholdern, Teams und Kunden muss jeweils nachhaltig austariert werden. Und auch die Mitarbeiter eines Produktteams sollten sich individuell weiterentwickeln können, um anpassungsfähig zu bleiben.

Es sollten z.B. individuelle Weiterbildungsbudgets (für externe Fortbildungen und Events) bestehen, damit wichtige externe Einflüsse importiert und bewertet werden können. Produkt-Leute, die nur noch im eigenen “Saft kochen” verlieren den Biss und den Blick für die Umwelt.

So ist auch der Wechsel von fachlichen Schwerpunkten (z.B. durch ein neues Produkt oder eine andere Zielsetzung) für Mitarbeiter eine gute Option, um fachlich oder persönlich die Perspektive zu erweitern. Investieren Sie also ebenso in die Zukunft Ihrer Produktorganisation.

Je nach Produkt und Geschäftsmodell sind rollenbezogene Schwerpunkte innerhalb Ihrer Organisation anders zu setzen. Etwa, ob kommunikative Tätigkeiten im Kundenkontakt überwiegen oder die Arbeit mit den Entwicklungsteams im Vordergrund steht. Das anvisierte Modell der Produktorganisation würde ich zu Beginn grob analysieren und in Wirkungsbereiche aufgliedern (z.B. Market Research, Product Design, Go-to-Market, Product Delivery etc.). Ob dann ein Produktzuständiger mehrere Bereiche bedienen kann oder ob spitz definierte Rollen mit verschiedenen Personen besetzt werden, sollte initial beurteilt kontinuierlich neu bewertet werden. Planen Sie die Produktorganisation also vielmehr als Transformationsprozess entlang ihrer Wirkungsentfaltung, nicht als einzelne Talente.

Die Beweggründe, welche von Product Professionals angegeben werden, ihren Job letztlich zu verlassen verraten viel über worst practices. Laut einer über Facebook ausgespielten Umfrage, die mitunter in der Product Managers Community von Product School erreichbar war, sind dies die Top-3-Gründe, warum Produkt Manager den Job kündigen:

• 1: Schlechte Unternehmensführung und Leadership
• 2: Mangel an Herausforderung und Weiterentwicklungsmöglichkeiten
• 3: Mangel an Klarheit bzgl. der Rolle

Diese Antworten wurden aus einer Auswahlmöglichkeit von sieben möglichen Antwortoptionen am häufigsten gewählt, wobei auch mehrere und eigene Antworten möglich waren. [ Link: Ergebnisse der Umfrage ]

Fazit: Tipps für Ihre neue Produktorganisation

1 - Rekrutieren Sie nicht einfach so einen Product Rockstar um zu schauen, welcher Effekt eintritt. Investieren Sie stattdessen etwas Zeit, um sich über die Ziele und eine mögliche Einbettung der Produktorganisation im Kontext der Gesamtorganisation Gedanken zu machen.

2 - Klären Sie wichtige Voraussetzungen für die Ausgestaltung einer effektiven Produktfunktion. Eröffnen Sie die Diskussion innerhalb der Organisation, was die Erwartungen an neue Rollen betrifft, aber auch, was für Änderungen resultieren können.

3 - Seien Sie offen für Wandel. In der Regel führt eine vitale Produktorganisation zu Veränderungsimpulsen und deckt manchmal unbeliebte Fragestellungen auf. Wenn diese konstruktiv aufgenommen werden können, profitiert die Organisation, das Produkt und der Kunde.

4 - Informieren Sie sich über gängige Rollen und Abläufe im Produkthandwerk, damit Sie nicht etwa einen Produkt Manager als klassischen Projekt Manager oder historischen Brand Man einsetzen.

5 - Entwickeln Sie die Produktorganisation kontinuierlich mit dem Gesamtunternehmen und an Herausforderungen weiter. Investieren Sie in Weiterbildungsangebote, aber auch in das konstante Finetuning der Abläufe. Lassen Sie Freiraum für Experimente auf der Suche nach Verbesserungspotentialen.

6 - Besprechen Sie neue Kompetenzen transparent über Bereiche hinweg, holen Sie Input ein und artikulieren Sie Ihre Absicht für Veränderungen. Denn gerade Schnittstellenrollen können nur auf Basis eines grundsätzlichen Committments wirklich Wirkung entfalten.

7 - Prüfen Sie vor der Einführung neuer Rollen, welche Kompetenz Sie bereit sind an eine Productunit oder einzelne Rollen zu delegieren. Klären Sie die Erwartungshaltung und das Mandat jeweils ab.

8 - Geben Sie einem neuen Team Zeit, um mit anderen Abteilungen einen Rhythmus zu etablieren oder Abläufe zu optimieren. Wandel ist ein Prozess.

9 - Lassen Sie Fehler zu, jede Organisation muss Fehler machen. Wenn Sie Raum für Experimente schaffen, können Sie noch mehr Einsichten generieren. Wichtig ist, dass Erkenntnisse aus Fehlern zu Lerneffekten führen kann.

10 - Bauen Sie keine Silos oder Elfenbeintürme auf, sondern ergeifen Sie die einmalige Chance, eine wichtige Schnittstelle für das Produkt zu schaffen, um Silos abzubauen. Dazu gehört auch, dass Sie wissen, welche Wirkungsbereiche diese Schnittstelle tangieren soll.