Cómo convertirte en GTM engineer sin dejar tu puesto

La forma más corta de convertirte en GTM engineer es usar la empresa en la que ya trabajas como campo de prácticas: encuentra el proceso manual que más tiempo le quita a tu equipo, construye la versión más simple que lo resuelva, dásela a quien lo sufre, mide el antes y el después, y repite con el siguiente cuello de botella. Un portfolio de problemas resueltos y medidos vale más que una lista de herramientas en el currículum.

Por qué tu empresa es el mejor campo de prácticas

Porque ya sabes lo que más cuesta enseñar: dónde pierde tiempo el equipo, qué leads se quedan sin atender, cómo es un buen prospecto y qué información necesita un comercial antes de una llamada.

Mucha gente que quiere pasar a GTM engineering empieza al revés: aprende Clay, monta un proyecto suelto con un modelo de IA y conecta herramientas sin un problema detrás. Aprende a usar las piezas, pero no a decidir qué merece la pena construir, que es lo que de verdad se contrata. RevGuild encontró que el 92 % de las ofertas de GTM engineer filtran por criterio comercial y solo el 44 % por saber usar Clay: la herramienta se puede enseñar, el criterio no tanto.

Y a medida que la IA hace más fácil la parte de construir, pesan más el criterio, el gusto, saber escribir y saber qué problema resolver primero. Eso se aprende dentro de un equipo comercial, no en un tutorial.

Paso 1: encuentra el proceso manual que más molesta

Empieza por hacer una lista de las tareas que hacen pensar a tu equipo «tiene que haber una forma mejor de hacer esto». Hay más de las que parece:

• Los SDR dedican un buen rato a investigar cada prospecto antes de escribir.
• Los comerciales preparan a mano un resumen de la cuenta antes de cada llamada.
• Leads buenos se quedan atascados en la cola equivocada del CRM.
• Alguien actualiza el CRM a mano después de cada llamada.
• Customer success no tiene forma de saber qué clientes están listos para ampliar.
• Marketing pierde medio día a la semana construyendo una lista de empresas que encajan con el ICP.

La mejor forma de encontrarlas es acompañar unas horas a alguien de tu equipo mientras trabaja y apuntar cada tarea manual y cuánto tarda. No tienes que inventarte el problema: estás sentado al lado de quien lo sufre.

De la lista, elige uno que sea repetitivo, que duela y que esté cerca de los ingresos, para que después puedas medir si tu solución ayudó.

Paso 2: construye la versión fea

La primera versión tiene que ser casi vergonzosamente simple. El objetivo es que algo que hoy le lleva a una persona 30 minutos le lleve 3, no construir la plataforma perfecta.

Tres ejemplos de primeras versiones según el problema:

• Investigación de prospectos. Un flujo que coge los leads nuevos, los enriquece con datos de empresa y persona, los puntúa contra el ICP, busca un disparador relevante, propone una primera línea y deja la lista lista en la herramienta de envío que ya usa el equipo.
• CRM al día. Coger las transcripciones de las llamadas de Gong o Granola, extraer los datos importantes y los siguientes pasos, actualizar la oportunidad, crear las tareas y dejar redactado el email de seguimiento.
• Señales de ampliación. Vigilar qué clientes están contratando mucho en un área que usa tu producto, identificar a quien decide y crear una oportunidad para el comercial cuando las señales coinciden.

Ninguno necesita ser sofisticado. De hecho, conviene evitarlo al principio. Tienes el detalle de las herramientas que usamos para cada pieza en nuestras herramientas GTM.

Paso 3: dásela a quien tiene el problema

No pases tres semanas construyendo a solas. Dale la primera versión a una persona que haga ese trabajo cada día y mira qué pasa.

Si eres SDR, dásela a otro SDR; si trabajas en marketing, a alguien de marketing. Y observa: quizá no se fía de una de las fuentes de datos, quizá el flujo es correcto pero añade tres pasos molestos a algo que ya era rápido, quizá el texto que propone la IA está bien pero nadie lo enviaría a un cliente, o quizá automatizaste la parte equivocada.

Todo eso es bueno. Es lo que ningún tutorial te enseña: qué hace que un sistema sea útil para quien lo usa. Corrige, dáselo a dos personas más y sigue iterando.

Paso 4: mide el antes y el después

Es el paso más importante. Hay mucha diferencia entre «he construido un flujo con IA» y «he construido un sistema que ha mejorado cómo trabaja el equipo comercial».

