Vom Schaltschrank zur Schnittstelle: Die Product-Owner-Reise von Dominik Zimmel (Auftragnehmerkataster Österreich)

Einleitung: Eine Rolle, die man nicht sucht – sie findet einen

„Den Beruf Product Owner sucht man sich eigentlich nicht aus, man findet dorthin.“ Dieser Satz aus der Session „Dominik Zimmel, Product Owner bei ANKÖ“ ist der rote Faden, der sich durch die gesamte Laufbahn von Speaker Dominik Zimmel (Company: Auftragnehmerkataster Österreich) zieht. In unserer DevJobs.at-Redaktion haben wir selten eine so klare, nüchterne und zugleich menschliche Beschreibung dieser Rolle gehört. Keine Buzzwords, keine Methoden-Aufzählung – sondern ein präziser Blick auf das Handwerk und die Haltung, die es braucht, um zwischen Technik und Management zu vermitteln.

Was wir in dieser Erzählung besonders schätzen: Dominik bleibt bei den Essentials. Er erklärt, wie ihn seine technische Herkunft erdet, warum wirtschaftliches Denken im Product Ownership eine Konstante ist, und weshalb Kommunikation nicht „nice to have“, sondern ein Ausschlusskriterium ist: Wer sie nicht beherrscht, sollte den Job nicht wählen. Dieser Beitrag rekonstruiert seine Stationen, Motive und Lehren – und destilliert daraus konkrete Impulse für Entwicklerinnen und Entwickler, die sich zur produktführenden Schnittstelle entwickeln möchten.

Von der Elektrotechnik zur Arbeit mit Menschen

Dominik beginnt seine Laufbahn auf der HTL mit Elektrotechnik. Das Bild, das er zeichnet, ist haptisch, präzise und praktisch: Schaltschränke, Anlagenbau, „sehr physisch, wenig am Bildschirm“. Er beschreibt die Faszination, aber auch die Leerstelle: Die Arbeit ist technisch und handfest, doch ihm fehlt der Austausch. Er sieht sich „in Richtung mit Leuten reden, das Management vielleicht ein bisschen“.

Dieser Kontrast ist entscheidend. Er markiert den ersten Wendepunkt: Nicht weg von Technik, sondern hin zu einer Rolle, in der Technik und Menschen zusammenkommen. Diese innere Bewegung – der Wunsch, das Technische mit dem Wirtschaftlichen und Zwischenmenschlichen zu verbinden – bildet bei Dominik den Keim für Product Ownership.

Digital Business: Die Brücke aus Technik und Wirtschaft

Auf die HTL folgt der Studiengang Digital Business. Dominik beschreibt ihn als „super“, weil er Management und Wirtschaft auf der einen, Technik auf der anderen Seite verbindet. Er nennt die Bausteine bewusst nüchtern:

• Basics im Programmieren
• Webentwicklung
• Management
• Kostenrechnung
• Wirtschaftliche Machbarkeit

Damit setzt er den Rahmen, der später sein Arbeitsprinzip wird: Product Ownership ist ohne ökonomische Perspektive unvollständig. „Ob das Ganze wirtschaftlich überhaupt möglich ist“, sagt er, sei eine Konstante der Rolle. Für unsere Redaktion ist dieser Punkt zentral: In vielen Teams ist die Frage nach technischer Machbarkeit präsent, die ökonomische Tragfähigkeit jedoch zu spät Teil der Diskussion. Dominiks Weg stellt diese Reihenfolge auf die Füße.

Was Product Ownership für ihn bedeutet

Wenn Dominik die Rolle beschreibt, sind es drei Spannungsfelder, die er immer wieder adressiert:

1) Strategie und Vision halten

2) Gesetzliche Anforderungen verstehen und einhalten

3) Nutzerwünsche ernst nehmen und in ein verwendbares Produkt bringen

Diese Formel ist anspruchsvoll. Sie verlangt Ambiguitätstoleranz: Mehrere Wahrheiten – Gesetz, Nutzerperspektive, Produktziel – müssen gleichzeitig gültig bleiben. Für Dominik ist genau das attraktiv: „eine super Möglichkeit, kreative Lösungen zu bringen, die teilweise auch komplexe Probleme dann angehen.“ Kreativität heißt hier nicht „Feature-Ideen streuen“, sondern klug zugespitzte Antworten auf echte Restriktionen zu finden.

