Vom Entwickler zum Product Owner – Mein erstes Jahr, alle Lessons Learned & ein Praxis-Fahrplan

Ein persönlicher Erfahrungsbericht für alle, die den Sprung wagen (wollen).

---

1. Einleitung – Warum ich diesen Artikel schreibe

Ich bin Lars. Seit vielen Jahren bin ich Softwareentwickler – am liebsten mit TypeScript, Webtechnologien, klarer Logik und einem sauberen Git-Flow. Ich mochte es, Dinge „richtig“ zu bauen. Bis ich merkte, dass „richtig“ nicht immer bedeutet, dass es für den Nutzer funktioniert.

Vor rund einem Jahr habe ich die Seiten gewechselt: vom Entwickler zum Product Owner. Und obwohl ich den Titel jetzt trage, fühlt sich vieles davon immer noch neu an.

In diesem Artikel erzähle ich dir ehrlich und ungeschönt, wie sich dieser Wechsel angefühlt hat – was mich überrascht hat, was mir schwerfiel, was gut funktioniert hat – und was ich heute anders machen würde. Wenn du gerade an derselben Schwelle stehst (oder mitten drin bist), ist dieser Text für dich.

2. Rückblick: Wie alles begann – und warum ich den Schritt gegangen bin

Ich erinnere mich noch gut an den Tag, an dem mein Chef mich fragte, ob ich mir vorstellen könnte, die Rolle des Product Owners zu übernehmen. Es klang erstmal schmeichelhaft – Vertrauen, Verantwortung, mehr strategischer Einfluss.

Aber ehrlich gesagt: Ich hatte keine Ahnung, was genau das bedeuten würde. Ich dachte: „Ich kenne unser System in- und auswendig, ich weiß, was realistisch ist – das ist doch eine gute Voraussetzung.“ Und das ist es auch. Aber es ist längst nicht alles.

Was mich gereizt hat, war der Wunsch, mehr Einfluss auf das Produkt zu nehmen, früher in Entscheidungen eingebunden zu sein und nicht erst dann, wenn das Konzept schon steht und das Frontend angeblich „nur noch umgesetzt werden“ muss.

Ich wollte verstehen: Warum machen wir dieses Feature überhaupt? Wer braucht es wirklich? Und wie merken wir, ob es hilft?

3. Die ersten Wochen: Orientierungslosigkeit trifft Anspruchsdenken

Die Wahrheit ist: Die ersten Wochen waren zäh.

Ich saß in Meetings mit Leuten aus dem Marketing, Vertrieb oder Support – und ich verstand nicht, was sie eigentlich wollten. Ich hatte gelernt, auf technische Klarheit zu achten. Aber jetzt ging es auf einmal um Nutzerbedürfnisse, Wertversprechen, Conversion-Ziele und Kundensegmente.

Ich fühlte mich, als wäre ich in einem neuen Team – nur ohne Einarbeitung.

Und gleichzeitig hatte ich diesen hohen Anspruch an mich selbst. Ich wollte direkt „funktionieren“ in der Rolle, wollte zeigen, dass ich zurecht PO geworden bin. Das führte dazu, dass ich oft zu viel gemacht habe. Ich habe nebenher noch Bugs analysiert, Pull Requests kommentiert, selbst mal was gecodet – und gleichzeitig versucht, Roadmaps zu schreiben und Meetings vorzubereiten.

Spoiler: Es hat nicht funktioniert.

Ich war schnell an meiner Grenze. Vor allem mental.

4. Der Punkt, an dem ich gemerkt habe: Ich muss das Programmieren loslassen

Ein Moment ist mir besonders im Kopf geblieben. Ich war abends noch am Rechner, um ein technisches Problem in einem Modul zu lösen, das ich früher selbst gebaut hatte. Parallel hatte ich eine unklare Story im Sprint-Backlog, die für die Entwickler sehr vage war.

Am nächsten Morgen fragte mich ein Kollege:

„Lars, willst du eigentlich Entwickler sein oder Product Owner?“

