Lista de prospectos a partir de descripciones de puestos: extraer herramientas y necesidades

Por qué las descripciones de puestos superan a las suposiciones

El outreach genérico se siente aleatorio porque lo es. Cuando envías un email a una empresa con un pitch vago como “mejorar tu proceso de desarrollo” o “ahorrar tiempo a ingeniería”, apuestas a que tienen exactamente el problema que vendes. La mayoría de las veces no lo tienen, o no lo están considerando ahora mismo. Tu mensaje parece otro cold email más y se ignora.

Una descripción de puesto es diferente. Es una foto de lo que un equipo necesita este trimestre, escrita en lenguaje directo y aprobada por un responsable de contratación. A menudo incluye detalles que no verás en la web: las herramientas que usan realmente, los proyectos que están construyendo, el dolor que intentan reducir y qué significa “bien” en ese rol.

Por eso construir una lista de prospectos a partir de descripciones de puestos puede superar a las suposiciones. No partes de una etiqueta genérica del sector. Partes de su trabajo actual.

Este método funciona mejor cuando:

• Vendes productos o servicios B2B ligados a una herramienta, flujo de trabajo o equipo específico.
• Tu comprador es técnico o está estrechamente ligado a resultados técnicos.
• La empresa está contratando activamente en el área que afecta tu oferta.

Hay límites. Una oferta puede decirte lo que planean hacer, pero no siempre su presupuesto, contratos con proveedores o la política interna. Puedes inferir con seguridad cosas como “usan X” o “están migrando a Y” si está claramente indicado. No puedes inferir con seguridad que “odian a su proveedor actual” o “están listos para comprar ahora mismo”.

Un ejemplo práctico: si una empresa contrata para “AWS IAM, SOC 2 e integración SIEM”, puedes escribir un gancho sobre reducir la carga de auditoría o acelerar la integración de logs. Estás respondiendo a sus objetivos declarados, no haciendo un salto.

Qué extraer de una descripción técnica

Una descripción técnica es un mini‑brief. Tu objetivo no es adivinar lo que necesitan, sino capturar lo que ya le dijeron al mercado que están construyendo, arreglando o escalando.

Empieza por lo básico porque condiciona todo lo demás: el título del puesto, la seniority, el nombre del equipo y si el rol es remoto, híbrido o ligado a una ubicación. Un “Staff Platform Engineer, Developer Experience” apunta a prioridades distintas que un “Junior DevOps Engineer, IT Operations”. Las notas de ubicación también pueden insinuar restricciones como residencia de datos o cobertura on‑call.

A continuación, extrae las herramientas y plataformas nombradas. No resumas todavía. Anota exactamente las palabras que usan, especialmente en categorías como nube e infraestructura, datos y analítica, seguridad e identidad, entrega y código, y sistemas de cliente o ingresos.

Luego captura proyectos y resultados. Estas son las señales de “por qué ahora” más útiles porque implican urgencia y presupuesto. Frases como “migrar de X a Y”, “escalar a N solicitudes”, “automatizar onboarding” o “reducir gasto en la nube” te dan una dirección clara para el outreach.

Las restricciones importan tanto como los objetivos. Anota cualquier cosa sobre cumplimiento, uptime, latencia, objetivos de coste, plazos y dependencias entre equipos. Si una oferta menciona “99.9% uptime”, “HIPAA” o “entrega trimestral”, tu mensaje debe respetar esa realidad.

Finalmente, vigila señales de compra: una nueva función (“construir el primer equipo de datos”), una reescritura (“re‑arquitecturar servicios core”), un despliegue de herramienta (“estandarizar CI/CD”) o un aumento de contratación. Esas suelen significar evaluación activa, no “algún día”.

Paso a paso: convertir ofertas en datos de leads

Empieza eligiendo un rol objetivo y mantenlo estrecho. “Backend Engineer” es demasiado amplio. “Backend Engineer para pagos fintech” es mucho más fácil porque los stacks y problemas se repiten. Elige una o dos industrias que entiendas para poder identificar lo que importa.

