solvistas GmbH

Digital Agency

Show all Videos

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Sophie Brückl, Product Owner bei solvistas," Speaker: Sophie Brückl outlines her journey from studying software engineering/bioinformatics (now Data Science) to software development, acting as a bridge to Data Science, then moving into consulting, software architecture, and project management, including leading a digitalization unit later merged with software development. Today she drives project management and requirements engineering end-to-end—from customer conversations through specifications and work packages to developer coordination—leveraging her development background to simplify communication. She highlights solvistas’ friendly culture and the constant variety of new projects, and advises that for PM/RE the key is wanting to talk to people; the tech is learnable, but genuine stakeholder engagement is essential.

From Code to Conversation: How Sophie Brückl at solvistas GmbH scales impact as a Product Owner through Requirements and People-Centered Project Work

Introduction: A career that ties two worlds together

In the session “Sophie Brückl, Product Owner bei solvistas” with speaker Sophie Brückl (solvistas GmbH), we encountered a career path that begins in software engineering, stretches across data-oriented interfaces, and finds its core in project management and requirements engineering. What stood out to us editorially is how naturally Sophie Brückl merges technical depth with clear communication—and turns that into an everyday bridge between customers and development, between requirements and implementation, between business and technology.

Her journey mirrors the shift many engineers experience when they move toward product responsibility. And it shows that buzzwords matter less than posture: listen, understand, structure—and have the right conversations. About the team, she says: “Die Leute sind extrem gemütlich”—the people are extremely easy-going—and she points to a culture where ambitious projects and a good human dynamic go together. In this article, we trace Sophie’s path, highlight its milestones, and pull out the learnings that feel most actionable for engineers and aspiring Product Owners.

The foundation: Software engineering, bioinformatics, and Data Science thinking

Sophie Brückl studied Software Engineering and Bioinformatics in Hagenberg—a program that today carries the name Data Science. That detail matters because it explains why her start at solvistas GmbH worked so well. Her studies contained “a lot of software development” and not just a pure data track. The result: she entered the field with both—an ability to write solid code and an understanding of data-driven work.

This duality shaped her early assignments at solvistas. She began “very strongly” in software development while simultaneously keeping an eye on the interfaces. Acting as a connector to Data Science colleagues—“who were more involved with statistics”—she could speak both languages. Anyone who has mediated between statistical modeling, data pipelines, and application logic knows this is more than translation; it is the art of aligning different mental models.

Stepping outward: Consulting and direct customer conversations

Sophie moved “relatively quickly” into consulting—working with external customers, taking on projects where requirements must be clarified and expectations stewarded. This move didn’t abandon her technical background; it built on it. Knowing how software is built helps you ask better questions, judge feasibility more precisely, and prioritize more clearly in customer conversations.

Here we see a recurring pattern in Sophie’s career: she widens her radius of impact without losing technical grounding. And she uses that grounding to uncover what is truly needed—not only what is first articulated as a want. That is the essence of product responsibility many engineers grow into: deep enough in the craft to weigh options and constraints, present enough in dialogue to sharpen goals and boundaries.

Architecture, project management—and the craft of clarifying requirements

Over time, Sophie “developed toward software architecture and also project management.” Her focus shifted toward orchestration—but never detached from delivery. For her, project management is not just about watching timelines; it is about creating the conditions for good work. In her description of requirements engineering, it becomes very concrete:

“Talk to customers from the beginning”—set the frame with the right conversations.
“Figure out what customers need”—surface the actual need.
“Write it all down”—document outcomes clearly.
“Split it into work packages”—structure the work so development can get going.
“Talk to developers about what they need”—act as a translator, close information gaps, enable execution.

Coming from engineering pays dividends: “I have a relatively good basis so that I don’t have to speak to a developer from every faction and also don’t have to bring a developer to every meeting.” This captures a central advantage: technical fluency saves loops—and builds trust on both sides.

Organizational development: A Digitalization unit—and a merger with software engineering

