Vom Frontend zur Product Ownerin: Barbara Sikora (UNIQA Insurance Group AG) über Migration, Teamarbeit und echte Kundenzentrierung

Warum diese DevStory wichtig ist

Als wir „Barbara Sikora, Product Owner bei UNIQA“ mit Speaker Barbara Sikora von UNIQA Insurance Group AG verfolgt haben, wurde schnell klar, warum ihre Geschichte Entwicklerinnen und Entwickler ebenso anspricht wie Product-People. Sie erzählt nicht nur von einer klassischen Transition vom Coding zur Product-Verantwortung. Sie zeigt, wie technisches Verständnis, Teamkultur und konsequente Kundenzentrierung zusammenwirken, wenn ein digitales Produkt wächst, sich technologisch erneuert und organisatorisch skaliert.

Wir haben eine Laufbahn erlebt, die in der Schule mit einem kleinen Reiseblog begann, sich über ein interdisziplinäres Studium weiterentwickelte, zu einer externen Frontend-Rolle bei „mein UNIQA“ führte und schließlich in die interne Leitungsfunktion und den Wechsel zur Product Ownerin mündete. Prägend: eine komplette Migration von AngularJS auf einen modernen Stack mit Angular, Ionic und Cypress, die 2023 abgeschlossen wurde – und die Einsicht, dass Product Ownership vor allem eines ist: Kommunikation, Priorisierung und das konsequente Denken aus Kundensicht.

Der erste Impuls: Ein Reiseblog, der Neugier weckt

Bei Barbara Sikora begann alles in der Schule – und zwar sehr pragmatisch.

Uns fällt auf, wie prägend dieser frühe Moment war: Ein digitales Produkt zum Klicken, Interagieren, Erleben – nicht Theorie, sondern Anfassen. Für viele Entwicklerkarrieren ist das der Funke, der später Entscheidungen in Studien- und Berufsphasen beeinflusst. Barbarras Begeisterung war keine abstrakte, sondern eine für Wirkung: Ein Nutzer klickt – und etwas geschieht. Genau diese Rückkopplung ist oft der Motor, um dranzubleiben.

Breite statt Tunnelblick: Das Studium als Experimentierfeld

Im Studium – an der Fachhochschule in Hagenberg – suchte sie bewusst die Weite. Film, Fotografie, Programmierung in verschiedenen Sprachen: kein starres Festlegen, sondern Neugier als Methode. Diese Breite war kein Umweg, sondern Teil des Plans.

Aus DevJobs.at-Sicht ist das ein wiederkehrendes Muster: Wer später Teams und Produkte führt, profitiert spürbar von interdisziplinären Erfahrungen. Design-Sensibilität, Prozessverständnis, technisches Grundrauschen – all das schafft eine gemeinsame Sprache mit unterschiedlichen Rollen. Bei Barbara legte es den Grundstein für eine spätere Stärke: Sie kann in der Product-Owner-Rolle technische Fragen genauso verorten wie Nutzerbedürfnisse und Business-Prioritäten.

Praxis schlägt Theorie: Der Einstieg als externe Frontend-Entwicklerin

Der erste Kontakt mit UNIQA entstand über „mein UNIQA“, entwickelt im Team Digital. Als externe Frontend-Entwicklerin war sie plötzlich „hands-on“ am echten Produkt.

Genau das spüren wir in ihrer Erzählung: Berufsrealität relativiert Theorie. Entscheidend war jedoch nicht nur die Technik, sondern die Teamkultur.

Diese wenigen Sätze erklären, warum sie den Wechsel nach intern wagte: Wertschätzung, Gestaltungsspielraum, Förderung. In vielen Tech-Teams ist das kein „Nice-to-have“, sondern die Grundlage, um Verantwortung zu übernehmen – und wichtige Veränderungsprozesse zu treiben.

2019 intern: Lead Frontend-Entwicklerin mit Qualitätsfokus

