Logo ABP PATENT NETWORK GmbH

ABP PATENT NETWORK GmbH

Etablierte Firma

Stefan Wöhrer, Product Manager bei ABP PATENT NETWORK

Description

Product Manager bei ABP PATENT NETWORK Stefan Wöhrer spricht im Interview über das Support Team des Unternehmens, wie dort das Recruiting gehandhabt wird und welche Technologien im Fokus stehen.

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

Video Zusammenfassung

In "Stefan Wöhrer, Product Manager bei ABP PATENT NETWORK", Speaker: Stefan Wöhrer, skizziert ein vierköpfiges Support- und Produktmanagement-Team als Schnittstelle zu Kunden und Entwicklung mit klassischem First-Level-Support und tiefem technischem Arbeiten, inklusive Datenbankzugriffen und umfangreichen Migrationen aus Altsystemen per C#-Skripten ohne formale Tests oder Pflichten-/Lastenhefte. Technologisch arbeitet das Team in C#/.NET, SQL für komplexe Abfragen und Elasticsearch; das Produkt App2IP kombiniert SQL für Bewegungsdaten mit einer Echtzeit-Volltextsuche über bis zu 2,8 Mio. Dokumente. Das Recruiting ist bewusst unkompliziert (Erstkontakt, Kennenlernen remote/vor Ort, technischer Austausch in Windisch-Garsten), gesucht sind sinnverstehendes Lesen/Schreiben und Wissbegierde, während Branchenwissen und vieles Weitere im Job erlernt werden.

Zwischen Datenmigration und Kundenfokus: Wie das Support- und Produktteam von ABP PATENT NETWORK arbeitet – Insights aus „Stefan Wöhrer, Product Manager bei ABP PATENT NETWORK“

Kontext: Eine Tech-Lead-Story mit Fokus auf Pragmatismus und Wirkung

In unserer DevJobs.at Tech-Lead-Story „Stefan Wöhrer, Product Manager bei ABP PATENT NETWORK“ sprach Speaker Stefan Wöhrer von ABP PATENT NETWORK GmbH über ein Setup, das in seiner Klarheit und Kundennähe auffällt: ein vierköpfiges Team, ein bewusst „dehnbarer“ Support-Begriff, pragmatische Datenmigrationen für große Industriekunden und eine klare Erwartungshaltung an Bewerberinnen und Bewerber. Die Quintessenz: Hier zählt Neugier, Verständlichkeit im Denken und Schreiben – und die Lust, komplexe Daten sinnvoll zu strukturieren.

„Support Team ist bei uns ein bisschen ein dehnbarer Begriff.“

Von der ersten Support-Hotline bis zur tiefen SQL-Analyse, von der Aufnahme von Kundenwünschen bis zur Migrationsentwicklung: Bei ABP PATENT NETWORK greift vieles ineinander. Für Tech-Talente, die gerne Verantwortung übernehmen, mit echten Kundendaten arbeiten und sich in ein rechtsnahes Domänenumfeld einlernen wollen, eröffnet sich ein Arbeitsfeld mit spürbarem Impact – ohne überbordende Prozesse, aber mit hohem Anspruch an inhaltliches Verständnis.

Session-Referenz: Title: Stefan Wöhrer, Product Manager bei ABP PATENT NETWORK · Speaker: Stefan Wöhrer · Company: ABP PATENT NETWORK GmbH

Teamstruktur: Klein, fokussiert, wirkungsstark

