solvistas GmbH

Digitale Agentur

Alle Videos anzeigen

Sophie Brückl, Product Owner bei solvistas

Sophie Brückl von solvistas teilt im Interview ihre Erfahrungen beim Wechsel vom Software Development hin zur aktuellen Arbeit als Product Owner und welche Tipps sie jenen gibt, die ähnliche Schritte planen.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "Sophie Brückl, Product Owner bei solvistas", Speaker: Sophie Brückl schildert ihren Weg vom Studium in Softwareentwicklung/Bioinformatik (heute Data Science) in Hagenberg über Softwareentwicklung und die Schnittstelle zu Data Science hin zu Consulting, Softwarearchitektur und Projektmanagement, inklusive der Leitung einer Digitalisierungs-Unit, die später mit der Softwareentwicklung zusammengelegt wurde. Heute verantwortet sie vor allem Projektmanagement und Requirements Engineering – vom Kundengespräch über Spezifikation und Arbeitspakete bis zur Abstimmung mit Entwicklern – und profitiert dabei stark von ihrem Entwicklungs-Background. Sie betont die kollegiale Kultur und die Vielfalt neuer Projekte und rät, für PM/RE vor allem gern und gut mit Menschen zu sprechen; Technik kann man lernen, echte Kundennähe muss man mitbringen.

Vom Code zur Kommunikation: Wie Sophie Brückl bei solvistas GmbH als Product Owner Brücken zwischen Entwicklung, Data Science und Kunden baut

Einleitung: Eine Karriere, die zwei Welten verbindet

In der Session „Sophie Brückl, Product Owner bei solvistas“ mit Speaker Sophie Brückl (solvistas GmbH) haben wir eine Laufbahn kennengelernt, die in der Softwareentwicklung startet, sich über Data-Science-Schnittstellen erstreckt und im Projektmanagement sowie Requirements Engineering ihren Wirkungskern findet. Was uns als Redaktion besonders hängen geblieben ist: die Selbstverständlichkeit, mit der Sophie Brückl technische Tiefe mit klarer Kommunikation verbindet – und daraus eine Rolle formt, die im Alltag Brücken schlägt: zwischen Kundenseite und Entwicklung, zwischen Anforderungen und Umsetzung, zwischen Business und Technologie.

Ihr Weg ist exemplarisch für viele Entwickler:innen, die sich im Laufe ihrer Karriere Richtung Produktverantwortung orientieren. Und er zeigt, dass es weniger um Schlagworte geht als um Haltung: zuhören, verstehen, strukturieren – und die richtigen Gespräche führen. „Die Leute sind extrem gemütlich“, sagt sie über das Team – und meint damit eine Kultur, in der anspruchsvolle Projekte und ein gutes Miteinander zusammenfinden. In diesem Beitrag zeichnen wir Sophies Weg nach, fassen zentrale Stationen zusammen und destillieren die Learnings, die uns für Entwickler:innen und künftige Product Owner besonders wertvoll erscheinen.

Fundament: Softwareentwicklung trifft Bioinformatik und Data Science

Sophie Brückl hat Softwareentwicklung bzw. Bioinformatik in Hagenberg studiert – ein Studiengang, der mittlerweile den Namen Data Science trägt. Dieses Detail ist nicht nur biografisch: Es erklärt, warum ihr Start bei der solvistas GmbH so gut funktionierte. Denn ihr Studium enthielt „sehr viel Softwareentwicklung“ und nicht nur eine reine Datenschiene. Die Folge: Sie brachte von Beginn an beides mit – die Fähigkeit, sauberen Code zu schreiben, und das Verständnis für datengetriebene Arbeitsweisen.

Genau diese Verschränkung prägte ihren frühen Einsatz bei solvistas. Sie stieg „zuerst sehr stark in der Softwareentwicklung“ ein, hatte aber gleichzeitig den Blick auf die Schnittstellen. Als Bindeglied zu den Data-Science-Kolleg:innen – „die halt verstärkt mit Statistiken zu tun gehabt haben“ – konnte sie beide Sprachen sprechen. Wer schon einmal zwischen Statistikmodellen, Datenpipelines und Applikationslogik vermittelt hat, weiß: Das ist mehr als nur Fachübersetzung; es ist das Zusammenführen unterschiedlicher Denkkulturen.

