Product Owner: Aufgaben, Backlog und Gehalt im Überblick

Dein Entwicklungsteam arbeitet seit vier Monaten. Alle sind ausgelastet. Niemand faulenzt. Und trotzdem ist das, was am Ende herauskommt, nicht das, wofür du bezahlt hast.

Der Grund steht selten im Code. Er steht in der Frage, die niemand beantwortet: Wer entscheidet eigentlich, was als Nächstes gebaut wird?

Bei den meisten Betrieben, die ich kenne, lautet die ehrliche Antwort: der, der am lautesten ruft. Mal ist es der Vertrieb, weil ein A-Kunde gedroht hat. Mal der Geschäftsführer, weil er auf einer Messe etwas gesehen hat. Mal der Entwickler selbst, weil er die technische Schuld nicht mehr erträgt. Drei Absender, drei Prioritätenlisten, ein Team. Das Ergebnis ist Stillstand mit hoher Auslastung.

Genau dafür gibt es den Product Owner. Nicht als Titel auf einer Visitenkarte, sondern als die eine Person, bei der die Frage „was zuerst" endet. Er verantwortet den Wert dessen, was das Team liefert — und er trägt diese Verantwortung allein.

Hier bekommst du beides: was die Rolle wirklich umfasst, und was sie in einem Betrieb mit 30 oder 120 Leuten praktisch bedeutet. Dazu die Abgrenzung zum Scrum Master, das Handwerk am Product Backlog und eine ehrliche Einordnung zum Gehalt.

Was ein Product Owner ist

Ein Product Owner ist die Person, die verantwortet, dass die Arbeit eines Entwicklungsteams Wert schafft. Er entscheidet, was gebaut wird, in welcher Reihenfolge — und vor allem, was nicht gebaut wird. Das ist die gesamte Rolle in einem Satz.

Die Rolle stammt aus Scrum, dem verbreitetsten Rahmenwerk für agile Produktentwicklung. Der offizielle Scrum Guide von Ken Schwaber und Jeff Sutherland beschreibt den Product Owner als verantwortlich für die Maximierung des Werts des Produkts, das aus der Arbeit des Scrum Teams entsteht. Es gibt ihn auch auf Deutsch als PDF, gerade mal dreizehn Seiten. Lies ihn einmal selbst, bevor du dir von einem Berater erklären lässt, was drinsteht.

Drei Punkte daraus sind für die Praxis entscheidend.

Der Product Owner ist eine Person, kein Gremium. Nicht ein Lenkungskreis, nicht ein Ausschuss, nicht „die Geschäftsführung". Sobald zwei Leute gleichberechtigt priorisieren dürfen, hast du wieder das Problem vom Anfang — nur mit besseren Titeln. Er kann sich beraten lassen, er kann Zuarbeit bekommen. Die Entscheidung fällt bei ihm.

Seine Entscheidungen werden respektiert. Das steht so im Rahmenwerk und ist der Teil, an dem die meisten mittelständischen Einführungen scheitern. Wenn der Geschäftsführer jeden zweiten Freitag die Reihenfolge umwirft, ist die Rolle eine Schauspielerei. Dann brauchst du die Rolle nicht, dann bist du selbst der Verantwortliche und solltest es auch so nennen.

Er verantwortet den Wert, nicht die Auslastung. Ein volles Team ist kein Erfolg. Ein Team, dessen Arbeit sich in Umsatz, gesparter Zeit oder gehaltenen Kunden niederschlägt, ist einer. Diesen Unterschied musst du als Unternehmer verstehen, bevor du die Rolle besetzt.

Wo die Rolle außerhalb der Softwareentwicklung passt

Der Begriff kommt aus der Software. Das Prinzip nicht. Überall dort, wo ein festes Team über längere Zeit an einem Produkt oder einer Leistung arbeitet und der Bedarf schneller wechselt als der Jahresplan, funktioniert dieselbe Konstruktion.

Ein Maschinenbauer mit einer eigenen Konstruktionsabteilung. Ein Dienstleister, der ein Kundenportal betreibt. Eine Marketingabteilung, die eine Plattform bespielt. In allen drei Fällen gibt es eine Warteschlange von Wünschen, mehr Wünsche als Kapazität, und keine einzelne Person, die den Vorrang verantwortet. Genau da hilft diese Rolle — auch wenn der Rest des Betriebs kein Scrum macht.

Product Owner und Scrum Master: die Abgrenzung, die im Alltag entscheidet

