Lead‑Liste aus Stellenanzeigen: Tools und Bedürfnisse extrahieren

Warum Stellenanzeigen besser sind als Raten

Generische Outreach wirkt zufällig, weil sie es ist. Wenn du einem Unternehmen eine vage Nachricht schickst wie „verbessert euren Dev‑Prozess“ oder „spart Engineering‑Zeit“, setzt du darauf, dass sie genau dieses Problem haben. Meistens ist das nicht der Fall oder sie denken gerade nicht darüber nach. Deine Nachricht sieht aus wie jede andere Cold‑Email und wird ignoriert.

Eine Stellenanzeige ist anders. Sie ist ein Schnappschuss dessen, was ein Team dieses Quartal braucht, in klarem Wortlaut und abgesegnet vom Hiring Manager. Sie enthält oft Details, die du nicht auf der Website findest: die Tools, die sie tatsächlich verwenden, die Projekte, an denen sie aktiv bauen, die Schmerzen, die sie reduzieren wollen, und wie „gute“ Ergebnisse für die Rolle aussehen.

Deshalb kann das Erstellen einer Lead‑Liste aus Stellenanzeigen besser funktionieren als Raten. Du startest nicht mit einem generischen Branchenlabel, sondern mit ihrer aktuellen Arbeit.

Diese Methode passt besonders gut, wenn:

• Du B2B‑Produkte oder -Services verkaufst, die an ein bestimmtes Tool, einen Workflow oder ein Team gebunden sind.
• Dein Käufer technisch ist oder eng mit technischen Ergebnissen arbeitet.
• Das Unternehmen aktiv in dem Bereich einstellt, den dein Angebot beeinflusst.

Es gibt Grenzen. Eine Anzeige sagt, was sie vorhaben, aber nicht immer Budget, bestehende Lieferantenverträge oder interne Politik. Du kannst sicher ableiten wie „sie nutzen X“ oder „sie migrieren zu Y“, wenn es klar steht. Du kannst nicht sicher annehmen, dass „sie ihren aktuellen Vendor hassen“ oder „sie sind jetzt kaufbereit“.

Ein praktisches Beispiel: Wenn eine Firma nach „AWS IAM, SOC 2 und SIEM‑Integration“ sucht, kannst du einen Hook formulieren, der sich ums Reduzieren von Audit‑Aufwand oder das Beschleunigen der Log‑Integration dreht. Du antwortest auf ihr genanntes Ziel, statt zu spekulieren.

Was du aus einer Tech‑Stellenanzeige extrahieren solltest

Eine Tech‑Stellenanzeige ist ein Mini‑Brief. Dein Ziel ist nicht, zu erraten, was sie brauchen, sondern festzuhalten, was sie dem Markt bereits gesagt haben, dass sie bauen, reparieren oder skalieren.

Fang mit den Basics an, denn die prägen alles: Jobtitel, Seniorität, Teamname und ob die Rolle remote, hybrid oder an einen Ort gebunden ist. Ein „Staff Platform Engineer, Developer Experience“ hat andere Prioritäten als „Junior DevOps Engineer, IT Operations“. Standortangaben können außerdem Hinweise auf Einschränkungen wie Datenresidenz oder On‑Call‑Abdeckung geben.

Zieh als Nächstes die genannten Tools und Plattformen heraus. Fasse noch nicht zusammen. Notiere die genauen Worte, die sie verwenden, besonders in Kategorien wie Cloud & Infrastruktur, Daten & Analytics, Sicherheit & Identity, Delivery & Code und Customer‑/Revenue‑Systeme.

Dann erfasse Projekte und Outcomes. Das sind die nützlichsten "Why now"‑Signale, weil sie Dringlichkeit und Budget implizieren. Formulierungen wie „migrate from X to Y“, „scale to N requests“, „automate onboarding“ oder „reduce cloud spend“ geben dir eine klare Richtung fürs Outreach.