Das Team umfasst aktuell vier Personen. Was zunächst nach klassischem Support klingt, ist bewusst erweitert gedacht – an der Schnittstelle zwischen Produktmanagement, Kundenanforderungen und Softwareentwicklung.

  • Produktmanagement als Schnittstelle: Kundenwünsche werden aufgenommen, bewertet und so aufbereitet, dass das Softwareentwicklungsteam konkret damit arbeiten kann. Dazu gehört auch die Frage: Welche Anfragen machen Sinn? Welche nicht? Wie kommuniziert man das transparent und priorisiert sinnvoll?
  • First-Level-Support mit Tiefgang: Zwei Kolleginnen bzw. Kollegen besetzen die Support-Hotline und beantworten Support-E-Mails. Dabei bleibt es nicht beim Oberflächen-Check – „das geht technisch teilweise schon sehr tief“, etwa wenn direkte Datenbankverbindungen nötig sind, um Informationen zu ziehen und den Kunden fundiert Auskunft zu geben.
  • Migrationsentwicklung für Neukunden: Eine der technisch spannendsten Aufgaben im Team entsteht bei der Integration neuer Mandanten – häufig größere Industriebetriebe. Hier werden bestehende Datenbestände übernommen, strukturiert und ins System integriert.

Die Kombination aus direktem Kundendialog, Datenverständnis und enger Verzahnung mit der Entwicklung prägt die Kultur. Für Engineers heißt das: viel Kontext, viel Autonomie – und viel Verantwortung.

Produktmanagement, das in der Realität ankommt

„Produktmanagement“ ist hier keine PowerPoint-Folie, sondern gelebte Schnittstelle. Wöhrer beschreibt sehr klar, wie Anforderungen den Weg vom Kunden in die Software finden: aufnehmen, einordnen, prüfen, vorbereiten, priorisieren und ins Entwicklungsteam bringen. Besonders wichtig ist dabei ein realistischer Blick auf den Nutzen: Nicht jede Anfrage wird umgesetzt – und die Begründung muss nachvollziehbar kommuniziert werden.

  • Verständlichkeit und Priorisierung: Was kommt rein? Was hat Wert für mehrere Kunden? Welche Anpassungen sind sinnvoll, welche nicht?
  • Kommunikation und Erwartungsmanagement: Die Brücke zwischen Kundenperspektive und technischer Umsetzung ist nur stabil, wenn sie beidseitig Verständnis erzeugt.
  • Nähe zum System: Die Schnittstelle arbeitet nicht im luftleeren Raum, sondern greift selbst aktiv auf Daten zu, prüft Annahmen und navigiert Komplexität.

Dieses Zusammenspiel wirkt sich positiv auf die Produktqualität aus: Anforderungen werden nicht blind implementiert, sondern auf Kohärenz mit der Systemlogik und den realen Arbeitsabläufen der Nutzerinnen und Nutzer geprüft.

Datenmigration als Königsdisziplin: Sinn vor Syntax

Eine zentrale Herausforderung und zugleich Alleinstellungsmerkmal des Teams: die Migration umfangreicher Datenbestände ins hauseigene System. Die Größenordnung ist greifbar:

  • Rund 100.000 Dokumente
  • Ca. 5.000 Akten
  • 2.000–3.000 Fristen

Diese Daten kommen aus Altsystemen oder verschiedensten Formaten – Excel, SQL-Datenbanken, JSON-Dateien, „was auch immer der Kunde gerade so bringt“. Die Integration erfolgt über Migrationsskripte: zielgerichtete, anwendungsnahe Transformationen statt generischer Einmal-Importe.

„Ich habe eine Datenbank und baue das so, dass das in unsere Datenbank reingeht.“

Wöhrer ist ausgebildeter Softwareentwickler und übernimmt diese Migrationsentwicklung „in einem sehr ungezwungenen Umfeld“ – ohne Test-Suites, Pflichten- oder Lastenhefte. Was im ersten Moment nach Freifahrtschein klingt, ist in Wahrheit ein anderes Qualitätsversprechen: Sinnhaftigkeit. Denn hier reicht es nicht, Strings, Datumswerte und Integer technisch korrekt zu parsen. Entscheidend ist die Frage: Was bedeutet das fachlich – und ist es sinnvoll, die Information so zu überführen?

„Man kann das nicht blind einfach nur als String und Datum und Integer behandeln, sondern man muss wirklich sagen, okay, was macht das? Ist das jetzt sinnhaft, das so zu überführen?“

Dieses Arbeiten setzt auf tiefes Datenverständnis, präzise Abwägung und die Fähigkeit, sich in das Tätigkeitsfeld der Kunden hineinzuversetzen. Genau das macht die Aufgabe abwechslungsreich – und für viele Engineers besonders reizvoll.