Der Product Owner verantwortet das Was und das Warum. Der Scrum Master verantwortet das Wie der Zusammenarbeit. Zwei Rollen, zwei Verantwortungen, niemals dieselbe Person.

Product Owner:

• entscheidet über Inhalt und Reihenfolge des Product Backlogs
• formuliert und vertritt das Produktziel
• spricht mit Kunden, Vertrieb, Fachabteilungen und Geschäftsführung
• nimmt Ergebnisse ab oder lehnt sie ab
• sagt Nein — täglich, begründet, ohne schlechtes Gewissen
• wird daran gemessen, ob das Gebaute Wirkung zeigt

Scrum Master:

• verantwortet, dass Scrum verstanden und gelebt wird
• moderiert die Termine und hält sie kurz
• räumt Hindernisse weg, die das Team ausbremsen
• schützt das Team vor Zurufen von außen
• coacht Team und Organisation, weist niemanden an
• wird daran gemessen, ob das Team ungestört liefern kann

Der häufigste Fehler im Mittelstand ist die Doppelbesetzung: Eine Person macht beides, „weil wir nur ein Team haben". Das geht immer schief, und zwar aus einem strukturellen Grund. Der Product Owner muss Druck aufbauen — mehr Wert, schnellere Rückmeldung, klare Zusagen. Der Scrum Master muss Druck abfangen. Wer beides gleichzeitig ist, entscheidet in jedem Konflikt gegen sich selbst. In der Praxis gewinnt dann immer der Terminkalender: Die Backlog-Pflege fällt aus, weil eine Retrospektive ansteht.

Zweiter Fehler: den Produktverantwortlichen zum Vorgesetzten des Teams zu machen. Er ist es nicht. Er hat keine Weisungsbefugnis über Personen, er hat Entscheidungsgewalt über Inhalte. Wie sich Führungsverantwortung und fachliche Verantwortung sauber trennen lassen, gehört ins Thema Mitarbeiterführung — und wenn in deinem Betrieb grundsätzlich unklar ist, wer entscheidet, wer mitredet und wer nur informiert wird, dann klär das mit einer RACI-Matrix, bevor du irgendeine Rolle besetzt. Das ist eine halbe Stunde Arbeit und erspart dir Monate.

Die Aufgaben eines Product Owners

Die Product-Owner-Aufgaben lassen sich auf fünf reduzieren: Produktziel setzen, Backlog führen, priorisieren, Anforderungen klären, Ergebnisse abnehmen. Alles andere ist Zuarbeit oder Beiwerk.

Das Produktziel setzen und verteidigen

Vor jeder Liste steht ein Ziel. Nicht „das Portal verbessern", sondern etwas, das man am Jahresende prüfen kann: Angebote gehen in unter 24 Stunden raus. Der Anteil der Selbstbedienung im Kundenkonto steigt von 12 auf 40 Prozent. Ein Monteur erfasst seinen Tagesbericht in unter drei Minuten.

Dieses Ziel ist der Maßstab, an dem jede spätere Entscheidung hängt. Wenn ein Wunsch nicht auf das Ziel einzahlt, fliegt er raus — egal wer ihn geäußert hat. Wer Ziele in seinem Betrieb ohnehin schon über OKR steuert, hat es hier leichter: Das Produktziel wird dann zum Key Result, und die Diskussion um Prioritäten ist zur Hälfte schon geführt.

Und ein Produktziel ohne Nutzenversprechen ist Beschäftigungstherapie. Bevor du ein Team an ein Produkt setzt, muss klar sein, für wen es welches Problem löst und warum ausgerechnet deine Lösung. Das ist die Value Proposition, und sie gehört auf ein Blatt, nicht in einen Foliensatz.

Das Product Backlog führen

Die zentrale, tägliche Arbeit. Nur er fügt Einträge hinzu, sortiert um, formuliert um oder streicht. Er darf sich zuarbeiten lassen — die Verantwortung bleibt bei ihm. Wie das Handwerk dabei aussieht, steht weiter unten im eigenen Abschnitt.

Priorisieren und Nein sagen

Der unbequemste Teil. Er sagt in einer normalen Woche mehr Nein als Ja, und jedes Nein hat einen Absender mit Erwartung. Der Vertriebsleiter, dessen Kunde eine Sonderfunktion will. Die Buchhaltung, die eine Auswertung braucht. Der Geschäftsführer, der etwas beim Wettbewerber gesehen hat.

