Mit „Alles Idioten?“ ist Thomas Erikson bereits 2011 ein echter Bestseller rund um Kommunikation und Stakeholder-Management gelungen. Auf Basis seiner langjährigen Praxiserfahrung als Verhaltensexperte und Leadership-Coach beschreibt er vier Persönlichkeitstypen, die ähnlich ticken – und vor allem ähnlich angesprochen werden wollen. Ziel: Beziehungen bewusster nutzen, schneller vorankommen und dabei möglichst harmonisch bleiben.

Wer kennt sie nicht, diese Gedanken nach zähen Diskussionen oder gescheiterten Überzeugungsversuchen?
„Das müsste doch jeder verstehen …“ oder „Was ist daran so kompliziert?“ 🤯
Genau hier setzt das Buch an.

Stakeholder Management ist eine der wichtigsten, aber oft unterschätzten Disziplinen im Produktmanagement. Wer seine Stakeholder nicht aktiv einbindet, verliert schnell an Einfluss, Zeit und Motivation. Doch wie gelingt es, die richtigen Personen zum richtigen Zeitpunkt zu erreichen? Wie schafft man Vertrauen und baut stabile Beziehungen auf?

Dazu haben wir im Juni ein Webinar durchgeführt und obige Fragen fundiert beantwortet. In diesem Beitrag beleuchten wir die zentralen Erkenntnisse daraus – praxisnah, strukturiert und mit konkreten Umsetzungstipps. Viele Inspirationen, Tipps und Tricks habe ich aus dem Buch „Aligned – Stakeholder Management for Product Leaders“ von Bruce McCarthy und Melissa Appel entnommen – die Ausführungen von Bruce und Melissa decken sich dabei zu 100% mit meinen 25 Jahren Erfahrung in Fach- und Führungspositionen im Produktmanagement.

Wichtige Stakeholder gibt es natürlich innerhalb und ausserhalb unseres Unternehmens (Kunden, Nutzer, Partner, …). Ich möchte in diesem Beitrag aber in erster Linie einen genaueren Blick auf unsere internen Stakeholder werfen. Viele Prinzipien und Denkweisen lassen sich aber ebenso auf den Umgang mit externen Stakeholdern übertragen.

In diesem Sinne wünsche ich Euch, dass Ihr die richtigen Stakeholder korrekt charakterisiert, mit den richtigen Mitteln anpackt und zu Helfern und Unterstützern macht. Das ist anstrengend und arbeitsintensiv, da individuell auf jede/n eingegangen werden muß.

Eines aber steht felsenfest – ES LOHNT SICH!

Wer sich näher mit dem Thema beschäftigen möchte, dem seien nochmal meine beiden Hauptquellen
ans Herz gelegt:

• Aligned – Stakeholder Management for Product Leaders, Bruce McCarthy & Melissa Appel
• People Styles at Work … And Beyond – Making Bad Relationships Good and Good Relationships Better, Robert Bolton & Dorothy Grover Bolton

Happy Stakeholder Management!

Im Jahr 2014 formulierte der damalige CEO des Beleuchtungsunternehmens Zumtobel – Ulrich Schumacher – den Plan, sich „zu einer Art Google der Beleuchtungsindustrie“ zu entwickeln. Dabei hatte er möglicherweise 2 Dinge im Kopf:

• den Wunsch, der unangefochtene Marktführer in der Beleuchtungsindustrie zu werden – so wie Google im Bereich der Websuche – im nachhinein vielleicht etwas zu ambitioniert
• die Idee,  den Kundennutzen durch den Einsatz von Software Lösungen, die ein immer wichtigerer Teil im Unternehmensportfolio werden sollten, zu steigern und sich somit „fit für die Zukunft zu machen“.

Zur damaligen Zeit hatte ich gerade als Segment-Manager bei der Tridonic GmbH – einem Tochterunternehmen der Zumtobel Gruppe – angefangen und war verantwortlich für ein großes Portfolio von Produkten zur Beleuchtungssteuerung. Der Vergleich mit Google in diesem Zusammenhang fühlte sich für mich an, als würde sich das Unternehmen selbst überheben, da es sich in der Vergangenheit in erster Linie durch seine hochwertige Beleuchtungshardware hervorgetan hatte. Außerdem hatte ich bereits während meiner vorherigen beruflichen Stationen bei Harman Automotive (jetzt Teil von Samsung) und bei Nokia mehrmals durchlebt, wie wahnsinnig schwer es traditionell hardwarezentrischen Unternehmen fällt, Softwarelösungen zu erdenken, zu entwickeln, zu vermarkten und zu verkaufen.

Ich habe viele CEOs Aussagen machen hören wie „Wir müssen jetzt ein Software-Unternehmen werden!“ Ich denke, dass eine solche Aussage für ein Unternehmen sehr irreführend oder sogar falsch sein kann – vielleicht fällt Euch im weiteren auf, dass ich diese Terminologie in diesem Blog nicht verwende, sondern dass ich über den Übergang zur Bereitstellung von Kundennutzen durch Software spreche. Ein gutes Beispiel, wo die Dinge schief liefen, war, als Nokia seine Geschäftseinheit „Services“ neben der Geschäftseinheit „Devices“ einführte und – da „Services“ eine so hoch strategische Sache waren – die Geschäftseinheit „Services“ die Geschäftseinheit „Devices“ aufforderte, keine neuen Geräte auf den Markt zu bringen, es sei denn, ein neuer Service wäre fertig entwickelt und könnte zusammen mit dem Gerät auf den Markt gebracht werden. Dies führte zu einer Situation im Unternehmen, in der der „Schwanz praktisch mit dem Hund wedelte“ und gefährdete folglich Nokias „Brot und Butter“ Geschäft. Apple hat das viel besser verstanden und durch eine Entkopplung von Hardware und Software ein perfektes Risikomanagement betrieben, indem eine neue iOS-Version nicht strikt an die Einführung eines neuen iPhones gebunden ist (in der Praxis hat Apple den Launch neuer iphone Modelle mit neuen iOS Versionen aber stets hinbekommen)

Der Übergang zu einem Unternehmen, das seinen Kunden vor allem durch Software einen Mehrwert bietet, ist keine leichte Aufgabe. Er vollzieht sich nicht über Nacht. Es ist ein Weg, der sich auf alle Bereiche des Unternehmens auswirkt, einschließlich, aber nicht beschränkt auf Produktmanagement, Technik, Finanzen, Qualität, Lieferkette und Vertrieb. Die meisten Unternehmen, die ich in einer solchen Übergangsphase beobachtet habe, waren übermäßig ehrgeizig in Bezug auf das, was sie in einem Zeitraum von 2-3 Jahren erreichen konnten. Ich halte es für vernünftig, davon auszugehen, dass innerhalb eines Zeitraums von 5 Jahren etwas erreicht werden kann, 2 Jahre sind definitiv zu kurz.

Wenn Unternehmen sich auf digitale Dienste und Software zubewegen, tun sie das häufig, ohne die Softwareentwicklung und Datenanalyse als Kernkompetenzen zu betrachten (obwohl beide Begriffe immer wieder auf den „Strategiefolien“ auftaucht). Als Produktmanager habe ich mich stattdessen in Situationen wiedergefunden, in denen die F&E-Organisation die SW-Entwicklung an viele – nicht assoziierte – kleine Unternehmen ausgelagert hat, die eher nach der Verfügbarkeit von Ressourcen und dem Preis ausgewählt wurden als nach einer strategischen Überlegung, wie die von externen Unternehmen geschaffenen Software Artefakt (eigentlich ein Flickenteppich) richtig verwaltet und später möglicherweise wieder eingelagert werden könnte. Die frühzeitige Einsetzung von System-/Softwarearchitekten und Datenanalytikern als Eigentümer eines solchen Software-Assets und Datenbasen ist von größter Bedeutung, um den Übergang erfolgreich zu meistern. Die Installation eines technischen Produktmanagers als Product Owner der Softwareplattform wird sich sehr auszahlen. Wir konnten den Erfolg beispielsweise bei Zumtobel deutlich sehen.

Wenn es um den Business Case für Produkte geht, die dem Kunden vor allem durch Software & Daten einen Mehrwert bieten, passen die bestehenden „xls-Sheets“, die typischerweise Parameter wie Bruttomarge, Deckungsbeitrag oder Kapitalwert auf der Basis von Produktkosten und Produktpreis berechnen, nicht mehr. Diese Tabellen sind in der Regel im „Besitz“ der Finanzabteilungen des Unternehmens und versuchen sicherzustellen, dass Produkte einen Gewinn erzielen, die neben den Produktkosten auch die Gemeinkosten finanzieren kann und zusätzlich Mittel abwirft, um neue Produktideen anschieben zu können. Da nun zusätzliche Investitionen in die Softwareentwicklung getätigt werden mussten, führten die Finanzzahlen nicht selten zu einer Ablehnung einer Idee und der Vizepräsident der Finanzabteilung rief im Produktmanagement an, um das „Problem zu beheben“.

Es kommt erschwerend hinzu, dass sich gute Software ständig weiterentwickelt und dem Kunden kontinuierlich weiteren Nutzen liefern soll, was im Umkehrschluss bedeutet, dass eine Softwareentwicklung „nie“ abgeschlossen ist.

Die in Hardware Unternehmen übliche Frage „Wieviel Stück verkaufe ich mehr mit einem neuen Feature?“ führt hier nicht zum Ziel, denn es ist eine Betrachtungsweise zu etablieren die eher fragt „Welche Auswirkungen hat es auf mein Geschäft, wenn ich NICHT weiter in die Weiterentwicklung eines Produktes investiere?“. Alter Muster funktionieren nicht mehr und gerade das Produktmanagement läuft oft gegen Wände, da die alten Zöpfe nicht abgeschnitten werden – oder zumindest neu geflochten werden.

Produktmanager/-innen wissen, wie äußerst wichtig es ist, Trends auszukundschaften und den Markt zu beobachten, um „IoT“, „Cloud Computing“, „Datenschutz“ und „Industrie 4.0“ zu verfolgen und sich mit ihnen vertraut zu machen, aber noch wichtiger ist es, aus diesen Trends relevante und konkrete Anwendungsfälle abzuleiten, die unserem spezifischen Kunden einen spezifischen Mehrwert bieten und für die höchstwahrscheinlich nur ein kleiner Bruchteil aller Technologien benötigt wird, die durch die oben genannten Buzzwords grob beschrieben werden.