Technologischer Unterbau: C#, SQL und Elasticsearch – bewusst gewählt

Die Technologien im Umfeld von App2IP sind klar benannt und folgen einer pragmatischen Logik:

  • C# / .NET: Da das Team sehr eng mit der Softwareentwicklung zusammenarbeitet, ist C# das zentrale Programmiermedium. .NET-Kenntnisse sind von Vorteil.
  • SQL: Komplexe Abfragen über sehr große Datensätze sind Teil des Tagesgeschäfts. Dabei geht es nicht nur um technische Korrektheit, sondern auch um inhaltliche Bewertung – etwa, um Kunden Auskunft zu bestimmten Akten, Ländern, Dokumenten und Fristen zu geben. SQL-Joins sind hier kein Randthema, sondern Kernwerkzeug.
  • Elasticsearch: App2IP basiert auf zwei Datenbanken – einer SQL-Datenbank für Bewegungsdaten sowie einer Elasticsearch-Volltext-Suchdatenbank. Alles, was im System ist, wird zusätzlich in Elasticsearch indexiert, in Echtzeit durchsucht und so dem rechtsnahen Umfeld gerecht, in dem mit Anwälten, Ämtern u. a. über E-Mails, PDFs oder Excel-Listen kommuniziert wird.

Die Skalierung ist real, nicht theoretisch: „Wir haben einen Mandanten mit knapp 2,8 Millionen Dokumenten im System drinnen und das funktioniert so.“ Die qualitativ hochwertige Volltextsuche ist ein Differenzierungsmerkmal – und verlangt technisches Verständnis für Indexierung, Query-Strategien und Relevanz.

Support mit Tiefgang: Vom Hotline-Gespräch zur Datenbankverbindung

Zwei Teammitglieder übernehmen den First-Level-Support – und gehen bei Bedarf „technisch teilweise schon sehr tief“. Das bedeutet: Keine bloße Ticketweitergabe, sondern direkte Analyse, SQL-Abfragen, Verbindungen zur Datenbank aufbauen, Informationen extrahieren und Kundinnen und Kunden zielgerichtet helfen.

Diese Arbeitsweise erhöht die Erstlösungsquote, schafft Vertrauen und gibt dem Team wertvolles Feedback aus der Praxis. Für Engineers ist das eine Schule des Denkens: Welche Frage steckt wirklich hinter der Frage? Welche Daten brauche ich für eine belastbare Antwort? Und wie übersetze ich komplexe Systemzusammenhänge in verständliche Sprache?

Recruiting: Unkompliziert, schnell, auf Augenhöhe

Wöhrer beschreibt den Recruitingprozess als „eher unkompliziert“ – ohne komplizierte Runden.

  • Quelle der Bewerbungen: Headhunter, Portale wie DevJobs sowie Initiativbewerbungen.
  • Kennenlernen: Erstkontakt, danach ein Gespräch – remote (z. B. via Teams) oder vor Ort, je nach Lage und Entfernung (etwa bei Bewerberinnen und Bewerbern aus Wien zunächst remote).
  • Zweites Gespräch in Windisch-Garsten: Hier geht es tiefer in technische Themen, das Team wird kennengelernt, und man prüft die Passung. In der Regel wird in diesem Rahmen bereits entschieden.

Das Ziel ist ein effizientes, wertschätzendes Verfahren mit Fokus auf Substanz statt Show. Genau das passt zur Kultur, die Wöhrer im Gespräch vermittelt.

Was zählt wirklich: Neugier, klare Sprache, Lernbereitschaft

„Die größte Hürde bei uns im Unternehmen ist aber selten die technische, sondern eher die branchenspezifische Wissenserlangung.“

Die Domäne ist rechtsnah, mit Akten, Fristen, Dokumenten, Kommunikation mit Anwälten und Ämtern – und einem komplexen Zusammenspiel dieser Entitäten. Dieses Verständnis lässt sich nicht in einem Tutorial abkürzen; es entsteht durch Einarbeitung, Mitdenken und gutes Fragenstellen.