Recoge ofertas de forma consistente. Usa las mismas fuentes y la misma ventana temporal (por ejemplo, publicaciones de los últimos 14 días). Así tu lista reflejará lo que las empresas están contratando ahora mismo, no una mezcla aleatoria de necesidades antiguas.

Un flujo de trabajo simple:

• Define tu filtro: rol, seniority, industria, región y tamaño de la compañía.
• Guarda cada oferta como texto crudo y registra la fecha y la fuente.
• Resalta palabras señal: nombres de herramientas, integraciones y verbos de proyecto (migrar, reconstruir, instrumentar, consolidar).
• Convierte los resaltados en campos estructurados que puedas ordenar.
• Añade campos básicos de la compañía para luego emparejar con el contacto correcto.

Mantén los campos estructurados simples para que realmente los uses. Un conjunto práctico es: Rol, Industria, Herramientas mencionadas, Integraciones mencionadas, Verbos de proyecto, Tema del proyecto e Indicadores de urgencia (plazos, “must have”, “primera contratación”).

Ejemplo: si una oferta menciona “migrar de on‑prem a AWS”, “instrumentar servicios con OpenTelemetry” y “reducir ruido de alertas en PagerDuty”, ya tienes señales ordenables. No estás afirmando su dolor exacto. Estás capturando lo que le dijeron al mercado que están haciendo en un formato que puedes filtrar y al que puedes dirigirte.

Cómo identificar las herramientas y el stack real

Las descripciones son intencionalmente desordenadas. Mezclan lo que el equipo usa hoy, lo que desearían usar y lo que RR.HH. copió de otra oferta. Si quieres datos de leads que se correspondan con necesidades reales, necesitas una forma simple de detectar señales del stack.

Las herramientas suelen aparecer en lugares previsibles: requisitos obligatorios (probablemente stack core actual), habilidades deseables (a menudo planes futuros), responsabilidades (la realidad del día a día), secciones de “nuestro stack” (cuando existen) y bullets de proyecto (donde se ocultan migraciones y nuevas construcciones).

Separa el stack core de las palabras de moda preguntando: “¿Fallararía esta persona en el puesto sin esto?” Si la oferta dice “construir pipelines en dbt” u “operar clústeres Kubernetes”, eso es core. Si dice “familiaridad con blockchain” junto a cinco items no relacionados, trátalo como ruido.

Busca patrones que sugieran madurez y gasto. Nube, warehouses, observabilidad y ticketing/ITSM suelen asociarse a puntos de dolor claros y a evaluaciones de proveedores en curso.

Normaliza sinónimos para no dividir la misma señal en tu hoja. “K8s” y Kubernetes deben ir a una misma casilla. “GCP” y Google Cloud también. “CI/CD” puede referirse a GitHub Actions, GitLab CI o Jenkins, así que anota la herramienta específica cuando esté indicada.

Finalmente, marca pistas de integración. Frases como “migrar desde”, “conectar con”, “funciona con” o “experiencia integrando” suelen apuntar a un proyecto real. “Migrar dashboards de Grafana a Datadog” es una señal más fuerte que una larga lista de herramientas de monitorización.

Inferir necesidades a partir de proyectos sin pasarse

Las ofertas suelen describir proyectos, no problemas. Tu trabajo es traducir ese lenguaje de proyecto en algunas necesidades plausibles y mantener el tono cuidadoso.

Empieza reescribiendo lo que dicen en lo que probablemente necesitan. “Migrar” suele significar riesgo de plazo, riesgo de calidad de datos y un equipo que no puede permitirse downtime. “Escalar” suele señalar huecos en fiabilidad, rendimiento y monitorización. “Consolidar herramientas” insinúa control de costes, consistencia en reporting y menos handoffs.

Fíjate en disparadores que sugieran urgencia. Un lanzamiento de plataforma, una re‑arquitectura, una consolidación o un empuje de cumplimiento suelen indicar presión. Esas son señales más fuertes que líneas de relleno como “ritmo rápido” o “colaborar con stakeholders”.

Una taxonomía simple te ayuda a mantenerte con los pies en la tierra:

