LinkedIn Stellenanzeige zu Buyer Pain Map
Analysiere LinkedIn-Stellenanzeigen. Erstelle daraus eine strukturierte Buyer Pain Map mit Scores, Schmerzpunkten und Outreach-Ansätzen.
Wichtige Regel: Jeder abgeleitete Schmerzpunkt muss mit einem spezifischen Zitat aus der Stellenbeschreibung belegt werden. Erfinde niemals Schmerzpunkte, die nicht im Text verankert sind. Wenn eine Anzeige zu allgemein ist, um Schmerzpunkte abzuleiten, sage dies explizit und weise eine niedrige Signalstärke zu.
Ethische Regel: Leite keine persönlichen Eigenschaften oder geschützten Merkmale über Kandidaten ab. Konzentriere dich ausschließlich auf operative Schmerzpunkte auf Unternehmensebene und organisatorische Bedürfnisse.
Schritt 1: Setup-Prüfung
Bestätige, dass die benötigten Umgebungsvariablen gesetzt sind:
echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+gesetzt}"
Wenn GEMINI_API_KEY fehlt: Stopp. Sag dem Benutzer: „GEMINI_API_KEY wird benötigt. Holen Sie ihn unter aistudio.google.com. Fügen Sie ihn Ihrer .env-Datei hinzu.“
Schritt 2: Eingaben sammeln
Das Skill benötigt 3 erforderliche Eingaben. Sammle sie, bevor du fortfährst.
2a: Produktbeschreibung
Frage: „Beschreibe dein Produkt in 2-5 Sätzen. Was machst du, was ist dein zentrales Wertversprechen und wen sprichst du an?“
Wenn der Benutzer dies bereits in seiner Eingabe erwähnt hat: Extrahiere es. Bestätige: „Produktbeschreibung erfasst: [Zusammenfassung].“
2b: ICP-Beschreibung
Frage: „Beschreibe dein ideales Kundenprofil in 2-6 Stichpunkten: Branchen, Unternehmensgrößen, Rollen, an die du verkaufst, Hinweise auf den Tech-Stack.“
Wenn der Benutzer dies bereits in seiner Eingabe erwähnt hat: Extrahiere es. Bestätige: „ICP erfasst: [Zusammenfassung].“
2c: Stellenanzeigen
Frage: „Füge die Stellenbeschreibungen ein, die du analysieren möchtest. Gib für jede Anzeige den Firmennamen, die Stellenbezeichnung und den vollständigen Beschreibungstext an. Du kannst 1-15 Anzeigen einfügen.“
Akzeptierte Formate:
- Roh eingefügter Text mit klar gekennzeichnetem Firmennamen und Stellenbezeichnung
- Strukturierte JSON-Objekte mit Feldern:
company_name,job_title,location(optional),seniority(optional),team_or_function(optional),job_description_text,job_url(optional) - Mehrere Anzeigen getrennt durch klare Trennzeichen (--- oder Nummerierung)
Wenn ein Feld fehlt: Schließe, was du aus dem Beschreibungstext ableiten kannst. Wenn company_name oder job_description_text fehlt, frage vor dem Fortfahren danach.
2d: Optionale Eingaben
Wenn der Benutzer eine dieser Angaben macht, erfasse sie:
account_notes: zusätzlicher Kontext pro Firma (Finanzierung, Tech-Stack, bekannte Tools, Kontakte)focus_dimension: „pipeline“ (Bevorzugung von Bewertung und Priorisierung), „positioning“ (Bevorzugung von Messaging-Ansätzen) oder „both“ (Standard)
Schritt 3: Signale extrahieren
Analysiere für jede Stellenanzeige und extrahiere:
- Team / Funktion: In welchem Team arbeitet diese Rolle? (GTM, Produkt, Infrastruktur, Daten, RevOps, CS, Engineering, etc.)
- Seniorität: IC, Senior IC, Manager, Director, VP, C-Level
- Fokus der Verantwortlichkeiten: Klassifiziere den dominierenden Modus:
- Brandbekämpfung: „stabilisieren“, „reparieren“, „Ausfallzeiten reduzieren“, „entblocken“
- Neuaufbau: „von Grund auf neu aufbauen“, „0→1“, „Grünfeld“, „entwerfen und implementieren“
- Optimierung: „skalieren“, „optimieren“, „Effizienz verbessern“, „automatisieren“
- Ersetzung: „Legacy ersetzen“, „migrieren von“, „modernisieren“
- Anforderungssprache: Notiere Schlüsselwörter, die Absicht signalisieren: „erster X-Mitarbeiter“, „kritische Rolle“, „sofort“, „muss haben“
- Tool-/Stack-Hinweise: Verweise auf bestimmte Tools, Plattformen oder Technologiekategorien, die mit dem Produktbereich des Benutzers überlappen
Nach Firma gruppieren. Wenn mehrere Anzeigen von derselben Firma stammen, gruppiere ihre Signale zusammen.
Gib an: „Signale aus X Anzeigen von Y Firmen extrahiert.“
Schritt 4: Mit dem LLM bewerten
Lies references/scoring-rubric.md für das vollständige Bewertungsmodell.
Erstelle die LLM-Anfrage:
cat > /tmp/pain-map-score-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Du bist ein GTM-Analyst, der sich darauf spezialisiert hat, Einstellungssignale in Käuferabsichten zu dekodieren. Für jeden bereitgestellten Account bewertest du drei Dimensionen und leitest den Unternehmenskontext ab. Regeln: (1) Jede Bewertung muss eine einzeilige Erklärung in Klartext enthalten. (2) signal_strength misst, wie viele und wie spezifisch die Einstellungssignale im Verhältnis zum Produktbereich des Benutzers sind. (3) urgency misst, wie zeitkritisch der Einstellungsbedarf erscheint. (4) icp_fit misst, wie genau das Unternehmen der ICP-Beschreibung des Benutzers entspricht. (5) Jede Bewertung ist 1-10. (6) overall_score = rund((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10). (7) Leite buy_vs_build aus der Stellenanzeigensprache ab. Verwende GENAU EINES dieser Labels: 'Leaning build', 'Leaning buy', 'Hybrid (buy-and-build)', 'Unknown'. (8) Leite stage_guess aus Firmenhinweisen ab: Finanzierungsphase, Mitarbeiterzahl, Unternehmenstyp. (9) Gib nur gültiges JSON aus."
}]
},
"contents": [{
"parts": [{
"text": "SCORING_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.2,
"maxOutputTokens": 4096
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-score-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Ersetze SCORING_CONTEXT_HERE durch:
- Die Produktbeschreibung und ICP-Beschreibung aus Schritt 2
- Die extrahierten Signale pro Firma aus Schritt 3
- Die Bewertungsrubrik-Regeln aus
references/scoring-rubric.md - Anweisungen, um JSON auszugeben mit:
company_name,headline,overall_score,score_breakdown(signal_strength, urgency, icp_fit – jeweils mit Score und Erklärung),stage_guess,buy_vs_build_guess
Schritt 5: Pain Map erstellen
Verwende für jeden Account die extrahierten Signale und den LLM-Bewertungskontext, um die Buyer Pain Map zu erstellen.
cat > /tmp/pain-map-analysis-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Du bist ein B2B-Schmerzpunkte-Analyst, der Stellenbeschreibungen liest und die operativen Schmerzpunkte identifiziert, die ein Unternehmen erlebt. Regeln: (1) Jeder Schmerzpunkt muss ein kurzes Label, eine 1-3-Satz-Beschreibung und spezifische Zitate aus der Stellenanzeige als Belege enthalten. (2) Klassifiziere Schmerzpunkte als primär (direkt relevant für das Produkt des Benutzers) oder sekundär (echter Schmerz, aber tangential zum Produkt). (3) Wenn eine Anzeige zu allgemein ist, um spezifische Schmerzpunkte abzuleiten, sage dies explizit – erfinde keine. (4) Erstelle für jeden Account auch 1-3 empfohlene Outreach-Ansätze. Jeder Ansatz hat: angle_name (kurz), narrative (1-2 Sätze, wie man führt) und talk_track_bullets (2-4 konkrete Gesprächspunkte). (5) Outreach-Ansätze müssen auf bestimmte Schmerzpunkte und Belege verweisen, nicht auf allgemeine Wertversprechen. Keine verbotenen Wörter: Synergie, Hebelwirkung, innovativ, hochmodern, erstklassig, weltklasse, bahnbrechend, disruptiv, nahtlos, robust, umfassend, revolutionieren, transformieren, optimieren. (6) Gib nur gültiges JSON aus."
}]
},
"contents": [{
"parts": [{
"text": "ANALYSIS_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.4,
"maxOutputTokens": 8192
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-analysis-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Ersetze ANALYSIS_CONTEXT_HERE durch:
- Die Produktbeschreibung und ICP-Beschreibung
- Die Stellenanzeigen jeder Firma (vollständiger Text)
- Die Bewertungen und Kontext aus Schritt 4
- Account-Notizen, falls vorhanden
- Die focus_dimension-Präferenz (pipeline / positioning / both)
- Anweisungen, um pro Account auszugeben:
buyer_pain_map(primary_pains, secondary_pains) undrecommended_outreach_angles
Lies references/examples.md, um die erwartete Ausgabequalität und -tiefe zu kalibrieren.
Schritt 6: Handoff-Objekt erstellen
Erstelle für jeden Account einen strukturierten Handoff-Block, den outreach-sequence-builder direkt verwenden kann:
handoff:
for_outreach_sequence_builder:
account_summary: 2-3 Sätze Zusammenfassung der Situation und des Einstellungskontextes des Unternehmens
key_pain: Der am besten umsetzbare Schmerzpunkt in einem Satz
suggested_personas: 2-4 Stellenbezeichnungen der Personen, die diesen Schmerzpunkt am ehesten betreuen
tone: Ein Satz, der den empfohlenen Outreach-Ton beschreibt
Der Handoff muss konkret genug sein, dass jemand ihn in die Eingabeaufforderung des Outreach-Sequence-Builders einfügen und eine nutzbare Sequenz erhalten könnte, ohne den Account erneut zu recherchieren.
Schritt 7: Selbst-QA
Führe jede Prüfung durch und behebe Verstöße, bevor du präsentierst:
- Jeder abgeleitete Schmerzpunkt zitiert mindestens einen spezifischen Ausdruck aus der Stellenbeschreibung
- Keine erfundenen Schmerzpunkte für allgemeine / schwache Signale (überprüfe Anzeigen mit signal_strength ≤ 3)
- Alle drei Bewertungen (signal_strength, urgency, icp_fit) haben eine einzeilige Erklärung
- Gesamtscore entspricht der Formel:
rund((0.4 × Signalstärke + 0.3 × Dringlichkeit + 0.3 × ICP-Fit) × 10) - Buy-vs-Build-Label ist eines von: „Leaning build“, „Leaning buy“, „Hybrid (buy-and-build)“, „Unknown“
- Keine verbotenen Wörter in Outreach-Ansätzen: Synergie, Hebelwirkung, innovativ, hochmodern, erstklassig, weltklasse, bahnbrechend, disruptiv, nahtlos, robust, umfassend, revolutionieren, transformieren, optimieren
- Jeder Outreach-Ansatz hat 2-4 Gesprächspunkte, keine allgemeinen Wertaussagen
- Accounts außerhalb des ICP werden mit einer klaren Empfehlung, sie zu depriorisieren, gekennzeichnet
- Handoff-Objekte sind vollständig mit allen 4 Feldern (account_summary, key_pain, suggested_personas, tone)
- Keine persönlichen Eigenschaften oder geschützten Merkmale über Kandidaten abgeleitet
- Anzeigen nach Firma gruppiert, wenn mehrere Anzeigen von derselben Firma stammen
Behebe jeden Verstoß, bevor du präsentierst.
Schritt 8: Ausgabe und Speicherung
Für Menschen lesbare Ausgabe
Präsentiere die vollständige Analyse in diesem Format:
## Buyer Pain Map — [YYYY-MM-DD]
**Produkt:** [Produktname aus der Beschreibung]
**Analysierte Anzeigen:** X Anzeigen von Y Firmen
**Fokus:** [pipeline / positioning / both]
---
### [Firmenname] — Score: [N]/100
**Überschrift:** [einzeilige Zusammenfassung, was die Einstellung enthüllt]
| Dimension | Score | Erklärung |
|-----------|-------|-------------|
| Signalstärke | N/10 | [ein Satz] |
| Dringlichkeit | N/10 | [ein Satz] |
| ICP-Fit | N/10 | [ein Satz] |
**Phase:** [Phasen-Schätzung] | **Buy-vs-Build:** [Haltungs-Label]
#### Primäre Schmerzpunkte
- **[Schmerzpunkt-Label]:** [1-3 Sätze Beschreibung]
- Beleg: „[zitierte Phrase aus Stellenanzeige]“
#### Sekundäre Schmerzpunkte
- **[Schmerzpunkt-Label]:** [1-3 Sätze Beschreibung]
- Beleg: „[zitierte Phrase aus Stellenanzeige]“
#### Empfohlene Outreach-Ansätze
1. **[Ansatzname]:** [Erzählung]
- [Aufzählungspunkt 1]
- [Aufzählungspunkt 2]
- [Aufzählungspunkt 3]
#### Handoff → Outreach-Sequence-Builder
> **Zusammenfassung:** [2-3 Sätze]
> **Schlüsselschmerz:** [ein Satz]
> **Vorgeschlagene Personas:** [Liste]
> **Ton:** [ein Satz]
---
[wiederhole für jede Firma, sortiert nach overall_score absteigend]
In Datei speichern
mkdir -p docs/pain-maps
OUTFILE="docs/pain-maps/$(date +%Y-%m-%d).md"
cat > "$OUTFILE" << 'EOF'
REPORT_CONTENT_HERE
EOF
echo "Pain Map gespeichert unter $OUTFILE"
Wenn mehrere Firmen analysiert werden, speichere auch einzelne Dateien mit slugifizierten Firmennamen (Kleinbuchstaben, ersetze Leerzeichen und Sonderzeichen durch Bindestriche, entferne abschließende Bindestriche):
z.B. „ACME, Inc.“ → acme-inc.md, „CoolStartup Inc“ → coolstartup-inc.md
SLUG=$(echo "COMPANY_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/-$//')
cat > "docs/pain-maps/${SLUG}.md" << 'EOF'
INDIVIDUAL_ACCOUNT_CONTENT_HERE
EOF
Wann verwenden
- Du hast 1-15 eingefügte Stellenbeschreibungen und möchtest wissen, welchen Schmerz jedes Unternehmen hat
- Du planst Account-basierten Outreach und benötigst eine strukturierte Schmerzanalyse, bevor du Sequenzen schreibst
- Du möchtest priorisieren, welche Accounts auf Basis von Einstellungssignalen zuerst angesprochen werden sollen
- Ein PMM möchte echte Schmerzsprache aus Stellenanzeigen nutzen, um die Positionierung zu verfeinern
Wann NICHT verwenden
- Du musst finden, welche Unternehmen einstellen (verwende stattdessen
linkedin-hiring-intent-scanneroderyc-intent-radar-skill) - Du musst Outreach-Nachrichten schreiben (verwende stattdessen
outreach-sequence-builder– füttere es mit dem Handoff aus diesem Skill) - Du möchtest eine Plattform auf Signale überwachen (verwende stattdessen
reddit-icp-monitorodertwitter-GTM-find-skill) - Du benötigst Kontaktinformationen oder E-Mail-Anreicherung (dieses Skill bietet das nicht)
Funktioniert gut mit
- outreach-sequence-builder: Übergib den
handoff.for_outreach_sequence_builder-Block direkt als Kontext, wenn du eine Sequenz erstellst. - noise-to-linkedin-carousel: Verwende die primären Schmerzpunkte und Belegzitate als Quellenmaterial für eine Karussell über Käuferprobleme.
- reddit-icp-monitor: Vergleiche Schmerzthemen aus Stellenanzeigen mit Schmerzthemen, die in Reddit-Diskussionen auftauchen.