Einschränkungen sind genauso wichtig wie Ziele. Notiere alles zu Compliance, Uptime, Latenz, Kostenzielen, Deadlines und teamübergreifenden Abhängigkeiten. Wenn eine Anzeige „99.9% uptime“, „HIPAA“ oder „quarterly delivery“ erwähnt, sollte deine Nachricht diese Realität respektieren.

Achte schließlich auf Buying‑Signale: eine neue Funktion („building the first data team“), ein Rebuild („re‑architecting core services“), ein Tool‑Rollout („standardize CI/CD“) oder ein starker Headcount‑Zuwachs. Die deuten meist auf aktive Evaluation hin, nicht auf ein „irgendwann“.

Schritt für Schritt: Postings in Lead‑Daten verwandeln

Wähle zunächst eine Zielrolle und halte sie eng. „Backend Engineer“ ist zu breit. „Backend Engineer für FinTech‑Payments“ ist viel leichter, weil sich Stacks und Probleme wiederholen. Wähle ein oder zwei Branchen, die du verstehst, damit du erkennst, was wichtig ist.

Sammle Job‑Posts konsistent. Nutze dieselben Quellen und dasselbe Zeitfenster (z. B. Postings der letzten 14 Tage). So spiegelt deine Liste, wofür aktuell eingestellt wird, und nicht ein zufälliges Gemisch alter Bedürfnisse.

Ein einfacher Workflow:

• Definiere deinen Filter: Rolle, Seniorität, Branche, Region, Unternehmensgröße.
• Speichere jede Anzeige als Rohtext und notiere Datum und Quelle.
• Markiere Signalwörter: Tool‑Namen, Integrationen und Projektverben (migrate, rebuild, instrument, consolidate).
• Überführe die Markierungen in strukturierte Felder, die du sortieren kannst.
• Füge grundlegende Firmenfelder hinzu, damit du später den richtigen Kontakt findest.

Halte die strukturierten Felder einfach, damit du sie wirklich nutzt. Ein praktisches Set ist: Rolle, Branche, Genannte Tools, Genannte Integrationen, Projektverben, Projektthema und Dringlichkeits‑Hinweise (Deadlines, "must have", "first hire").

Beispiel: Wenn eine Anzeige „migrate from on‑prem to AWS“, „instrument services with OpenTelemetry“ und „reduce alert noise in PagerDuty“ erwähnt, hast du jetzt sortierbare Signale. Du behauptest nicht ihre exakten Schmerzen, du hältst fest, was sie dem Markt gesagt haben — in einem Format, das du filtern und anschreiben kannst.

Wie du echte Tools und Stack‑Signale herausziehst

Stellenanzeigen sind bewusst unordentlich. Sie mischen, was das Team heute nutzt, was sie gerne nutzen würden und was HR aus einer anderen Rolle kopiert hat. Für Lead‑Daten, die zu echten Bedürfnissen passen, brauchst du eine einfache Methode, Stack‑Signale zu erkennen.

Tools tauchen meist an vorhersehbaren Stellen auf: Anforderungen (wahrscheinlich aktueller Kernstack), "nice‑to‑have"‑Skills (oft Zukunftspläne), Verantwortlichkeiten (tägliche Realität), "our tech stack"‑Sektionen (falls vorhanden) und Projektbullets (wo Migrationen und Neubauten versteckt sind).

Trenne Kernstack von Buzzwords mit einer Frage: „Scheitert die Person an der Aufgabe ohne das?“ Wenn die Anzeige sagt „build pipelines in dbt“ oder „operate Kubernetes clusters“, ist das Kern. Steht daneben „familiar with blockchain“ in einer langen Liste, behandle es als Rauschen.

Achte auf Muster, die Reife und Ausgaben nahelegen. Cloud, Data Warehouses, Observability und Ticketing/ITSM sind oft mit klaren Schmerzpunkten und laufender Anbieterbewertung verbunden.