Das hat mich getroffen. Und gleichzeitig war es der Weckruf, den ich brauchte.

Denn: Solange ich versuchte, beides zu sein, war ich in keiner Rolle wirklich gut.

Das war der Moment, in dem ich mir bewusst gesagt habe:

Ich bin nicht mehr verantwortlich für den besten Code. Ich bin verantwortlich dafür, dass wir das Richtige bauen.

Das war nicht leicht. Ich bin Entwickler durch und durch. Ich liebe guten Code. Aber ich habe gelernt, dass mein größter Hebel heute nicht mehr im Editor liegt – sondern im Gespräch, in der Klarheit, in Entscheidungen.

5. „Was ist eigentlich wichtig?“ – Die Priorisierungs-Falle

Einer der härtesten Brüche für mich war: Als Entwickler wusste ich meistens, was als Nächstes zu tun ist. Ein Ticket, ein Bug, ein Review – logisch, eindeutig.

Aber als PO? Plötzlich hatte ich 20 Themen gleichzeitig auf dem Tisch. Und alle schienen wichtig:

• Der Support will dringend ein altes Lizenzproblem gelöst haben.
• Der Vertrieb braucht neue Landingpages.
• Ein Stakeholder bringt eine Idee für ein tolles Bonus-Feature rein.
• Und das Entwicklungsteam fragt: „Welche Stories sind denn ready für den nächsten Sprint?“

Ich war oft blockiert. Nicht, weil ich keine Ideen hatte – sondern weil ich nicht entscheiden konnte, was zuerst kommen sollte.

Was mir geholfen hat: Themen in Ziele zu übersetzen

Ich habe gelernt, mich zu fragen:

Was ist gerade das wichtigste Ziel – für das Produkt, für den Kunden, fürs Business?

Nicht: Was fühlt sich gerade dringend an? Sondern: Was bringt uns dem Ziel näher?

Ich habe dafür angefangen, mit Quartalszielen zu arbeiten – nicht im klassischen OKR-Sinne, sondern ganz einfach:

• „Dieses Quartal wollen wir die Abo-Verlängerungen reduzieren.“
• „Wir wollen die Mobile-Conversion verbessern.“
• „Wir wollen den Support-Aufwand bei Feature X halbieren.“

Das war wie ein Leuchtturm. Alles, was nicht in diese Richtung gezeigt hat, kam erstmal nicht dran.

6. Stakeholder-Kommunikation: Zwischen allen Stühlen

Ich hatte mir das leichter vorgestellt. Ich dachte: Wenn alle das gleiche Ziel haben, dann ziehen auch alle an einem Strang.

Nope.

Stakeholder haben unterschiedliche Interessen – und das ist auch okay.

Der Vertrieb denkt in Monatszielen. Das Marketing in Kampagnen. Das Support-Team sieht jeden Tag, was beim Kunden nicht läuft. Und ich? Ich muss all das hören, verstehen, einordnen – und den Fokus fürs Team bewahren.

Was ich lernen musste: Zuhören heißt nicht zustimmen

Am Anfang wollte ich es allen recht machen. Ich habe versprochen, Themen „bald reinzunehmen“, habe ToDos gesammelt, statt Prioritäten zu setzen.

Irgendwann habe ich gemerkt: Das macht mich unglaubwürdig. Ich sage ja zu allem – aber liefere nichts davon wirklich. Das Entwicklungsteam war verwirrt. Die Stakeholder enttäuscht. Ich selbst gestresst.

Heute versuche ich klarer zu sein:

• „Das Thema XY klingt spannend – aber aktuell priorisieren wir Z, weil wir dort den größten Hebel sehen.“
• Oder auch: „Ich kann’s mit ins nächste Refinement nehmen, aber Stand jetzt sehe ich es frühestens in Q3.“

Das ist nicht immer beliebt. Aber es schafft Klarheit. Und am Ende ist das genau das, was ein PO liefern muss.

7. Zeitmangel & Selbstmanagement – der stille Gegner

Ehrlich gesagt: Ich war überrascht, wie wenig produktiv ich mich in der PO-Rolle oft gefühlt habe.

