Post-Image

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 Herausforderungen und Verantwortungen an eine neue Rolle zu delegieren. Die neue Rolle wird z.B. ab einem gewissen Reifegrad der Organisation nötig, um 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 reflektiert oder neu ausgerichtet wurde. Es wird etwa versucht, auf einen konkreten Bedarf oder ein Defizit zu reagieren. Etwa, um den Disconnect zwischen Vertrieb und Entwicklung aufzulösen, Anfragen nach einer Roadmap vonseiten der Kunden oder Stakeholder zu begegnen, usw.

In agilen Entwicklungsteams (gerade im Bereich Softwareentwicklung) werden Product Owner sehr oft in einem fachlich isolierten Team-Kontext platziert und sich selbst überlassen. Sie sollen z.B. eine bereits beschlossene Entwicklungsinitiative begleiten, ohne dabei eine übergeordnet strategischere Anbindung zu erfahren.

Die Beispiele lassen hoffentlich erkennen, dass Produktorganisationen in der Realität oftmals situativ einfach entstehen, aber gar nicht durchdacht sind oder einem sinnvollen Plan folgen.

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 in noch kein Fundament für bessere Produkte, höhere Kundenzufriedenheit, effektivere Innovationsmethodik, höhere Agilität oder neue Umsätze geschaffen worden.

Ein poröses Fundament für den Aufbau einer Produktorganisation führt sogar häufig zu Kollisionen zwischen Teams und Verantwortlichkeiten, zu dysfunktionalen oder redundanten Prozessen (z.B. aufgrund ungeklärter Kompetenzlagen) - letztlich zu mehr Frust aufseiten der Mitarbeiter. Im schlimmsten Fall führt eine so entstandene Schieflage zur qualitativen Verschlechterung der Produktentwicklungroutine und zu nicht gewollten Produkten. So ensteht Unzufriedenheit aufseiten der Kunden, es entstehen Abwanderungs-Effekte / Churn und eine Verschlechterung im Resultat.

Doch die gute Nachricht ist: viele Fehler sind vermeidbar! Wenn man bereit ist sich über die Ziele, Freiheitsgrade, Zuständigkeiten und interdisziplinären Routinen innerhalb der Organisation zu verständigen, dann kann vieles gelingen! Anders ausgedrückt: Das Einführen von Management bedarf Management. Wenn Sie Produkt Management einführen, dann ebnen Sie der zukünftigen Organisation 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: Sie wissen nicht, wofür Sie eine Produktrolle benötigen

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. 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 wie man weiß, mal besser und mal schlechter. In der Regel werden mit dem Etablieren von agilen Methoden, quasi als Nebeneffekt der Methode, neue Rollen eingeführt, wie z.B. die des Product Owners (in SCRUM). Was diese Rolle dann erfüllen soll, ist bereits im Kontext von SCRUM (also außerhalb Ihres Unternehmens) definiert worden. Dies hat oft zur Folge, dass die Einführung dieser neuen Zuständigkeit innerhalb der Organisation undiskutiert bleibt. Die Veränderungen geschehen “in der Blackbox”, z.B. lediglich innerhalb der Entwicklungsabteilung, die sich auf neue Prozesse umstellt. Vertrieb, Customer Success, Help Desk usw. sind in diesem Moment nicht Teil dieser Veränderung. Doch was könnte eine neue Rolle eigentlich für Ihr Unternehmen bedeuten?

Was die Funktion eines Product Owners außerhalb der Entwicklungsabteilung ist oder sein sollte, wird meist nicht produktiv durchdacht. Ein Klassiker ist deshalb, dass alle Abteilungen und Funktionen exakt so weiterarbeiten und denken wie zuvor. Die agile Methode und die neuen Schnittstellenfunktionen sind “Dev-only”. Allein die Entwicklungsabteilung ist im Wandel und darauf konzentriert, von nun an “agil zu werden”. Ein neuer Product Owner lernt dann meist sehr schnell, was wenig Kompetenz im Kontext des Produktes bedeutet. Denn es fehlen Schnittstellen zu Kundenstimmen, Feedbackkanäle und vieles mehr. Der Vertrieb fragt eventuell immer noch nach Projekt Delivery und die Prioritäten für das Produkt ergeben sich durch Zuruf. Das ist kein evolutionärer Schritt, sondern lediglich ein neuer Disconnect, der so entsteht.