Wöhrer bringt es auf den Punkt:

„Ein Bewerber muss sinn­er­greifend lesen und schreiben können und wissbegierig sein.“

Technische Skills – C#, .NET, SQL (inklusive komplexer Joins), Elasticsearch – sind wichtig und im Alltag hochrelevant. Doch entscheidend ist die Fähigkeit, Informationen zu strukturieren, sauber zu kommunizieren und Zusammenhänge zu erkennen. Das Team ist so organisiert, dass neues Wissen im Rahmen der Tätigkeit aufgebaut werden kann.

Zusammenarbeit mit der Entwicklung: Nähe statt Silos

Die Nähe zum Entwicklungsteam ist gelebter Alltag. Sie zeigt sich in zweierlei Hinsicht:

  • Gemeinsame Sprache: C# als geteiltes Medium erleichtert Übergaben und Diskussionen.
  • Reibungsarme Schnittstellen: Anforderungen werden vorbereitet, qualifiziert und so aufbereitet, dass Engineering zügig ansetzen kann – ohne Reibungsverluste durch unklare Spezifikationen.

So entsteht ein Kreislauf aus Feedback, fachlicher Prüfung und zielgerichteter Umsetzung. Die Support-Perspektive liefert reale Nutzersignale; die Produktfunktion priorisiert und strukturiert; die Entwicklung setzt um und trägt ihrerseits mit Expertise bei.

Qualität durch Sinnprüfung: Warum „keine Tests“ nicht „kein Anspruch“ bedeutet

Ein von Wöhrer explizit genannter Punkt ist die Migrationsentwicklung „in einem sehr ungezwungenen Umfeld“ – ohne formale Testpflichten oder schwerfällige Pflichten- und Lastenhefte. Das ist kein Plädoyer gegen Qualität, sondern für Kontextkompetenz:

  • Daten sind nie neutral: Die semantische Passung entscheidet über die Nützlichkeit der Migration.
  • Fachlogik vor Technik: Felder und Typen korrekt zu mappen, reicht nicht – entscheidend ist, ob die Zielstruktur den praktischen Arbeitsabläufen standhält.
  • Verantwortung beim Menschen: Wer migriert, prüft und entscheidet. Das verlangt Erfahrung, kritisches Denken und klare Kommunikation mit Kundinnen und Kunden.

Gerade diese Verantwortung ist für viele technische Talente attraktiv: Man baut nicht nur Software – man begleitet einen echten Veränderungsprozess, der für die Kunden hochrelevant ist.

Day-in-the-Job: Aufgabenbilder ohne Schema F

Jeder Tag kann anders aussehen – weil die Themenlage, Kundendaten und Anfragen wechseln. Einige wiederkehrende Muster:

  • Supportanfragen qualifizieren, priorisieren und – wenn nötig – direkt in der Datenbank analysieren.
  • Komplexe SQL-Abfragen formulieren, Ergebnisse interpretieren und verständlich rückmelden.
  • Anforderungen aufnehmen und fürs Entwicklungsteam vorbereiten.
  • Migrationsskripte entwerfen oder anpassen, Testläufe mit realistischen Daten fahren und die Sinnhaftigkeit der Überführung prüfen.
  • Volltextsuche in Elasticsearch nutzen oder Abfragen entwerfen, um spezifische Fragen zu Dokumenten zu beantworten.

Das Spektrum ist breit – und es belohnt Neugier genauso wie Sorgfalt.

Warum App2IP technisch spannend ist: Zwei Datenwelten, ein sofort sichtbarer Nutzen

Die Kombination aus SQL und Elasticsearch schafft ein System, das sowohl Transaktionen („Bewegungsdaten“) als auch unstrukturierte Inhalte effizient handhabt – und zwar in Echtzeit:

  • SQL: Konsistenz, Verknüpfungen, strukturierte Abfragen quer über viele Entitäten – inklusive anspruchsvoller Joins.
  • Elasticsearch: Volltext-Index über Mails, PDFs, Excel-Listen und weitere Dokumente – unmittelbar durchsuchbar und skalierbar.