Als Entwickler hatte ich am Ende des Tages etwas vorzeigbares: Pull Request, Deploy, neue Funktion.

Jetzt war mein Tag oft gefüllt mit Meetings, Rückfragen, Abstimmungen – und abends das Gefühl: „Ich hab doch gar nichts geschafft.“

Das war frustrierend. Und ich dachte kurz, ich sei einfach zu langsam. Zu unstrukturiert.

Aber dann habe ich angefangen, meine Zeit mal zu tracken. Und siehe da:

Ich hatte kein Zeitproblem. Ich hatte ein Fokusproblem.

Was mir geholfen hat: Struktur und Rituale

• Timeboxing: Jeden Tag ein fester Block für Backlog-Pflege, einer für Mails/Slack, einer für Fokusarbeit.
• 1-3-5-Regel: 1 große Sache, 3 mittlere, 5 kleine – mehr nehme ich mir nicht vor.
• Don’t break the chain: Jeden Tag ein kleines Learning notieren. Ein Satz reicht.

Und ganz wichtig: Pausen.

Ich neige dazu, mich durch den Tag zu hetzen – vor allem, wenn es viel zu tun gibt. Aber das rächt sich. Ich bin gereizt, unklar, unkonzentriert.

Inzwischen blocke ich mir bewusst kurze Pausen – auch wenn’s nur 10 Minuten sind. Sie helfen mir, nicht nur zu reagieren, sondern wieder zu denken.

8. Warum mein Agile Coach mein wichtigster Verbündeter war

Wenn ich heute eine Person nennen müsste, die den größten Einfluss auf meinen Lernprozess hatte, dann war das mein Agile Coach.

Am Anfang dachte ich: „Brauche ich nicht. Ich kenn Scrum, hab Retros moderiert, bin gut organisiert.“

Aber dann merkte ich: Ich war zwar organisiert, aber ich war oft allein mit meinen Entscheidungen.

Und genau da kam der Coach ins Spiel.

Was er für mich war (und ist):

• Spiegel: Wenn ich dachte, ich sei klar, fragte er: „Und was willst du jetzt konkret erreichen?“
• Mentor: Er hat mir Werkzeuge gezeigt – Impact Mapping, WSJF, User-Story-Muster.
• Vertrauter: Ich konnte offen sagen: „Ich weiß gerade nicht weiter.“ Und das war okay.

Ohne ihn hätte ich viele Denkfehler länger mitgeschleppt. Und ich hätte mich öfter verloren gefühlt.

Ich glaube, jeder neue PO sollte jemanden haben, der diese Rolle übernehmen kann – ob Agile Coach, erfahrener PO oder Mentor. Allein ist es ein harter Weg.

9. Meine 5 wichtigsten Learnings & Tipps für neue PO

1. Lerne, zwischen „laut“ und „wichtig“ zu unterscheiden Die lautesten Themen sind selten die wichtigsten. Frage bei jedem Input: „Welches Problem löst das? Wer profitiert – und wie?“ Sammle alles auf einem „Themen-Parkplatz“-Board und priorisiere anhand klarer Kriterien.

2. Du bist nicht der/die Projektmanagerin – du bist der/die Möglichmacherin Statt alles zu kontrollieren, gib deinem Team den Raum, selbst Lösungen zu finden. Formuliere Ziele, nicht To-Dos.

3. Klare Kommunikation schlägt perfektes Backlog Nichts ersetzt ein kurzes Gespräch oder ein Miro-Sketch. Stimme Stories persönlich ab, erstelle Slack-Voice-Notes, wenn nötig.

4. Sei transparent mit deiner Unsicherheit Zeige, wenn du nicht sicher bist, und lade das Team zum gemeinsamen Nachdenken ein. Vertrauen entsteht durch Ehrlichkeit.

5. Baue dir deine persönliche Retro Jeden Freitag schreibst du drei Fragen auf: Wo lag mein größter Hebel? Wo war ich reaktiv? Was will ich nächste Woche anders machen?