Las preguntas que tienes que poder contestar son concretas: ¿cuánto ha bajado el tiempo de investigación por prospecto?, ¿cuántas cuentas más trabaja cada SDR a la semana?, ¿llegan mejores leads a la persona correcta?, ¿se han recuperado leads que antes se perdían?, ¿dedican los comerciales menos tiempo a actualizar el CRM?

No hace falta generar un millón en ingresos para demostrar que algo funcionó: ahorrar varias horas a la semana a quince personas ya es mucho. Pero tienes que poder enseñar un antes y un después. «Sé usar Clay y varias herramientas de IA» dice poco. «Construí un flujo que redujo la investigación previa de 30 a 3 minutos por prospecto y que el equipo usa cada día», con tus números reales, dice que sabes encontrar un problema, entender el sistema, construir una solución, conseguir que se use y medir el resultado. Eso es el trabajo de un GTM engineer.

Paso 5: busca el siguiente cuello de botella

Una automatización casi siempre destapa el siguiente problema. Arreglas la investigación de prospectos y descubres que el cuello de botella real es la cualificación. Lo arreglas y ves que los leads cualificados se quedan en la cola equivocada. Lo arreglas y ves que los comerciales tardan demasiado en responder.

En algún momento dejas de construir automatizaciones sueltas y empiezas a entender el sistema entero: de dónde salen los datos, dónde se transforman, dónde intervienen las personas, dónde se rompe y dónde un poco de software cambia mucho. Ese pensamiento de sistema es el centro del trabajo.

Y algo cambia en tu puesto: dejas de ser «el SDR que sabe usar Clay» y pasas a ser la persona a la que el equipo pregunta «¿esto se podría automatizar?». Esa es la transición que buscas.

El plan de 12 semanas

Si quieres los cinco pasos convertidos en un calendario, lo tienes semana a semana en el plan de formación GTM engineer: cuatro bloques de tres semanas, unas cinco horas a la semana y un entregable por bloque.

Qué aprender (y qué no hace falta todavía)

Aprende primero lo que pide el problema que has elegido; el resto, cuando lo necesites. Aun así, conviene saber qué piden las ofertas.

En el análisis de Cargo sobre 1.350 ofertas de GTM engineer (abril-julio de 2026), el 59 % piden APIs, el 57 % CRM, el 40 % Python y el 38 % SQL, y el 70 % mencionan modelos de lenguaje, agentes o prompts. El mismo análisis encuentra que menos del 3 % de las ofertas son de nivel junior: otra razón para llegar con casos reales y no solo con formación.

Para la parte técnica, Clay tiene programas en grupo, algunos gratuitos, aunque su bootcamp principal y sus certificaciones no aceptaban solicitudes a fecha de octubre de 2026. Para entender dónde encaja tu trabajo con el resto del equipo, lee qué es un GTM engineer y en qué se diferencia del RevOps manager.

Errores frecuentes

1. Empezar por la herramienta en lugar de por un problema real.
2. Construir listas antes de entender qué vende tu empresa y a quién. Si el ICP está parcialmente identificado y no documentado, ese es tu primer proyecto: cómo calcular tu ICP real.
3. Creer reglas sin probarlas. «El email corto siempre gana» es una hipótesis, no un dato de tu mercado.
4. Desaparecer construyendo semanas sin enseñar nada al equipo.
5. Romper algo que funciona para sustituirlo por algo que crees mejor, sin haberlo medido.
6. Darlo por terminado cuando funciona técnicamente. Termina cuando alguien lo usa y lo has medido.

Preguntas frecuentes

¿Necesito saber programar para ser GTM engineer?

No para empezar: los primeros proyectos se hacen con herramientas visuales como Clay o n8n. Pero las ofertas piden con frecuencia APIs, SQL y algo de Python, así que conviene aprenderlo cuando un problema real te lo pida.

¿Desde qué puesto es más fácil dar el salto?

Desde cualquiera que esté cerca del proceso comercial: SDR, comercial, marketing, growth u operaciones. Quien viene de RevOps ya conoce el CRM y el proceso; quien viene de ventas conoce mejor al cliente. Los dos llegan con la mitad del camino hecho.

¿Cuánto tiempo lleva?

Con unas cinco horas a la semana, en unos tres meses puedes tener un primer caso resuelto, usado y medido. Es lo que propone nuestro plan de formación GTM engineer. Ser GTM engineer de verdad es acumular varios casos así.

¿Y si mi empresa no me deja tocar el CRM?

Empieza con acceso de lectura y una copia de los datos. Cuando tu flujo tenga que escribir en el CRM, pide que lo revise la persona responsable del CRM o el RevOps manager antes de activarlo: es además la mejor forma de ganarte su confianza.