Wichtig ist die Form des Neins. „Nein" allein zerstört Zusammenarbeit. „Nein, nicht in den nächsten sechs Wochen, weil A und B vorher mehr bringen — hier ist der Eintrag, hier ist der Stand" hält sie am Leben. Der Unterschied ist Sichtbarkeit: Wer nachvollziehen kann, warum sein Wunsch hinten steht, erträgt es.

Anforderungen klären

Ein Team kann nur bauen, was es versteht. Also sorgt er dafür, dass jeder Eintrag beantwortet, für wen etwas gebaut wird, welches Problem gelöst wird und woran man die Fertigstellung erkennt. Das übliche Format dafür ist die User Story samt Akzeptanzkriterien. Er schreibt sie nicht zwingend allein — er verantwortet, dass sie am Ende taugen.

Dafür braucht er den direkten Draht zu denen, die das Produkt nutzen. Nicht zur Meinung über die Nutzer, sondern zu den Nutzern. Wer seit einem halben Jahr mit keinem Kunden gesprochen hat, priorisiert nach Bauchgefühl. Die Handwerkszeuge dafür sind dieselben wie im Vertrieb: eine ordentliche Bedarfsanalyse und offene Fragen statt Bestätigungssuche.

Ergebnisse abnehmen

Am Ende jedes Sprints entscheidet er, ob etwas fertig ist. Nicht „technisch fertig", sondern brauchbar für den Anwender. Diese Abnahme ist der Moment, in dem die Rolle Zähne zeigt — oder eben nicht. Wer alles durchwinkt, um niemanden zu enttäuschen, hat nach einem halben Jahr ein Produkt, das aus lauter halbfertigen Funktionen besteht.

Das Product Backlog: das wichtigste Werkzeug

Das Product Backlog ist eine geordnete Liste von allem, was am Produkt getan werden könnte. Es ist die einzige Quelle für die Arbeit des Teams. Nur eine Liste, nur eine Reihenfolge, nur ein Verantwortlicher.

Der wichtigste Teil dieses Satzes ist „geordnet". Ein Product Backlog ist keine Sammlung, sondern eine Rangfolge. Es gibt keine drei Einträge mit Priorität 1. Was oben steht, kommt zuerst. Wer diese Disziplin nicht aushält, hat statt eines Backlogs einen Wunschzettel — und Wunschzettel produzieren genau das Chaos, das die Rolle beseitigen soll.

Was hineingehört und was nicht

Hinein gehört alles, was Arbeit am Produkt bedeutet: neue Funktionen, Änderungen, Fehlerbehebungen, technische Aufräumarbeiten, Anpassungen an neue Vorschriften. Aus dem Backlog wird die Arbeit des Teams gespeist — es gibt keinen zweiten Kanal. Kein Zuruf im Flur, keine Direktnachricht an den Entwickler, keine E-Mail mit „nur ganz kurz".

Diesen einen Punkt musst du als Unternehmer durchsetzen, sonst funktioniert nichts anderes. Solange der Chef an ihm vorbei Aufträge verteilt, ist die Liste Fiktion. Das ist am Ende dasselbe Thema wie Delegieren: Verantwortung abgeben heißt, die Umgehung zu unterlassen, auch wenn es schneller ginge.

Nicht hinein gehören Zieldefinitionen, Strategiepapiere und Projektpläne für das nächste Jahr. Das Backlog ist ein Arbeitsvorrat, kein Ablagesystem. Und Einträge, die seit einem Jahr unten liegen, löscht du ohne Rückfrage. Was wichtig ist, kommt von allein wieder — meistens innerhalb weniger Wochen und dann mit einem Absender, der es begründen kann.

Die drei Ebenen der Genauigkeit

Ein gut geführtes Product Backlog ist oben scharf und unten grob. Das ist kein Mangel, das ist der Sinn.

• Oben, die nächsten ein bis zwei Sprints: klein geschnitten, mit Akzeptanzkriterien, vom Team geschätzt, sofort startbar.
• Mitte, die nächsten Monate: grob umrissen, Größenordnung bekannt, offene Fragen notiert.
• Unten, alles Weitere: eine Zeile, ein Gedanke, ein Kundenwunsch. Mehr nicht.

Wer jeden Eintrag bis zur letzten Zeile durchspezifiziert, verbrennt Arbeitszeit für Dinge, die nie gebaut werden. Wer nichts vorbereitet, hat ein Team, das im Sprint Planning ratlos dasitzt.

Refinement: die Stunde, die den Sprint rettet