Dieses Wissen haben Unternehmen anfangs nicht und es ergeben sich daraus zwangsweise falsche Einschätzungen zur Komplexität eines neuen Entwicklungsvorhabens mit dem Ergebnis, dass sich bald Ernüchterung allenthalben einstellt.

Kein Zweifel – die Umstellung von Hardware auf Software und digitale Dienste ist schwierig. Die Unternehmen verfügen zwar über äußerst fähige und kluge Mitarbeiter, aber kann ein Unternehmen, das im Hardware-Geschäft hervorragende Leistungen erbracht hat, organisch (d. h. mit denselben Mitarbeitern) zu einem Team heranwachsen, das den Übergang erfolgreich bewältigt?

Meine Meinung ist ein klares „NEIN“ – es bedarf mehr als nur der Ausbildung oder Qualifizierung von Mitarbeitern für die neuen Herausforderungen. Es wird notwendig sein, „frisches Blut“ mit Software-Kompetenz in das Team zu bringen. Die Umstellung muss zwar alle Bereiche/Abteilungen betreffen, aber einige Bereiche brauchen dieses frische Blut dringender als andere. Die ersten sind typischerweise F&E und Produktmanagement, aber bald werden auch Supply Chain, Finanzen und Qualität folgen, wiederum gefolgt von Vertrieb, Recht und Beschaffung.

Es gibt keinen heiligen Gral dafür, ob ein solcher Kompetenzzuwachs durch die Einstellung der besten Talente von Unternehmen, die bereits im SW-Bereich tätig sind, oder durch eine Übernahme erreicht werden kann. Beide Optionen sollten in Betracht gezogen und bewertet werden – die endgültige Entscheidung wird sehr spezifisch für jedes einzelne Unternehmen sein.

Produktmanagement-Teams sind hier in der Schlüsselposition, um die Erwartungen zu steuern. Business Cases mit moderaten Software-Investitionen und großen Umsätzen nach 2 Jahren sollten mit Vorsicht genossen werden und eher die Ausnahme als die Regel sein. Bei Zumtobel mussten wir lernen, dass eine drahtlose und IP-basierte Lichtsteuerung, die mit der Cloud verbunden ist (nichts davon hatten wir vorher gemacht), uns weit mehr Schweiß und Tränen gekostet hat als ursprünglich geplant.

Das „Not Invented Here Syndrom“ ist in einer Transformation wie dieser kein guter Ratgeber. Produktmanagement Teams mit ihrer ganzheitlichen Sichtweise sind hier aufgefordert, den Finger in die Wunde zu legen und zu sensibilisieren, inwiefern im Unternehmen die benötigten Kompetenzen vorhanden sind, um mit digitalen Produkten erfolgreich sein zu können.

In fast allen Fällen bietet sich die Nutzung bereits vorhandenen Wissens und bereits vorhandener Technologie und der Aufbau eines entsprechenden Partnernetzwerks an. Das bedeutet mitnichten, digitale Kompetenzen langfristig outzusourcen, sondern die Zeit zu nutzen, in welcher das Unternehmen noch nicht über entsprechende Kompetenzen verfügt.

Wenn Führungskräfte sagen: „Wir müssen jetzt ein Softwareunternehmen werden!“ gehen sie oft davon aus, dass sich der Umsatz des Unternehmens von Hardware auf Software verlagern sollte. Diese Auffassung ist riskant und sollte niemals implizit angenommen werden, wenn der Kundenwert durch Software geliefert wird. Noch vor einigen Jahren habe ich im persönlichen Gespräch mit Top Managern der Automobilindustrie gehört, dass man „im Jahr 2030 ein Drittel des Umsatzes mit digitalen Diensten“ machen wolle. Die heutige Situation zeigt, dass diese Einaschätzung nicht falscher hätte sein können.

Stattdessen kommt dem Produktmanagement eine Schlüsselrolle zu, wenn es darum geht, individuell zu bewerten, ob die Kundenerwartungen, der Wettbewerb und die Technologie für die Bereitstellung von digitalen Lösungen eine solche Verlagerung der Einnahmen zulassen. Selbst wenn man zu dem Schluss gekommen ist, dass dies der richtige Weg ist, muss gemäß den Anmerkungen zur Ambition weiter oben ein realistischer Zeitrahmen für eine solche Verlagerung zwischen den Beteiligten gefunden werden.

Ich möchte Produktmanagement Teams hier ermutigen, eher konservativ zu sein und sich für konservative Ziele einzusetzen. Der Nutzen, der sich aus der Erreichung dieser Ziele ergibt, ist viel größer als das Risiko, sie zu verfehlen, was häufig zu Änderungen seitens der Geschäftsleitung führt, die wiederum „bewegliche Ziele“ und Unsicherheit in der Strategie zur Folge haben. Die Produktmanager sollten nicht zögern, immer wieder zu erklären, welchen Ansatz das Unternehmen bei der Bereitstellung von Software verfolgt. Dies hat auch nichts damit zu tun, hier der „Bremser“ zu sein oder „unkoooperativ“ zu erscheinen sondern verhindert frühzeitige Enttäuschung, Desillusion und das sofortige Hinterfragen der richtigen Strategie.

Es geht um viel mehr, als nur Software statt Hardware zu verkaufen. Die gesamte Organisation muß sich der Herausforderung stellen, dass sich Geschäftsmodelle ändern – Punkt! Ohne Ausnahme. Es betrifft jede Abteilung. Der Wandel ist definitiv nicht einfach – das Produktmanagement Team ist aber in einer zentralen Position, um den Wandel zu gestalten. Als Schnittstellenfunktion haben wir Verbindungen zu allen Abteilungen und kennen deren Abhängigkeiten. Diese Position gilt es im Sinne des Unternehmens zu nutzen und beispielsweise eine funktionsübergreifende Arbeitsgruppe einberufen, die gemeinsam Fragen beantwortet wie

• Wie amortisieren wir einen SW-Entwicklungsaufwand über mehrere Produkte hinweg?
• Soll die Basis-SW-Entwicklung über alle Produkte/Lösungen des Unternehmens abgeschrieben werden und Teil der Gemeinkosten werden?
• Wie sollen wir den Aufwand für mehrere Software-Releases auf der gleichen Hardware-Plattform behandeln? Finanzcontroller fragen häufig (siehe oben): „Wie viele Geräte würden wir mehr verkaufen, wenn wir diese neue Softwareversion entwickeln würden?“ In einer Welt, in der der Wert von Lösungen mehr und mehr durch Software geliefert wird, sollte die Antwort des Produktmanagements eher lauten: „Wenn wir die Software nicht aktualisieren, werden wir bald keines unserer Produkte mehr verkaufen, da die Konkurrenz einen höheren Kundennutzen bietet“.
• Wie wollen wir Software bepreisen ?
• …

An dieser Arbeitsgruppe sollten neben dem Produktmanagement zumindest der Leiter der Finanzabteilung, der Leiter der F&E-Abteilung, der Leiter der Abteilung für Personalentwicklung und der Leiter der Verkaufsabteilung teilnehmen.

Transformationsstrategien sind oft auf sehr hohem Level formuliert und werden als „wachsweich“ empfunden. Alle Abteilungen fragen sich zurecht „was es denn nun für sie bedeutet“. Im Zentrum der Erwägungen sollte dabei stehen, wie eine digitale Strategie unseren Kunden nutzt, denn am Ende wird sie sich nur auszahlen, wenn wir Mehrwert für unseren Kunden schaffen, für den er zu zahlen bereit ist. Produktmanagement Teams sind hier aufgefordert, den Mehrwert zu beschreiben und in der ganzen Organisation immer wieder zu erklären. Gleichzeitig sollte klargemacht werden, dass ein solcher  Mehrwert über alle Abteilungen des Unternehmens erarbeitet werden kann. Er ist keine Sache der Entwicklungsabteilung, die nun statt Hardware eben Software entwickelt. Er betrifft Entwicklung, Produktmanagement, Verkauf, Betrieb, Einkauf und Controlling. Niemand hat Grund, sich zurückzulehnen.

Produktmanagement Teams müssen durch ihre Nähe zu Markt und Kunde helfen, die Brücke zu bauen zwischen digitalen Strategien und nutzenstiftenden sowie umsetzbaren Kundenanforderungen und Anwenderszenarien – „Was hat unser Kunde denn davon?“ Eine Digitalstrategie ist kein Selbstzweck und keine Modeerscheinung. Als Produktmanagement Team sind wir aufgefordert, auch Änderungen in anderen Abteilungen anzustoßen, wenn dadurch Kundennutzen entsteht. Das wird anderen Abteilungen helfen, die Strategie umzusetzen – beispielsweise indem im Vertrieb Anwendungsexperten für die neuen Lösungen etabliert werden.

Es bedeutet aber auch, Zusammenhänge im Unternehmen immer wieder zu erklären und beispielsweise auch unsere Anstrengungen für die Schulung unserer Vertriebskollegen zu intensivieren. Ob man es nun glauben will oder nicht – für jemanden, der 30 Jahre lang Hardware Produkte vertrieben hat, ist die Promotion und die Erklärung eines digitales Services eine riesige Veränderung.

Der Bedarf an „frischem Blut“ ist natürlich auch im Produktmanagement vorhanden. Ich bin überzeugt, dass ein Gruppe von Hardware-Produktmanagern eine Umstellung auf Software besser bewältigen kann, wenn Expertise von außen mit dazu geholt wird über eine(n) neue(n) Kollegen/in, der/die bereits Erfahrungen mit digitalen Lösungen mitbringt.

Aber es müssen nicht nur neue Kompetenzen in  Teams eingebracht werden – das neue Team muss auch in eine geeignete Organisation eingebettet werden. Eine solche Organisation – auch wenn es sich anfangs schmerzhaft anfühlen mag – muss darauf achten, dass das „SW-Team“ die nötige Freiheit bekommt, um zu agieren und nicht völlig in die Prozesse eines Hardware-Unternehmens eingesperrt wird. Das Gegenteil sollte angestrebt werden: Das funktionsübergreifende „SW-Team“, welche das Softwareangebot des Unternehmens vorantreibt, muss ausdrücklich dazu ermutigt werden, die zukünftigen Prozesse des Unternehmens mit zu entwerfen.