Kreativität unter Auflagen: Warum ihn die Spannung reizt

Dominik mag die „Schwierigkeit zwischen gesetzlichen Anforderungen und User-Perspektive“. In seiner Stimme liegt dabei keine Klage, sondern Lust am Möglichmachen. Wer seinen Worten folgt, erkennt: Der Reiz liegt nicht im bequemen Innovationsraum, sondern in der reibungsreichen Zone, in der Technik, Recht und Nutzung aufeinandertreffen.

Das ist eine wichtige Erinnerung für alle, die Product Ownership romantisieren: Es geht weniger um neue Ideen, mehr um das disziplinierte Verknüpfen. Strategie und Vision sind die Klammer, die Gesetz und Bedürfnis auf Produktniveau zusammenführt. Gerade deshalb brauchen Product Owner die Fähigkeit, Wege offen zu halten, ohne den Kurs zu verlieren.

Nähe zu Nutzerinnen und Nutzern: Reden, zuhören, integrieren

Dominik nennt mehrfach, wie zentral Feedback ist: „Hier ist dann auch immer wichtig, dass man das Feedback der Nutzer einbeziehen kann. Man redet mit Leuten, man ist sehr stark involviert im Team.“ Dieses „Reden“ ist nicht Smalltalk, sondern eine professionelle Praxis: Diskussionen führen, einen gemeinsamen Nenner finden, Perspektiven integrieren.

Wesentlich ist für ihn die Rolle des Support-Teams: „Gerade Support zum Beispiel ist sehr stark involviert … Die sind immer sehr nah an Kunden dran und wissen eigentlich sehr gut, was dann gebraucht wird.“ Das ist einer der klarsten Sätze seiner Session. In vielen Organisationen wird Support als nachgelagerte Instanz gesehen – bei Dominik ist es eine Primärquelle. Daraus folgt eine Arbeitsweise: kontinuierlich fragen, abgleichen, die Nähe zum Bedarf nutzen, um Anforderungen früh zu schärfen.

Und am Ende steht ein Anspruch an die Umsetzung: „marktreif und verwendbar ins Produkt“ integrieren. Nicht jede Anforderung ist schon Produkt. Der Mehrwert der Product-Owner-Rolle liegt darin, rohes Feedback in ein belastbares, nutzbares Ergebnis zu verwandeln.

Kommunikation ist kein Zusatz – sie ist das Fundament

Dominik spricht Klartext: Ohne Kommunikationsfähigkeit und Teamfähigkeit empfiehlt er niemandem, diesen Job zu machen. Diese Aussage ist bemerkenswert hart – und gerade deshalb hilfreich. Sie verschiebt die Perspektive von „Welche Tools brauche ich?“ zu „Wie arbeite ich mit Menschen?“

Für uns ist das einer der stärksten Lerneffekte der Session. Kommunikation ist hier nicht Deko, sondern Methode. Sie strukturiert, priorisiert, verbindet. Wer sich in dieser Rolle sieht, sollte Freude daran haben, Bedeutungsräume zu öffnen (Was ist wirklich gemeint?), zu schärfen (Was ist wirklich wichtig?) und zu schließen (Worauf committen wir uns?).

Analytik, Priorisierung, Parallelität: Die innere Werkbank

Neben der Kommunikation nennt Dominik eine Reihe kognitiver Kompetenzen, die seinen Alltag prägen:

• Analytisch denken
• Priorisieren
• Mehrere Dinge parallel laufen lassen

Das klingt schlicht – ist aber ein anspruchsvolles Set. Analytik hilft, Probleme zu zerlegen, Abhängigkeiten zu sehen, Auswirkungen zu bewerten. Priorisierung ordnet knappe Ressourcen, schützt Fokus und Qualität. Parallelität hält den Laden am Laufen, ohne ins Chaos zu kippen.

Spürbar wird dabei ein Muster: Dominik verankert das Abstrakte im Praktischen. Es geht nicht um Schlagworte, sondern um die konkrete Fähigkeit, unter Bedingungen ein gutes Produkt zu liefern.