At one point, Sophie led a business unit “strongly specialized in digitalization.” Later, that unit was merged with the software engineering unit “because it overlapped so much that we were basically doing the same things by then.”

This mirrors what many organizations experience: digitalization is not an island next to software engineering. It is tightly intertwined. For Sophie, that meant taking responsibility at an interface—and acknowledging that technology and digital initiatives belong structurally together. The takeaway for those who want to grow in tech organizations: structure follows problems. As problem spaces converge, structures follow suit.

Today: Project management, requirements engineering, and larger projects

“Since then I’ve been active in all kinds of project management activities at solvistas.” Today, there are “a few larger” projects, and Sophie describes her focus in particular on requirements engineering. Her way of working becomes tangible here: talk early with customers, clarify needs, write them down, cut the work into packages, and build the bridge to engineering. Alongside that, there are phases of “really just project management”—making sure “things get done” and “the schedule is kept.”

The interplay is telling: in many cases she interweaves project management and requirements engineering. One can exist without the other, but in her role they reinforce each other. Clear requirements give rise to a robust plan, and plans are more realistic when you understand the flow of work.

Team culture at solvistas: “Die Leute sind extrem gemütlich”—and the projects stay exciting

On culture, Sophie puts it plainly: “The people are extremely easy-going. It’s an extremely good climate. The people all get along.” At the same time, she underlines the project mix: “There are always new projects. It’s not a single big product that you maintain for decades where nothing changes anyway; there’s always a lot to do, a lot to discover, and a lot to learn.”

This mix—good collaboration, varied challenges, continuous learning—clearly fuels her motivation. And it explains why communication plays such a big role in her story: projects are shaped by people. When teams respect each other technically and relate well interpersonally, they explore new territory more easily and embrace change together.

“You must be able—and want—to talk to people”: The non-negotiable

Sophie sets a clear expectation for those who want to succeed in roles like hers: “You must be able to talk to people—and want to. The wanting is very important.” She has “met many project managers who also came from engineering,” who “had to take on project management by necessity,” but who “didn’t want to talk to people at all.” That is “unfavorable when you are in direct customer contact” or “when you take on the requirements part”—the moments when you “have to find out what the customer really needs” and “perhaps also talk to end users.”

Her conclusion is crisp: “Everything else can be learned, but this wanting to talk to people, to engage with people, and to try to understand each side… that is what you have to bring. Everything else is technology you can learn—but this is what you must have to be good.”

For engineers moving toward Product Ownership, Requirements Engineering, or Project Management, this is the headline: communication is not a side task—it is the core of the job. And it starts with the willingness to understand people.

What engineers can take away: Five practical insights

From “Sophie Brückl, Product Owner bei solvistas,” we draw the following points that translate directly into practice:

Keep your technical base—it’s leverage in every customer conversation.

It builds fluency with development teams.
It helps convert requirements into executable work packages.
It reduces friction by revealing misunderstandings early.

Requirements engineering is a conversation process, not a form to fill.

Start: listen and ask questions (“talk to customers from the beginning”).
Middle: clarify needs (“what customers need”).
End: write it down, structure it, split it—so teams can start.

Project management requires presence—and follow-through.

Ensure that “things get done.”
Make sure “the schedule is kept.”
Following up is not bureaucracy; it protects quality and trust.

Culture is a productivity factor.

“The people are extremely easy-going … an extremely good climate.”
Teams that get along learn faster and carry change better.

The most important ability: wanting to talk to people.

Without genuine interest, customer contact becomes a burden.
With genuine interest, it becomes a driver of clarity and progress.

A simple structure for your next requirements conversation

Sophie’s description points to a clear motion that defines her approach to requirements. For your next conversation with customers or end users, a simple structure can help—anchored in what she names:

Opening: clarify context and aims
What problem are we solving?
Which users are affected?
What value is being pursued?
Surface needs: “What do customers need?”
Which tasks should become better, faster, or safer?
What is missing today? What is in the way?
Write it down: document the outcomes
What core requirements follow from this?
Which assumptions require validation?
Split it: cut work into packages
What is the first meaningful step?
Which information does engineering need to start?
Align with engineering: ensure executable clarity
What questions does the team have?
Where do we need to sharpen?

