Aus unserer Erfahrung in über 1.200 Projekten im DACH-Mittelstand sehen wir: Unternehmen suchen einen „Product Owner" nach Scrum-Guide-Reinform und finden kaum jemanden, der die Rolle in einem 250-Personen-Haus methodisch leben kann. In ERP-Einführungen verschmilzt die PO-Rolle häufig mit der Projektleitung — methodisch falsch, organisatorisch nachvollziehbar.
Was sind die Aufgaben eines Product Owners?
Ein Product Owner verantwortet die Wertmaximierung des Produkts. Er definiert das Product Goal, priorisiert das Product Backlog, kommuniziert es transparent und vertritt die Stakeholder. Im Scrum-Framework ist der PO immer eine Einzelperson — kein Gremium.
Die formale Rollendefinition stammt aus dem Scrum Guide 2020 (Schwaber & Sutherland): „The Product Owner is accountable for maximizing the value of the product." Die deutsche Fassung des Scrum Guide 2020 nennt vier Verantwortungsbereiche: Entwicklung und Kommunikation des Product Goal, Erstellung der Backlog-Items, Reihenfolge der Items und Transparenz des Product Backlog. Eine wichtige terminologische Verschiebung der 2020er-Fassung: aus „role" wurde „accountabilities". Der PO trägt keine Rolle, er trägt Rechenschaft.
Sechs Aufgabenfelder prägen die Rolle in der Praxis:
- Product Goal definieren — das langfristige Zielbild, abgeleitet aus Unternehmens- und Kundenstrategie.
- Product Backlog pflegen — Erstellung, Verfeinerung und Reihenfolge aller Items, inklusive User Stories und Akzeptanzkriterien.
- Stakeholder-Kommunikation — Abstimmung zwischen Fachbereich, Geschäftsführung, Kundinnen und Entwicklungsteam.
- Sprint-Planning und Sprint-Review — Mitgestaltung des Sprint Goal, Akzeptanz oder Ablehnung von Inkrementen.
- Backlog-Transparenz — Sicherstellen, dass alle Beteiligten Stand und Priorität jeder Position verstehen.
- Wertentscheidungen treffen — Nein-sagen können, Prioritäten verschieben, unliebsame Entscheidungen vertreten.
Die Abgrenzung klärt mehr als jede Stellenanzeige: Der Scrum Master verantwortet das „Wie" des Prozesses, der PO das „Was" des Produkts. Der Product Manager (SAFe) verantwortet die strategische Roadmap — der PO das taktische Backlog. Der ERP-Projektleiter verantwortet Vertrag, Budget, Anbieter-Steuerung — der PO die fachlichen Anforderungen. Im Konzern werden diese Rollen sauber getrennt; im DACH-Mittelstand sitzen sie regelmäßig in einer Person — und genau dort liegt der häufigste Rollenkonflikt.
Warum die PO-Rolle 2026 im DACH-Mittelstand zählt
Drei Treiber machen die PO-Rolle 2026 zum Engpass im DACH-Mittelstand: beschleunigte ERP-Modernisierung, knappe interne Methodenkompetenz und die wiederkehrende Verwechslung zwischen Product Owner und ERP-Projektleiter in Häusern mit 50 bis 500 Beschäftigten.
Erstens: agile Verbreitung. Agile Methoden haben sich im deutschen IT-Bereich breit etabliert, Scrum ist das dominierende Framework. Im Mittelstand fehlt aber häufig die entscheidungsfähige PO-Besetzung — die Methode ist verbreitet, die Rolle selten sauber verankert.
Zweitens: Personalknappheit und Teilbesetzung. Laut StepStone-Gehaltsdaten Product Owner 2026 liegt das Mediangehalt bei rund 61.700 Euro brutto im Jahr, die Spanne reicht von etwa 54.000 bis 73.700 Euro; aktuell sind rund 1.029 PO-Stellen ausgeschrieben. Aus unserer Erfahrung wird die Rolle im Mittelstand häufig in Teilzeit oder als Kombinationsrolle besetzt — eine Vollzeit-PO-Stelle ist im 200-Personen-Haus oft schlicht nicht refinanzierbar.
Drittens: ERP-Modernisierung und Rollenverwechslung. In unseren Projekten der letzten Jahre sehen wir: Sobald Vertrag, Budget und Anbietersteuerung in einer Person mit der Backlog-Hoheit liegen, leidet entweder die methodische Sauberkeit oder die kommerzielle Steuerung. Wir trennen in unserer vendor-neutralen ERP-Beratung konsequent: PO für das fachliche Was, Projektleitung für das kommerzielle Wie.
Praxisbeispiel: Mittelständischer Maschinenbauer, ca. 280 Beschäftigte
In einer ERP-Einführung bei einem süddeutschen Maschinenbauer mit rund 280 Beschäftigten haben wir den klassischen Mittelstands-Rollenkonflikt erlebt: Der designierte „Product Owner" war faktisch zugleich ERP-Projektleiter und Lenkungsausschuss-Mitglied — in keiner Rolle ausreichend wirksam.
Ein Maschinenbauer mit rund 280 Beschäftigten, drei Standorten und einer ERP-Landschaft aus dem späten 2000er-Jahrzehnt hatte die Modernisierung gestartet. Die Geschäftsführung hatte den Leiter Auftragsabwicklung als „Product Owner ERP-Einführung" ernannt. Methodisch verständlich — er kannte die Prozesse, hatte das Vertrauen der Belegschaft. Faktisch war er aber gleichzeitig Vertragsverantwortlicher gegenüber dem Anbieter, Budgetinhaber und Lenkungsausschuss-Mitglied.
Nach fünf Monaten verlor das Projekt Tempo. Der Sprintplan rutschte um drei Sprints. Der Anbieter eskalierte vertragliche Klärungen — auf denselben Schreibtisch, an dem die User Stories priorisiert wurden. Backlog-Verfeinerung — laut Scrum.org-Definition eine fortlaufende Aktivität — fand zwischen Tür und Angel statt. Wir wurden zur Wiederaufsetzung gerufen.
Die methodische Korrektur war pragmatisch. Wir haben die Doppelrolle aufgelöst. Der Leiter Auftragsabwicklung übernahm fortan die reine Product-Owner-Verantwortung mit klarer Backlog-Hoheit, 50 Prozent seiner Arbeitszeit, mit dokumentiertem Stellvertretermodell. Die ERP-Projektleitung — Vertrag, Budget, Anbieter-Steuerung — übernahm die kaufmännische Leitung mit externer Unterstützung durch uns. Im Lastenheft haben wir beide Rollen explizit ausgeschrieben, inklusive Eskalationspfade.
Das Ergebnis nach acht Monaten: stabiler Sprintrhythmus, konsistentes Backlog mit gepflegter Priorisierung, Nutzerakzeptanz von 87 Prozent — keine vertragliche Eskalation mehr auf demselben Schreibtisch. Der Hebel war methodisch banal: Trennung zweier Rollen, die der Scrum Guide 2020 nie zusammengedacht hatte.
Was Product-Owner-Leitfäden verschweigen
Drei Punkte, die gängige Product-Owner-Leitfäden in ihrer Konzernlogik nicht abbilden — und die aus unserer Erfahrung im DACH-Mittelstand zwischen 50 und 500 Beschäftigten regelmäßig über Erfolg oder Scheitern einer PO-Besetzung in ERP-Projekten entscheiden.
1. Der Product Owner im DACH-Mittelstand ist fast nie Vollzeit
Der Scrum Guide 2020 setzt implizit voraus, dass der PO seine volle Arbeitszeit für ein Produkt aufwendet. In Konzernen mit dedizierten Produktorganisationen funktioniert das. Im Mittelstand zwischen 50 und 500 Beschäftigten ist die Vollzeit-PO-Rolle weder besetzbar noch refinanzierbar. In unseren Projekten kombinieren wir die PO-Aufgaben fast immer: PO plus Leitung Auftragsabwicklung, PO plus Produktmanagement, PO plus Vertrieb. Auch der Markt zeigt das: Ein Teil der ausgeschriebenen PO-Stellen wird in Teilzeit angeboten. Faustregel: mindestens 50 Prozent PO-Zeit, klare Stellvertretung, dokumentierte Entscheidungsbefugnis.
2. Product Owner ist nicht ERP-Projektleiter — und umgekehrt
Der häufigste Rollenkonflikt im Mittelstand entsteht, wenn die PO-Funktion in einer ERP-Einführung mit der Projektleitung gleichgesetzt wird. Methodisch sind das zwei verschiedene Rollen: Der PO verantwortet das fachliche Was — Product Goal, Backlog, User Stories. Der ERP-Projektleiter verantwortet das kommerzielle Wie — Vertrag, Budget, Anbieter-Steuerung, Termine. Der Scrum.org-Leitfaden zu Product-Owner-Stances ergänzt: „For Product Owners to succeed, the entire organization must respect their decisions." Diese Entscheidungshoheit lässt sich nicht mit kaufmännischer Anbieter-Verhandlung in einer Person vereinen. Wir trennen die Rollen im Lastenheft explizit. Diese Trennung ist im Verhältnis zum Process Owner ähnlich, aber strukturell anders: PO und Process Owner können in einer Person liegen, PO und ERP-Projektleitung dürfen es nicht.
3. DACH-Pragmatik kombiniert PO und Fachbereichsleitung — bewusst
Im Scaled Agile Framework (SAFe) ist die PO-Rolle strukturell von der Product-Manager-Rolle getrennt: PO verantwortet das taktische Backlog, der Product Manager die strategische Roadmap. Sinnvoll in skalierten Settings mit mehreren parallelen Scrum-Teams. Im Mittelstand mit einem oder zwei agilen Teams erzeugt diese Trennung nur Schnittstellenkosten. Aus unserer Erfahrung empfehlen wir die SAFe-Trennung erst ab vier parallelen Teams. Darunter ist die Kombination PO plus Fachbereichsleitung die ehrlichere Lösung — sofern Backlog-Hoheit und Linien-Stellvertretung dokumentiert sind.
Unsere Einordnung
Der Scrum Guide 2020 ist ein präzises methodisches Fundament. Er ist aber kein Stellenprofil. Wer ihn im 250-Personen-Mittelstand wörtlich nimmt, schreibt Vollzeit-PO-Stellen aus, die niemand füllt — oder fällt in die Doppelrolle PO/ERP-Projektleiter, die das Projekt strukturell ausbremst.
So setzen wir die PO-Rolle in ERP-Projekten ein
Wir setzen die PO-Rolle in vier Phasen ein: Zielklarheit und KPI-Definition vor Sprintstart, Rollentrennung PO und Projektleitung vor Anbieterauswahl, Backlog-Coaching der internen PO-Kandidatin über sechs bis zwölf Wochen, KPI-gestützte Solution Evaluation nach Roll-out.
In der vendor-neutralen ERP-Beratung hat sich ein vierstufiges Vorgehen bewährt. Wir übernehmen die PO-Rolle nicht dauerhaft — sondern coachen interne PO-Kandidatinnen über sechs bis zwölf Wochen und ziehen uns dann strukturiert zurück. Der mittelstandstaugliche Gegenentwurf zum Konzern-„Interim-PO über 18 Monate".
- Zielklarheit und KPI-Set — vor dem ersten Sprint. Product Goal mit messbaren KPIs: Sprint-Goal-Hit-Rate, Backlog-Reifegrad, Stakeholder-NPS, Nutzerakzeptanz nach drei Monaten.
- Rollentrennung PO und Projektleitung — im Lastenheft und in der Projektcharta explizit ausgeschrieben.
- Backlog-Coaching der internen PO-Kandidatin — sechs bis zwölf Wochen begleitete Backlog-Pflege, User-Story-Schreiben und Refinement-Moderation.
- KPI-gestützte Solution Evaluation — nach drei und sechs Monaten Roll-out.
Wie wir die PO-Rolle methodisch verankern
Wir coachen, wir übernehmen nicht dauerhaft. Die interne PO-Kandidatin bleibt entscheidungsfähig im Haus. Der wesentliche Unterschied zum klassischen Beratungsangebot: Wir empfehlen herstellerunabhängig.
Mehr zu unserer Haltung in unserem Beratungsansatz.
Häufige Fehler bei der PO-Besetzung im Mittelstand
Fünf Fehlermuster sehen wir bei der PO-Besetzung im DACH-Mittelstand wiederkehrend in unseren Mandaten. Alle fünf sind vermeidbar, wenn sie vor der Stellenausschreibung im Lastenheft und in der Projektcharta sauber adressiert werden.
Fehler 1 — PO und ERP-Projektleiter in einer Person. Die häufigste Konstellation im Mittelstand — und der häufigste Bremsklotz. Lösung: Rollen im Lastenheft explizit trennen.
Fehler 2 — Vollzeit-PO-Stellenprofil im 200-Personen-Unternehmen. Die Ausschreibung beschreibt die Konzernrolle, die im Mittelstand nicht refinanzierbar ist. Folge: Vakanz über zwölf Monate. Lösung: Kombinationsrolle (PO plus Fachbereichsleitung, mindestens 50 Prozent PO-Zeit) explizit ausschreiben.
Fehler 3 — PO ohne Entscheidungshoheit (Auftragsannehmer-PO). Wenn jede Backlog-Priorisierung durch einen Lenkungsausschuss läuft, ist der PO faktisch ein Sekretär. Lösung: Entscheidungsbefugnis in der Projektcharta verankern.
Fehler 4 — KPIs erst nach dem ersten Sprint. Das Product Goal bleibt vage, der Erfolg wird gefühlt. Lösung: KPI-Set in der Zielklarheits-Phase definieren.
Fehler 5 — SAFe-Strukturen in einem Single-Team-Setting. Die PO/PM-Trennung erzeugt unter vier parallelen Teams nur Schnittstellenkosten. Lösung: SAFe erst ab vier Teams einführen.
Unsere Einordnung
Vier der fünf Fehler sind selten persönliche Fehler. Sie sind strukturell — und genau dort liegt der Hebel der vendor-neutralen Beratung.
Häufig gestellte Fragen
Ein Product Owner verantwortet die Wertmaximierung des Produkts. Sechs Aufgabenfelder prägen die Rolle: Product Goal definieren, Backlog erstellen und priorisieren, Stakeholder-Kommunikation, Sprint Planning und Sprint Review, Backlog-Transparenz und das Treffen von Wertentscheidungen. Der PO ist laut Scrum Guide 2020 immer eine Einzelperson. Im DACH-Mittelstand kommt fast immer eine Kombinationsrolle mit Fachbereichsleitung hinzu.
Der Scrum Master verantwortet das „Wie" des Prozesses — er coacht das Team, beseitigt Hindernisse, sichert die Methodik. Der Product Owner verantwortet das „Was" des Produkts — er definiert das Product Goal, priorisiert das Backlog und trifft Wertentscheidungen. Beide Rollen sind im Scrum Guide 2020 explizit getrennt und in einer Person nicht vereinbar — ein häufiger Anti-Pattern im Mittelstand.
Laut StepStone-Gehaltsdaten 2026 liegt das Mediangehalt bei rund 61.700 Euro brutto im Jahr, die Spanne reicht von etwa 54.000 bis 73.700 Euro. Aktuell sind rund 1.029 Product-Owner-Stellen ausgeschrieben. Aus unserer Erfahrung wird die Rolle im Mittelstand häufig in Teilzeit oder als Kombinationsrolle besetzt — eine Vollzeit-PO-Stelle ist im 200-Personen-Haus oft nicht refinanzierbar.
Zwei Pfade dominieren: Die PSPO-Zertifizierungen von Scrum.org (PSPO I, II, III) — prüfungsbasiert, lebenslang gültig, PSPO I für 200 USD mit 85 Prozent Bestehensgrenze. Und die CSPO-Zertifizierung der Scrum Alliance — vergeben über einen zweitägigen Kurs bei einem Certified Scrum Trainer. Aus unserer Sicht: PSPO für die methodische Tiefe, CSPO für den schnellen Einstieg.
Aus unserer Erfahrung in über 1.200 Projekten lohnt sich der externe PO selten dauerhaft. Sinnvoll ist das Modell: externer Berater coacht interne PO-Kandidatin über sechs bis zwölf Wochen. Eine dauerhafte externe Besetzung empfehlen wir nicht — die Rolle verlangt Hauskenntnis und Stakeholder-Beziehungen, die ein Externer strukturell nicht abbilden kann.
Nächste Schritte
Vor der Stellenausschreibung oder dem Start eines externen PO-Coachings empfehlen wir eine kurze Klärung: Welche Ziele soll der PO-Einsatz unterstützen, wie wird Erfolg gemessen, welche Rollen werden kombiniert und welche getrennt? Wenn Sie die PO-Rolle verankern oder einen Einsatz in einer ERP-Einführung vorbereiten möchten, lohnt der Blick in unsere Digitalisierungs-Dienstleistungen und in den Bereich ERP-Beratung. Wir arbeiten herstellerunabhängig und besetzen die PO-Rolle nicht dauerhaft — wir coachen interne Kandidatinnen.
Ergänzend empfehlen wir unsere Wiki-Beiträge zur Rolle der Process Owner und zur ERP-System-Definition. Methodische Vertiefungen finden Sie in unseren Einblicken. Für eine persönliche Einordnung steht unser Team unter Kontakt zur Verfügung.
30 Minuten mit Dreher Consulting
Eine strukturierte Klärung Ihrer PO-Besetzung — Zielbild, KPI-Set und die saubere Trennung von Product Owner und ERP-Projektleitung, anbieterneutral aus über 1.200 Projekten im DACH-Mittelstand.