Backlog Refinement heißt, gemeinsam mit dem Team die oberen Einträge zu schärfen: aufteilen, präzisieren, schätzen, offene Fragen klären. Ein bis zwei Stunden pro Woche reichen bei den meisten Teams.

Diese Stunde ist die höchstverzinste Zeit im ganzen Ablauf. Ein Eintrag, der im Refinement geklärt wird, kostet zehn Minuten Diskussion. Derselbe Eintrag, unklar in den Sprint gelassen, kostet zwei Tage Entwicklung in die falsche Richtung. Wenn dein Team regelmäßig überzieht, schau nicht zuerst auf die Entwickler, sondern auf das Refinement.

Priorisieren: drei Verfahren, die im Mittelstand tragen

Für die Reihenfolge braucht es kein Studium, aber ein Verfahren, das man vorzeigen kann.

• Wert gegen Aufwand. Zwei Schätzungen, ein Quotient. Grob, schnell, ausreichend für 80 Prozent der Fälle. Oben landet, was viel bringt und wenig kostet.
• Kosten der Verzögerung. Die einzige Frage: Was kostet es uns pro Monat, wenn wir das nicht tun? Verlorene Aufträge, gebundene Personenstunden, Vertragsstrafen. Diese Sicht macht aus Meinungsstreit eine Rechnung.
• Muss, Soll, Kann, Nicht jetzt. Vier Töpfe, streng geführt. Der Trick liegt im vierten Topf: Er muss benutzt werden, sonst ist alles ein Muss.

Egal welches Verfahren — schreib die Begründung an den Eintrag. Wer seine Reihenfolge nicht in zwei Sätzen erklären kann, verliert sie beim nächsten lauten Zuruf.

Wer im Backlog mitreden darf

Alle dürfen etwas eintragen oder vorschlagen. Sortieren darf einer. Diese Trennung ist der ganze Mechanismus, und sie funktioniert nur, wenn die Beteiligten sich gesehen fühlen. Deshalb gehört zur Rolle ein geordneter Umgang mit den Interessengruppen: wissen, wer welchen Anspruch hat, wer Einfluss ausüben kann und wer regelmäßig informiert werden will. Wie du diese Gruppen sauber erfasst und führst, steht beim Thema Stakeholder.

Praktisch heißt das: ein fester Termin alle zwei Wochen, in dem der Verantwortliche den oberen Teil des Backlogs zeigt und begründet. Dreißig Minuten. Wer da war, ruft nicht mehr dazwischen.

Product Owner Gehalt: die ehrliche Einordnung

Belastbare amtliche Zahlen speziell für den Product Owner gibt es nicht — der Beruf ist in keiner offiziellen Statistik als eigene Kategorie geführt. Was kursiert, stammt aus Gehaltsportalen und beruht auf Selbstauskünften. Als Orientierung taugt das, als Beleg nicht.

Was du dagegen belegen kannst, ist der Vergleichsmaßstab. Das Statistische Bundesamt weist für April 2025 ein durchschnittliches Bruttomonatsgehalt von Vollzeitbeschäftigten in Deutschland von 4.784 Euro aus; der mittlere Bruttojahresverdienst lag 2025 bei 54.066 Euro. Die Behörde weist ausdrücklich darauf hin, dass rund zwei Drittel der Beschäftigten unter dem Durchschnitt liegen.

Ein Product Owner liegt über diesem Median — es ist eine qualifizierte Rolle mit Entscheidungsgewalt. In welchem Abstand, hängt an fünf Dingen, und die kennst du aus jeder anderen Stellenbesetzung auch:

• Erfahrung. Ein Einsteiger, der aus der Fachabteilung kommt, und jemand mit fünf Jahren Produktverantwortung liegen weit auseinander.
• Größe und Branche. Konzern und Softwarehaus zahlen anders als ein Mittelständler mit einem Team.
• Region. München, Frankfurt und Hamburg liegen deutlich über der ostdeutschen Fläche.
• Umfang der Verantwortung. Ein Team oder vier. Ein internes Werkzeug oder das Produkt, das den Umsatz trägt.
• Zertifikate. Türöffner im Bewerbungsprozess, mehr nicht. Ersetzen tun sie nichts.

Mein Rat als Unternehmer: Führ die Gehaltsdiskussion nicht über Portalzahlen, sondern über den Wert der Entscheidung. Wenn diese Person die Reihenfolge der Arbeit eines vierköpfigen Teams bestimmt, entscheidet sie über einen sechsstelligen Personalaufwand pro Jahr. Wer da an 10.000 Euro Jahresgehalt spart und die Rolle mit jemandem besetzt, der sich nicht durchsetzt, hat teuer gespart.