This structure is intentionally simple. It follows the exact path Sophie outlines. And it lays the groundwork for turning conversations into execution.

From a digitalization unit to a shared software engineering practice: what the merger signals

The decision to merge the digitalization unit with the software engineering unit—because “we were basically doing the same things by then”—illustrates a familiar pattern: as domains converge, organizational consolidation pays off. For roles like Sophie’s, that means looking beyond your discipline and recognizing where boundaries dissolve.

The lesson for tech talent: careers don’t only grow vertically (more responsibility) but also laterally (more impact at interfaces). Mastering interfaces amplifies the output of the entire system.

Why communication is the product lever

Sophie repeatedly emphasizes conversation as leverage. Talk to customers to understand needs. Talk to developers to supply the information they require. Talk to end users to mirror reality. And maintain the posture of wanting to understand people—each side with its needs.

This is not soft—it’s powerful. Good communication reduces uncertainty. It creates shared expectations. It prevents requirements from turning into a wish list or a black box. And it ensures that work packages are not only technically correct but also meaningful in context.

This is the difference, in Sophie’s portrayal, between project management as administration and project management as leadership: don’t just distribute tasks—create clarity and make the team compatible with real needs.

Who this path suits: Engineers curious about people

If we distill Sophie’s path into a profile, it would be this: people who enjoy engineering, who have a solid technical base—and who are also eager to talk to customers and users—are well-suited for roles like Product Ownership, Requirements Engineering, or Project Management. You don’t have to master everything on day one. But you should “be able—and want—to talk to people.” The “wanting” is the bridge. Everything else can be “learned.”

That thought is encouraging. It lowers the barrier for talent interested in responsibility but wary of grand titles. Responsibility begins in conversation. And it grows with each successful translation between need and delivery.

A look at the day-to-day: Variety over monolith

Sophie describes a day-to-day that is both varied and structured. There are “always new projects”—not “one big product you maintain for decades.” To us, that sounds like an environment where continuous learning is part of the job. If you crave variety, her experience resonates. If your preference is a single long-lived product, you might find fulfillment elsewhere. Both are valid—what matters is choosing consciously.

That Sophie embraces this variety is obvious. She speaks of “a lot to discover and a lot to learn.” This is not self-congratulation; it’s a posture. Learning isn’t just a resource you draw down—it’s an environment you co-create through questions, conversations, and the willingness to take responsibility.

Three questions we draw from Sophie’s approach

What do I need to understand in the next customer conversation before proposing any solution?
Which information does our engineering team require so it can start without additional meetings?
What small organizational hurdle can I remove today so that “things get done” and “the schedule is kept”?

These questions are deliberately concrete. They target the levers Sophie keeps using: create clarity, translate, enable.

A line to remember: “Everything else is technology you can learn …”

If we had to highlight a single line from this session, it would be: “Everything else can be learned … Everything else is technology you can learn—but this is what you must have to be good.” She means the interest in people, conversation, and understanding. It’s a realistic optimism: you can build the technical. What you must bring is the willingness to engage—with customers, colleagues, and end users.

Conclusion: Bridge-building is a skill—and a posture

The session “Sophie Brückl, Product Owner bei solvistas” (solvistas GmbH) shows a path that refuses false binaries. Software engineering and Data Science aren’t separate worlds—they enrich each other. Project management isn’t clerical—it’s enabling. Requirements engineering isn’t a document—it’s a conversational process. And culture isn’t a nice-to-have—it’s the ground we work on.

Sophie Brückl makes it clear that a career along these lines emerges when you combine two things: a solid technical base and the willingness to talk to people—openly, clearly, and with genuine interest. Bring both, and you can grow from code into roles of amplified impact—on the product, on the process, and especially at the interfaces where we turn needs into reality.

More Dev Stories