Gleichzeitig bin ich kein Freund einer vollständigen Trennung von Hardware- und Softwaregruppen, da dies die Abstimmung auf der Arbeitsebene erschwert und zu einer „Software gegen Hardware“-Kultur führen kann. Wie eine solche Zusammenarbeit auf Arbeitsebene aussehen kann, hat unser Kollege Ulf Greiner in unserem Webinar „Brücke zwischen den Welten – Verbindung digitaler und physischer Produktstrategien“ beschrieben, welches auch auf unserer Website verfügbar ist.

Sehr wichtig ist mir dabei zu betonen, dass Organisationen mit Bedacht angepasst werden müssen. Jede Änderung birgt Komplexität und Probleme. Zu viele gleichzeitige Änderungen können Organisationen „überfordern“. Das Motto „Wir machen jetzt alles anders“ hat noch sehr selten funktioniert.

Die Erfahrungen, die ich im Laufe meiner Karriere gemacht habe, stimmen recht gut mit dem überein, was die Boston Consulting Group bereits 2008 in einem virtuellen Interview mit 3 CEOs zum unserem Thema  veröffentlicht hat. Für mich ist es ein „Deja-vu“ dessen, was ich im Laufe der Jahre erlebt habe, und ich empfehle allen, diese Lektüre zu genießen.

Natürlich haben nicht nur die virtuellen Unternehmen von BCG den Übergang erfolgreich gemeistert, denn es gibt tonnenweise Beispiele für Marktteilnehmer, die den Übergang gut gemeistert haben, darunter Cisco, IBM, Apple, Harman, Automobilhersteller wie BMW oder Mercedes-Benz, „klassische“ Kopiergerätehersteller wie Kyocera oder Minolta.

Es gibt also guten Grund für die traditionellen Hardware-Akteure zuversichtlich zu sein, dass sie diesen Beispielen folgen können, auch wenn es vielleicht länger dauert als ursprünglich erwartet. Und wer ganz genau hinsieht, der bemerkt sogar, dass viele grosse Software Unternehmen begonnen haben, in Hardwareprodukte zu investieren … Google’s Pixel Familie, Meta’s Quest oder aber Microsoft’s Surface Produkte sind gute Beispiele dafür.

Kommunikationsfähigkeiten werden zurecht als Schlüsselkompetenz für alle Teilnehmer im modernen Wirtschaftsleben eingestuft. Das Bundesinstitut für Berufsbildung beginnt seinen Abschlussbericht zum Thema Sprachlich kommunikative Anforderungen in der beruflichen Ausbildung“ aus dem Jahr 2017 mit den Worten „Sprachlich-kommunikative Kompetenzen werden als elementar für den Erwerb beruflicher Handlungskompetenz im Betrieb … für die Ausübung beruflicher Tätigkeiten angesehen. Sprachlich-kommunikative Kompetenzen gelten als Schlüsselkompetenzen.“

Wir dürfen mit Sicherheit auch davon ausgehen, dass die Wichtigkeit erfolgreicher Kommunikation mit der Zunahme der zur Verfügung stehenden Kommunikationskanäle (Mail, Chat, Soziale Medien, Blog, Streaming, Teams, Kollaborations-Tools, …) in den letzten Jahren zugenommen hat und weiter zunehmen wird.

Für Produktmanager, Produktmarketingmanager oder Product Owner nimmt sie – im Vergleich zu anderen Rollen im Berufsleben – nochmals eine zentralere Rolle ein, wie die Ergebnisse aus der ProduktManageMentor Marktstudie im Jahr 2023 eindrucksvoll belegen. Dies liegt zum einen sicher an unserer zentralen Rolle in Produktteams mit einer Vielzahl von Schnittstellen, aber auch an der schieren Menge an Informationen, die wir empfangen, verarbeiten und mit anderen teilen. Die relevanten Informationen auszufiltern, aufzubereiten und damit andere zu überzeugen, um unsere Ziele als Produktmanager zu erreichen, kann – bei allem fachlichen Knowhow – nicht hoch genug eingeschätzt werden. Was also können wir tun, um in unserer Kommunikation erfolgreich zu sein?

Vollkommen unabhängig von der Art des Kommunikationsmediums lässt sich jedoch eine Sammlung von Methoden – oder Best Practices – ausmachen, die wir anwenden können, um „erfolgreich“ zu kommunizieren – „erfolgreich“ insofern, als dass wir der Erreichung unserer Ziele näherkommen.

Als Produktmanager, Produktmarketingmanager oder Product Owner haben wir natürlich sehr spezifische Gelegenheiten, unser Kommunikationstalent zu beweisen, sei es bei der Zusammenstellung und Vorstellung eines Business Cases, der Diskussion von Anforderungen oder aber der Formulierung unseres Kundenversprechens bei der Produkteinführung.

Alle diese Aufgaben haben ihre spezifischen Besonderheiten, Chancen und Fallstricke, auf die wir aber – aus Zeitgründen 😉 (wir alle sind vielbeschäftigte Produktmanager) nicht eingehen werden. Vielmehr wollen wir hier das Augenmerk auf allgemein gültige und anwendbare Methoden legen.

Bei allen Dingen, die uns helfen können, wirksam zu kommunizieren, gibt es 2 Dinge, die über allen anderen stehen sollten und die bereits erledigt sein müssen, bevor der erste Satz getippt, das erste Wort gesprochen oder der Button des Teams oder Zoom Meetings geklickt wird!

Als Produktmanager wollen wir Ziele erreichen! Im Rahmen unserer Kommunikation verfolgen wir einen Zweck. Damit wir überhaupt erfolgreich sein können, sind 2 Voraussetzungen zu schaffen.

1. Kenne Dein(e) Gegenüber – im „Business Jargon“ auch „Stakeholder Management“
2. Kenne das Ziel Deiner Kommunikationsbemühung und formuliere es „explizit!

In beiden Punkten gilt „je genauer, umso besser“! Was kann das aber im Detail bedeuten und warum ist es so entscheidend?

Kenne Dein Gegenüber

Alles, was später gesagt, geschrieben oder gehört wird, muss den Gesprächspartner berücksichtigen – wer sind die Personen, welche Verantwortung tragen sie, welche Entscheidungen treffen sie, wie ticken sie, was ist Ihnen wichtig, aber auch, was ist Ihnen weniger wichtig. Zur Einordnung unsere Gegenüber können Tools wie das „Stakeholder Mapping“ oder eine Einschätzung des Arbeitsstils nach der Kategorisierung nach „Bolton & Bolton weiterhelfen. Wir werden nur erfolgreich sein, wenn wir verstehen, wen wir „vor uns“ haben und wie wir ihn anpacken müssen. Ein CEO wird uns in der Regel selten länger als 3 Folien zuhören, ohne uns zu unterbrechen und Fragen aufzuwerfen.

Kenne Dein Ziel

Wer war nicht oft genug schon in den Meetings, in denen man sich am Ende gefragt hat, was der Einladende eigentlich erreichen wollte. Wer hat sie nicht auch schon „en masse“ bekommen – Mails, an deren Ende man weniger schlau ist als vor dem Lesen. Uns muss klar sein, was wir erreichen wollen, und das sollten wir unserem Gegenüber auch explizit mitteilen.

Beispiele:

• als konkrete Formulierung im Betreff einer Email („Strategietag am 31.12.2023: Brauche von Dir die Freigabe für die Kostenübernahme des Silvestermenüs bis zum 01.05.“)
• als einleitenden Satz einer Präsentation („Ich möchte Ihnen heute einen Überblick geben über unsere Produkte im Bereich X und gerne Ihr Feedback aufnehmen, um es in unserer Roadmap zu berücksichtigen …“).

Es macht einen Unterschied, ob ich jemandem einen Überblick verschaffen möchte mit dem Ziel, sein Interesse zu wecken oder aber ob ich jemanden zum kurzfristigen Kauf eines Produktes bewegen möchte.

Die Maxime „Kenne Dein Ziel“ gilt aber ebenso für die Rolle  des Empfängers, Zuhörers oder Lesers – schließlich möchte ich nicht unnötig Zeit vergeuden und mir Dinge anhören oder durchlesen, die für mich aktuell keine Wichtigkeit haben. Es ist also auch hier vollständig legitim, sein Ziel explizit zu formulieren und beispielsweise zu sagen “Ich habe vergangene Woche das Produkt des Wettbewerbs gesehen mit Funktion X und würde gerne verstehen, ob Ihre Lösung etwas ähnliches anbietet und zu welchem Preis wir so etwas bei Ihnen kaufen könnten …“- Indem Ihr Euer Ziel explizit formuliert, schafft ihr Klarheit, demonstriert, dass ihr einen Plan habt und tretet souverän auf.

Als Produktmanager sind wir täglich damit beschäftigt, viele verschiedenen Informationen und Sichtweisen zu einem Gesamtbild zusammenzufügen und die richtigen Entscheidungen im Sinne des ganzen Unternehmens zu treffen. Dabei sprechen wir mit vielen verschiedenen Stakeholdern. Alle diese Stakeholder haben – und dies gilt es für uns zu respektieren – ihre spezifischen Interessen und Sichtweisen und diese sind – jeweils aus deren Perspektive – vollkommen legitim und richtig.

Um dies aber auch so sehen zu können, müssen gute Produktmanager Empathie beweisen und sich – bildlich – in die Lage des anderen versetzen, um seine Interessen als wichtig einzuordnen, als legitim zu verstehen und nicht als irrelevant abzutun. Euer Gegenüber steht im Fokus – wichtig ist, was Euer Gegenüber wissen möchte und nicht, welche tollen Details ihr selber wisst.

Für empathische Kommunikation kommt im Zweifelsfall „Zuhören vor Zuquatschen“. Nur so kann ich Dinge erfahren und lernen, die uns ansonsten verborgen bleiben, weil wir den anderen mit unserem Detailwissen oder dem letzten Rhetorikkurs beeindrucken wollen. Zur Empathie gehört damit auch die Wertschätzung der Zeit des anderen. Wir alle haben genug zu tun und erwarten auch von anderen, dass sie unsere Zeit sinnvoll nutzen.

Empathie bedeutet also am Ende, die legitime Sichtweise von vielen anderen Stakeholdern einzuholen und sie auch als valide anzuerkennen. Ein vollständiges Bild entsteht am Ende nur durch die Betrachtung aus unterschiedlichen Perspektiven.  Das befreit uns natürlich nicht von der Aufgabe, am Ende alle Sichtweisen zusammenzubringen und abzuwägen und – im Ganzen – optimale Lösungen im Sinne des Unternehmens zu finden.