Der Schritt nach außen: Consulting und Kundenkontakt

Relativ schnell ging es für Sophie in Richtung Consulting – zu externen Kund:innen, zu Projekten, in denen Anforderungen sauber geklärt und Erwartungen gemanagt werden müssen. Dieser Schritt stand nicht im Gegensatz zur Technik, sondern baute auf ihr auf. Wer weiß, wie Software gebaut wird, kann im Kundengespräch präziser fragen, besser einschätzen und klarer priorisieren.

Hier zeigt sich ein roter Faden in Sophies Laufbahn: Sie erweitert ihren Wirkungskreis, ohne ihre technische Basis zu verlieren. Und sie nutzt diese Basis, um in Gesprächen zu verstehen, was wirklich gebraucht wird – nicht nur, was im ersten Satz gewünscht wird. Das ist eine Kompetenz, die vielen Entwickler:innen eigen ist, die Verantwortung für Produkt und Projekt übernehmen: Sie greifen tief genug in die Fachlichkeit, um Möglichkeiten und Grenzen abzuwägen, und sind gleichzeitig präsent genug im Dialog, um Ziele und Rahmenbedingungen zu schärfen.

Architektur, Projektmanagement – und die Kunst, Anforderungen zu klären

Mit der Zeit entwickelte sich Sophie „in Richtung Softwarearchitektur und eben dann auch Projektmanagement“. Damit verschob sich der Schwerpunkt stärker in Richtung Orchestrierung – aber nie losgelöst von der Umsetzung. Projektmanagement heißt für sie nicht nur Termine überwachen. Es heißt, die Voraussetzungen für gute Arbeit zu schaffen. Und in ihrer Beschreibung des Requirements Engineering wird das konkret:

„Von Anfang mit Kunden reden“ – die Gespräche führen, die den Rahmen setzen.
„Hin zu, was brauchen die Kunden“ – das eigentliche Bedürfnis herausarbeiten.
„Bis hin zu das ganze Festhalten“ – die Ergebnisse sauber dokumentieren.
„Das Arbeitspaket aufteilen“ – so strukturieren, dass Entwicklung effizient loslegen kann.
„Mit den Entwicklern reden, wie die das dann brauchen“ – translatorisch wirken, Informationslücken schließen, die Umsetzung ermöglichen.

Dass sie aus der Entwicklung kommt, zahlt sich aus: „Ich habe da schon eine relativ gute Basis, dass ich jetzt nicht bei jeder Fraktion Entwickler reden muss und auch nicht bei jedem Meeting einen Entwickler mitnehmen muss.“ Dieser Satz bringt einen zentralen Vorteil auf den Punkt: Technische Anschlussfähigkeit spart Schleifen – und schafft Vertrauen auf beiden Seiten.

Organisationsentwicklung: Eine Digitalisierungs-Unit und ihre Zusammenlegung

Zwischendurch leitete Sophie eine Business Unit, die „sich stark auf Digitalisierung spezialisiert hat“. Später wurde sie mit der Softwareentwicklungs-Business-Unit zusammengelegt, „weil sich das dann einfach so überschnitten hat, dass wir da einfach dieselben Sachen mittlerweile machen.“

Diese Entwicklung spiegelt, was viele Unternehmen erleben: Digitalisierung ist keine Insel neben der Softwareentwicklung. Sie ist untrennbar mit ihr verwoben. Für Sophie bedeutete das, Verantwortung in einer Schnittstellenrolle zu übernehmen – und anzuerkennen, dass Technologie und Digitalisierungsinitiativen strukturell zusammengehören. Eine wichtige Erkenntnis für alle, die in Tech-Organisationen wachsen wollen: Die Struktur folgt dem Problem – und wenn sich die Probleme angleichen, ziehen die Strukturen nach.

Heute: Projektmanagement, Requirements Engineering und größere Projekte

„Seitdem bin ich in allen möglichen Projektmanagement-Tätigkeiten in der Solvistas tätig.“ Die Projekte sind „mittlerweile ein paar größere“, und Sophie beschreibt ihren Fokus vor allem im Requirements Engineering. Hier wird ihre Arbeitsweise greifbar: frühzeitig mit Kund:innen sprechen, Bedürfnisse klären, festhalten, Arbeitspakete schneiden und die Brücke zur Entwicklung schlagen. Daneben gibt es Phasen des „wirklich nur Projektmanagement“ – also das Sicherstellen, „dass die Sachen erledigt werden“ und „dass der Zeitplan eingehalten wird“.