Isoliert aufgesetzte und damit zu kurz gedachte Rollendefinitionen machen also meist nicht viel Sinn für die Organisation und auch nicht für das Produkt. Ein Product Owner, der weder Kundensichtweise noch Probleme aus den Fachabteilungen kennt und kaum außerhalb der Entwicklung interagieren kann, ist letztlich wenig wertvoll für das Unternehmen. Wenn ein Product Owner aus zig möglichen Handlungsoptionen dann zusätzlich nicht die Kompetenz erhält, eine Option als Priorität selbst festzulegen (z.B. im Kontext des Product Backlogs oder die Zielsetzung für einen Sprint), dann kann die Position schnell ins Absurde abgleiten. Und überraschend oft ist dies der Fall, glaubt man vielen Studien. In vielen Unternehmen sind Produktrollen (wie die Product Owner Rolle) nicht genügend empowered, um ihre eigentliche Funktion auszuführen.

Wenn also agile Methoden wie SCRUM einführt werden sollen, dann empfiehlt sich hier ein teamübergreifender Dialog hinsichtlich der teamübergreifenden Möglichkeiten, Prozesse und Zustündigkeiten. Gerade Teamleiter und Management sollten sich darüber klar werden, welche Kompetenzen für welche Themen an welche Rolle geknüpft werden müssten, so dass z.B. Matrix-Positionen und Schnittstellenfunktionen wirksam werden können. Von einem funktional sinnvollen Rollen-Aufbau profitiert das gesamte Unternehmen.

Stellen Sie sich also immer die Frage, warum Sie eine Rolle einführen. Fragen Sie sich auch, was nötig ist, damit neue Arbeitsweisen und Rollen wirksam 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 Produktentwicklung, den Kundenanfragen oder dem Designprozess. Wenn nun bestehende Produkte im Portfolio die phantastischen Wertversprechen aber nicht einlösen können, dann führt dies nicht zur Begeisterung von Kunden und Partnern. Im Gegenteil - eine zu hohe Abweichung zwischen Wunsch und Wirklichkeit führt zu fatalen Folgen. Es kommt auch ferner zu einer Silo-Bildung zwischen der kommerziellen und nicht-kommerziellen Fraktion der Organisation (also z.B. Marketing und Entwicklung), was schließlich toxische Ausmaße erreichen kann und neue Probleme für die Zukunft kultiviert.

Um solche Entwicklungen zu vermeiden gilt hier auch, sich früh Gedanken über die Ausrichtung der Produktorganisation und des Produkt Managements zu machen. Ist die Funktion Product 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 Schwerpunkte einnehmen sollen oder wie interdisziplinär Rollen agieren können, all das wäre am besten im Vorfeld zu reflektieren. Es bringt durchaus viel, wenn ein bestehendes Management grundlegende Ambitionen im Vorfeld diskutiert und die Sichtweisen bzgl. neuer Funktionen austauscht. Es ist nützlich, wenn über die Ziele und den primären Wirkungsraum von Produktrollen Konsens besteht, bevor diese dann eingeführt werden.

Die Transformation der Organisation (hin zu einer neuen Produktausrichtung) sollte mit einem solchen Konsens starten. Denn Zweck und Motivation können nun eindeutiger kommuniziert werden. Es bietet sich die Möglichkeit im Vorfeld mit verschiedenen Teilen der Organisation die Motivation zu besprechen. Es geht schließlich nicht um Produkt Manager, es geht um die Folgen für die Organisation, die Kunden, das Produkt.

Informieren Sie sich über die verschiedenen Ausprägungen von Produktfunktionen und spielen Sie durch, welche Aufgaben mit welchen Kompetenzen am besten adressiert werden können. Es sollte auch bewertet werden, welche bestehenden Funktionen anders ausgerichtet werden müssen, damit bereits im Vorfeld erwartbare Reibungsverluste gelättet werden können.