Sind diese Lösungen dann aber gefunden, gilt es diese KLAR zu kommunizieren – womit wir wieder beim Punkt „Klarheit gewinnt“ sind.

Als Produktmanager wollen wir unsere Ziele erreichen. Dazu müssen wir andere überzeugen. Helfen können uns dabei die bereits beim Thema „Klarheit“ erwähnten Zahlen, Daten und Fakten, am besten gleich immer mit Quellenangabe. Aber auch einfache Techniken, wie das konsistente Wiederholen von Schlüsselaussagen – egal ob als Teil einer Kundenpräsentation oder auf der Website im Rahme eines Produktlaunches – geschickte gewählte Wiederholungen erfüllen den Zweck und geben Euren Argumenten Überzeugungskraft.

Am Ende wollen wir andere Stakeholder von unserem Vorhaben überzeugen. Das geht am besten, wenn wir sie von unserer Sache begeistern können. Als gute Methode für guten Zugang zu Stakeholdern hat sich dabei die „Kunst“ des sogenannten Storytellings (Buchtip „Tell Me!“ Wie Sie mit Storytelling überzeugen“) bewährt. Wer könnte uns diese Kunst besser in einem Beispiel erklären als einer der größten Geschichtenerzähler aller Zeiten  – in Steve Jobs‘ Rede an der Standford Universität in 2005 gibt er gleich 3 seiner Geschichten zum Besten.

Eine gute Story zeichnet sich dadurch aus, dass sie nicht nur Fakten aneinanderreiht, sondern diese auch in geeigneter Weise miteinander verknüpft, um so eine zusammenhängende Geschichte zu erzählen, der man einfacher folgen kann – in die man sich ggf. sogar selbst hineinversetzen kann.

Ach ja, eine letzte Sache liegt mir noch am Herzen.

Auch wenn wir als Produktmanager viele verschiedene Sichtweisen einholen müssen, und wir – um es in der Fussballersprache zu formulieren – die legitimen Meinungen vom Torwart über die Abwehrspieler bis zum Mittelfeld und Sturm anhören sollten – unsere generelle Spielweise sollte immer offensiv ausgerichtet sein.

Beim Thema Kommunikation bedeutet das, dass wir unsere Kommunikation proaktiv gestalten sollten, statt abzuwarten. Wir sollten lieber Fakten schaffen, als dass über unseren Kopf hinweg Fakten geschaffen werden, mit denen wir dann – oft mehr schlecht als recht – leben müssen.

Fakten können wir schaffen, indem wir im Hintergrund Allianzen bilden und auch informelle Kanäle nutzen, um andere für unsere Sache zu gewinnen. Sollten wir dabei – natürlich völlig unabsichtlich oder aus reiner Unwissenheit – gegen bestehende Prozesse verstoßen haben, dann halte ich es im Sinne der Erreichung unserer Ziele mit der Maxime „Lieber danach entschuldigen als vorher ständig um Erlaubnis fragen“.

Am Ende des Tages sind viele Tipps und Tricks keine Geheimnisse, sondern Dinge, die auf der Hand liegen – wir müssen Sie uns nur immer wieder – und rechtzeitig – ins Bewusstsein rufen. In diesem Sinne wünsche ich Euch erfolgreiches und wirksames Kommunizieren innerhalb und außerhalb Eures Unternehmens und auf dieser Basis begeisternde und erfolgreiche Produkte.

Thomas

„Strategie ohne Umsetzung ist ein Tagtraum – Umsetzung ohne Strategie ist ein Albtraum.“

(Frei nach japanischem Sprichwort: „理念なき行動は凶器であり、行動なき理念は無価値である“)

Dieser Text ist kein Plädoyer gegen Produktstrategien. Im Gegenteil: er ist die Aufforderung, Produktstrategien die Zuwendung und Aufmerksamkeit zu geben, die sie verdienen und dabei typische Fallstricke zu vermeiden.

Die Aussage kommt für die meisten unserer Leser hoffentlich nicht überraschend, aber auch in Zeiten zunehmender Agilität in der Produktentwicklung lohnt es sich, erneut zu betonen: du brauchst eine Produktstrategie. Es ist kein Zeichen von gelebter Agilität, sich ohne Strategie in die Entwicklung und Vermarktung eines Produkts zu stürzen.

In diesem Blog soll es um die häufigsten Fallen gehen, in die Produktmanager*innen bei der Entwicklung einer Strategie tappen können. Zwar kann dieser Beitrag nicht dafür sorgen, dass auf magische Weise in kurzer Zeit die perfekte Produktstrategie entwickelt wird, aber er kann viel Zeit und Mühen sparen, wenn man sich bewusst wird, welche klassischen Fehler zu vermeiden sind.

Um gleich zu Beginn mal mit ein paar Mythen zum Thema auszuräumen:

• Strategieentwicklung ist keine hohe Kunst, die auf Spezialwissen basiert, das man sich nur durch den Besuch von teuren Privatunis oder Business Schools aneignen kann. Jeder Mensch kann eine gute Produktstrategie schreiben. Es erfordert die Bereitschaft sich vorher mit Kunden, Markt, Wettbewerb und Technologien auseinanderzusetzen, zu lernen, zu reflektieren und – vor allem – den eigenen Schreibtisch zu verlassen. Das NIHITO-Prinzip: „Nothing interesting ever happens in the office“. Man könnte auch sagen “Gute Strategien entstehen nicht im stillen Kämmerlein“. Kontinuierliche Product Discovery ist hier ein wichtiger Baustein.
• Produktstrategie entsteht nicht einfach durch das Ausfüllen eines Templates. Sie ist das Destillat aus vielen Kundengesprächen und dem Verstehen ihrer Bedürfnisse, aus erweiterter Markt- und Wettbewerbsanalyse und dem Verstehen der eigenen Stärken und Schwächen. Vorlagen können einem helfen, die Strategie auf die richtigen Inhalte herunterzubrechen (Ziele, Zielgruppen, Erfolgsfaktoren, Maßnahmen und einiges mehr), aber sie führen nicht automatisch zur „richtigen“ Strategie.
• Die erfolgreichsten Techprodukte waren nicht einfach „das richtige Produkt zum richtigen Zeitpunkt“. Auch wenn man wenig davon hört: die erfolgreichsten Techprodukte basieren auf klaren Produktstrategien, die wiederum auf einer nahezu stoischen Kundenzentrierung fußen. (Manche Unternehmen verschweigen das allerdings gerne, weil sie dadurch besonders hellsichtig und genial erscheinen.)

Was ist dieses manchmal wenig greifbare Konzept „Produktstrategie“ eigentlich (außer ein Wort von dem man in Gesprächen mit Geschäftsleitung und Beratern in Anzügen ständig hört)?

Kurzgesagt ist es ein langfristig angelegter Aktionsplan zur Erreichung definierter Produktziele. Und weil der Zeithorizont langfristiger ist, hat die Produktstrategie eine etwas höhere Flughöhe und lässt Raum für taktische Anpassungen.

Eigentlich ziemlich offensichtlich, dass man eine Produktstrategie haben sollte, oder?

Nichtsdestotrotz überrascht es, wie viele Unternehmen sich nicht die Zeit nehmen eine klare Produktstrategie zu formulieren, vor allem in Software-Unternehmen (man kann schließlich vieles auch wieder anpassen, wenn es neue Ziele und Anforderungen gibt. Oh, hallo technische Schuld!)

Dafür gibt es einige Gründe, und die meisten haben damit zu tun, dass dort wo Menschen handeln auch Denkfehler und Fehlschlüsse passieren. So sehr wir uns auch einreden immer objektiv „nach gesundem Menschenverstand“ zu handeln, die eigene Perspektive ist ein Produkt unserer (limitierten) Erfahrungen und damit sehr subjektiv.

Wozu das Fehlen von Produktstrategien führen kann? Ein paar Szenarien:

• Der Geschäftsführer hat das Unternehmen weit gebracht und ist dementsprechend weiterhin sehr bestimmend. Ihr Wort zählt und übertrumpft am Ende alle anderen, auch wenn der „richtige Riecher“ eher auf Wissen von vor 5-10 Jahren basiert. „Et hätt noch immer jot jejange“. Und plötzlich holt einen die Marktrealität ein: der Wettbewerb hat bei Qualität und weiteren Leistungen aufgeholt. Neue Kundensegmente legen Wert auf Produktaspekte, die einem erst zu spät bewusst werden. Und sicher geglaubten Bestandskunden liebäugeln plötzlich mit der Konkurrenz.
• Das „Executive Team“ hat regelmäßig neue Ideen, die unbedingt noch mit in die Planung eingehen müssen. Pläne von vor 3 Monaten sind Schnee von gestern oder sollen bitte weiter „soweit möglich“ bedient werden. Nichts wird fertig, die Time-To-Market wird länger und länger, verpasste Deadlines sind die Norm.
• Kurzfristig anstehendende Kundenprojekte gehen fast immer vor der Verfolgung langfristiger Produktziele vor. Schließlich will man sich diese Deals nicht entgehen lassen, und für Strategie ist danach auch noch Zeit, wenn der Cashflow stimmt.
• Die Produktteams stehen unter enormen Druck, die Produkte performen einfach nicht wie sie sollen. Die Teammoral ist am Boden, Fluktuation hoch und Burnouts keine Seltenheit.

Das sind klassische Situation, die in Unternehmen auftreten, die nicht zusammen an der Erreichung von klar festgelegten und messbaren Zielen arbeiten. Mangels einer klaren Produktstrategie stehen die lautesten Meinungen, die stärksten Bauchgefühle, falschverstandene Agilität und Zielerreichung mittels „Druck von oben“ im Vordergrund. Alles keine nachhaltigen Erfolgsfaktoren.

Jetzt haben wir uns angeschaut, warum es zu häufig (fatalerweise) keine Produktstrategien gibt.

Leider ist auch eine Produktstrategie selbst nicht der automatische Weg zum Erfolg. Aber wenn man die typischen Fallen kennt, in die Produktstrategiker tappen können, kannst man ihnen Indiana-Jones-mäßig aus dem Weg springen und ans Ziel kommen (nämlich zur von allen verstandenen Produktstrategie, die zum nachhaltigen Produkterfolg führt).

Also, werfen wir einen Blick auf die typischen Gründe, warum Produktstrategien scheitern:

Häufig sind Techunternehmen (vor allem in einem Ingenieursland wie Deutschland) so besessen von ihren Technologien und Lösungen, dass sie aus den Augen verlieren, ob es sich dabei überhaupt um ein dringliches Problem handelt (und welche Alternativen die potentiellen Kunden zur Verfügung haben). Gut gemeintes erstes Feedback von wohlgesonnenen Bestandskunden und Kollegen kann das Gesamtbild weiter verzerren. Haben wir es uns mit Suggestivfragen bei der Validierung vielleicht zu einfach gemacht?

Die Lösung: die eigene Blase verlassen. Das Problem und seine Dringlichkeit validieren. Echte Lerngespräche mit Kunden führen, in denen es um die Bedürfnisse, Ziele und Arbeitsweisen der Kunden, und weniger um Produkt- und Lösungsideen geht.

Übrigens: „Wir gehen in die Cloud“ oder „Wir nutzen die Power der Blockchain“ sind keine Strategien, sondern lediglich technische Versatzstücke die möglicherweise dabei helfen können, Kundenbedürfnisse auf bessere Weise zu erfüllen. In die Strategie gehört aber vor allem die Information, welche Bedürfnisse von welchen Kundensegmenten das sind, wie sich das Unternehmen im Wettbewerb durchsetzen will (es ist bestimmt nicht das einzige, mit diesem Plan) und welche Initiativen entlang Entwicklung, Vermarktung und Abläufen in Angriff genommen werden müssen.)

Es ist ein klassischer Fehlschluss, wenn die Zielgruppe sehr breit definiert wird, hat man damit nicht automatisch ein größeres Verkaufspotenzial. Im Gegenteil: selbst die Kunden, die besonders vom Produkt profitieren würden erkennen das Potenzial nicht sofort hinter dem breiten Funktionsspektrum und der allgemeinen Ansprache.

Wenn Produkte ohne klare Zielgruppe entwickelt und vermarktet werden, enden sie häufig als Enttäuschung. Trotz breitem potenziellen Kundenspektrum lassen sich nur wenige davon überzeugen (auch, weil es der Preis dieser „Alleskönner“ meist in sich hat). Diesen Produkten merken Kunden an, dass sie eher ein Sammelsurium an Ideen sind, als ein in sich konsistentes Produkt mit klarem Zweck.

Ein Beispiel wäre eine B2B-Software für die Steuerung und Optimierung von Unternehmensprozessen. Schließlich hat ja jedes Unternehmen Geschäftsprozesse, die optimiert werden könnten, oder? Wenn wir aber nicht klar definieren, auf welche Segmente mit welchen Prozessen und dazugehörigen Daten wir das Produkt ausgerichtet haben, verzetteln wir uns in der Produktentwicklung, bei der Priorisierung von Anforderungen und bei der Vermarktung. Mit viel Konfiguration und Aufwand lässt es sich vielleicht für viele Zwecke nutzen, aber trotzdem wirkt es auf Kunden wenig zweckmäßig.

Die Lösung: eine klare Marktsegmentierung, basierend auf der Dringlichkeit für die Problemlösung, passender Zielgruppen (addressierbar, nachhaltig, kaufbereit), der Wettbewerbssituation und eigener technologischer Ausrichtung und Fähigkeiten. Dann fällt nicht nur die Vermarktung leichter (wir wissen schließnlich, welche Kunden besonders zu uns passen, wo sie sich aufhalten und wie sie angesprochen werden wollen), sondern auch der Vertrieb wird effektiver.

Sollte das „Alleskönner“-Produkt bereits im Markt sein, kann eine Modularisierung der Produktkomponenten dabei helfen, gezielte Anwendungspakete für einzelne Kundensegmente zu schnüren und zu bepreisen. Hier kann ein marktorientiertes Produktmanagement selbst mit umfangreichen Produkten und Plattformen gezielte Zielgruppenansprache ermöglichen.

Merke: Segmentierung ist eines der wichtigste Werkzeuge bei der Entwicklung von Produktstrategien.

Die Produktstrategie wurde vorgestellt und auch irgendwie abgenommen, aber in der Umsetzung stehen wichtige Ressourcen plötzlich nicht zur Verfügung, andere Initiativen werden vorgezogen und Meilensteine werden immer wieder verlegt. Diagnose: fehlendes Bekenntnis (neudeutsch „buy-in“) der Entscheider zur Strategie und daher auch der anderen Geschäftsbereiche, die für die Umsetzung so wichtig sind. Der Rückhalt bei der Umsetzung fehlt.

Dafür kann es mehrere Gründe geben.

1. Dem Produktmanager/der Produktmanagerin fehlt es an ausreichenden Belegen für die Strategie, das Management zeigt aber guten Willen und hofft auf „agile Arbeitsweise“ bei der die Belege mit der Zeit schon eintrudeln werden.
2. Das Management setzt auf zuviele Pferde gleichzeitig und muss daher regelmäßig Prioritäten und entsprechende Ressourcen verschieben. Strategien, die vor kurzem noch abgesegnet schienen sind plötzlich Schnee von gestern.

Die Lösung:

Klares Stakeholdermanagement, bei dem ein klares Bekenntnis zur Strategie und den benötigen Ressourcen gefordert wird.

Leider werden in vielen Unternehmen Produktstrategien immer noch stiefmütterlich oder halbherzig entwickelt. Dabei ist eine klare Produktstrategie wichtig, um sich nicht im hektischen Produktalltag mit seinen vielfältigen Anforderungen zu verzetteln. Vorlagen helfen, die Inputs zu strukturieren und auf Vollständigkeit zu prüfen, sie ersetzen aber keine Kunden- und Marktanalyse. Obwohl oft vernachlässigt, sind die Identifizierung von Kundensegmenten, die Validierung des Kundenbedarfs und das Sicherstellen des Engagements der Führungskräfte entscheidend, um die klassischen Fallstricke zu umgehen. Eine klare, zielgerichtete Produktstrategie ist der Kompass, der Unternehmen durch die turbulenten Gewässer der Marktentwicklung und Produktinnovation navigieren lässt.

Eine klare Produktstrategie ist kein Luxus, sondern eine Notwendigkeit für nachhaltigen Markterfolg.

Jan Harste

Produktmanager und Product Owner – zwei Titel, die auf den ersten Blick darauf schließen lassen könnten, dass es hier um denselben Job geht. Und das ist auch der Grund, warum in so manchem Unternehmen oder Produkt-Team Verwirrung darüber herrscht, wie sich diese Rollen denn abgrenzen lassen, wenn beide vorhanden sind.

Eine berechtigte Frage mit einer Antwort, die ein bisschen in die Historie dieser beiden Titel einsteigen muss. Der Job des Produktmanagers und die Rolle des Product Owners im Scrum Prozess sind unabhängig voneinander und aus anderen Kontexten entstanden, auch wenn es Überschneidungen gibt. Produktmanager gibt es mindestens seit den 90ern und ist die Weiterentwicklung von „Brand Managern“ (im FCMG-Segment) und „Program Managern“ (im Software-Bereich). Als essentieller Teil des Marketing-Mix sollte eine Person das Produkt, seine Promotion und Distribution und den Produkterfolg verantworten. Diese Person wurde Produktmanager genannt.

Die Rolle des Product Owners entstand als Teil von Scrum (eine Methode der agilen Produktentwicklung). Der Product Owner soll als interne Rolle des Scrum-Teams die Bedürfnisse der Anwender sowie des Marktes sowie Wettbewerb und zukünftige Trends repräsentieren. Product Owner haben zur Aufgabe sichzustellen, dass ein Produkt entwickelt wird, das für Anwender einen Mehrwert liefert, dass sie gerne nutzen und mit dem sich das Unternehmen nachhaltig im Wettbewerbsumfeld behaupten kann.

Vorweggesagt: es gibt hierbei nicht die eine Wahrheit und Definition, die bei jeder Organisation angewandt werden kann. Genau wie die Titel Produktmanager und Product Owner ihre eigene Entstehungsgeschichte haben, so haben auch Unternehmen eine eigene Historie, wie sie Produktmanager und Product Owner für sich definiert haben.

Das Thema wird dennoch insbesondere in Europa und im deutschsprachigen Raum immer wieder intensiv diskutiert. Vielleicht liegt es daran, dass deutsche Unternehmen gerne „Regeln und Klarheit“ haben und sich gerne klar definierten Normen anschließen. Vielleicht aber auch, weil Produktmanagement in Europa im Vergleich zu den USA eine jüngere Disziplin ist und sich daher parallel unterschiedliche Sichtweisen bildeten (die unterschiedlichen Kulturen und Sprachen mögen außerdem ihren Teil dazu beigetragen haben…).

Es ist daher wichtig, sich eine eigene Meinung zu beiden Rollen zu bilden und Klarheit in der eigenen Organisation zu schaffen. Der bekannte Product Coach und Autor Marty Cagan hat dazu wie gewohnt eine ziemlich eindeutige Meinung: “The Product Owner is just 10% of the Product Management job. Product Owner is a role. Product Management is a job.” Das ist natürlich sehr überspitzt formuliert. Dennoch stimme ich der Grundaussage zu. Die Unterscheidung zwischen “Job” und “Rolle” ist hier sehr nützliches Gedankenkonstrukt. Typischerweise vereinen Produktmanager mehrere Rollen in ihrem Job. Sie sind Innovationstreiber, Chancenmaximierer, Intrapreneure, Dolmetscher und Kommunikatoren, Champion des Kundenproblems oder auch Verbesserer und Optimierer. Das macht ihren Job so herausfordernd, aber gleichzeitig auch so spannend.

Mit 20 Jahren Erfahrung in Produktmanagement-Positionen bin ich natürlich voreingenommen. Dennoch habe ich in Zusammenarbeit mit Kunden und Partnern, sowie im Rahmen meiner Weiterbildung zum Certified Scrum Master und Agile Coach viele Einblicke in die Definition und Ausgestaltung dieser Rolle in der Praxis gewonnen. Eine der Hauptursachen für die Verwirrung um diese Begriffe ist, dass viele Organisationen diese Titel austauschbar verwenden, ohne die Ursprünge der Product Owner-Rolle zu kennen, die größtenteils durch Scrum geprägt wurde. Führungskräfte glauben oft fälschlicherweise, dass ein Product Owner einfach eine „moderne und agilere“ Beschreibung eines Produktmanager ist. Die Praxis zeigt jedoch, dass es viele Ausprägungen beider Rollen gibt, insbesondere wenn nur eine davon in einer Organisation existiert.