Spannend ist das Zusammenspiel: In vielen Fällen verschränkt sie Projektmanagement und Requirements Engineering. Das eine ohne das andere ist möglich – aber in ihrer Rolle ergänzt es sich. Der Projektplan folgt aus klaren Anforderungen. Und Anforderungen werden realistischer, wenn man Projektabläufe im Blick hat.

Arbeitskultur bei solvistas: „Die Leute sind extrem gemütlich“ – und die Projekte bleiben spannend

Über die Kultur sagt Sophie einen Satz, der beides ausdrückt: Verbundenheit und Professionalität. „Die Leute sind extrem gemütlich. Es ist ein extrem gutes Klima. Die Leute verstehen sich alle.“ Gleichzeitig betont sie die Spannung der Projekte: „Es gibt immer wieder neue Projekte. Es ist jetzt nicht dieses eine große Produkt, das man über Jahrzehnte betreut und wo sich eh nichts ändert, sondern es gibt immer viel zu tun, viel Neues zu entdecken, viel Neues zu lernen.“

Dieser Mix – gute Zusammenarbeit, abwechslungsreiche Aufgaben, kontinuierliches Lernen – scheint zentral für ihre Motivation zu sein. Und er erklärt, warum Kommunikation in ihrer Erzählung so viel Raum einnimmt: Projekte leben von Menschen. Wer sich fachlich respektiert und menschlich versteht, erschließt neues Terrain leichter und trägt Veränderungen gemeinsam.

„Sie müssen auf jeden Fall mit Leuten reden können und wollen“: Das wichtigste Kriterium

Sophie formuliert klare Erwartungen an Menschen, die in Rollen wie ihrer erfolgreich sein wollen. „Sie müssen auf jeden Fall mit Leuten reden können und wollen. Also das Wollen ist ganz wichtig.“ Sie hat „viele Projektmanager kennengelernt, die auch aus der Entwicklung gekommen sind“, die „zwangsmäßig dann Projektmanagement mitmachen haben müssen“, aber „überhaupt nicht mit den Leuten reden wollten“. Das sei „ungünstig, wenn man in direkten Kundenkontakt ist“ oder „wenn man eben diesen Requirements Part mitnimmt“ – dort, wo man „herausfinden muss, was braucht der Kunde wirklich“ und „vielleicht auch noch mit Endusern reden“ sollte.

Ihr Fazit ist prägnant: „Alles andere kann man lernen, aber dieses mit Menschen reden, wollen, auf Menschen eingehen und versuchen zu verstehen jeder Seite … das ist das, was du mitbringen musst. Alles andere ist Technik, die du lernen kannst, aber das ist einfach was, was du dabei haben musst, damit du gut bist.“

Für uns liegt darin eine Kernbotschaft für Entwickler:innen, die Richtung Product Ownership, Requirements Engineering oder Projektmanagement streben: Kommunikation ist nicht Beiwerk – sie ist Jobkern. Und sie beginnt mit der Haltung, Menschen verstehen zu wollen.

Was wir für Entwickler:innen mitnehmen: Fünf handfeste Einsichten

Aus der Session „Sophie Brückl, Product Owner bei solvistas“ nehmen wir folgende Punkte mit, die sich unmittelbar in die Praxis übersetzen lassen:

Behalte deine technische Basis – sie ist ein Hebel im Kundengespräch.

Sie macht dich anschlussfähig gegenüber Entwicklungsteams.
Sie hilft, Anforderungen in umsetzbare Arbeitspakete zu übersetzen.
Sie reduziert Reibungsverluste, weil du Missverständnisse früh erkennst.

Requirements Engineering ist ein Gesprächsprozess, kein Formular.

Anfang: Zuhören und Fragen stellen („von Anfang mit Kunden reden“).
Mitte: Bedürfnisse klären („was brauchen die Kunden“).
Ende: Festhalten, strukturieren, aufteilen – damit Teams starten können.

Projektmanagement braucht Präsenz – und Konsequenz.