Normalisiere Synonyme, damit du dasselbe Signal nicht in verschiedene Spalten zerlegst. "K8s" und Kubernetes gehören in einen Bucket. "GCP" und Google Cloud ebenfalls. "CI/CD" kann GitHub Actions, GitLab CI oder Jenkins bedeuten — notiere das spezifische Tool, wenn es genannt wird.

Markiere schließlich Integrationshinweise. Formulierungen wie "migrate from", "connect to", "works with" oder "experience integrating" deuten meist auf ein echtes Projekt hin. "Migrate dashboards from Grafana to Datadog" ist ein stärkeres Signal als eine lange Liste von Monitoring‑Tools.

Bedürfnisse aus Projekten ableiten, ohne zu weit zu gehen

Stellenanzeigen beschreiben oft Projekte, nicht Probleme. Deine Aufgabe ist, diese Projektsprache in ein paar plausible Bedürfnisse zu übersetzen und dabei vorsichtig zu formulieren.

Formuliere zuerst um, was sie sagen, in das, was sie wahrscheinlich brauchen. "Migrate" bedeutet meist Zeit‑ und Datenqualitäts‑Risiken sowie ein Team, das Ausfallzeiten nicht verkraften kann. "Scale" deutet oft auf Lücken bei Zuverlässigkeit, Performance und Monitoring hin. "Consolidate tools" spricht für Kostenkontrolle, konsistente Reports und weniger Übergaben.

Achte auf Auslöser, die Dringlichkeit signalisieren. Ein Launch, Re‑Architecture, Konsolidierung oder Compliance‑Push bedeutet meist Druck. Diese Signale sind stärker als Füllphrasen wie "fast‑paced" oder "collaborate with stakeholders".

Eine einfache Taxonomie hält dich geerdet:

• Kosten: Tool‑Sprawl, redundante Anbieter, Cloud‑Ausgaben
• Geschwindigkeit: schneller liefern, kürzere Onboarding‑Zeit, weniger manuelle Schritte
• Zuverlässigkeit: Uptime, Reduktion von Incidents, Skalierungsprobleme
• Sichtbarkeit: Reporting, Attribution, Monitoring, Pipeline‑Klarheit
• Sicherheit: Compliance, Access‑Kontrolle, Audit‑Trails

Ordne dann jede wahrscheinliche Need der Person zu, die sie am stärksten spürt. Engineering kümmert sich um Build‑Zeit, Zuverlässigkeit und technischen Debt. Ops und SRE fühlen Ausfälle und Monitoring‑Lücken. Security sorgt für Compliance und Zugriffssteuerung. RevOps oder Sales Ops achten auf Sichtbarkeit, saubere Übergaben und konsistente Daten.

Halte Annahmen modest, indem du sie in Fragen verwandelst. Statt „Ihr habt Downtime‑Probleme“, schreibe „Ist Uptime ein Thema während der Migration?“ Statt „Euer Stack ist chaotisch“, frage „Wollt ihr die Anzahl der involvierten Tools reduzieren?“

Beispiel: Eine Anzeige erwähnt "re‑architecting a data pipeline to support real‑time reporting". Eine vernünftige Ableitung sind: Geschwindigkeit (aktuelle Daten), Zuverlässigkeit (weniger fehlerhafte Jobs) und Sichtbarkeit (vertrauenswürdige Metriken). Zu weit wäre zu behaupten, ihre Reports seien falsch. Ein sicherer Hook fragt, was "real‑time" für sie bedeutet und was heute ausfällt.

Lead‑Liste aufbauen und segmentieren

Wenn du Signale extrahierst, speichere sie in einem konsistenten Lead‑Datensatz. Jede Zeile sollte dir sagen, wer sie sind, was sie bauen wollen und welcher Stack genannt wurde, damit du später eine relevante Nachricht schreiben kannst.

Ein praktisches Lead‑Format enthält:

• Company, offene Rolle, Team (falls angegeben), Standort
• Genannte Tools, Projekt oder Initiative, Trigger (Warum jetzt), Posting‑Datum
• Quellnotiz (die genaue Zeile, die du gezogen hast) und eine Konfidenz‑Bewertung