• Coste: proliferación de herramientas, proveedores redundantes, gasto en nube
• Velocidad: entregar más rápido, onboarding más corto, menos pasos manuales
• Fiabilidad: uptime, reducción de incidentes, problemas de escalado
• Visibilidad: reporting, atribución, monitorización, claridad de pipelines
• Seguridad: cumplimiento, control de accesos, trazabilidad de auditoría

Mapea cada necesidad probable a quién la siente más. Ingeniería se preocupa por tiempo de desarrollo, fiabilidad y deuda técnica. Ops y SRE sienten las caídas y falta de monitorización. Seguridad se preocupa por cumplimiento y accesos. RevOps o sales ops se centran en visibilidad, handoffs limpios y datos consistentes.

Mantén las suposiciones modestas convirtiéndolas en preguntas. En lugar de “Están luchando con downtime”, escribe “¿El uptime es una preocupación durante la migración?” En vez de “Tu stack está desordenado”, prueba “¿Buscan reducir la cantidad de herramientas involucradas?”

Ejemplo: una oferta menciona “re‑arquitecturar un pipeline de datos para soportar reporting en tiempo real”. Necesidades razonables son velocidad (datos frescos), fiabilidad (menos jobs rotos) y visibilidad (métricas de confianza). Excederse sería afirmar que sus reportes actuales son incorrectos. Un gancho seguro pregunta qué significa “tiempo real” para ellos y qué falla hoy.

Construye y segmenta tu lista de leads

Una vez empieces a extraer señales, recógelas en un registro de leads consistente. Cada fila debería decir quiénes son, qué intentan construir y qué stack mencionaron para que luego puedas redactar una nota relevante.

Un formato práctico para el registro de leads incluye:

• Compañía, puesto abierto, equipo (si se indica), ubicación
• Herramientas mencionadas, proyecto o iniciativa, disparador (por qué ahora), fecha de la oferta
• Notas de la fuente (la línea exacta que extrajiste), más una puntuación de confianza

Después de tener entre 20 y 50 registros, añade un scoring ligero para invertir tiempo en los mejores objetivos primero. Mantén las reglas obvias. Las publicaciones frescas suelen superar a las antiguas. Varias contrataciones relacionadas suelen indicar un proyecto real. Menciones específicas de herramientas (por ejemplo, “Kafka” más “pipeline en tiempo real”) son más fuertes que frases genéricas.

La segmentación es donde esto se vuelve accionable. En lugar de una lista grande, crea pequeños lotes basados en una combinación herramienta + proyecto. Ejemplo: “Snowflake + migración”, “Kubernetes + expansión del equipo de plataforma” o “Salesforce + limpieza de calidad de datos”. Esos lotes hacen tu outreach más focalizado y te ayudan a comparar resultados.

Decide si atacar por cuenta o por contacto. Si tu oferta es sobre un problema a nivel compañía, empieza por cuentas y luego encuentra al contacto adecuado. Si tu oferta ayuda a un equipo específico, empieza con el líder del equipo relacionado con el proyecto de la oferta.

Finalmente, escribe reglas de exclusión para mantener la lista limpia. Comunes: roles de prácticas o entry level, publicaciones con más de 60–90 días, equipos que no sirves o anuncios que nunca nombran herramientas ni proyectos.

Escribe un gancho relevante a partir de las señales

Un buen gancho no es una apertura ingeniosa. Es un reflejo breve de lo que ya intentan hacer, usando el mismo lenguaje de herramientas y proyectos que extrajiste.

Mantén la referencia ligera. Menciona que están contratando para X y que notaste que trabajan en Y. No pegues una cita, un ID de oferta ni una lista larga de herramientas. Un detalle específico basta para sentirse relevante sin resultar inquietante.

Apunta a una frase corta que conecte su contexto con un resultado que puedas ayudar a lograr. Piensa “reducir tiempo hasta producción” o “recortar el triage manual” en lugar de “ofrecemos servicios”. Luego añade una pequeña prueba sin exagerar.

Estructura simple:

• Señal: rol más un proyecto o sistema
• Contexto de herramienta: una herramienta clave (o categoría)
• Resultado: un resultado medible que probablemente les importe
• Prueba: un ejemplo breve o un rango realista
• Pregunta: un sí/no que encaje con el rol

Ejemplo de gancho:

“Veo que están contratando un Backend Engineer para mejorar su pipeline de eventos basado en Kafka. Ayudamos a equipos a reducir el lag de consumidores y el ruido on‑call en picos (recientemente redujimos el volumen de incidentes un 20–30% en setups similares). ¿Vale la pena revisarlo brevemente si es prioridad este trimestre?”

Si haces outreach a escala, mantiene el gancho como plantilla reutilizable con dos campos para rellenar (proyecto y herramienta) y prueba pequeñas variaciones.

Termina con una pregunta fácil de responder con sí/no. Baja el esfuerzo de contestar y evita que te pases explicando.

Ejemplo: de una oferta a un mensaje

Resumen de la oferta

“Senior Backend Engineer (Platform). Stack: AWS, Kubernetes, Python, PostgreSQL, Kafka, Terraform. Proyecto: migrar el core de facturación de un monolito a servicios, construir un pipeline orientado a eventos, añadir mejor monitorización y alertas. Restricciones: SOC 2, 99.9% uptime, primer hito en 90 días. Nice to have: OpenTelemetry.”

Esto es lo que extraes a campos para ordenar y segmentar:

• Herramientas: AWS, Kubernetes, Kafka, Terraform, OpenTelemetry
• Verbo de proyecto: migrar, construir, añadir monitorización
• Tipo de trabajo: facturación, pipeline orientado a eventos, fiabilidad de plataforma
• Restricciones: SOC 2, objetivo de uptime
• Indicio de plazo: “primer hito en 90 días”

Ahora infiere una o dos necesidades sin pasarte. De “facturación + migrar + 90 días + uptime” una lectura segura es: hay alto riesgo en despliegues, y necesitan feedback más rápido cuando algo falla.

Elección de ángulo: reducir tiempo de incidentes durante la migración (no “tu sistema es un desastre”).

Gancho de ejemplo (y por qué funciona cada frase)

“Veo que están migrando facturación a servicios en AWS/K8s y añadiendo Kafka en los próximos 90 días. Los equipos suelen perder más tiempo por alertas ruidosas y diagnóstico lento durante los cutovers. Si te parece, puedo compartir un método en 3 pasos para configurar señales de trazas y alertas para consumidores Kafka y APIs de facturación, de modo que on‑call localice fallos en minutos.”

Por qué funciona: refleja su stack, referencia una restricción real (plazo), nombra un dolor común (alertas ruidosas) y ofrece un paso pequeño y concreto.

Para adaptar a distintos destinatarios, conserva las mismas señales pero cambia el “beneficio”. Un manager se preocupa por proteger el hito de 90 días. Un IC quiere menos puntos ciegos en consumidores y diagnósticos más rápidos en retires y timeouts.

Errores comunes y cómo evitarlos

Las ofertas están llenas de pistas, pero no son un carrito de compras. La trampa más grande es tratar cada herramienta mencionada como intención de compra. “Kubernetes” puede ser un requisito básico, no un dolor activo.

Una solución simple es marcar cada herramienta como una de tres cosas: must‑have (requisito), in‑progress (migración) o problem (explicitamente problemático). Solo las dos últimas son señales fuertes de outreach.

Otra forma fácil de perder confianza es sonar invasivo. Citar una línea entera de la oferta, repetir un nombre de proyecto interno o apilar demasiados detalles puede resultar inquietante. Usa una referencia ligera y luego pasa a una pregunta segura y útil.

Errores comunes y la solución:

• Suponer que una herramienta implica presupuesto. Solución: busca verbos como “migrando”, “reemplazando”, “escalando”, “urgente” o “problemas de estabilidad”.
• Personalizar en exceso. Solución: referencia el área (por ejemplo, “fiabilidad del pipeline de datos”) en lugar de copiar texto exacto.
• Apuntar a la persona equivocada. Solución: mapea cada señal al propietario (seguridad → responsable de seguridad, calidad de datos → manager de analítica, CI/CD → plataforma/DevOps).
• Ignorar el timing. Solución: anota frescura de la publicación y seniority.
• Guardar campos desordenados. Solución: mantén columnas consistentes (compañía, rol, ubicación, stack, proyecto, necesidad inferida, confianza, persona, fecha).