Die angeführte Größenordnung von „knapp 2,8 Millionen Dokumenten“ für einen Mandanten ist nicht nur ein Leistungsbeweis, sondern auch Lernfeld: Wie designt man Queries? Wie hält man Indizes gesund? Wie bewertet man Relevanz im rechtsnahen Kontext?

Employer Branding: Wofür ABP PATENT NETWORK steht – und wen das anspricht

Aus Wöhrers Einblicken lässt sich ein klares Profil ableiten. Dieses Umfeld passt zu Tech-Talenten, die…

  • …Kundenkontakt nicht scheuen, sondern als Quelle von Relevanz sehen.
  • …Komplexe Daten in sinnvolle Strukturen überführen wollen – über bloße Typkonvertierung hinaus.
  • …gern mit C#, .NET, SQL und Elasticsearch arbeiten und an großen Datenmengen wachsen möchten.
  • …eine kleine, fokussierte Teamumgebung schätzen, in der man viel Gestaltungsspielraum hat.
  • …in einem rechtsnahen Umfeld lernen möchten, wie Akten, Dokumente, Fristen und Länderbezüge zusammenspielen.
  • …unkomplizierte, direkte Prozesse bevorzugen – im Alltag wie im Recruiting.

Dazu kommen handfeste Argumente aus dem Gespräch:

  • Einfacher Bewerbungsprozess (Erstkontakt, Kennenlernen – remote oder vor Ort –, vertiefendes Gespräch in Windisch-Garsten, schnelle Entscheidung).
  • Echte Verantwortung ab Tag eins – und unmittelbarer Impact auf Kundensysteme.
  • Lerneffekt auf zwei Ebenen: Technologie (C#, SQL, Elasticsearch) und Domäne (rechtsnahes Arbeiten mit Akten, Fristen und Dokumenten).

Kandidatenprofil: Welche Fähigkeiten bringen dich hier nach vorn?

Nach dem Gespräch mit Wöhrer kristallisieren sich drei Kompetenzfelder heraus:

1) Kernfähigkeiten

  • Sinn­er­greifend lesen und schreiben: Klarheit in der Sprache bedeutet Klarheit im Denken – und umgekehrt.
  • Wissbegierde: Die Domäne ist der eigentliche „Schwierigkeitsgrad“ – wer neugierig ist, lernt schnell.

2) Technischer Werkzeugkasten

  • C# und .NET: Praxisnahes Arbeiten im engen Schulterschluss mit der Entwicklung.
  • SQL auf hohem Niveau: Komplexe Joins, große Datenmengen, Ergebnisse inhaltlich interpretieren.
  • Elasticsearch-Grundverständnis: Indexierung, Querying, Volltextkonzepte.

3) Arbeitsweise

  • Kundenorientierung: Fragen verstehen, Erwartungen managen, Ergebnisse verständlich vermitteln.
  • Eigenverantwortung: Entscheidungen in Migrationsprojekten treffen, Sinnhaftigkeit prüfen.
  • Team-Play: Anforderungen strukturiert ins Engineering bringen und Feedback aufnehmen.

Zusammenarbeit und Kommunikation: Das Rückgrat der Produktentwicklung

Das Modell „Support + Produktmanagement + Nähe zum Engineering“ bringt Vorteile mit sich:

  • Rückkopplung in Echtzeit: Support erkennt Muster, Produkt priorisiert, Engineering liefert.
  • Wissensaufbau im Tun: Branchenspezifisches Wissen wächst mit jeder Anfrage, jeder Migration, jeder Abstimmung.
  • Transparente Entscheidungen: Welche Kundenwünsche umgesetzt werden, ist nachvollziehbar begründet.

Damit wird ein organisatorischer Flaschenhals vermieden: Wissen verteilt sich, Entscheidungen werden dort getroffen, wo sie am besten informierte sind – nah am Problem.

Migrationsskripte als Werttreiber: Warum individuelle Wege besser sind als Einheitsimporte