Sobald du 20–50 Datensätze hast, füge leichtes Scoring hinzu, damit du deine Zeit auf die besten Ziele konzentrierst. Halte die Regeln offensichtlich. Frische Postings schlagen meist alte. Mehrere verwandte Einstellungen signalisieren oft ein echtes Projekt. Konkrete Tool‑Nennungen (z. B. „Kafka“ plus „real‑time pipeline") sind stärker als vage Phrasen wie „modern stack”.

Segmentierung macht das Ganze handlungsfähig. Statt einer großen Liste erstellst du kleine Gruppen basierend auf Tool plus Projekt‑Kombination. Beispiel: "Snowflake + Migration", "Kubernetes + Plattformaufbau" oder "Salesforce + Datenqualitätssanierung". Diese Batches machen dein Outreach fokussierter und helfen dir, Ergebnisse vergleichbar zu machen.

Entscheide, ob du Account‑first oder Contact‑first vorgehst. Wenn dein Angebot ein unternehmensweites Problem löst, starte mit Accounts und finde dann den besten Kontakt. Wenn dein Angebot einem bestimmten Team hilft, starte direkt beim Team‑Lead, der im Posting genannt wird.

Schreibe abschließend Ausschlussregeln auf, damit deine Liste sauber bleibt. Häufige: Praktikanten‑ oder Einstiegsrollen, Postings älter als 60–90 Tage, Teams, die du nicht bedienst, oder Anzeigen, die weder Tools noch Projekte nennen.

Einen relevanten Hook aus den Signalen schreiben

Ein guter Hook ist kein cleverer Opener. Er ist ein kurzes Spiegelbild dessen, was sie gerade tun, und nutzt dieselbe Tool‑ und Projektsprache, die du aus der Anzeige gezogen hast.

Halte die Referenz leicht. Erwähne, dass sie für X einstellen und dass du gesehen hast, dass sie an Y arbeiten. Kopiere keinen langen Satz, keine Job‑ID und keine Liste von Tools. Ein konkretes Detail reicht, um Relevanz zu signalisieren, ohne unheimlich zu wirken.

Ziel: Ein prägnanter Satz, der ihren Kontext mit einem Ergebnis verbindet, bei dem du helfen kannst. Denke an "Time‑to‑production reduzieren" oder "manuelle Triage verringern" statt an „wir bieten Services an“. Ergänze eine kurze, glaubhafte Referenz.

Eine einfache Struktur:

• Signal: Rolle plus ein Projekt oder System
• Tool‑Kontext: ein Schlüsseltool (oder Kategorie)
• Ergebnis: ein messbares Resultat, das sie wahrscheinlich wollen
• Beweis: kurzes Beispiel oder realistischer Bereich
• Frage: eine Ja/Nein‑Frage, die zur Rolle passt

Beispiel‑Hook:

"Mir ist aufgefallen, dass ihr einen Backend Engineer für eure Kafka‑basierte Event‑Pipeline sucht. Wir helfen Teams, Consumer‑Lag und On‑Call‑Noise bei Spitzenlasten zu reduzieren (bei einem ähnlichen Setup Incident‑Volumen um 20–30% gesenkt). Wäre das diese Quartal einen kurzen Check wert?"

Wenn du skalierte Kaltakquise machst, halte den Hook als wiederverwendbare Vorlage mit zwei Platzhaltern (Projekt und Tool) und teste kleine Variationen.

Schließe mit einer einfachen Ja/Nein‑Frage. Sie senkt die Antworthürde und verhindert Übererklärungen.

Beispiel: von einer Anzeige zur Nachricht

Die Stellenauszug‑Kurzfassung

"Senior Backend Engineer (Platform). Stack: AWS, Kubernetes, Python, PostgreSQL, Kafka, Terraform. Project: migrate core billing from a monolith to services, build an event‑driven pipeline, add better monitoring and alerting. Constraints: SOC 2, 99.9% uptime, first milestone in 90 days. Nice to have: OpenTelemetry."

Das ziehst du in Felder, um später zu sortieren und zu segmentieren:

• Tools: AWS, Kubernetes, Kafka, Terraform, OpenTelemetry
• Projekt‑Verben: migrate, build, add monitoring
• Arbeitsfeld: Billing, Event‑Driven Pipeline, Plattform‑Zuverlässigkeit
• Einschränkungen: SOC 2, Uptime‑Ziel
• Zeitrahmen‑Hinweis: "first milestone in 90 days"

Leite nun ein oder zwei Bedürfnisse ab, ohne zu weit zu gehen. Aus "billing + migrate + 90 days + uptime" ist eine sichere Lesart: hohes Deploy‑Risiko und Bedarf an schneller Fehler‑Rückmeldung.

Winkel: Incident‑Zeit während Migration reduzieren (nicht: „Ihr System ist ein Chaos").

Beispiel‑Hook (und warum jede Phrase dort ist)

"Mir ist aufgefallen, dass ihr die Abrechnung in den nächsten 90 Tagen von einem Monolithen auf Services in AWS/K8s migriert und Kafka einführt. Teams verlieren dort meist Zeit durch laute Alerts und langsame Root‑Cause‑Analyse während Cutovers. Falls ihr offen seid, kann ich eine 3‑Schritte‑Lösung teilen, um Trace‑ und Alert‑Signale für Kafka‑Consumer und Billing‑APIs einzurichten, damit On‑Call Fehler in Minuten lokalisieren kann."

Warum es funktioniert: Es spiegelt ihren Stack, nennt eine reale Einschränkung (Zeitrahmen), benennt ein übliches Problem (laute Alerts) und bietet einen kleinen, konkreten nächsten Schritt.

Passe das für verschiedene Empfänger an: Ein Manager will das 90‑Tage‑Milestone schützen. Ein IC will weniger Blindspots bei Consumern und schnellere Root‑Cause‑Analyse bei Retries und Timeouts.

Häufige Fehler und wie du sie vermeidest

Stellenanzeigen sind voll von Hinweisen, aber sie sind kein Warenkorb. Der größte Fehler ist, jedes genannte Tool als Kaufabsicht zu behandeln. "Kubernetes" kann einfach nur eine Anforderung sein, kein akutes Problem.

Eine einfache Korrektur: Markiere jedes Tool als eines von drei Dingen: Must‑have (Table‑stakes), In‑Progress (Migration), oder Problem (explizit als schmerzhaft genannt). Nur die letzten beiden sind starke Outreach‑Signale.

Ein anderer Vertrauenskiller ist zu invasiv zu klingen. Ganze Sätze aus der Anzeige zu zitieren, interne Projektnamen zu wiederholen oder zu viele Details zu stapeln wirkt creepy. Nutze eine leichte Referenz und wechsle schnell zu einer sicheren Frage.

Häufige Fehler und Fixes:

• Tools mit Budget gleichsetzen. Fix: auf Verben wie "migrating", "replacing", "scaling", "urgent" oder "stability issues" achten.
• Überpersonalisieren. Fix: das Gebiet benennen (z. B. "Datenpipeline‑Zuverlässigkeit"), statt genauen Text zu kopieren.
• Falsche Persona ansprechen. Fix: Signal der passenden Owner zuordnen (Security → Security Lead, Data Quality → Analytics Manager, CI/CD → Platform/DevOps).
• Timing ignorieren. Fix: Posting‑Frische und Seniorität notieren.
• Chaotische Felder speichern. Fix: konsistente Spalten (Company, Role, Location, Stack, Project, Inferred Need, Confidence, Persona, Date).

Ein Reality‑Check: Wenn eine Anzeige "experience with SOC 2" fordert, ist das selten ein Grund, einem Data Engineer ein Compliance‑Produkt zu verkaufen. Meist ist es eine unternehmensweite Anforderung. Dein Hook sollte sich auf die tägliche Arbeit des Teams konzentrieren, nicht auf Checkboxen.

Saubere Daten machen Segmentierung später möglich. Wenn du nicht nach Persona, Projekttyp oder Konfidenz filtern kannst, wirst du am Ende dieselbe generische Nachricht an alle senden.

Kurze Checkliste vor dem Versenden

Vor dem Senden ein 60‑Sekunden‑Sanity‑Check:

• Ist das Posting aktuell und relevant für dein Angebot? Wenn nicht, überspringen.
• Hast du ein klares Tool‑Signal und ein klares Projekt‑Signal? Tool: benanntes Produkt/Plattform. Projekt: Migration, Build‑Out oder Uptime‑Ziel.
• Kannst du deine Annahme als Frage formulieren? Ersetze "Ihr braucht X" durch "Arbeitet ihr an X im Rahmen von [Projekt]?"
• Ist dein Hook unter zwei kurzen Sätzen vor der eigentlichen Bitte? Spiegel das Signal, verbinde es mit einem wahrscheinlichen Schmerz und stelle eine einfache Frage.
• Verfolgst du Segmente, damit du lernst, was wirkt? Ohne Label für den Grund, warum eine Firma auf der Liste steht, kannst du Targeting nicht verbessern.

Erfasse anschließend ein paar Felder, damit du testen und lernen kannst statt bei jeder Nachricht neu zu schreiben:

• Segment‑Label (Tool, Projekt oder beides)
• Quelle: Posting‑Titel und Datum
• Hook‑Winkel (Speed, Risk, Cost, Quality)
• Outcome (no reply, interested, not interested, bounce)

Bei höherer Versandmenge wird Deliverability zur versteckten Variable. Neue Domains und Mailboxen brauchen richtige Authentifizierung und langsames Warm‑Up, sonst kommen selbst gute Nachrichten nicht an.

Nächste Schritte: Einen kleinen, messbaren Outbound‑Test fahren

Du brauchst keinen großen Launch, um die Methode zu prüfen. Nimm deine Liste und mache einen kleinen Test, bei dem jeder Schritt bewusst ist und jedes Ergebnis dich etwas lehrt.

Starte mit 50–100 Leads, aufgeteilt in zwei oder drei enge Segmente. Halte jedes Segment konsistent (gleiche Rolle, ähnlicher Stack, ähnliches Projekt‑Signal). Beispiel: "Hiring for Kubernetes + platform team" vs. "Hiring for data warehouse migration". So sind Antworten vergleichbar.

Vor dem Senden Deliverability‑Basics erledigen: dedizierte Sending‑Domain, SPF/DKIM/DMARC setzen und neue Mailboxen langsam aufwärmen. Überspring das nicht, sonst landen perfekte E‑Mails im Spam.

Ein einfacher Ein‑Wochen‑Testplan:

• Baue zwei bis drei Segmente mit je 25–50 Leads
• Schreibe eine kurze 3‑Schritt‑Sequenz (Tag 1, Tag 3, Tag 7)
• A/B‑teste nur eine Variable (z. B. Hook‑Winkel)
• Tracke täglich: Bounce, keine Antwort, interessiert, nicht interessiert, Abwesenheit, Abmeldung
• Mach pro Segment eine Änderung basierend auf den Erkenntnissen

Antwortkategorien zählen mehr als Open‑Rates. Viele "not interested" deuten auf falsches Targeting oder Hook. Viele Bounces bedeuten schlechte Daten. Viele Abmeldungen heißen: Nachricht zu breit oder zu aufdringlich.

Wenn du einen Ort suchst, um Domains, Mailboxes, Warmup, Sequenzen und Antwortklassifikation zu verwalten, ist LeadTrain (leadtrain.app) so ausgelegt, dass du kleine Tests fahren und iterieren kannst, ohne mehrere Tools zu jonglieren.