Und wenn du intern besetzt: Rechne die Rolle als Vollzeit. Diese Aufgabe nebenbei, zwei Stunden die Woche zwischen zwei Terminen, ist die häufigste Ursache für ein Team, das ins Leere arbeitet.

Welche Fähigkeiten die Rolle wirklich verlangt

Der beste Product Owner ist nicht der mit dem meisten Fachwissen, sondern der mit der höchsten Entscheidungsfreude. Alles andere ist erlernbar.

Entscheiden bei unvollständiger Information. Es wird nie genug Daten geben. Wer wartet, bis die Lage eindeutig ist, blockiert ein ganzes Team. Lieber eine Entscheidung, die nach zwei Wochen korrigiert wird, als vier Wochen Analyse.

Konfliktfähigkeit. Die Rolle bedeutet, Menschen zu enttäuschen, die man morgen wieder braucht. Wer Harmonie über Klarheit stellt, ist falsch besetzt.

Kundennähe. Nicht die Meinung über den Markt, sondern der Kontakt zum Markt. Termine bei Anwendern, Mitfahrten im Außendienst, Zuhören am Servicetelefon.

Zahlen statt Anekdoten. Ein Anruf ist ein Anruf, kein Trend. Wer drei Kundenbeschwerden zu einem Notfall erklärt, ohne zu prüfen, wie viele Nutzer betroffen sind, wird zum Verstärker für die Lautesten.

Schneiden können. Große Wünsche in kleine, lieferbare Stücke zerlegen. Das ist die technischste der fünf Fähigkeiten und die, an der man Erfahrung erkennt.

Was auffällt: Vier von fünf Punkten sind kein IT-Thema. Deshalb kommen gute Product Owner im Mittelstand oft aus dem Vertrieb, dem Service oder der Fachabteilung — und nicht aus der Entwicklung.

Die vier häufigsten Fehlbesetzungen im Mittelstand

Der Geschäftsführer als Product Owner. Klingt naheliegend, scheitert an der Verfügbarkeit. Die Rolle braucht Ansprechbarkeit im Tagesgeschäft: Rückfragen im Sprint, Refinement, Abnahme. Wer drei Tage die Woche unterwegs ist, blockiert das Team, statt es zu führen. Wenn du die Rolle trotzdem selbst übernimmst, dann verbindlich mit festen Zeiten — nicht zwischen Tür und Angel.

Der Entwickler, der zusätzlich priorisiert. Er versteht das Produkt technisch am besten und priorisiert deshalb technisch. Aufräumarbeiten wandern nach oben, unbequeme Kundenwünsche nach unten. Nicht aus Böswilligkeit, sondern weil jeder aus seiner Sicht sortiert.

Der Projektleiter mit neuem Titel. Klassische Projektleitung steuert über Termine, Aufwand und Umfang. Ein Product Owner steuert über Wert und Reihenfolge. Wer nur das Schild tauscht, bekommt einen Sprint-Zeitplan mit anderen Vokabeln. Wo klassische Projektsteuerung ihre Berechtigung hat und wo nicht, ist ein eigenes Thema — nachzulesen im Projektmanagement.

Das Gremium. Drei Abteilungsleiter, die gemeinsam priorisieren. Nach vier Sitzungen steht die Liste in der Reihenfolge der Hierarchie, nicht des Nutzens. Ein Entscheider, drei Berater — so herum funktioniert es.

So besetzt du die Rolle in deinem Betrieb

Vier Schritte, und du kannst am Montag anfangen.

Erstens: Ziel schreiben, bevor du jemanden benennst. Ein Satz, prüfbar, mit Datum. Ohne Ziel ist jede Priorisierung Geschmackssache.

Zweitens: eine Person benennen, öffentlich. In der Runde, in der auch die sitzen, die künftig nicht mehr direkt beim Entwickler anrufen. Sag den Satz laut: Ab heute geht jeder Wunsch über diesen Weg. Auch meiner.

Drittens: Zeit freiräumen. Mindestens 60 Prozent einer Stelle bei einem Team. Wer das nicht kann, sollte die Rolle nicht besetzen, sondern das Team verkleinern.