Un control rápido: si una oferta dice “experiencia con SOC 2”, rara vez es razón para vender un producto de cumplimiento al data engineer. Normalmente es un requisito de empresa. Tu gancho debe centrarse en el trabajo del equipo día a día, no en la casilla de la compañía.

Datos limpios son lo que hace posible la segmentación después. Si no puedes filtrar por persona, tipo de proyecto o confianza, acabarás enviando un mensaje genérico a todos.

Checklist rápido antes de enviar

Antes de mandar un mensaje, haz un chequeo de sentido común de 60 segundos. Mantiene tu outreach anclado en lo que la compañía dijo, no en lo que esperas que sea verdad.

• ¿La oferta es reciente y relevante para tu oferta? Si es antigua o para un equipo que no sirves, descártala.
• ¿Tienes una señal clara de herramienta y una señal clara de proyecto? Señal de herramienta: un producto o plataforma nombrada. Señal de proyecto: una iniciativa como migración, ampliación o meta de uptime.
• ¿Puedes formular tu suposición como una pregunta? Sustituye “Necesitan X” por “¿Están trabajando en X como parte de [proyecto]?”
• ¿Tu gancho tiene menos de dos frases antes del pedido? Refleja la señal, conéctala a un posible dolor y luego pregunta algo simple.
• ¿Estás rastreando segmentos para aprender qué funciona? Si no etiquetas por qué una compañía está en la lista, no podrás mejorar el targeting.

Después, captura unos campos para poder testar y aprender en lugar de reescribir desde cero cada vez:

• Etiqueta de segmento (herramienta, proyecto o ambos)
• Título y fecha de la oferta
• Ángulo del gancho usado (velocidad, riesgo, coste, calidad)
• Resultado (sin respuesta, interesado, no interesado, rebote)

Si envías a volumen, la entregabilidad puede convertirse en la variable oculta. Dominios y buzones nuevos necesitan autenticación adecuada y calentamiento gradual, o incluso buenos mensajes no llegarán al inbox.

Próximos pasos: ejecuta una prueba outbound pequeña y medible

No necesitas un lanzamiento gigantesco para validar esto. Toma tu lista y ejecuta una prueba pequeña donde cada parte móvil sea intencional y cada resultado te enseñe algo.

Empieza con 50 a 100 leads divididos en dos o tres segmentos cerrados. Mantén cada segmento consistente (mismo rol, stack similar, señal de proyecto similar). Por ejemplo: “Contratando para Kubernetes + equipo de plataforma” vs “Contratando para migración de data warehouse”. Así las respuestas serán comparables.

Antes de enviar, haz bien lo básico de entregabilidad. Usa un dominio de envío dedicado, configura SPF/DKIM/DMARC y calienta buzones nuevos gradualmente. Si lo omites, puedes escribir emails perfectos y aún así acabar en spam.

Un plan simple de prueba de una semana:

• Construye dos o tres segmentos, 25–50 leads cada uno
• Escribe una secuencia corta de tres pasos (día 1, día 3, día 7)
• A/B testea solo una cosa (por ejemplo, el ángulo del gancho)
• Rastrea resultados a diario: rebote, sin respuesta, interesado, no interesado, fuera de oficina, baja
• Haz un cambio por segmento basado en lo aprendido

Las categorías de respuesta importan más que las tasas de apertura. Si “no interesado” es alto, tu targeting o gancho está mal. Si hay muchos rebotes, tus datos son débiles. Si suben las bajas, tu mensaje es demasiado amplio o agresivo.

Si quieres un lugar para gestionar dominios de envío, buzones, calentamiento, secuencias multi‑paso y clasificación de respuestas, LeadTrain (leadtrain.app) está diseñado para ese flujo de trabajo y te permite ejecutar pruebas pequeñas e iterar sin saltar entre herramientas.