Sie wollen eventuell einen höheren Kundennutzen generieren, Wertversprechen einlösen oder neue Innovationen auf den Weg bringen - fragen Sie sich also, welchen Beitrag die Produktorganisation dabei spielen soll. Führen Sie nicht einfach so moderne Methoden ein, ohne dass Teams im übergeordneten Sinne davon Nutzen ziehen können. Die Teams müssen zwar nicht homogen arbeiten, aber schnell entstehen dysfunktionale Silos, die man eigentlich schnell vermeiden könnte. Gegen neue Methoden ist nichts zu sagen, doch wichtig ist es, dass die Dinge “ineinandergreifen” und nicht auseinander driften.

Fehler 2: Sie sind nicht auf Neuigkeiten oder neue Diskussion vorbereitet

Wenn Sie Produkt Manager, Product Leads, CPO oder Product Owner im Unternehmen etablieren und Personen rekrutiert haben, die Ihr Produkt nach vorne bringen wollen, dann sollten Sie mit potentieller Manöverkritik und garantiert 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 können natürlich auch bislang unentdeckte Probleme aufgedeckt werden. Sobald Produktdaten konsequent analysiert werden und neue Rückschlüsse gezogen werden können, kann es zu neuen Schlussfolgerungen kommen, die das Bestehende in Frage stellen. Das Produkt kann plötzlich z.B. als weniger erfolgreich eingestuft werden als bislang angenommen. Bestimmte Routinen der operativen Praxis können hinterfragt werden usw. 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.

Seien Sie aber gefasst auf neue Informationen und neuen Handlungsbedarf - oder anders formuliert - auf neue Potentiale für die Verbesserung und Weiterentwicklung!

b) Produkt Manager balancieren in der Regel verschiedene Informationsquellen aus, um taktische oder strategische Ableitungen und Hypothesen für das Produkt zu erarbeiten. Das Management, z.B. die C-Suite, wird dadurch implizit zu einer von mehreren Informationsquellen. Natürlich kann die entsprechende Gewichtung der Managementstimme hier vorgenommen werden, aber im Sinne der Analyse wird die Stimme des Managements nun erst einmal degradiert (~ objektiviert). Produkt Manager sollten die Stimme des Kunden, des Marktes und ebenso Machbarkeitsaspekte, Potentiale und Investitionen etc. mit in solide Betrachtungen einschließen. So liegt es in der Natur der Sache, dass Bauchentscheidungen, Einzelstimmen oder eben Beschlüsse von “Oben” vermutlich häufiger hinterfragt werden als zuvor. Und zwar im Sinne einer kritischen Analyse, die auf die Optimierung des Beschlusses 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. bzgl. 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 neue Themen, Daten oder Meinungen in Austausch gebracht werden. Das ist alles andere als negativ, wenn die Organisation guten Argumenten gegenüber offen sein kann. Wenn sich Rollen und Zuständigkeiten ergänzen und eine konstruktive, offene Diskussion möglich ist, dann sollten neue Erkenntnisse zu einer besseren Strategie führen. Wichtige Diskussionen führt man zudem besser, bevor man das Produkt oder große Änderungen auf den Markt bringt. Die Organisation kann dann insgesamt kompetenter am Markt agieren.

Fehler 3: Mangelnde Weiterentwicklung der Produktorganisation

Manchmal werden Produkt Manager mit einer Vielzahl an Zuständigkeiten überschüttet, ohne dass aber die Machbarkeit ihrer Ausübung sichergestellt wird. Viele Stellenausschreibungen lesen sich wie eine Suche nach einer eierlegenden Woll-Milch-Sau im Produktspielfeld, die dann entweder Product Owner, Product Lead, CPO, Product Manager oder Product Developer heißt. Das Spektrum der Zuständigkeiten reicht von Roadmap-Maintenance, über das Einholen von Kundenfeedback, zur datengetriebenen Nutzungsanalyse und Designaufgaben, bis zum Anleiten der Development Teams und einer Launch Orchestrierung sowie Dokumentation.