10. Warum das Loslassen vom Coden mein Denken verändert hat

Anfangs empfand ich den Programmier-Entzug als schmerzhaft. Code war mein Flow, mein Safe Space. Doch je länger ich als PO agierte, desto klarer wurde:

Mein Hebel liegt nicht im Editor, sondern in der Richtung, die ich vorgebe.

Ich sehe heute, wie Features, die ich initiiert habe, aktiv genutzt werden. Ich sehe, wie mein Team selbstständiger wird, weil ich mich zurückziehe und Räume schaffe.

Gelegentlich helfe ich in Proof-of-Concepts – bewusst, nicht aus Pflicht.

11. Tools und Strukturen im Alltag

Tool	Zweck	Warum es mir hilft
Jira (Epics & Labels)	Backlog-Organisation	Struktur & schnelle Suche
Miro	Workshops, Story-Mapping, Ideensortierung	Visueller Austausch, direktes Feedback
Confluence	Dokumentation & Entscheidungshistorie	Kontext für Stakeholder, nachvollziehbare Roadmaps
Clockify	Zeittracking	Zeigt, wo Meetings und Ad-hoc-Zeiten bleiben
Apple Kalender + Erinnerungen	Persönliche Planung	Simpel, zuverlässig synchronisiert
Notion (privat)	Journal & persönliche Retro	Reflektion meiner Lernreise

Regelmäßige Rituale:

• Montagmorgen: Wochenausrichtung (Fokus setzen)
• Freitagmittag: Private Retro (Lernpunkte dokumentieren)
• Alle zwei Wochen: Check-in mit Agile Coach
• Monatlich: Selbst-Review (größte Fehler und Learnings)

12. Der Druck, der nicht im Backlog steht

Die größte Herausforderung als PO ist oft nicht das Produkt — sondern du selbst. Abends frage ich mich manchmal: War das genug? Hätte ich früher eingreifen sollen? Dieser Druck kommt von meinem Perfektionsanspruch. Und er ist nicht immer sichtbar.

13. Die Stimme im Kopf, die zweifelt

Der innere Dialog kann hart sein:

• „Als Entwickler hast du Ergebnisse geliefert. Jetzt moderierst du nur.“
• „Ist das wirklich dein Beitrag?“

Ich habe gelernt: Zweifel sind ein Zeichen, dass du es ernst nimmst. Offen mit meinem Agile Coach und vertrauensvollen Kolleg:innen darüber zu sprechen, hat mir sehr geholfen.

14. Arbeit & Familie – zwischen Präsenz und schlechtem Gewissen

Als Vater von zwei kleinen Kindern erlebe ich täglich den Spagat zwischen Job und Familie. Früher wollte ich alles sofort fertig machen. Heute sage ich bewusst: „Jetzt bin ich für dich da.“ Diese bewussten Pausen geben mir die Energie, danach wieder klar zu entscheiden.

15. Was ich über mich selbst gelernt habe

• Ich muss nicht alles wissen — ich muss lernbereit sein.
• Fehlende Kontrolle ist kein Versagen, sondern Raum für Team-Eigeninitiative.
• Mein Wert zeigt sich in gelebter Klarheit und Impact, nicht in Codezeilen.

16. Für wen ist diese Rolle vielleicht nichts?

• Wer tief technisch bleiben und Probleme selbst lösen will,
• Wer ungern moderiert, verhandelt oder priorisiert,
• Wer Unsicherheit schwer erträgt,

für den kann die PO-Rolle zur Last werden. Aber wer neugierig ist und Wirkung über Menschen sucht, findet hier Erfüllung.

17. Mein persönliches Fazit nach einem Jahr

Ich bin keine reiner Entwickler mehr — und kein reiner PO. Ich bin die Brücke zwischen Technik, Business und Nutzer. Meine Superkraft ist nicht der nächste Commit, sondern die Richtung, die ich setze.

Danke, dass du bis hierhin gelesen hast. Wenn du Fragen hast oder Erfahrungen teilen möchtest, melde dich gern!