Ein guter Startpunkt ist das Framework von Paul Inness, das auf der Grundannahme basiert, dass für die erfolgreiche Produktentwicklung drei W-Fragen beantwortet werden müssen.

• Warum entwickeln wir das Produkt (welche Kunden- und Anwenderbedürfnisse werden erfüllt, was bringt es uns als Anbieter)?
• Was wird entwickelt? (welche Anforderungen und Jobs muss das Produkt erfüllen, welche Funktionen soll es beinhalten, was wäre ein MVP?)
• Wie erreichen wir das? (Welche technologischen Voraussetzungen brauchen wir dafür, wie gelingt die Umsetzung der Entwicklung?)

Die Verantwortung zur Beantwortung dieser Fragen liegt im Zusammenspiel von Produktmanager, Product Owner und Entwicklungsabteilung (natürlich mit Unterstützung weiterer Rollen wie z.B. Produktdesign, User Experience oder Interaktionsdesignern)

In der Praxis entstehen aus dem speziellen Unternehmenskontext heraus verschiedene mögliche Modelle beim Einsatz der Rollen Produktmanager und Product Owner:

1. Es gibt nur Produktmanager und die Product Owner-Rolle kommt nicht zum Einsatz (z.B. weil nicht nach Scrum-Methoden gearbeitet wird)
2. Es gibt Produktmanager, die gleichzeitig die Scrum Product Owner-Rolle übernehmen
3. Es gibt sowohl Produktmanager als auch Product Owner, die in gemeinsamer Abstimmung den Produkterfolg vorantreiben
4. Es gibt Product Owner, die auch Produktmanagement-Verantwortlichkeiten übernehmen
5. Es gibt nur Scrum-Product Owner und Produktmanagement-Verantwortlichkeiten werden in anderen Abteilungen übernommen oder finden nicht statt.

Hier einmal schematisch dargestellt:

Wie sieht es aber in der Praxis aus? Welche Konstellationen existieren in Unternehmen mit Produktmanagement-Organisationen?

Wir können diese Frage zum Glück beantworten, denn jedes Jahr führen wir eine Marktstudie zur Praxis im Produktmanagement und Produktmarketing durch. In der Studie von 2023 mit 947 Teilnehmenden aus 50 Ländern haben wir erneut die Frage gestellt, welche Produktmanagement- Rollen in ihrem Unternehmen existieren.

Das folgende Bild ergibt sich dabei für 2023:

Existiert nur eine der beiden Rollen, findet man in aller Regel eher die Rolle des Produktmanagers (Modell 1 – 21%) bzw. den Produktmanager dessen Rolle die Aufgaben des Product Owners im Scrum-Kontext beinhaltet (Modell 2 – 31%).

Existieren beide Rollen nebeneinander (Modell 3 – 32%) , fokussiert der Produktmanager sich typischerweise stärker auf das „Warum“ des Produkts (welche Probleme lösen wir, welche Kundenbedürfnisse adressieren wir). Der Product Owner konzentriert sich eher das „was“ (was ist das passende Produkt) und das “wie” (wie setzen wir das um). Letzteres sollte dabei vor allem in der Zusammenarbeit mit der Entwicklung gemeinsam erarbeitet werden. Der Product Owner ist für das Product Backlog verantwortlich und stellt sicher, dass das Team die richtigen Dinge entwickelt und auf die Bedürfnisse der Kunden und des Unternehmens ausgerichtet ist. Er arbeitet eng mit dem Team zusammen und stellt sicher, dass die priorisierten Anforderungen im Product Backlog verstanden und richtig umgesetzt werden. Product Vision und Roadmap können hier als Artefakte dienen, die von beiden Rollen gemeinsam gestaltet werden.

Sein Aufgabenfeld ist typischerweise breiter angelegt als die eine Product Owners:

• Ein Produktmanager ist häufiger im Kundenkontakt (über die Produktentwicklung hinaus)
• Ein Produktmanager agiert unternehmerischer und ist daher stärker in den betriebswirtschaftlichen Themen involviert, wie Geschäftskennzahlen, Business Pläne, Preisgestaltung, Finanzplanung, KPIs, Prognosen und Planung
• Ein Produktmanager hat mehr mit marktnahen Funktionen wie Marketing, Vertrieb und Support zu tun
• Ein Produktmanager interagiert häufiger mit nicht-produktbezogenen internen Stakeholdern wie Finanzen, Recht und Management
• Ein Produktmanager hat typischerweise eine höhere Verantwortung in Bezug auf P&L (Gewinn und Verlust).
• Ein Produktmanager sollte eher ein Generalist als ein Spezialist sein.

Fazit

Beide Rollen können allein existieren und unterschiedlich ausgestaltet werden. Haben Organisationen sowohl Produktmanager als auch Product Owner, sollten sie sich komplementär ergänzen. Die übergeordneten Ziele sind es gemeinsam sicherzustellen, dass die richtigen Produkte entwickeln werden, die den wichtigsten Bedürfnissen der Kunden aber auch des Unternehmens entsprechen, um so langfristigen Erfolg zu erzielen.

Wie auch immer Dein Unternehmen aussieht, das Fundament für wirksame Product Owners und Produktmanagers ist eine klare Rollendefinition. Stelle also sicher, dass Deine gesamte Organisation ein gemeinsames Verständnis von den wichtigsten Aufgaben und Verantwortungen hat.

Ulf Greiner – Trainer bei ProduktManagementor und Agile Coach

Vielleicht kennst Du bereits unsere Leseliste für Produktmanagement-Bücher, sie listet Bücher auf, die Produktmenschen unserer Meinung nach kennen und idealerweise gelesen haben sollten.

Jetzt gehen wir einen Schritt weiter und haben – mit Unterstützung von Autor Nils Janse – die wichtigsten Bücher in einen visuellen Leitfaden untergebracht, mit dem Du einen Überblick bekommst, welches Buch sie für welchen Zweck besonders eignet. Den Original-Blogartikel von Nils findest Du hier.

Wir wünschen viel Spaß mit unserem Visuellen Leitfaden für die besten Produktmanagement Bücher 2022!

Fazit

Dies ist unser bescheidener Versuch, eine aktuelle Übersicht zur unser Meinung nach besten Literatur für Menschen zu liefern, die Produkte entwickeln möchten, die die Kunden lieben. Sie hat natürlich keinen Anspruch auf Vollständigkeit, und wir empfehlen jedem Leser individuell zu prüfen, welche Bücher und welcher Stil zu den aktuellen Herausforderungen, der persönlichen Entwicklung und der Lebenszyklusphase des Produkts passen.

Wir hoffen aber, dass unser visueller Leitfaden den ein oder anderen hilfreichen Impuls geben kann, mehr über bestimmte Themen zu lernen, tiefer einzusteigen und sich mit mehr Wissen für die Aufgaben und Herausforderungen zu wappnen.

Um dieses Thema zu beleuchten, greife ich hier auf Empfehlungen zurück, die auch in meinen Beratungsprojekten immer wieder eine große Rolle spielen – im Wesentlichen geht es im Produktmanagement von Dienstleistungsprodukten um drei Besonderheiten:

1.Dienstleistungen sind nicht greifbar.

Das heißt, dass man als PM die Dienstleistungen für Kunden glaubhaft machen muss. Dadurch, dass man sie bildlich beschreibt, Beispiele und Referenzen schafft und möglichen Kunden Ergebnisse zur Verfügung stellt. Wichtig ist auch, interne Qualitätsstandards zu etablieren und diese den potenziellen Auftraggebern aufzuzeigen. Durch die fehlende Gegenständlichkeit müssen auch kritische Punkte im Verkauf (wie ausreichende Bedarfserhebung und Kosten-Nutzen-Transparenz) noch stärker als bei konkreten Produkten beachtet werden.

2. Dienstleistungen sind nicht lagerbar.

Die Unmöglichkeit, Dienstleistungen zu lagern, zeigt stark die Beschränkungen auf, denen man als PM eines Dienstleistungsprodukts unterliegt. Dazu gehören die Limitationen durch vorhandenes Personal, die Begrenzungen im Vertrieb (klassische Vertriebskanäle sind oft nur schlecht nutzbar) und die Notwendigkeit, bestimmte Kapazitäten (Räumlichkeiten und Ausrüstung) ständig bereitzuhalten. Auch in diesem Bereich zeigt sich deutlich die Notwendigkeit, als PM Standards zu schaffen und damit den Einsatz der vorhandenen Ressourcen zu optimieren.

3. Dienstleistungen haben oft einen hohen Personenbezug.

Dienstleistungsprodukte sind in vielen Fällen untrennbar mit den Personen verbunden, die sie erbringen. Dieses Merkmal zeigt auf, dass der Erfolg eines Dienstleistungsanbieters in vielen Fällen vom Einsatz und der Kompetenz seiner Mitarbeiter bestimmt wird. Diese Verknüpfung reicht im Extremfall bis zur Abhängigkeit von hochkarätigen Spezialisten. Solch eine Situation kann man als PM mit strengen Vorgaben und autoritärem Führungsstil nicht in den Griff bekommen. Motivation, Vertrauen und Weitblick des einzelnen Mitarbeiters, die für eine starke Kundenorientierung notwendig sind, lassen sich nur auf einem Weg erreichen: durch starkes Einbeziehen des einzelnen Mitarbeiters in die Entwicklung der Dienstleistung und der betroffenen Prozesse.

In einem gemeinsamen Webinar im Mai 2022 haben Jan Harste und ich diese Eigenschaften und ihre Konsequenzen für das Produktmanagement näher beleuchtet.

Zusätzlich haben wir drei Kennzeichen vorgestellt, mit denen sich jedes Dienstleistungsprodukt genauer charakterisieren lässt: Der Immaterialitätsgrad, der Interaktionsgrad und der Individualisierungsgrad. Diese drei Parameter liefern für jedes spezielle Dienstleistungsprodukt sofort konkrete Hinweise, worauf in der Vermarktung der jeweiligen Leistung besonders zu achten ist. Das Webinar wurde aufgezeichnet und kann hier angesehen werden:

Wie in unserer Diskussion deutlich herauskommt, spielen Standardisierung und Qualitätsmanagement von Dienstleistungsprodukten eine große Rolle. Mehr darüber ist in diesen beiden Publikationen zu erfahren:

Abschließend nochmals ein herzliches Danke an Jan Harste und Thomas Moder für die Einladung zu den Gastbeiträgen.

Allen Leserinnen und Lesern dieser Zeilen wünsche ich viel Erfolg beim Design, bei der Vermarktung und beim Management ihrer Dienstleistungen!

Erwin Matys

Wir von ProduktManageMentor bedanken uns ebenfalls bei Erwin Matys für diesen aufschlussreichen Beitrag und das Webinar!

von Thomas Moder
Produktmanagement-Enthusiast und PMM-Trainer und -Mentor

Als Produktmanager bin ich es gewohnt, Segmentierungsmodelle für alle möglichen Märkte zu erstellen, um Produktchancen, Ansprache und Maßnahmen besser einschätzen und priorisieren zu können. Für mich fühlt sich das als etwas Logisches und Natürliches an. Doch in Unternehmen kann das natürlich komplett anders empfunden werden. Gerade vertriebs- und projektorientierte Organisationen, in denen maßgeschneiderte Kundenlösungen für individuelle Anfragen und Anforderungen entwickelt werden tun sich schwer mit dem „Aufteilen des Markts“.

Vergangene Woche hatte ich eine sehr interessante Diskussion mit einem Team von Ingenieuren aus einem Unternehmen, das sich mit genau solchen maßgeschneiderten Lösungen beschäftigt. Das Unternehmen hatte festgestellt, dass seine Kostenstruktur bei weitem nicht ideal war.
Zusätzlich machte es auch das optimierte Setup fürs Projektgeschäft schwer bis unmöglich, die entwickelten Dinge (die in der aktuellen Aufstellung im Wesentlichen das Knowhow und die Erfahrung der Mitarbeiter waren) breiter am Markt zu skalieren.
Als ich ihnen ein einfaches zweidimensionales Segmentierungsmodell vorschlug, um die Menge ihrer potentiellen Kunden besser zu strukturieren, rief das einige – was soll ich sagen – „interessante“ Reaktionen in der Gruppe hervor. Diese würde ich als typisch für Unternehmen bezeichnen, die sich vom reinen Projektgeschäft in Richtung Produktgeschäft entwickeln wollen. In diesem Blog möchte ich diese Reaktionen teilen und Hilfestellung geben, wie damit umgegangen werden kann.

Die erste und stärkste Reaktion war ANGST – konkret die Angst, eine Vertriebsgelegenheit mit einem Kunden zu verpassen, der sich nicht exakt einem der von mir vorgeschlagenen Segmente zuordnen ließ.

Das Bild, dass ich gezeichnet hatte, sah in etwa wie folgt aus:

Für die Kollegen aus der Entwicklung und dem Projektmanagement sah das Ganze eher aus wie ein löchriges Fischernetz eines Fischers, der es doch aber gewohnt war, selbst den kleinsten Fisch in seinem Netz zappeln zu sehen. Ihr Unbehagen erwuchs aus der Sorge, dass jede Menge Fische – darunter potenziell auch sehr wertvolle – durchs Netz schlüpfen würden. Wie konnte ich also ihre Bedenken ausräumen? Denn ich verglich meine abgeleiteten Segmente eher mit einem Satz von Fliegenklebern – mit unterschiedlichen Farben und Düften, an denen jeweils ganz bestimmte Gruppen von Insekten kleben bleiben. Oder – um in der Analogie des Fischers zu bleiben – die Segmente als ein Satz unterschiedlicher Köder zu verstehen, die jeweils eine ganz bestimmte Sorte von Fischen anlocken sollten. Dabei habe ich die Köder natürlich nicht zufällig gewählt. Nein – meine Wahl beruhte auf jeder Menge an Erfahrung und Wissen, dass bestimmte Köder eben von ganz bestimmten Fischen bevorzugt werden. Die Wahl der Köder war somit eine ganz bewusste Entscheidung, die ich auf Basis der von mir bevorzugten Fische traf. Denn ich möchte schließlich diejenigen fangen, die am besten schmecken oder – um in Business Terms zu sprechen – die größten Umsätze oder Margen für mich bringen.

Sogar die Mitarbeiter stimmten mir zu. Denn auch sie hielten natürlich gerne nach den größeren Fischen (oder schmackhafteren?) Ausschau und sie bejahten, dass sie durchaus wüssten, welches diese größeren Fische wären.
Trotzdem waren sie zögerlich, Unterschiede zwischen verschiedenen Gruppen von Fischen (Kunden) zu machen, innerhalb jeder Gruppe eine Ähnlichkeit der Kundenanforderungen oder Kundenprobleme (speziell im B2B Bereich) festzustellen und typische Lösungen anzuerkennen, die gerade die Probleme dieser Gruppe löst. Es könnte ja schließlich ein wichtiger Kunde dabei sein, auf den die Lösung nicht passt. Einen Teil ihrer Bedenken konnte ich ausräumen, indem ich ihnen versicherte, dass wir die meisten Segmente bewusst um die großen Fische herum bauen würden, die sie in der Vergangenheit gefangen hatten. Eine allgemeine Lösung für ein solches Kundensegment wäre in der Regel auch attraktiv für ihre bestehenden großen Kunden, auch wenn sie vielleicht nicht zu 100% ihre Anforderungen treffen würden. Ein gewisses und angemessenes Level an Personalisierung oder Customisation in die DNA einer solchen – generischen – Lösung einzubauen, bringt uns dann einen weiteren Schritt voran, um projektgetriebenen Teams ihre Skepsis gegenüber Marktsegmentierungsmodellen zu nehmen. Wir investieren nämlich an dieser Stelle in einen gemeinsamen Lösungsbestandteil (nennen wir ihn „Plattform“ oder „Referenz-Design“ oder …), welcher für alle Kunden dieses Segmentes attraktiv ist und erweitern das ganze dann noch um die Flexibilität, daraus kundenspezifische Anpassungen abzuleiten. Die Gemeinsamkeiten möglichst früh im Entwicklungsprozess zu finden, ist der Schlüssel hier.

Für das Unternehmen bedarf es einer bewussten Entscheidung, ob sie einen solchen Arbeitsmodus aufnehmen wollen. Er bedeutet gerade am Anfang des Entwicklungsprozesses mehr Zeit und Investitionen (die Gemeinsamkeiten von Kundenanforderungen auszuloten). Diesem Aufwand steht dann jedoch auch die Chance gegenüber, das Geschäft schneller und profitabler zu skalieren. Projektgetrieben Unternehmen tun sich erfahrungsgemäß sehr schwer mit einem solchen Schritt. Oft ist es ein geeigneter Kompromiss, die Vorgehensweise erst mal in einem abgegrenzten Teil ihres Geschäftes aufzusetzen, während der große Teil des Geschäfts nach den bekannten Mustern weiterläuft.
Immer noch nicht überzeugt? Tatsächlich sah ich in den Augen einiger Mitarbeiter immer noch die Angst, dass einiges an kleinen Fischen durchs Netz flutschen und für immer (oder zumindest für die nächste Zeit) verloren wären. Nun, in diesem Fall war es nun an mir, einige Beispiele aufzulisten. Denn Lösungen, die wir gezielt für ein ganz bestimmtes Kundensegment entwickelt hatten, haben in der Regel auch eine gewisse Attraktivität für Kunden, die sich eben nicht genau diesem Segment zuordnen lassen.
Nehmen wir die Automobilindustrie als Beispiel. Für wen wurde der VW Caddy wohl ursprünglich entwickelt? Und wer kauft ihn heute? Für wen war das iPhone ursprünglich gedacht? Und wer sind die Kunden heute?

Gut! Wenn die Argumentation an dieser Stelle immer noch keine Früchte trägt, dann macht es tatsächlich auch Sinn, die Ambition eines Unternehmens, aus dem reinen Projektgeschäft herauszutreten, zu hinterfragen. Vielleicht ist das Unternehmen dann tatsächlich noch nicht reif genug, einige Risiken einzugehen, um danach mit einem stark wachsenden Geschäft belohnt zu werden. In diesem Fall ist es vielleicht besser, beim bekannten Modell zu bleiben – oder wie wir Deutschen auch gerne sagen: „Schuster, bleib bei Deinen Leisten“.

Die zweite Reaktion des Teams war nicht direkt Angst, sondern eher ein Gefühl der Unsicherheit oder Bedenken. Meine Gegenüber forderten mich heraus und fragten „Wie kannst Du sicher sein, dass die Achsen, die Du gewählt hast – erinnert Euch an das Beispiel der Weinkäufer vorne – die richtigen sind?“ An der Stelle erklärte ich ihnen, dass es kein reines „Richtig“ oder „Falsch“ gibt, um die richtigen Achsen im Rahmen eines Segmentierungsmodelles zu finden. Das Vorgehen entspricht dabei eher einer Mischung aus Wissenschaft und Erfahrung. „Aber wenn wir andere Achsen wählen, dann kommen wir ja zu komplett anderen Segmenten und woher wissen wir dann …“ war ihr nächster Einwand.
In der Denke der Kollegen aus R&D und Projektmanagement (und ich glaube, das ist ganz typisch), waren sie auf der Suche nach der 100% Lösung. Um die Bedenken hier zu zerstreuen, hilft es, von der Theorie in die konkrete Praxis zu wechseln. Ich forderte das Team auf, Vorschläge zu den Dimensionen (Achsen) einer möglichen Segmentierung in ihrem Bereich zu machen. Die Vorschläge müssten geeignet sein, um Kundensegmente in einer relevanten Art und Weise voneinander abzugrenzen – relevant in Sinne typischer Kundenanforderungen oder Kundenprobleme (eine Abgrenzung aufgrund des Alters des Einkaufsleiters wäre wohl nicht relevant in unserem Sinne 😊). Danach sollten sie an einer Reihe von Möglichkeiten arbeiten, zwei der potentiellen Achsen miteinander zu kombinieren und in das resultierende Koordinatensystem einige typische Kundensegmente einzuzeichnen.

Um beim Beispiel des Fischers und der Fische zu bleiben, könnten ihre Segmentierungsmodelle in etwa wie die folgenden ausgesehen haben.