Es geht darum, „dass die Sachen erledigt werden“ und „dass der Zeitplan eingehalten wird“.
Konsequentes Nachhalten ist kein Selbstzweck, sondern schützt Qualität und Vertrauen.

Kultur ist ein Produktivitätsfaktor.

„Die Leute sind extrem gemütlich … ein extrem gutes Klima.“
Wer sich versteht, lernt schneller und trägt Veränderung leichter.

Die wichtigste Fähigkeit: reden wollen.

Ohne echtes Interesse am Austausch wird Kundenkontakt zur Bürde.
Mit echtem Interesse wird er zum Motor für Klarheit und Fortschritt.

Praxis: Eine einfache Gesprächsstruktur für das nächste Requirement-Gespräch

In Sophies Beschreibung steckt eine klare Grundbewegung, die ihr Requirements Engineering prägt. Für das nächste Gespräch mit Kund:innen oder Endnutzer:innen kann eine einfache Struktur helfen – immer entlang dessen, was sie nennt:

Einstieg: Kontext und Ziel klären
Was ist das Problem, das wir lösen wollen?
Welche Nutzer:innen sind betroffen?
Welcher Nutzen wird angestrebt?
Bedürfnis herausarbeiten: „Was brauchen die Kunden?“
Welche Aufgaben sollen besser, schneller, sicherer werden?
Was fehlt heute? Was behindert?
Festhalten: Ergebnisse dokumentieren
Welche Kernanforderungen ergeben sich daraus?
Welche Annahmen sind zu überprüfen?
Aufteilen: Arbeitspakete schneiden
Was ist der erste sinnvolle Schritt?
Welche Informationen braucht die Entwicklung, um loszulegen?
Abgleich mit der Entwicklung: Anschlussfähigkeit sichern
Welche Fragen hat das Team?
Wo müssen wir nachschärfen?

Diese Struktur ist bewusst einfach. Sie folgt genau dem Weg, den Sophie beschreibt. Und sie schafft die Grundlage, um aus Gesprächen Arbeitsfähigkeit zu machen.

Von der Digitalisierungs-Unit zur gemeinsamen Softwareentwicklung: Was die Zusammenlegung zeigt

Die Entscheidung, die Digitalisierungs-Unit mit der Softwareentwicklungs-Unit zusammenzuführen, weil „wir da einfach dieselben Sachen mittlerweile machen“, illustriert ein wiederkehrendes Muster: Wenn Aufgabenfelder zusammenwachsen, lohnt sich die organisatorische Konsolidierung. Für Rollen wie die von Sophie heißt das: Den Blick über die eigene Disziplin hinaus richten und erkennen, wo sich Grenzen verflüssigen.

Die Lektion für Tech-Talente: Karrieren verlaufen nicht nur vertikal (mehr Verantwortung), sondern auch lateral (mehr Wirkung an Schnittstellen). Wer Schnittstellen beherrscht, steigert die Wirkung des gesamten Systems.

Warum Kommunikation der Produkthebel ist

Sophie betont mehrfach das Gespräch als Hebel. Mit Kund:innen sprechen, um Bedürfnisse zu verstehen. Mit Entwickler:innen sprechen, um Informationsbedarfe zu decken. Mit Endnutzer:innen sprechen, um die Realität zu spiegeln. Und sich selbst die Haltung bewahren, Menschen „verstehen“ zu wollen – jede Seite mit ihren Bedürfnissen.

Das ist nicht weich, sondern hochwirksam. Denn gute Kommunikation reduziert Unsicherheit. Sie schafft geteilte Erwartung. Sie verhindert, dass Anforderungen zur Wunschliste oder zur Black Box werden. Und sie sorgt dafür, dass Arbeitspakete nicht nur technisch korrekt, sondern auch fachlich sinnvoll sind.

Genau das macht in Sophies Beschreibung den Unterschied aus zwischen Projektmanagement als Verwaltung und Projektmanagement als Führung: Nicht nur Aufgaben verteilen, sondern Klarheit schaffen – und das Team anschlussfähig an die echten Bedürfnisse machen.

Für wen sich der Weg lohnt: Entwickler:innen mit Neugier auf Menschen