Mit 2019 kam der interne Wechsel – und damit mehr Verantwortung: Prozessoptimierungen, Qualität erhöhen, Problemstellen im Frontend aufspüren und verbessern. Die Ausgangslage war anspruchsvoll: AngularJS in einem zusätzlichen Framework „eingepackt“, an dessen Vorgaben sich die Entwickler halten mussten. Das erzeugte Reibung.

Wir kennen diese Situation aus vielen gewachsenen Produkten: ein Legacy-Setup, das einst produktiv war, heute jedoch den Takt vorgibt und Veränderungen bremst. Dass Barbara an genau dieser Stelle Prozess- und Qualitätsarbeit priorisierte, war konsequent – und die Voraussetzung, um Migration nicht nur technisch, sondern organisatorisch tragfähig zu machen.

Der technologische Wendepunkt: Migration auf Angular, Ionic und Cypress

Gemeinsam mit dem Team trieb sie die Modernisierung an. Ergebnis: 2023 war die Migration geschafft. Heute setzt das Frontend auf Angular, nutzt Ionic und testet mit Cypress.

Für uns ist dieser Abschnitt aus zwei Gründen bemerkenswert:

• Migration ist nie nur Code. Sie ist Veränderungsarbeit am System – Technologie, Prozesse, Verantwortung, Rhythmus. Dass Barbara diesen Weg aus der Lead-Frontend-Rolle mit angestoßen hat, zeigt, wie eng technische und organisatorische Arbeit verwoben sind.
• Das Zielbild ist bewusst modern, aber pragmatisch: Angular als Framework, Ionic als Brücke für ein einheitliches UI/UX-Paradigma über Plattformen hinweg, Cypress für automatisiertes Testen im Frontend. Kein „Shiny-Stack um jeden Preis“, sondern ein klarer Fokus auf Stabilität und Testbarkeit.

Perspektivwechsel: Die Product-Owner-Rolle während der Migration

Inmitten dieser Veränderung ergab sich für Barbara eine entscheidende Chance: die Product-Owner-Rolle zu übernehmen – und die Migration aus einem anderen Blickwinkel weiter voranzutreiben.

Dass sie sich für diesen Weg entschied, hatte viel mit Haltung zu tun: Projekt und Team lagen ihr am Herzen; die Verantwortung zu erweitern fühlte sich richtig an. Mit dem Rollenwechsel veränderten sich die Aufgaben deutlich:

• Kommunikation statt Code als primäres Werkzeug
• Informationen verstehen, strukturieren und adressatengerecht transportieren
• Brücke zwischen Entwicklungsteam und Fachbereich sein
• Priorisieren – stets mit dem Blick auf Kundennutzen

Für uns ist das der Kern: Product Ownership heißt, Komplexität einzudampfen und den Fokus konsistent auf Wert für Nutzerinnen und Nutzer zu legen – ohne technische Realitäten aus dem Blick zu verlieren. Barabaras technischer Hintergrund ist hier kein Selbstzweck, sondern ein Türöffner für bessere Gespräche mit Stakeholdern und realistischere Entscheidungen.

Skalierung erfordert Abstimmung: Sechs Teams, ein Produkt

Mit dem Wachstum des Produkts wuchs auch die Organisationskomplexität. Heute arbeiten sechs cross-funktionale Teams in einem agilen Setup, mit Sprintzyklen und klarer Verantwortungstaktung.

Das Entscheidende: Das digitale Produkt muss für Kundinnen und Kunden „aus einem Guss“ wirken. Diese Außenperspektive stellt hohe Anforderungen an interne Koordination – insbesondere auf Product-Owner-Ebene. Aus unserer Sicht zeigt sich hier, warum POs mehr sind als „Ticket-Sortierer“: Sie synchronisieren strategische Akzente, orchestrieren Abhängigkeiten und sorgen dafür, dass sich Einzelentscheidungen zu einem stimmigen Gesamtbild fügen.

So wird aus einer Idee ein Release: Der End-to-End-Fluss

Besonders konkret wurde Barbara, als sie den Weg einer Funktion von der Idee bis zum Deployment beschrieb. Für uns ist das ein Lehrbeispiel – nicht wegen neuer Buzzwords, sondern weil die Stationen klar aufeinander aufbauen:

1. Customer Research: Ein dediziertes Team untersucht, was sich Kundinnen und Kunden wünschen und welches Problem überhaupt gelöst werden soll.
2. Konzeptionsphase: POs und Entwickler arbeiten zusammen, um nur Lösungen zu designen, die technisch umsetzbar sind – im Idealfall ohne böse Überraschungen später.
3. Prototyping: Der Prototyp wird erstellt und getestet – als Reality-Check, bevor die große Umsetzung beginnt.
4. Entwicklung und Deployment: Erst wenn das Konzept verprobt ist, wird in den Teams entwickelt und ausgerollt.

In dieser Kette zeigt sich der Mehrwert des technischen Hintergrunds: Barbara versteht, warum in der Konzeptionsphase die Machbarkeit mitgedacht werden muss – und kann diese Perspektive sauber in die Kommunikation mit dem Fachbereich übersetzen.

Extern vs. intern: Lernpfade und Motivation

Ein spannender Teil ihrer Geschichte betrifft den Wechsel von extern zu intern – und was beide Wege auszeichnet.

Gleichzeitig wurde für sie irgendwann etwas anderes wichtiger:

Für uns wirkt das wie ein Kompass: Abwechslung vs. Tiefe, Breite vs. Eigentümerschaft. Beides sind valide Wege. Entscheidend ist, was in der eigenen Karrierephase zählt. Wer Produkte dauerhaft prägen will, findet intern oft die bessere Bühne – insbesondere, wenn Kultur und Team passen.

Skillset im Vergleich: Product Owner vs. Frontend-Entwicklerin

Barbara zeichnet die Unterschiede klar nach. Frontend-Entwicklung heißt, Code effizient und wiederverwendbar zu schreiben. Product Ownership heißt, Informationen so zu transportieren, dass sie auf der Empfängerseite ankommen – egal ob beim Fachbereich, bei der Entwicklung oder beim Kunden. Dazu gehört Empathie, das Hineinversetzen in das Gegenüber, und das Übersetzen zwischen Perspektiven.

Uns fällt auf: Der Rollenwechsel ist keine Abkehr von Technik, sondern eine Erweiterung des Wirkungskreises. Der Code wird zur Domäne des Teams – die Verantwortung der PO ist, den Raum dafür zu schaffen: klare Prioritäten, stabile Schnittstellen, realistische Zielbilder. Genau da zahlt sich der technische Hintergrund aus: Missverständnisse werden seltener, Abhängigkeiten früher sichtbar, Konzepte pragmatischer.

Was wir als Redaktion mitnehmen

Aus „Barbara Sikora, Product Owner bei UNIQA“ nehmen wir mehrere handfeste Erkenntnisse für Entwicklerinnen, Entwickler und angehende Product-People mit:

• Früh ausprobieren, breit lernen: Der Reiseblog in der Schule und das interdisziplinäre Studium in Hagenberg waren keine Zufälle, sondern Bausteine einer Haltung. Breite verschafft Perspektive – ein Vorteil in jeder Rolle, besonders in Product.
• Kultur schlägt Stack: Die Entscheidung, intern zu wechseln, fiel wegen Wertschätzung, Förderung und Gestaltungsspielraum. Das sind die Faktoren, die Migration und Qualitätsarbeit überhaupt ermöglichen.
• Migration ist Organisationsarbeit: Der Wechsel von AngularJS hin zu Angular, Ionic und Cypress ist nicht nur ein technischer Schritt. Er verlangt Priorisierung, Koordination und Kommunikation – Fähigkeiten, die in der Product-Owner-Rolle essenziell sind.
• Kundennutzen als Leitstern: „Was bringt dem Kunden wirklich was?“ – diese Frage ist der Anker in Barabaras Entscheidungen. Sie schützt vor technischem Selbstzweck und verankert Prioritäten.
• Skalierung verlangt PO-Synchronisation: Mit sechs cross-funktionalen Teams wird die Abstimmung zur Kernaufgabe. Auf PO-Ebene entsteht das Bild, das beim Kunden als „rundes Produkt“ ankommt.
• Extern oder intern? Beides ist richtig – abhängig von Motivation und Lernzielen. Abwechslung und technologische Breite vs. Ownership und Produktwirkung.