An dieser Stelle stellen die Leute dann in der Regel fest, dass es mehrere Optionen gibt, die in ihrem spezifischen Kontext Sinn ergeben. Aber es kristallisiert sich immer eine Option, die für ihre Zwecke und für ihr Business am besten passen würde. Diese Möglichkeit lässt sich (in der Regel) nicht über einen Algorithmus finden, der die spezifische Natur des Geschäfts, in dem man tätig ist, nicht berücksichtigt. Ja – es kann extrem hart sein, an dieser Stelle Entscheidungen zu treffen. Und das Team ist vielleicht in Versuchung, ein 10-dimensionales Segmentierungsmodell zu entwerfen (mit 587 Segmenten – die am Ende einen Kreis um jeden einzelnen Kunden reflektieren – also genau das Geschäftsmodell wiedergibt, dem das Unternehmen aktuell folgt).

Es sollte nicht allzu schwierig zu argumentieren sein, dass wir einige Vereinfachungen anwenden müssen, damit unser Modell verständlich („ich versteh’s auf den ersten Blick“) und die Anzahl der Segmente überschaubar bleibt. Mit statistischen Methoden lässt sich (bei Verfügbarkeit von sehr vielen Daten) dann eine Reduktion von Segmenten durch „Clustering“ erreichen. Das wird jedoch in den meisten Fällen absolut overengineered und auch zu teuer sein. Am Ende wollen wir unser Business besser strukturieren und Entscheidungen treffen über Investitionen, die mehr als einen einzigen Kunden glücklich zu machen können.

Nachdem wir uns geeinigt hatten, an einigen unserer Entwürfe für ein Segmentierungsmodell weiter zu tüfteln, folgte Reaktion Nummer 3: „Was sagt uns das jetzt? Was machen wir jetzt damit? Welchen Impact macht das Modell jetzt?“

Ganz ehrlich – das hätte mir nicht passieren sollen und offensichtlich hatte ich einen miserablen Job gemacht. Meine Aufgabe war es doch, vorab ausreichend zu motivieren, warum wir ein solches Segmentierungsmodell erarbeiten sollten, wie es uns helfen kann unser Geschäft voranzubringen und wozu wir es konkret nutzen würden. Nehmt es also als „Best Practice“, nicht zu viel Wissen über das Thema Marktsegmentierung oder Kundensegmentierung vorauszusetzen. Verwendet mehr Zeit am Anfang – mehr als ihr Euch vorstellen könnt – um Sinn und Zweck einer solchen Segmentierung ausführlich zu erklären. Dies hätte eigentlich meine erste Priorität sein sollen und ich hätte die Basics besser erklären sollen, bevor die weiteren Diskussionen im konkreten Umfeld dann folgen. Was wären also meine Antworten auf die Fragen „Was sagt uns das jetzt? Was machen wir jetzt damit? Welchen Impact macht das Modell jetzt?“ gewesen?

Gegenüber Kollegen oder Teams, die es gewohnt sind in einzelnen Kundenprojekte zu arbeiten, können Euch die folgenden Erklärungen nützen:

1. Das gemeinsame Ziel verdeutlichen

Am Anfang sollten wir nochmal klarstellen, dass wir alle das gemeinsame Ziel haben, unser Business zu skalieren. Unser Ziel ist, vorausschauend Entwicklungen vorantreiben, die Nutzen stiften oder Probleme lösen für mehr als einen einzelnen Kunden. Im Wesentlichen sollte es darum gehen, Liefer- oder Lösungsbestandteile anzuvisieren, die wir einmal entwickeln, aber mehrfach verkaufen können.

2. Bisherige Vorgehensweisen hinterfragen

Ist das erst mal geschafft, dann fragt (und dokumentiert die Antworten) in die Runde „Was hat uns in der Vergangenheit denn abgehalten, genau das zu tun?“ und mit hoher Wahrscheinlichkeit werdet ihr Antworten wie die folgenden bekommen.

• „Der Zeitplan des (späteren) Kunden B hat sich gebissen mit dem Zeitplan des (früheren) Kunden A …“
• „Nun, im Prinzip wollte Kunde B was ähnliches wie Kunde A, aber das wussten wir ja nicht, als wir die Lösung für Kunde A entwickelt haben, weil die Anfrage von B kam erst viel später …“
• „Weil wir die Anforderungen von Kunde B bei der Entwicklung für Kunde A nicht berücksichtigt haben, konnten wir auch nicht einfach Teile aus der Lösung für A herausschneiden und sie mit weiteren Teilen für B anreichern …“

Stellt sicher, dass solche Dinge auf den Tisch kommen. Das Team sollte sich einig sein, dass die Vorgehensweise „Lass uns mal sehen, was wir für Kunde A entwickelt haben und checken, ob wir was davon auch für Kunde B, C, D oder E brauchen können …“ NICHT zielführend ist. Sollte so etwas je funktioniert haben, dann ist es eher eine Sache reinen Zufalls in einem projektgetriebenen Markt.
Alle im Team sollten kurz reflektieren, warum in der Vergangenheit kein besserer Ansatz gefunden wurde (vielleicht hat man es einfach nicht versucht …)

3. Gemeinsamkeiten identifizieren

Wenn wir also tatsächlich wegkommen wollen von einem Ansatz reiner „maßgeschneiderter“ Lösungen für einzelne Kunden, müssen wir zwingend ein besseres Verständnis entwickeln über die Gemeinsamkeiten zwischen unseren potentiellen Kunden sowie ihren Anforderungen und Problemen. Die Identifikation dieser Dinge wird uns Zeit und Vorab-Investitionen abfordern für Markt- und Kundenrecherche.

4. Kundensegmente ordnen

Wenn wir dann aber tatsächlich Gemeinsamkeiten/Ähnlichkeiten in Kundenbedürfnissen oder Kundenproblemen gefunden haben, können wir diese Kunden auch einem „Kundensegment“ zuordnen. Haben wir dann den Markt in solche Segmente aufgeteilt, haben wir einen perfekten Startpunkt um gemeinsame Lieferbestandteile (Lösungsbestandteile, Assets, Plattformen, …) zu entwickeln, die für alle Kunden eines Segmentes attraktiv sind. Investitionen können somit über mehrere Kunden geteilt werden und müssen nicht innerhalb eines einzelnen Kundenengagements monetarisiert werden (Was vermutlich unseren Angebotspreis in die Höhe treibt und eventuell zum Verlust des Kunden führt).

5. „Sanity Check“ für das Segment durchführen

Für jedes abgeleitete Segment sollten wir einen „Sanity Check“ machen. Ist das Segment homogen, nachhaltig, groß genug, profitabel und für uns adressierbar? Versucht hierbei z.B. mit einer Top-Down oder Bottom-Up-Analyse das realistische Potenzial in den einzelnen Segmenten abzuschätzen.

6. Segmente priorisieren

Dass wir nun in unserem Markt eine Anzahl von Segmenten identifiziert haben, bedeutet nicht automatisch, dass wir auch alle diese Segmente mit unserem Angebot bedienen müssen. An dieser Stelle sind wir gefordert, NEIN zu sagen zu bestimmten „Business Opportunities“ zugunsten von langfristig besseren Business Opportunities. Es mag gute Gründe geben, ein Segment zu adressieren und ein anderes dafür zu vernachlässigen. Das können zum Beispiel die große Kundennähe oder die verfügbare Technologie für ein Segment sein oder aber fehlender Vertriebskanal, Support Organisation oder Entwicklungskapazitäten auf der anderen Seite. Unser Anliegen muss es sein, Investitionen dahin zu leiten, wo sie uns den größten Erfolg versprechen. Damit sollten wir für jedes Segment auch verstehen, welchen Teil des Marktes (in %, € oder $) es repräsentiert.

7. Das Segmentierungsmodell konsequent anwenden

Es gibt viele Antworten auf die Frage „Ja, und was machen wir jetzt mit dem Segmentierungsmodell? Ist das nicht nur Theorie?“

• A) Der wichtigste Grund wurde bereits genannt – wir nutzen es, um zu verstehen und zu entscheiden, auf welche Kunden wir unser Angebot abzielen.
• B) Wir sollten das Modell kontinuierlich heranziehen um gesamtheitlich über unseren Investitionsfokus zu entscheiden – in R&D, Vertrieb, Marketing, Produktion, Support usw. Das Wissen über Bedürfnisse und Probleme der Segmente wird uns nicht nur helfen zu entscheiden, WO (in welches Segment) wir investieren wollen, sondern WAS (Plattformen, …) wir schaffen wollen über Vorab-Investitionen in Lösungen, welche die von uns ermittelten Kundenbedürfnisse und -probleme adressieren.
• C) Wann immer wir im Zweifel sind, ob wir uns auf ein bestimmtes Kundenengagement einlassen sollen, können wir das Modell heranziehen, um zu beurteilen, ob der Kunde und seine Anfrage zu dem passen, was die Kunden aus unseren Zielsegmenten typischerweise fordern. Falls nein, bewegen wir uns wahrscheinlich in eine Sackgasse und die Lösung kann nur einmal verkauft werden.
• D) Unser Modell unterstützt den Rest der Organisation, unseren Kundenfokus zu verstehen und die richtigen Kommunikationskanäle und Botschaften zu wählen. Den Vertriebskanälen hilft es, einem Kunden ein passendes Angebot zu machen, dass mit hoher Wahrscheinlichkeit, ein Bedürfnis oder Problem des Kunden adressiert als der Ansatz – und glaubt mir ich sehe das viel zu oft – „Lass uns dem Kunden mal alles erzählen, was wir in der Vergangenheit so gemacht haben …“
• E) Unser Segmentierungsansatz hilft uns, unser Angebot und unsere Lösungen in einer strukturierten Art und Weise innerhalb und außerhalb des Unternehmens zu kommunizieren. Den Startpunkt bildet dabei immer Das Segment und dessen Bedürfnisse oder Probleme und von dort bilden wir die Brücke zu den Lösungen, die wir speziell für dieses Segment konzipiert und entwickelt haben. Eine solche Vorgehensweise verspricht größere Erfolge als der allzu oft verwendet „One Size Fits All“ Approach.

Die Reaktionen #1 bis #3 stellen ein durchaus übliches Szenario dar in Unternehmen, die vom Projektgeschäft ins Produktgeschäft streben. Eine Wandlung im „Mindset“ solcher Unternehmen ist dabei genauso notwendig, wie der Aufbau von Marktwissen und Prognosen über zukünftige Geschäftsaussichten. Ein Segmentierungsmodell ist dabei ein wertvoller Bestandteil, die Sicht auf den Markt zu strukturieren und Entscheidungen über zukünftige Vorab-Investitionen zu treffen.

Thomas Moder – ProduktManageMentor Trainer und Mentor