Wenn wir Sophies Weg auf ein Profil herunterbrechen müssten, wäre es dieses: Menschen, die gern entwickeln, die eine solide technische Basis haben – und die gleichzeitig Lust haben, mit Kund:innen und Nutzer:innen zu sprechen, sind für Rollen wie Product Ownership, Requirements Engineering oder Projektmanagement prädestiniert. Sie müssen nicht alles von Anfang an können. Aber sie sollten „mit Leuten reden können und wollen“. Das „Wollen“ ist die Brücke. Alles andere lässt sich „lernen“.

Dieser Gedanke ist ermutigend. Er senkt die Schwelle für Talente, die an Verantwortung interessiert sind, aber sich vor dem großen Titel scheuen. Verantwortung beginnt im Gespräch. Und sie wächst mit jeder gelungenen Übersetzung zwischen Bedürfnis und Umsetzung.

Ein Blick auf den Alltag: Vielfalt statt Monolith

Sophie beschreibt ihren Alltag als ebenso vielseitig wie verlässlich in der Struktur. Es gibt „immer wieder neue Projekte“ – nicht „dieses eine große Produkt, das man über Jahrzehnte betreut“. Für uns klingt das nach einem Arbeitsumfeld, in dem kontinuierliches Lernen Teil des Jobs ist. Wer Vielfalt sucht, findet hier Resonanz. Wer Fokus auf ein einzelnes Produkt sucht, findet vielleicht an anderer Stelle Erfüllung. Beides ist legitim – entscheidend ist, bewusst zu wählen.

Dass Sophie diese Vielfalt als Chance erlebt, ist spürbar. Sie spricht über „viel Neues zu entdecken, viel Neues zu lernen“. Das ist kein Selbstlob, sondern gelebte Haltung. Sie zeigt: Lernen ist weniger eine Ressource, die man abrufen kann, als eine Umgebung, die man mitgestaltet – durch Fragen, Gespräche und die Bereitschaft, Verantwortung zu übernehmen.

Drei Fragen, die wir aus Sophies Ansatz ableiten

Was muss ich im nächsten Kundengespräch verstehen, bevor ich eine Lösung vorschlage?
Welche Informationen braucht unser Entwicklungsteam, damit es ohne weitere Meetings starten kann?
Wo kann ich heute eine kleine organisatorische Hürde aus dem Weg räumen, damit „die Sachen erledigt werden“ und „der Zeitplan eingehalten wird“?

Diese Fragen sind bewusst konkret. Sie zielen auf die Hebel, die Sophie in ihrer Erzählung immer wieder betätigt: Klarheit schaffen, Übersetzen, Ermöglichen.

Zitat, das bleibt: „Alles andere ist Technik, die du lernen kannst …“

Wenn wir ein Zitat aus dieser Session hervorheben müssten, wäre es dieses: „Alles andere kann man lernen … Alles andere ist Technik, die du lernen kannst, aber das ist einfach was, was du dabei haben musst, damit du gut bist.“ Gemeint ist das Interesse an Menschen, das Gespräch, das Verstehen-Wollen. Es ist ein realistischer Optimismus: Fachliches lässt sich aufbauen. Was du mitbringen musst, ist die Bereitschaft, in Beziehung zu treten – mit Kund:innen, mit Kolleg:innen, mit Endnutzer:innen.

Fazit: Brücken bauen ist ein Skill – und eine Haltung

Die Session „Sophie Brückl, Product Owner bei solvistas“ (solvistas GmbH) zeigt uns einen Weg, der nicht in Widersprüchen denkt. Softwareentwicklung und Data Science sind keine getrennten Welten – sie befruchten sich gegenseitig. Projektmanagement ist keine Verwaltungsdisziplin – es ist Ermöglichung. Requirements Engineering ist kein Dokument – es ist ein Gesprächsprozess. Und Kultur ist kein Nice-to-have – sie ist Arbeitsgrundlage.

Sophie Brückl macht deutlich, dass eine Karriere entlang dieser Linien entsteht, wenn man zweierlei verbindet: eine saubere technische Basis und die Bereitschaft, mit Menschen zu sprechen – freundlich, klar, interessiert. Wer beides mitbringt, kann vom Code aus in Rollen wachsen, die Wirkung entfalten: am Produkt, am Prozess und vor allem an den Schnittstellen, an denen aus Anforderungen Realität wird.

Weitere Dev Stories