Praktische Anregungen für den Alltag in Tech-Teams

Was lässt sich aus dieser DevStory direkt in den Arbeitsalltag mitnehmen?

• Die „Machbarkeitsbrille“ in der Konzeptionsphase: Spart Zeit, Geld und Nerven. Entwickler früh einbinden – nicht erst zur Umsetzung.
• Testen als normaler Takt: Mit Tools wie Cypress standardisiert man Feedback und reduziert Regressionen. Wichtig ist weniger das Tool als die Verbindlichkeit, Tests ernst zu nehmen.
• PO als Übersetzer-Rolle denken: Es geht nicht ums Weiterreichen von Tickets, sondern um das Übersetzen von Problem zu Lösung, von Kundenwunsch zu Implementation und zurück.
• Kundenfokus messbar machen: Auch ohne Metrik-Katalog kann man bei jedem Item fragen: Welches Kundenproblem lösen wir? Woran erkennen wir das im Review?
• Cross-funktionale Zuschnitte pflegen: Wenn sechs Teams an einem Produkt arbeiten, ist Klarheit über Verantwortungen und Schnittstellen Gold wert – plus regelmäßige Abstimmung der POs.

Zitate, die hängen bleiben

Einige Passagen aus dem Talk fassen die Haltung und Erfahrung von Barbara prägnant zusammen:

Fazit: Eine Laufbahn, die Wirkung erklärt – nicht nur Rollen

Am Ende dieser Session mit Barbara Sikora von der UNIQA Insurance Group AG bleibt für uns ein klares Bild: Rollen ändern sich, Wirkung bleibt. Der Weg vom Frontend zur Product Ownerin war bei ihr kein Rollen-Hopping, sondern eine konsequente Erweiterung der Verantwortung – von Codequalität und Prozessverbesserung hin zu Priorisierung, Kommunikation und Kundennutzen. Die technologische Modernisierung – weg von AngularJS, hin zu Angular, Ionic und Cypress – war dabei Katalysator und Prüfstein zugleich.

Die Botschaft an alle, die zwischen Technik und Produkt navigieren: Breite Kompetenzen sind kein Luxus. Sie sind das Fundament, auf dem man Migrationen meistert, Teams skaliert und Produkte baut, die für Kundinnen und Kunden „rund“ wirken. Oder, um es mit Barbaras Haltung zu sagen: Genau hinsehen, was gebraucht wird – und die Verantwortung übernehmen, es möglich zu machen.

• 

  

  GenAI myUNIQA

  Aleksandar Kamenica von UNIQA zeigt in seinem devjobs.at TechTalk einen Anwendungsfall für AI innerhalb des Unternehmens und wie das Team zu der Lösung gekommen ist.

  Jetzt ansehen

• 

  

  Christoph Gruber, Head of IT Security bei UNIQA

  Christoph Gruber von UNIQA gibt im Interview Einblicke in die Organisation der Teams in der IT, welche Grundgedanken es bei der Wahl der jeweiligen Technologien gibt, sowie wie das Recruiting und Onboarding gestaltet ist.

  Jetzt ansehen

• 

  

  Eva-Maria Tscherne, Business Analyst bei UNIQA

  Eva-Maria Tscherne von UNIQA spricht im Interview über ihren Background wie sie zur Business Analyse gekommen ist und was ihre aktuelle Rolle beinhaltet und gibt Tipps zur Weiterentwicklung.

  Jetzt ansehen
• 

  

  Martin Fuger, Test Analyst bei UNIQA

  Martin Fuger von UNIQA erzählt im Interview darüber, wie er zur Test Analyse gekommen ist, wie dort der Tagesablauf in der Arbeit aussieht und welche Dinge seiner Ansicht nach für Neueinsteiger wichtig sind.

  Jetzt ansehen