Viertens: nach zwölf Wochen messen. Nicht die Zufriedenheit im Team, sondern das Ergebnis am Produktziel. Drei Zahlen reichen: Wie viele der obersten zehn Einträge sind fertig geworden? Wie oft wurde die Reihenfolge von außen umgeworfen? Und hat sich die Kennzahl bewegt, die im Produktziel steht — Durchlaufzeit, Nutzungsanteil, gehaltene Kunden? Wenn der Nutzen beim Kunden ankommt, siehst du es dort zuerst; wie du das sauber erhebst, steht bei der Kundenzufriedenheit. Wenn sich in zwölf Wochen nichts bewegt hat, liegt es fast nie am Team. Es liegt an einem Ziel, das keins war, oder an einer Rolle, die auf dem Papier steht und im Alltag umgangen wird.

Ich habe in 35 Jahren viele Betriebe gesehen, die an Umsetzung gescheitert sind, obwohl der Plan gut war. Der Grund war fast immer derselbe: Es gab keinen, der entscheiden durfte. Genau diese Lücke schließt ein Product Owner — im Produkt, und dasselbe Prinzip trägt in jedem anderen Bereich deines Unternehmens.

Wenn du an dieser Stelle weiterkommen willst: Hol dir das Unternehmer-Paket mit sieben Anleitungen für mehr Umsatz. Darin steckt das, was vor jeder Methode kommt — klare Verantwortung, klare Reihenfolge, klare Zahlen. Kostenlos, sofort als PDF.

Häufige Fragen zum Product Owner

Braucht ein Product Owner eine Zertifizierung?

Nein, verpflichtend ist keine. Der Scrum Guide kennt keine Zertifikate, er beschreibt Verantwortlichkeiten. Ein zweitägiger Kurs mit Prüfung vermittelt das Vokabular und hilft im Bewerbungsprozess, ersetzt aber weder Produktverständnis noch Durchsetzungsfähigkeit. Für die Besetzung im eigenen Betrieb zählt anderes: Kennt die Person die Kunden, kann sie entscheiden, hält sie Widerspruch aus. Wenn du extern einstellst, lass dir im Gespräch eine echte Priorisierungsentscheidung aus dem letzten Jahr erklären — samt Begründung und dem, was danach passiert ist. Das sagt mehr als jedes Zertifikat.

Kann eine Person Product Owner für mehrere Teams sein?

Möglich ist es, gut ist es selten. Bei zwei kleinen Teams am selben Produkt geht es, wenn die Rolle Vollzeit ist. Bei zwei getrennten Produkten wird es eng, weil beide Backlogs Pflege brauchen und beide Kundenkreise Kontakt. Die Grenze erkennst du an einem Symptom: Sobald die Teams anfangen, selbst zu priorisieren, weil niemand erreichbar ist, ist sie überschritten. Dann ist die Rolle geteilt — nur unausgesprochen und ohne Verantwortung.

Wer schreibt die User Stories, der Product Owner oder das Team?

Verantwortlich ist der Product Owner, geschrieben wird gemeinsam. In der Praxis skizziert er Ziel, Nutzer und Nutzen, und im Refinement schärft das Team die Akzeptanzkriterien und den Schnitt. Das ist besser als beide Extreme: Wer allein im Büro sitzt und ausformuliert, produziert Vorgaben, die niemand versteht. Ein Team, das sich seine Anforderungen selbst ausdenkt, baut, was technisch interessant ist. Wie ein brauchbarer Eintrag aussieht, steht bei der User Story.

Was unterscheidet Product Owner und Produktmanager?

Der Product Owner ist eine Rolle im Rahmenwerk Scrum mit einem klar umrissenen Auftrag: Product Backlog und Wertmaximierung für ein Team. Produktmanagement ist die breitere Funktion — Markt, Preis, Positionierung, Produktstrategie über den gesamten Lebenszyklus. In kleineren Betrieben macht dieselbe Person beides, und das ist völlig in Ordnung. In größeren Organisationen verantwortet der Produktmanager, was am Markt gewonnen werden soll, und die Produktverantwortung übersetzt das in die Reihenfolge der Arbeit.

Wie viel Zeit muss ein Product Owner täglich einplanen?

Rechne mit mindestens einem halben Tag pro Arbeitstag bei einem Team, in Sprint-Planungs- und Abnahmewochen mehr. Der Kern ist die tägliche Erreichbarkeit für Rückfragen, dazu wöchentliches Refinement, laufender Kundenkontakt und die Gespräche mit den Interessengruppen. Wer die Rolle mit zwei Stunden pro Woche kalkuliert, bekommt ein Team, das rät. Und ein ratendes Team ist teurer als jede Personalstelle, die du dir sparst.