Die Entscheidung, Migrationsskripte als Basis der Systemintegration zu nutzen, ist ein Statement. Sie würdigt die Besonderheiten der Kundendaten, die aus unterschiedlichsten Quellen stammen. Standardwerkzeuge stoßen an Grenzen, wenn semantische Details entscheiden. Skripte erlauben:

  • Feinsteuerung: Feld für Feld, Regel für Regel – plausibel und nachvollziehbar.
  • Iteration: Testen mit Echtdaten, Nachjustieren, Sinnprüfung.
  • Dokumentation durch Code und Ergebnis: Die Migration „erklärt“ sich im Ergebnis – Daten liegen am richtigen Ort, in sinnvoller Struktur.

Für Engineers ist das attraktiv: Man arbeitet nicht gegen das Problem, sondern mit ihm – und lernt dabei jede Menge über die Datenlandschaft der Kunden.

Skalierung in der Suche: Volltext als Differenzierungsmerkmal

„Alles was im System drinnen ist, wird Voltex [Volltext] gescannt und ist in Echtzeit durchsuchbar.“

In einem Umfeld, in dem viel über E-Mails, PDFs und Excel kommuniziert wird, ist eine belastbare Volltextsuche kein Nice-to-have. Sie ist das, was viele Workflows überhaupt erst praktikabel macht. App2IP setzt dafür auf Elasticsearch – und skaliert bis in den Millionenbereich an Dokumenten.

Wer sich in diese Technologie vertieft, lernt nicht nur ein Tool, sondern ein Denkmodell: Wie strukturiere ich unstrukturierte Informationen so, dass sie in Echtzeit wertvoll werden?

Einfacher Einstieg, nachhaltiges Wachstum: Ein Lernpfad, der trägt

Der Weg ins Team ist bewusst niedrigschwellig – ohne „kompliziertes Aufnahmeprozedere“. Gleichzeitig ist der Lernpfad anspruchsvoll und substanziell: branchenspezifisches Wissen, technische Tiefe, Verantwortung in Kundensituationen. Diese Kombination ist selten – und sie schafft ein Umfeld, in dem man fachlich wie persönlich wachsen kann.

Praktisch bedeutet das:

  • On-the-job lernen: Kein Schulbuch ersetzt die Erfahrung echter Datenmigrationen und Supportfälle.
  • Mit Kunden arbeiten: Direkte Rückmeldung auf die eigene Arbeit.
  • Mit Engineering verzahnt sein: Schneller Wissenstransfer, kurze Wege.

Fazit: Für Neugierige, die Komplexität mögen – und Wirkung suchen

Das Gespräch mit Stefan Wöhrer zeigt ein Team, das durch Substanz überzeugt: kleiner Headcount, große Verantwortung, reale Datenmengen, echte Kundennähe. Wer C#, .NET, SQL und Elasticsearch beherrscht – oder bereit ist, sich hier tief einzuarbeiten – und wer bereit ist, Domänenlogik ernst zu nehmen, findet bei ABP PATENT NETWORK ein Umfeld, das fordert und fördert.

  • Datenmigration als anspruchsvolle Praxis – mit Sinnprüfung statt Schema F.
  • Support, der nicht „weiterreicht“, sondern versteht und löst.
  • Produktmanagement, das Prioritäten setzt und Klarheit schafft.
  • Technologie, die skaliert – mit SQL und Elasticsearch als starkem Duo.

Bewerbungen sind willkommen – über Headhunter, Portale wie DevJobs oder initiativ. Und das Kennenlernen ist so unkompliziert, wie der Arbeitsalltag pragmatisch ist. Wer im Gespräch in Windisch-Garsten überzeugt – fachlich wie menschlich –, kann schnell Teil eines Teams werden, das sich täglich mit der Frage beschäftigt, wie Daten sinnvoll werden.

In Summe ist das die Einladung an alle, die Verantwortung mögen, Kontext lieben und an der Schnittstelle von Technik, Daten und Kundennutzen arbeiten wollen. Genau hier entsteht Wirkung.

Weitere Tech Talks

Weitere Tech Lead Stories

Weitere Dev Stories