Es ist zwar durchaus fair, von einem Produktverantwortlichen vielseitigen Einsatz und fachübergreifende Zuständigkeiten zu verlangen, aber es macht manchmal vielleicht mehr Sinn, wenn wichtige Zielsetzungen und reale Machbarkeiten zusammen passen. So ist es besser, verschiedene Produktrollen für verschiedene Fokusbereiche in der Organisation zu besetzen, als einen ständig überforderten und garantiert nicht zufriedenen Einzelkämpfer zu züchten.

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, tradiert, erneuert werden. Das Zusammenspiel mit Stakeholdern, anderen Teams und den Kunden muss austariert werden. Und auch die Mitarbeiter eines Produktteams sollten sich weiterentwickeln können. Es sollten etwa 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. 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 in die Zukunft Ihrer Produktorganisation, denn ansonsten sparen Sie definitiv an der falschen Stelle. Wenn Sie lediglich ein Team aufsetzen, das die Entwickler beschäftigen soll, dann werden Sie dies auch ganz bestimmt bekommen. Und sich später ärgern.

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 Konstrukt der Produktorganisation würde ich dementsprechend zu Beginn grob analysieren und in wichtige Fokusbereiche aufgliedern (z.B. User Research, Product Design, Stakeholder Management, Product Marketing, Product Owner Team 1-n etc.). Ob dann ein Produkt Manager die essentiellen Funktionen realistisch als Einzelperson abbilden kann oder ob Sie besser spitz definierte Rollen mit mehreren Personen besetzen, das sollte initial beurteilt und dann regelmäßig neu bewertet werden. Planen Sie die Produktorganisation also vielmehr als Transformationsprozess, nicht als Team, welches man montags einsetzt.

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 Produkt Manager oder Product Owner, um zu schauen, welcher Effekt eintritt oder weil man diese Rollen heute eben hat. Sondern: Investieren Sie 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 Zielsetzungen für die Produktfunktion. Stellen Sie dann früh Konsens im Management her, was neue Zuständigkeiten, Budgets und Prozesse betrifft. Gerade Matrix-Konstellationen und Programm-Zuständigkeiten führen bei schlechter Machart zu Frust und Reibungsverlusten.
  • 3 - Seien und bleiben Sie offen für Wandel, denn in der Regel führt eine vitale Produktorganisation zu Veränderungsimpulsen und neuen Fragestellungen. Wenn diese konstruktiv aufgenommen werden können, profitiert die Gesamtorganisation, das Produkt und der Kunde. Wenn Sie nicht offen für Wandel sind, prüfen Sie nochmals kritisch, was Sie eigentlich vorhaben.
  • 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 _Brand Man_ einsetzen.
  • 5 - Entwickeln Sie die Produktorganisation konstant **mit** dem Gesamtunternehmen und an Herausforderungen weiter. Investieren Sie in Weiterbildungsangebote, aber auch in das konstante Finetuning der Abläufe und lassen Sie Freiraum für Experimente auf der Suche nach Verbesserungspotentialen.
  • 6 - Besprechen Sie Änderungen für die Organisation horizontal über Bereiche hinweg, holen Sie Input ein und artikulieren Sie Ihre Absicht. Denn gerade Schnittstellenrollen können nur auf Basis eines breiten Committments wirklich Wirkung entfalten.
  • 7 - Prüfen Sie vor der Einführung neuer Rollen, welche Kompetenz Sie bereit sind zu teilen. Klären Sie die nötigen Verwantwortlichkeiten und die Erwartungshaltung früh mit möglichen Kandidaten für Ihre neue Organisation.
  • 8 - Geben Sie einem neuen Team Zeit, um für sich und mit anderen Abteilungen einen Rhythmus zu etablieren oder Prozesse zu besprechen. Geben Sie hierfür gleichzeitig Ziele vor oder lassen Sie sich Zwischenstände zeigen, um so auch einen Rahmen zu schaffen, der für verschiedene Teams gleichermaßen verbindlich gilt.
  • 9 - Lassen Sie Fehler zu, jede Organisation muss Fehler machen. Wenn Sie Raum für Experimente schaffen, können Sie noch mehr Einsichten generieren.
  • 10 - Bauen Sie keine neuen 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 Verantwortung Sie an welche Rolle delegieren und dass Kollaboration eine Art KPI ist.
Weitere Beiträge
Innovation managen? Ja.

Innovation managen? Ja.

Innovationen sind mehr als kreative Ideen - wenn Innovation auf die Organisation trifft, wird es oft anstrengend. Trotzdem sollte man Innovation wagen!

Mehr erfahren

Newsletter

Neues von conceptMonkey einfach abonnieren

Hier