Technisches Verständnis als Entscheidungshebel

„Generell ist auch ein technisches Verständnis sicher von Vorteil, weil es geht ja um Softwareentwicklung im Endeffekt“, sagt Dominik. Er findet klare Worte dafür, warum diese Komponente zählt: Nur so lässt sich einschätzen, „zahlt sich das im längerfristigen Sinn aus oder nicht? Wird hier ein starker Eingriff betrieben oder nicht?“

Das ist kein Ruf nach „Product Owner muss Programmierer sein“. Es ist die Einsicht, dass die Qualität von Produktentscheidungen steigt, wenn man technische Tiefe zumindest in ihren Konsequenzen versteht. Dominiks Biografie – Elektrotechnik, Digital Business, Grundlagenprogrammierung – macht plausibel, wie er zu diesen Einschätzungen kommt. Entscheidend ist jedoch das Warum: Technisches Verstehen schafft Bewertungsfähigkeit.

„Wie wird man Product Owner?“ – Eine Herzentscheidung, kein Pfad

Auf die Frage nach dem Weg in den Beruf antwortet Dominik ohne Illusionen: „Die lässt sich nie so leicht beantworten.“ Er betont, die Rolle sei „jung“ und entziehe sich klaren Karriereleitern. Vielmehr müsse man sich dort sehen, „eine Schnittstelle zu bilden zwischen Technik … und auf der anderen Seite Management“.

Dieser Doppelübersetzer-Job ist die Essenz. Wer sich ungern festlegt – entweder rein technisch oder rein kaufmännisch – und im Dazwischen Karriere machen möchte, findet hier sein Zuhause. Dominik formuliert es so: Man findet sich „zwischen IT und Management … und findet damit genau die Mitte, die man mit Product Owner perfekt abschließt.“

Was diese Story Entwicklern konkret mitgibt

Aus Dominiks Erzählung lassen sich handfeste Schritte ableiten – ohne etwas hinzuzudichten. Alles folgt aus dem, was er betont:

• Rede mit Menschen – systematisch. Dominik stellt Gespräche und Diskussionen ins Zentrum. Übe, die „gemeinsame Nenner“-Frage in Meetings zu beantworten: Worin sind wir uns einig? Was fehlt? Was ist missverständlich?
• Hole den Support an den Tisch. Wenn der Support „sehr nah an Kunden dran“ ist, ist er eine der besten Quellen für Bedarfe. Baue dir feste Schleifen mit dem Support-Team auf.
• Denke wirtschaftlich. Dominik nennt wirtschaftliche Machbarkeit als Konstante. Trainiere, Aufwand und Nutzen gemeinsam zu denken – nicht nacheinander.
• Priorisiere hart. Nicht alles geht gleichzeitig. Überprüfe, welche Entscheidungen den größten Unterschied für Strategie und Vision machen.
• Stärke dein technisches Verständnis. Nicht, um zu bauen, sondern um zu bewerten: Langfristiger Nutzen? Tiefe des Eingriffs? Risiken?
• Pflege Teamfähigkeit. Die Rolle ist kooperativ. Dominik macht deutlich: Ohne Team- und Kommunikationsstärke wird das nichts.

Die Rolle von Strategie und Vision – als gelebte Leitplanke

Wenn Dominik von „Produktstrategie und Vision“ spricht, ist das keine abstrakte Folie, sondern ein Arbeitssatz. Strategie und Vision sind die Leitplanken, mit denen gesetzliche Anforderungen und Nutzerwünsche überhaupt „in einem Package“ zusammenfinden. Ohne diesen Rahmen fransen Diskussionen aus. Mit ihm werden sie gestaltbar: Wie stützt diese Anforderung die Vision? Wo kollidiert sie mit Normen? Was braucht es, um beides zusammenzubringen?

Für uns ist das eine hilfreiche Erinnerung: Vision bedeutet nicht, alles offen zu lassen. Im Gegenteil: Sie macht Entscheiden erst möglich.

„Marktreif und verwendbar“: Vom Input zum Produkt

Dominik formuliert den Anspruch an seine Aufgabe knapp: Anforderungen so integrieren, dass sie „marktreif und verwendbar“ werden. Darin steckt viel Produktdisziplin:

• Rohes Feedback wird geordnet und präzisiert.
• Wünsche werden gegen gesetzliche Anforderungen und Strategie abgeglichen.
• Die Umsetzung wird so gestaltet, dass sie nutzbar und tragfähig ist.

Dieser Teil bleibt in seiner Story bewusst unspektakulär – und gerade deshalb glaubwürdig. Product Ownership ist hier weniger Show, mehr Handwerk.

Die Mitte als Berufung – und als Verantwortung

„Man findet sich … in der Mitte.“ Was romantisch klingen könnte, beschreibt Dominik als Pflicht: verstehen, übersetzen, verknüpfen, entscheiden. Die Mitte ist kein Kompromiss, sondern ein Ort der Verantwortung. Wer dort stehen will, braucht die Freude am Gespräch, die Ruhe der Analyse und die Konsequenz der Priorisierung.

Aus unserer Sicht ist das die stärkste Botschaft der Session „Dominik Zimmel, Product Owner bei ANKÖ“ (Speaker: Dominik Zimmel; Company: Auftragnehmerkataster Österreich): Product Ownership ist kein Titel, den man sich abholt, sondern eine Haltung, die man einnimmt – täglich, Gespräch für Gespräch, Entscheidung für Entscheidung.

Zentrale Zitate und Kernaussagen von Dominik Zimmel

Was Teams sofort umsetzen können

• Nutzt Support als Kompass. Baut feste Austauschformate mit dem Support-Team auf – dominiksches Prinzip: Nähe zum Kunden zuerst.
• Trennt Input und Produkt. Haltet den Anspruch hoch, Anforderungen „marktreif und verwendbar“ zu machen – nicht nur zu dokumentieren.
• Verankert Wirtschaftlichkeit als Konstante. Prüft Machbarkeit immer doppelt: technisch und wirtschaftlich.
• Pflegt die Diskussionskultur. Ziel: Konsens ist nicht Zufall, sondern Ergebnis von Gesprächsqualität.
• Haltet Strategie und Vision präsent. Sie sind das Bindeglied zwischen Gesetz und Nutzerwunsch.

Fazit: Product Ownership als Herzfrage – und als Königsdisziplin des Verbindens

Dominik Zimmel zeichnet in „Dominik Zimmel, Product Owner bei ANKÖ“ ein klares Bild: Product Ownership ist weniger Karrierepfad als Herzensentscheidung für das Dazwischen. Wer sich dort sieht, braucht Kommunikationskraft, Teamgeist, analytische Schärfe, Priorisierungsstärke und technisches Verständnis.

Für Entwicklerinnen und Entwickler, die spüren, dass sie mehr als nur bauen wollen, bietet diese Story eine starke Orientierung: Beginnt mit dem Gespräch, bleibt nah am Support, denkt Wirtschaftlichkeit als Konstante, und haltet Strategie und Vision als Leitplanken hoch. Der Rest ist Handwerk – und tägliche Verantwortung.

So wird aus der Mitte ein Wirkungsort: Dort, wo Gesetz auf Bedürfnis trifft, wo Team auf Nutzer hört und wo aus Feedback Produkt wird. Genau dort verortet sich Dominik Zimmel – als Product Owner beim Auftragnehmerkataster Österreich –, und genau dort gewinnt die Rolle ihre Tiefe.

• 

  

  Zwei-Faktor-Authentifizierung und ID Austria

  Dominik Zimmel von ANKÖ demonstriert in seinem devjobs.at TechTalk wie die Produkte funktionieren, an denen das Unternehmen arbeitet.

  Jetzt ansehen

• 

  

  Patrick Osika, IT-Leiter bei ANKÖ

  Patrick Osika von ANKÖ spricht im Interview über den Aufbau des IT Teams im Unternehmen, den Ablauf des Bewerbungsprozesses und gibt Einblicke in die technologischen Challenges.

  Jetzt ansehen

• 

  

  Marek Dusecina, Senior Full Stack Engineer bei ANKÖ

  Marek Dusecina von ANKÖ erzählt im Interview über seinen Background im Programmieren, gibt Einblicke in seine aktuelle Arbeit im Full Stack Engineering und gibt Tipps für Neueinsteiger.

  Jetzt ansehen