El charlista sube al escenario, presenta sus slides, responde un par de preguntas, y se va. El conferencista entiende que la charla es solo una pieza de un sistema más grande — un sistema que empieza semanas antes del evento y continúa semanas después.

Después de más de 60 keynotes y presentaciones en eventos como Google Cloud Next, DevRelCon, DrupalCon y Nerdearla, he desarrollado un proceso que convierte cada presentación en una oportunidad de impacto medible. No se trata de ser el mejor orador del evento. Se trata de conectar tu presencia con resultados reales.

En este artículo voy a compartir ese proceso completo: desde la preparación estratégica hasta el seguimiento post-evento.

Antes del Evento: La Preparación Estratégica

La mayoría de los speakers empiezan preparando sus slides. Ese es el error. Antes de abrir Google Slides, necesitas responder preguntas fundamentales que van a guiar todo lo demás.

Define tu KPI de éxito

Cada charla debe tener un objetivo medible. No "que la gente aprenda algo" — eso es demasiado vago. Necesitas saber exactamente qué quieres lograr:

Ejemplos de KPIs concretos:

• Incrementar registros en la plataforma (activación)

• Generar awareness de una nueva feature

• Reducir preguntas frecuentes sobre un tema específico

• Posicionar el producto en una nueva categoría

• Generar leads calificados para el equipo de ventas

El KPI determina todo: el contenido de tu charla, el call-to-action, cómo vas a medir el éxito, y qué materiales necesitas preparar.

Estudia a tu audiencia

No asumas que conoces a tu audiencia. Investiga:

• Pain points: ¿Qué problemas enfrentan día a día? ¿Qué los frustra?

• Challenges: ¿Qué están tratando de lograr? ¿Qué obstáculos tienen?

• Motivaciones: ¿Por qué asisten a este evento específico? ¿Qué esperan llevarse?

• Nivel técnico: ¿Son principiantes, intermedios, avanzados? ¿Qué conocimientos previos tienen?

• Outcome deseado: ¿Qué quieren poder hacer después de tu charla que no podían hacer antes?

Puedes obtener esta información de varias formas: habla con los organizadores del evento, revisa el programa y otras charlas, investiga en comunidades relacionadas, o incluso pregunta directamente en redes sociales.

Alinéate con marketing

Si representas a una empresa, necesitas entender la voz y el tono del producto. Tu charla no existe en el vacío — es parte de una estrategia de comunicación más amplia.

Habla con tu equipo de marketing:

• ¿Cuál es el messaging actual del producto?

• ¿Hay alguna campaña activa con la que debas alinear?

• ¿Qué términos o frases debemos usar (o evitar)?

• ¿Hay materiales que pueda aprovechar o adaptar?

Esta alineación asegura consistencia y amplifica el impacto de tu presencia.

Prepara tu sistema de atribución

Este paso es crítico y la mayoría lo ignora: ¿cómo vas a saber si tu charla generó resultados?

Opciones de atribución:

• URL con parámetros UTM específicos para el evento (ejemplo: tuproducto.com/signup?utm_source=devrelcon&utm_medium=talk&utm_campaign=kevin)

• Código promocional exclusivo para asistentes

• Landing page específica mencionada solo en tu charla

• QR code único en tus slides finales

• Formulario de feedback con tracking

Sin atribución, no puedes demostrar impacto. Y si no puedes demostrar impacto, tu trabajo se vuelve invisible para los stakeholders.

Para Google Developer Experts, MVPs, GitHub Stars y Otros Programas

Quizás estás pensando: "Yo no trabajo para una empresa. Soy parte de un programa de expertos. ¿Esto aplica para mí?"

La respuesta es: absolutamente sí.

Como Google Developer Expert, Microsoft MVP, GitHub Star, o miembro de cualquier programa de reconocimiento, no eres empleado de esa empresa. No la representas oficialmente. Pero indirectamente, eres parte del impacto positivo para esa plataforma o tecnología.

Y aunque no lo creas, los mismos pasos aplican:

Habla con tu Program Manager. Explícale tu charla antes del evento. Cuéntale:

• Qué tema vas a presentar

• Qué audiencia esperas

• Cómo conecta con la tecnología o plataforma que evangelizas

• Qué resultados esperas

Tu Program Manager puede:

• Darte materiales actualizados

• Conectarte con el equipo de producto para información reciente

• Ayudarte a alinear tu mensaje con iniciativas actuales

• Amplificar tu presencia a través de canales oficiales

Además, documentar tu impacto te ayuda a mantener tu status en el programa y demuestra el valor que aportas.

Durante el Evento: Maximiza Cada Momento

El evento no empieza cuando subes al escenario. Empieza cuando llegas.

Llega temprano y conecta

Siempre llego al evento con tiempo de sobra. No para revisar mis slides (eso ya debería estar listo), sino para conectar con personas.

Los eventos de tecnología suelen tener actividades la noche anterior: cenas de speakers, happy hours, reuniones informales. Investiga estas actividades y únete a ellas. El networking más valioso sucede en estos espacios, no durante las sesiones.

En el evento mismo, camina por los pasillos. Habla con otros speakers. Conoce a los organizadores. Visita los booths de sponsors. Cada conversación es una oportunidad.

Diferénciate visualmente

En eventos de cientos o miles de personas, necesitas ser memorable. No solo por tu contenido, sino por tu presencia.

Encuentra algo que te haga reconocible:

Mi elemento: Siempre llevo mis lentes de sol. Son parte de mi personal brand. La gente me reconoce por ellos incluso antes de saber mi nombre.

Otros ejemplos que he visto funcionar:

• Sombreros distintivos

• Colores específicos de ropa

• Stickers o pins únicos

• Llevar detalles para regalar (chocolates, por ejemplo)

• Un trípode con cámara para hacer entrevistas (lo he hecho)

El objetivo no es ser extravagante. Es ser memorable en un mar de personas con camisetas negras de tech.

La charla en sí

No voy a profundizar en cómo dar una charla de impacto — eso merece su propio artículo. Pero hay un punto crítico:

Termina con un call-to-action claro.

No termines con "¿preguntas?" y ya. Termina con algo accionable:

• "Escaneen este QR para empezar gratis"

• "Visiten esta URL para el código de ejemplo"

• "Únanse a nuestra comunidad en Discord"

Y asegúrate de que ese CTA esté conectado con tu sistema de atribución.

Post-charla: El momento más importante

Aquí es donde la mayoría de los speakers fallan. Terminan, responden preguntas desde el escenario, y desaparecen.

Error.

Después de tu charla, quédate disponible. Si alguien se acerca a hablarte en persona, esa es una señal de alto interés. Esa persona invirtió energía en buscarte entre la multitud.

Mi proceso post-charla:

1. Escucha activamente. No hables de ti. Pregunta sobre ellos. ¿Qué están construyendo? ¿Qué desafíos tienen?

2. Conecta inmediatamente. LinkedIn, correo, lo que funcione. No dejes que sea "luego te busco" — hazlo en el momento.

3. Toma notas. Después de cada conversación significativa, anoto en mi teléfono: nombre, empresa, de qué hablamos, cómo puedo ayudar.

4. Invierte tiempo. Yo dedico gran parte del tiempo post-charla exclusivamente a hablar con las personas que se me acercan. Es más valioso que ir corriendo a la siguiente sesión.

Las preguntas que te hacen también son oro. Te dicen qué no quedó claro, qué genera más interés, qué pain points resonaron. Esa información mejora tu próxima charla.

Después del Evento: El Follow-Up que Genera Resultados

El evento terminó. Estás agotado. Quieres irte a casa y descansar.

Pero el trabajo más importante empieza ahora.

Haz follow-up en las primeras 48 horas

Las conexiones que hiciste tienen fecha de vencimiento. Mientras más tiempo pase, menos te recordarán.

Para cada persona que conectaste:

• Envía un mensaje personalizado (no genérico)

• Referencia algo específico de su conversación

• Ofrece algo de valor (un recurso, una introducción, ayuda específica)

Ejemplo:

"Hola María, fue genial conocerte en DevRelCon. Me quedé pensando en el challenge que mencionaste sobre integrar auth en tu app. Te comparto este tutorial que creo te puede servir. Si necesitas ayuda, avísame."

Circle back con propósito

No dejes que la conexión muera después del primer mensaje. Haz seguimiento:

• ¿Probaron el producto? ¿Cómo les fue?

• ¿Puedes ayudarles con algo específico?

• ¿Tienen feedback que puedas llevar al equipo de producto?

Estas conversaciones son invaluables. Son feedback real de usuarios potenciales.

Revisa tus KPIs

Recuerda el KPI que definiste antes del evento. Ahora es momento de medirlo:

• ¿Cuántos registros vinieron del URL/código específico de tu charla?

• ¿Hubo incremento en tráfico/signups durante y después del evento?

• ¿Qué feedback cualitativo recibiste?

Haz el reporte interno

Si trabajas para una empresa, tu trabajo no está completo hasta que reportas resultados.

Un buen reporte de evento incluye:

Métricas cuantitativas:

• Asistentes a tu sesión (si tienes el dato)

• Conversiones atribuibles (signups, downloads, etc.)

• Leads recolectados

• Engagement en redes sociales

Insights cualitativos:

• Preguntas más frecuentes (señales de friction o interés)

• Feedback directo de asistentes

• Percepción del producto vs. competencia

• Oportunidades identificadas

Qué funcionó y qué no:

• Aspectos de la charla que resonaron

• Cosas que mejorarías para la próxima vez

• Recomendación sobre participar en este evento de nuevo

Este reporte no solo demuestra tu impacto — te posiciona como alguien que piensa estratégicamente, no solo tácticamente.

Haz debrief con tu equipo

Si asistieron varias personas de tu empresa, organiza una reunión de debrief mientras todo está fresco:

• ¿Qué aprendimos sobre nuestra audiencia?

• ¿Qué feedback escuchamos sobre el producto?

• ¿Qué está haciendo la competencia?

• ¿Qué deberíamos hacer diferente la próxima vez?

Esta cultura de mejora continua es lo que separa a los equipos de DevRel buenos de los excepcionales.

El Sistema Completo

Para resumir, aquí está el sistema completo:

Pre-evento (2-4 semanas antes):

• [ ] Define tu KPI de éxito

• [ ] Estudia la audiencia (pain points, challenges, motivaciones)

• [ ] Alinéate con marketing sobre voz y tono

• [ ] Prepara sistema de atribución (URLs, códigos, etc.)

• [ ] Si eres GDE/MVP/etc., habla con tu Program Manager

• [ ] Investiga actividades de networking pre-evento

Durante el evento:

• [ ] Llega temprano, conecta con personas

• [ ] Asiste a eventos de networking la noche anterior

• [ ] Lleva tu elemento diferenciador

• [ ] Da tu charla con CTA claro

• [ ] Quédate post-charla para conectar con asistentes

• [ ] Conecta en LinkedIn/email en el momento

• [ ] Toma notas de cada conversación significativa

Post-evento (primeras 48-72 horas):

• [ ] Follow-up personalizado a cada conexión

• [ ] Circle back preguntando si probaron el producto

• [ ] Revisa tus KPIs y métricas de atribución

• [ ] Crea el reporte interno

• [ ] Haz debrief con tu equipo

• [ ] Documenta aprendizajes para el próximo evento

Reflexión Final

La diferencia entre un charlista y un conferencista con impacto no está en las habilidades de oratoria. Está en el sistema.

El charlista ve cada evento como un momento aislado. El conferencista ve cada evento como parte de un sistema que genera resultados medibles.

Cuando abordas eventos de esta manera, dejas de ser "la persona que da charlas" y te conviertes en alguien que consistentemente genera valor para tu empresa, tu comunidad, y tu propia carrera.

Y eso te hace invaluable.

¿Tienes un sistema propio para eventos? ¿Qué agregarías? Comparte tu experiencia en nuestra comunidad.

Sitio Web: https://latamdevrel.com
Discord: https://discord.gg/kwugZvJS
LinkedIn: https://www.linkedin.com/company/latamdevrel/

Tags: #devrel #eventos #conferencias #speaking #networking #estrategia

Cada friction log que hago empieza de la misma manera: cállate y observa.

Observa dónde dudan. Observa dónde abren una nueva pestaña para googlear algo que tu documentación debería haber respondido.

Ahí es donde está el oro.

Si quieres ser un DevRel que realmente tiene valor — no solo uno que crea contenido bonito — necesitas desarrollar la habilidad de detectar señales y eliminar fricción. Esta habilidad te convierte en alguien invaluable para cualquier producto que quiera convertir y vender más.

¿Qué Son las Señales (Signals)?

Las señales son indicadores de comportamiento que te dicen lo que los desarrolladores realmente experimentan — no lo que dicen que experimentan, no lo que tú crees que experimentan.

Las señales vienen en muchas formas:

Señales directas (explícitas):

• Un desarrollador te dice "esto es confuso"

• Un ticket de soporte preguntando algo que debería estar en los docs

• Un comentario en el foro pidiendo clarificación

• Feedback negativo en una encuesta

Señales indirectas (implícitas):

• Un desarrollador que abre Google mientras sigue tu tutorial

• Una pausa larga antes de hacer clic en algo

• Scroll repetido entre dos secciones de documentación

• Abandono en un paso específico del onboarding

• Tiempo inusualmente largo en una página que debería ser rápida

Las señales indirectas son más valiosas porque son honestas. La gente no siempre te dice lo que realmente piensa, pero su comportamiento no miente.

¿Qué Es la Fricción?

La fricción es cualquier cosa que ralentiza, frustra o detiene a un desarrollador en su camino hacia el éxito con tu producto.

Puede ser obvia:

• Documentación incompleta o desactualizada

• Errores confusos sin contexto

• Proceso de registro que pide demasiada información

• SDK que requiere 15 pasos para un "Hello World"

O puede ser sutil:

• Terminología inconsistente entre docs y producto

• Ejemplos de código que funcionan pero no explican el "por qué"

• Navegación que no coincide con el modelo mental del desarrollador

• Ausencia de información que el desarrollador asume que debería estar

La fricción sutil es más peligrosa porque es invisible para quienes crearon el producto. Están demasiado cerca. Han visto el código mil veces. Ya no pueden ver lo que un novato no entiende.

Por Qué Esto Te Hace Invaluable

Aquí está la realidad del negocio: cada punto de fricción es un punto donde potencialmente pierdes usuarios.

Si 1,000 desarrolladores visitan tu página de "Getting Started" y solo 300 completan el primer tutorial, tienes un problema de fricción. Esos 700 desarrolladores que abandonaron podrían haber sido clientes, podrían haber recomendado tu producto, podrían haberse convertido en champions de tu comunidad.

Un DevRel que sabe identificar dónde está la fricción y cómo eliminarla está directamente impactando:

• Conversión: Más desarrolladores que prueban → más que adoptan → más que pagan.

• Retención: Menos frustración → menos churn → mayor lifetime value.

• Soporte: Menos fricción → menos tickets → menor costo operativo.

• Reputación: Mejor experiencia → mejores reviews → más referrals orgánicos.

Cuando puedes conectar tu trabajo con estas métricas de negocio, dejas de ser "el que hace videos" y te conviertes en alguien que directamente contribuye al revenue.

El Arte del Friction Logging

Friction logging es el proceso de caminar por el developer journey como si fueras un usuario nuevo, documentando cada momento de confusión, duda o frustración.

No es simplemente "probar el producto". Es una práctica deliberada de observación y documentación.

Cómo hacer un friction log efectivo:

1. Olvida todo lo que sabes

Este es el paso más difícil. Tienes que simular ser alguien que nunca ha visto tu producto. Si llevas meses trabajando con él, considera pedirle a alguien externo que lo haga mientras tú observas.

2. Define el escenario

¿Qué está tratando de lograr este desarrollador? "Quiero integrar la API de pagos en mi app de e-commerce." Ese es el contexto. Todo lo que hagas debe evaluarse contra ese objetivo.

3. Empieza desde cero

No desde tu Developer Hub. Desde Google. ¿Qué buscaría alguien que no conoce tu producto? ¿Qué encuentra? ¿La primera impresión es clara?

4. Documenta TODO

Cada clic, cada duda, cada momento donde piensas "hmm". Usa categorías:

• 🔴 Bloqueador: No puedo continuar sin resolver esto

• 🟡 Fricción alta: Puedo continuar pero estoy frustrado

• 🟢 Fricción menor: Pequeña molestia, no detiene el progreso

• ✨ Positivo: Algo que funcionó mejor de lo esperado

5. Captura el contexto emocional

No solo "la documentación no explica X". Sino "en este punto me sentí perdido porque esperaba encontrar Y pero solo vi Z, lo que me hizo dudar si estaba en el lugar correcto."

6. Incluye timestamps

¿Cuánto tiempo tomó cada paso? El "Time to Hello World" es una métrica crítica. Si tu competidor logra que un desarrollador tenga algo funcionando en 5 minutos y tú tardas 45, tienes un problema.

Dónde Buscar Señales

Las señales están en todas partes si sabes dónde mirar:

Fuentes cuantitativas (datos):

Analytics del Developer Hub:

• ¿Dónde abandonan los usuarios?

• ¿Qué páginas tienen bounce rate alto?

• ¿Cuál es el flujo real vs. el flujo esperado?

• ¿Qué buscan en el search interno que no encuentran?

Métricas de producto:

• Time to first API call

• Completion rate del onboarding

• Drop-off por paso en el flujo de integración

• Errores más comunes en los primeros 7 días

Datos de soporte:

• Tickets más frecuentes

• Preguntas repetidas

• Tiempo de resolución por categoría

Fuentes cualitativas (humanas):

Comunidad:

• Preguntas en Discord/Slack

• Posts en el foro

• Menciones en Stack Overflow

• Discusiones en GitHub Issues

Conversaciones directas:

• Office hours

• Calls con developers

• Feedback en eventos

• Entrevistas de usuario

Observación:

• User testing sessions

• Pair programming con nuevos usuarios

• Hackathons (observa, no solo juzgues)

Mi Proceso: De Señal a Solución

Después de años haciendo esto, he desarrollado un proceso que funciona:

Paso 1: Recolectar señales sistemáticamente

No espero a que las señales lleguen a mí. Tengo sistemas:

• Reviso tickets de soporte semanalmente buscando patrones

• Monitoreo el canal de #help en nuestra comunidad diariamente

• Hago friction logs mensuales del flujo de onboarding

• Tengo calls regulares con el equipo de Customer Success

Paso 2: Categorizar por impacto

No toda fricción es igual. Categorizo por:

• Volumen: ¿Cuántos desarrolladores afecta?

• Severidad: ¿Es bloqueador o solo molestia?

• Posición en el journey: ¿Es al principio (alto impacto en conversión) o al final (menor impacto)?

Paso 3: Identificar la causa raíz

La señal es el síntoma, no la enfermedad. Si muchos developers preguntan "¿cómo autentico?", el problema puede ser:

• La documentación de auth está mal escrita

• La documentación está bien pero es difícil de encontrar

• El flujo de auth es inherentemente confuso

• El error message cuando falla no es útil

Cada causa raíz requiere una solución diferente.

Paso 4: Proponer soluciones priorizadas

Presento opciones al equipo:

• Quick win: Actualizar el error message (1 día de trabajo)

• Medio plazo: Reescribir la sección de auth en docs (1 semana)

• Largo plazo: Rediseñar el flujo de auth en el producto (1 mes+)

Paso 5: Medir el impacto

Después de implementar, vuelvo a medir:

• ¿Bajaron los tickets sobre este tema?

• ¿Mejoró el completion rate de ese paso?

• ¿Cambió el feedback cualitativo?

Sin medición, no sabes si realmente resolviste algo.

Ejemplo Real: Los 500 Videos en Appsmith

En Appsmith produje más de 500 videos. Pero no empecé diciendo "voy a hacer 500 videos". Empecé observando señales.

La señal: El equipo de soporte recibía las mismas preguntas una y otra vez. "¿Cómo conecto a una base de datos?" "¿Cómo hago un formulario con validación?" "¿Cómo despliego mi app?"

El diagnóstico: La documentación escrita existía, pero muchos desarrolladores preferían ver el proceso. Además, algunos conceptos eran más fáciles de entender viendo a alguien hacerlo.

La solución: Videos cortos, enfocados en UN problema específico, optimizados para ser encontrados cuando alguien busca exactamente esa pregunta.

El resultado: Reducción significativa en tickets de soporte sobre esos temas. Los videos no solo educaban — reducían carga operativa del equipo de soporte.

Eso es impacto de negocio medible. No "hice 500 videos" sino "reduje tickets de soporte en X% a través de contenido educativo estratégico."

La Conexión con Ventas y Conversión

Aquí es donde muchos DevRels no conectan los puntos: la fricción en el developer journey directamente impacta el revenue.

Piensa en el funnel:

1,000 developers visitan tu landing page ↓ (20% continúan) 200 developers llegan al signup ↓ (50% completan registro) 100 developers crean una cuenta ↓ (30% completan onboarding) 30 developers llegan a "Hello World" ↓ (20% continúan a uso real) 6 developers se convierten en usuarios activos ↓ (30% convierten a pago) 2 developers se convierten en clientes

De 1,000 a 2. Cada punto de fricción en ese camino es una oportunidad de mejora.

Si mejoras el onboarding de 30% a 50% completion, pasas de 30 a 50 developers en "Hello World", lo que potencialmente duplica tus clientes finales.

Un DevRel que entiende esto y puede identificar dónde está la fricción más costosa es un DevRel que habla el idioma del negocio.

Cómo Comunicar Esto a Stakeholders

Cuando presento hallazgos de fricción, no digo "la documentación es confusa". Digo:

"Identificamos que el 40% de los desarrolladores abandonan en el paso 3 del onboarding. A través de friction logging y análisis de tickets de soporte, encontramos que el error message en ese paso no da contexto suficiente para resolver el problema. Propongo tres soluciones con diferentes niveles de esfuerzo, y estimo que resolver esto podría mejorar el completion rate entre 10-15%, lo que representaría aproximadamente X nuevos usuarios activos por mes."

Eso es diferente. Eso es estratégico. Eso te posiciona como alguien que entiende el negocio.

Herramientas y Frameworks Útiles

Para analytics:

• Google Analytics / Mixpanel / Amplitude (comportamiento en web)

• PostHog / Heap (product analytics)

• FullStory / Hotjar (session recordings, heatmaps)

Para feedback:

• Typeform / SurveyMonkey (encuestas)

• Intercom / Zendesk (tickets de soporte)

• Discord / Slack (comunidad)

Para documentar:

• Notion / Coda (friction logs internos)

• Loom (grabar sesiones de friction logging)

• Miro / FigJam (mapear el journey visualmente)

Métrica clave a trackear:

• Time to Hello World

• Completion rate por paso del onboarding

• Ticket volume por categoría

• NPS de la experiencia de desarrollador

El Mindset del DevRel Orientado a Señales

Los ingenieros que construyen grandes productos son los que mantienen curiosidad sobre los humanos que los usan.

Lo mismo aplica para DevRel. Los mejores DevRels que conozco tienen estas características:

• Curiosidad incansable: Siempre preguntan "¿por qué?" cuando ven un comportamiento inesperado.

• Empatía genuina: Pueden ponerse en los zapatos de alguien que nunca ha visto el producto.

• Pensamiento sistémico: Ven patrones, no incidentes aislados.

• Orientación a datos: No asumen — miden y validan.

• Comunicación de negocio: Pueden traducir hallazgos técnicos a impacto de revenue.

Reflexión Final

Cualquiera puede crear contenido. Cualquiera puede dar una charla. Cualquiera puede responder preguntas en un foro.

Pero pocos pueden observar sistemáticamente dónde están las paredes invisibles que frustran a los desarrolladores, diagnosticar las causas raíz, proponer soluciones priorizadas, y medir el impacto de esas soluciones en métricas que importan al negocio.

Esa habilidad — detectar señales, eliminar fricción, conectar con impacto de negocio — es lo que separa a los DevRels buenos de los excepcionales.

La próxima vez que un desarrollador suspire mientras usa tu producto, presta atención. Ahí hay una oportunidad de crear valor real.

¿Has implementado friction logging en tu trabajo? ¿Qué señales has descubierto? Comparte tu experiencia en nuestra comunidad.

Sitio Web: https://latamdevrel.com
Discord: https://discord.gg/kwugZvJS
LinkedIn: https://www.linkedin.com/company/latamdevrel/

Tags: #devrel #developer-experience #fricción #producto #métricas #estrategia

La mayoría de las personas que quieren entrar a DevRel piensan en habilidades como escribir, hablar en público, crear videos, o construir comunidad. Todas son importantes. Pero si no entiendes el contexto de negocio en el que operas, terminarás ejecutando tácticas sin saber si realmente están moviendo la aguja.

Entender Product-Market Fit te da una ventaja que pocos tienen: la capacidad de pensar como un estratega, no solo como un ejecutor.

¿Qué es Product-Market Fit?

Product-Market Fit (PMF) es el punto donde tu producto satisface una demanda real del mercado. Es cuando los usuarios no solo prueban tu producto, sino que lo adoptan, lo recomiendan, y se frustran cuando algo no funciona porque ya dependen de él.

Marc Andreessen, cofundador de Andreessen Horowitz, lo describió así: "Product-Market Fit significa estar en un buen mercado con un producto que puede satisfacer ese mercado."

Suena como algo que solo debería importarle a founders y product managers. Pero para DevRel, entender PMF cambia completamente cómo abordas tu trabajo.

Por Qué PMF Importa Para Tu Carrera en DevRel

Cuando entiendes en qué etapa de PMF está una empresa, puedes:

1. Elegir mejor dónde trabajar

No todas las oportunidades de DevRel son iguales. Una startup pre-seed buscando su primer DevRel tiene necesidades completamente diferentes a una empresa Series C escalando su comunidad. Si no sabes distinguirlas, podrías terminar en un rol donde las condiciones no te permiten tener éxito, sin importar tu talento.

2. Adaptar tu enfoque según el contexto

En una empresa que aún busca PMF, tu rol está más cercano a producto — recopilar feedback, hablar con los pocos usuarios activos, iterar junto con el equipo de ingeniería. En una empresa con PMF validado, puedes enfocarte en escalar: más contenido, más eventos, más alcance.

3. Establecer expectativas realistas

Cuando entiendes la etapa de la empresa, puedes proponer métricas y objetivos que tengan sentido. No vas a prometer 10,000 nuevos usuarios si el producto todavía está pivoteando. Esto te protege y te hace ver más profesional ante los stakeholders.

4. Tener conversaciones estratégicas

En lugar de solo recibir instrucciones ("necesitamos más blogs", "haz un video sobre X"), puedes participar en discusiones sobre prioridades, timing, y cómo DevRel se conecta con los objetivos de negocio. Esto te posiciona como un partner estratégico, no solo como un creador de contenido.

5. Demostrar ROI de formas que importan

Porque sabes qué métricas son relevantes en cada etapa, puedes alinear tu trabajo con lo que realmente le importa a la empresa. Esto te hace invaluable cuando llegan los momentos de justificar presupuesto o headcount.

Las Etapas de PMF y Cómo Cambia el Rol de DevRel

Para aplicar este conocimiento, necesitas entender cómo se ve cada etapa y qué tipo de trabajo DevRel tiene más impacto en cada una.

Pre-PMF (Pre-seed / Seed)

Contexto: El producto está en desarrollo activo. El equipo está experimentando, iterando, buscando los primeros usuarios que realmente encuentren valor. El producto puede cambiar significativamente cada pocas semanas.

Qué tipo de DevRel tiene impacto aquí:

• Conversaciones 1:1 con los pocos usuarios activos

• Feedback loops directos con producto

• Documentación básica que evoluciona con el producto

• Participación en comunidades existentes (no crear una propia todavía)

Mentalidad: Más cercano a producto que a marketing. El objetivo es aprender, no escalar.

PMF Inicial (Series A)

Contexto: Hay señales claras de que algo funciona. Usuarios que regresan, que recomiendan, que dependen del producto. El equipo puede articular para quién es el producto y qué problema resuelve.

Qué tipo de DevRel tiene impacto aquí:

• Establecer sistemas y frameworks (estructura de docs, templates de contenido)

• Crear los primeros recursos educativos de alta calidad

• Empezar a construir comunidad con intención

• Feedback loops formalizados entre comunidad y producto

Mentalidad: Construir las bases para escalar. Calidad sobre cantidad.

PMF Validado (Series B/C)

Contexto: El producto tiene tracción real. Casos de uso claros y repetibles. El crecimiento es predecible. Es momento de escalar.

Qué tipo de DevRel tiene impacto aquí:

• Contenido a escala (videos, tutoriales, blogs, webinars)

• Presencia en eventos y conferencias

• Programas de community champions o embajadores

• Integraciones y partnerships con otras herramientas

Mentalidad: Amplificar lo que funciona. Escalar awareness y adopción.

Post-PMF (Series D+ / IPO / Enterprise)

Contexto: Producto establecido, millones de usuarios, casos de uso enterprise. La estabilidad permite planificación a largo plazo.

Qué tipo de DevRel tiene impacto aquí:

• Programas de certificación

• Ecosistema de integraciones y partnerships

• Eventos propios (conferencias de usuario)

• Trabajo con enterprise y Fortune 500

• Equipos especializados (education, community, advocacy)

Mentalidad: Sofisticación y profundidad. Construir ecosistema.

Mi Experiencia en Diferentes Etapas

He tenido la fortuna de trabajar en distintos puntos del espectro, y la diferencia en cómo abordo el trabajo es notable.

En Appsmith (Series B):

Cuando entré, Appsmith ya había encontrado su PMF. Sabían exactamente qué problema resolvían (construir aplicaciones internas rápidamente), para quién (desarrolladores en empresas que necesitan herramientas internas), y tenían una comunidad activa de más de 1,000 miembros.

Mi trabajo fue claro: escalar lo que ya funcionaba. Crecimos la comunidad de 1,000 a más de 16,000 miembros. Produje más de 500 videos. Pude planificar contenido con confianza porque el producto tenía una identidad estable.

Sabía que cada video que creaba iba a seguir siendo relevante en 6 meses. Esa certeza me permitió invertir en calidad y construir una biblioteca de recursos que generaba valor compuesto con el tiempo.

En Asana (post-IPO):

El contexto es completamente diferente. Asana tiene PMF validado por años de operación, millones de usuarios, y casos de uso enterprise probados.

Mi enfoque no es validar si el producto funciona — es expandir hacia nuevas audiencias de desarrolladores, construir integraciones, y trabajar con partners Fortune 500. La escala y sofisticación del trabajo es diferente.

La estabilidad me permite crear contenido con horizontes de tiempo más largos. Puedo construir relaciones profundas con la comunidad y planificar iniciativas que toman meses en madurar.

La lección: Mi skillset es el mismo en ambos casos. Lo que cambia es cómo lo aplico según el contexto. Entender PMF me permite adaptar mi enfoque para maximizar impacto.

Cómo Evaluar el PMF de una Empresa

Ya sea que estés evaluando un rol o quieras entender mejor tu empresa actual, estas señales te ayudan a identificar dónde están:

Señales de que SÍ hay PMF:

→ Los usuarios regresan sin que nadie les recuerde. La retención es orgánica.

→ El crecimiento viene principalmente de word-of-mouth, no de paid ads.

→ Los usuarios se frustran cuando algo no funciona. Les importa porque dependen del producto.

→ Hay casos de uso claros y repetibles. No cada usuario usa el producto de forma completamente diferente.

→ El equipo puede articular claramente para quién es el producto y qué problema resuelve.

→ La propuesta de valor no cambia cada mes.

Señales de que aún buscan PMF:

→ El producto cambia significativamente cada pocas semanas.

→ Cada usuario parece tener un caso de uso diferente.

→ La retención es baja y nadie sabe exactamente por qué.

→ El pitch del producto cambia dependiendo de quién lo presenta.

→ Los fundadores todavía están "descubriendo" quién es el usuario ideal.

→ Mucha experimentación, poca repetibilidad.

Ninguna de estas situaciones es "mala" — son etapas naturales de una empresa. Lo importante es que tú sepas en cuál estás para adaptar tu trabajo.

El Error Común (Y Cómo Evitarlo)

Vale la pena mencionar un patrón que se repite: empresas que contratan DevRel antes de tener PMF, esperando que DevRel ayude a encontrarlo.

Esto pone al profesional DevRel en una posición casi imposible: se le pide construir comunidad y generar awareness de un producto que aún no ha demostrado valor en el mercado.

Si te encuentras evaluando un rol así, no necesariamente debes rechazarlo — pero debes entrar con expectativas claras. Tu trabajo estará más cercano a producto que a marketing. Deberás ser flexible y cómodo con la ambigüedad. Y deberás establecer métricas apropiadas para la etapa.

La clave es que tú entiendas el contexto, aunque la empresa no lo articule claramente. Eso te permite negociar expectativas realistas y proteger tu propio éxito.

Preguntas Para Evaluar una Oportunidad de DevRel

Cuando estés en una entrevista o evaluando un rol, estas preguntas te ayudan a entender el contexto:

1. ¿Cuántos usuarios activos tienen actualmente? ¿Cuál es la retención?

2. ¿De dónde viene la mayoría de sus usuarios? ¿Orgánico o pagado?

3. ¿Pueden describir su usuario ideal sin dudar?

4. ¿El producto ha pivoteado significativamente en los últimos 6-12 meses?

5. ¿Qué esperan que DevRel logre en los primeros 6 meses?

6. ¿Hay un equipo de producto con el que trabajaría directamente?

7. ¿Cuál es la etapa de funding actual?

Las respuestas te permitirán ubicar a la empresa en el espectro de PMF y decidir si el rol es adecuado para ti y tu estilo de trabajo.

Esto Te Diferencia del 90% de Candidatos

La realidad es que la mayoría de personas que quieren entrar a DevRel piensan solo en tácticas: "Sé escribir blogs", "Puedo dar charlas", "Tengo seguidores en Twitter".

Todas esas habilidades son valiosas. Pero cuando puedes entrar a una conversación y hablar sobre PMF, etapas de empresa, y cómo adaptar la estrategia DevRel según el contexto... estás jugando en otra liga.

Los hiring managers notan la diferencia. Los founders notan la diferencia. Te posicionas no como alguien que ejecuta tareas, sino como alguien que entiende el negocio y puede contribuir estratégicamente.

Y una vez que estás dentro, ese conocimiento te permite navegar la organización, alinear tu trabajo con lo que importa, y demostrar valor de formas que otros no pueden.

Reflexión Final

Product-Market Fit no es solo un concepto para founders y VCs. Es un framework que te hace mejor profesional de DevRel.

Te permite elegir mejor dónde trabajar. Te permite adaptar tu enfoque. Te permite establecer expectativas realistas. Te permite tener conversaciones estratégicas. Te permite demostrar ROI.

La próxima vez que evalúes una oportunidad de DevRel o quieras entender mejor tu rol actual, pregúntate: ¿En qué etapa de PMF está esta empresa? La respuesta te dirá mucho sobre qué tipo de trabajo va a tener impacto real.

Ese conocimiento es lo que separa a los DevRels que ejecutan de los DevRels que lideran.

¿Tienes experiencias sobre PMF y DevRel que quieras compartir? Únete a la conversación en nuestra comunidad.

Sitio Web: https://latamdevrel.com
LinkedIn: https://www.linkedin.com/company/latamdevrel/

Enero de 2026 marca varios años desde que me convertí en Developer Advocate profesional. Durante este tiempo he tenido la oportunidad de trabajar tanto en startups en etapa Series B como Appsmith, hasta colaborar con corporaciones globales como IBM, Google, Microsoft, Nintendo y Nike. Ha sido un viaje intenso, lleno de aprendizajes, y sin duda el trabajo más gratificante que he tenido.

Mientras escribo este artículo, estoy preparando mi próxima charla para All Things Open AI 2026 en Durham, North Carolina, así como mi presentación para Google Cloud Next 2026 en Las Vegas. Durante mi carrera como speaker he tenido el privilegio de dar conferencias en multiples ciudades en varios continentes y en cada evento, sin falta, alguien se me acerca y me pregunta: "¿Cómo puedo entrar a DevRel?"

No los culpo. Es un rol increíble para quienes disfrutan lo que implica: la mezcla de tecnología, comunicación, comunidad y el privilegio de ayudar a otros desarrolladores a crecer.

En este artículo voy a compartir lo que he aprendido en mi camino — desde mis inicios en Costa Rica con acceso limitado a tecnología, hasta ser Keynote Speaker y viajar por muchas ciudades educando a la nueva generación de tecnólogos. Estas lecciones vienen de mi experiencia personal y de observar a otros profesionales exitosos en este espacio. No es la única forma de entrar a DevRel, pero sí es un camino probado.

1. Aprende a escribir (y hazlo constantemente)

Cuando digo "aprende a escribir", no me refiero a que necesitas ser un perfeccionista gramatical o tener un estilo literario impecable.

Lo que quiero decir es que debes sentirte cómodo volcando tus ideas en una página. Para mí, esto vino con mucha práctica. Me hice el hábito de documentar todo lo que aprendía — tanto en forma de artículos de blog como en READMEs detallados en GitHub.

Escribir te obliga a entender las ideas a un nivel más profundo. Una cosa es poder hacer algo tú mismo, y otra muy diferente es explicárselo a alguien más. Cuando escribes, te enfrentas a las preguntas que aún no sabes responder. Te fuerza a investigar a fondo.

Mi experiencia personal: Uno de mis primeros artículos sobre Headless Drupal hace 13 años tuvo apenas 20 lecturas iniciales. Me sentí frustrado. Tres años después, ese mismo artículo fue citado por uno de los desarrolladores Drupal más reconocidos del mundo en su libro, lo que resultó en una invitación a hablar en DrupalCon. La moraleja: no te desanimes por las métricas iniciales. El contenido evergreen trabaja para ti mientras duermes.

Además, una de las habilidades más importantes en DevRel es la comunicación. Estarás constantemente comunicándote con tu equipo, otros desarrolladores, líderes de comunidad, organizadores de conferencias y muchos más. La gran mayoría de esta comunicación será escrita — tweets, emails, mensajes directos, documentación. Ser un escritor competente amplifica todo lo demás que hagas.

2. Construye puentes, no muros

Una de las charlas más influyentes que he visto fue de Aaron Frost en NG Vegas 2015, titulada "Building Bridges". Su mensaje era simple pero poderoso: otras personas pavimentaron el camino hacia su éxito, y ahora que él tiene la oportunidad, está pagando esa deuda hacia adelante.

La razón por la que muchos de nosotros estamos donde estamos hoy es por el trabajo de otros: los tutoriales que crearon, los proyectos open source que mantuvieron, las preguntas que respondieron en Stack Overflow. La idea es construir puentes y pagar hacia adelante cuando estés en posición de hacerlo.

Mi experiencia personal: Cuando empecé en el ecosistema Drupal, encontré verdadera pasión en contribuir de vuelta a la comunidad. Era increíble ver cómo desarrolladores brillantes eran súper humildes y extremadamente serviciales para sentarse conmigo y explicar las cosas. Eso me marcó profundamente. Hoy, esa misma filosofía guía todo lo que hago — desde mentorías gratuitas hasta organizar meetups y crear contenido educativo.

Dependiendo de tu nivel de experiencia, construir puentes puede verse de muchas formas: mentoría uno a uno, escribir artículos sobre lo que aprendes, organizar o apoyar meetups locales, responder preguntas en foros, contribuir a proyectos open source. Esta filosofía en acción ES lo que Developer Relations significa en esencia.

3. No te cases con una tecnología específica

Muchas personas entran a DevRel porque son especialistas en algo. Yo era (y sigo siendo) muy activo en ciertas comunidades tecnológicas. Pero esto es algo que debes mantener bajo control.

Cuando entras a DevRel, uno de los aspectos más importantes es construir confianza. No hay forma de fingir autenticidad.

Ser demasiado leal a una tecnología específica o a una forma particular de hacer las cosas te hará perder perspectiva del objetivo general. Nuestro trabajo NO es mostrar amor incondicional por nuestro framework o lenguaje favorito.

Mi experiencia personal: En mi carrera he trabajado con Drupal, Wordpress, Jommla, React, Angular, Vue Node.js, Java Spring, PHP, Ruby, Google Cloud, Azure, IBM Cloud, AWS, herramientas low-code como Appsmith y AppSheet, y muchas otras más, como puedes ver muchas de ellas son “competencias entre si” y dependiendo del proyecto una sirve más que la otra. Esta diversidad me ha permitido ver patrones que trascienden tecnologías específicas y me ha hecho más valioso para las empresas donde he trabajado.

Aprende a ser curioso sobre tecnologías competidoras. Muchas veces descubrirás que puedes aprender mucho de su enfoque, o incluso que te gusta más su forma de hacer las cosas. Cuando diriges un podcast, newsletter o comunidad, estás pidiendo a las personas que te den su confianza. Cuando muestras sesgo o impides que otras ideas sean escuchadas, le haces un daño a tu comunidad.

El objetivo no es promover lo que te gusta — es habilitar a las personas para que construyan cosas, resuelvan sus problemas y avancen en sus carreras.

4. Entiende el negocio: Go-to-Market y Difusión de Innovación

Aquí es donde muchos aspirantes a DevRel se quedan cortos. Esta es la diferencia entre ser un creador de contenidos o un verdadero Developer Advocate con madera para ser contratado por una empresa. Para tener conversaciones de valor con tu empresa y realmente aportar estratégicamente, necesitas entender conceptos fundamentales de producto y negocio.

La Ley de Difusión de Innovación

Este modelo, desarrollado por Everett Rogers, explica cómo las nuevas ideas y tecnologías se adoptan a través de una población:

Los cinco grupos de adoptantes:

• Innovators (2.5%): Los primeros en probar tecnología nueva, aunque no esté probada. Son tomadores de riesgo.

• Early Adopters (13.5%): Líderes de opinión que adoptan temprano y ayudan a normalizar la innovación para otros.

• Early Majority (34%): Individuos prudentes que adoptan después de ver evidencia de utilidad.

• Late Majority (34%): Consumidores escépticos que adoptan solo después de que la mayoría lo ha hecho.

• Laggards (16%): Tradicionalistas, resistentes al cambio, los últimos en adoptar.

El Tipping Point: Existe un punto crítico (aproximadamente 15-18% de penetración de mercado) donde una innovación pasa de ser un nicho a convertirse en mainstream. Como DevRel, tu trabajo frecuentemente es ayudar a cruzar ese abismo entre Early Adopters y Early Majority.

¿Por qué importa esto para DevRel? Porque tu estrategia debe adaptarse según dónde esté tu producto en esta curva. Si estás trabajando para una startup en etapa seed, tu audiencia principal son Innovators y Early Adopters — desarrolladores que disfrutan experimentar con tecnología emergente. Si estás en una corporación establecida, probablemente estés enfocándote en Early y Late Majority, donde necesitas demostrar casos de uso probados y estabilidad.

Entiende la etapa de tu empresa

La posición de crecimiento de tu empresa (pre-seed, seed, Series A, B, C, IPO) debe informar tu estrategia de DevRel:

• Pre-seed/Seed: Enfócate en construir comunidad inicial, feedback loops con el producto, contenido que valide el problema que resuelves.

• Series A/B: Escala tu alcance, establece métricas claras, construye relaciones con influencers del ecosistema.

• Series C+/IPO: Enfócate en enterprise, partnerships estratégicos, programas de certificación, ecosistema de integraciones.

Mi experiencia personal: En Appsmith, una startup Series B, mi enfoque fue muy diferente a mi rol actual en Asana. En la startup, me concentré en crecer la comunidad de 3,000 a más de 20,000 miembros y producir contenido que incrementara nuestro awareness, mi rol era rapidez, tenía mas capacidad de hacer prueba y error. En Asana, mi enfoque es más enterprise, debo tomar en cuenta un numero grande de partners y casos de uso de clientes Fortune 500.

5. Aprende lo básico de Marketing (aunque no seas marketer)

Nuestro rol no es 100% marketing, pero cruza muchas metas con el equipo de marketing de un producto tecnológico. Ignorar esto te pone en desventaja.

Conceptos que debes dominar:

MQLs (Marketing Qualified Leads): Entiende cómo el contenido que creas puede contribuir al pipeline de ventas. No porque vayas a vender directamente, sino porque necesitas hablar el mismo idioma que tus stakeholders.

Posicionamiento: Mi libro favorito es "Las 22 Leyes Inmutables del Marketing" de Al Ries y Jack Trout. Aunque tiene años, los principios fundamentales siguen vigentes. Algunas leyes que aplican directamente a DevRel:

• Ley del Liderazgo: Es mejor ser el primero que ser el mejor. Si tu producto no es el primero en una categoría, crea una nueva categoría donde puedas ser primero.

• Ley de la Categoría: Si no puedes ser el primero en una categoría, crea una nueva en la que puedas serlo.

• Ley de la Mente: Es mejor ser el primero en la mente del cliente que el primero en el mercado.

• Ley de la Percepción: El marketing no es una batalla de productos, es una batalla de percepciones.

¿Por qué importa para DevRel? Porque cuando creas contenido, cuando das charlas, cuando construyes comunidad, estás participando activamente en el posicionamiento de tu producto. Si no entiendes estos principios, podrías estar trabajando en contra de los objetivos de tu empresa sin darte cuenta.

6. Las métricas son tu mejor aliado (y tu escudo)

Este es quizás el consejo más importante y el menos discutido: DevRel va MUCHO más allá de crear contenido, dar charlas o ir a eventos.

Cada una de estas actividades debe tener pre-planeamiento con diferentes equipos — producto, ventas, marketing, soporte — para tener:

• Metas claras

• Audiencia meta definida

• User personas específicas

• Métricas de éxito establecidas ANTES de ejecutar

Por qué las métricas te protegen

En tiempos de recortes presupuestarios (y créeme, DevRel suele ser uno de los primeros equipos en ser cuestionados), las métricas son tu escudo. Si puedes demostrar que:

• Tu video tutorial redujo los tickets de soporte en un 30%

• Tu charla en la conferencia X generó Y nuevos usuarios registrados

• Tu comunidad tiene Z% de tasa de activación hacia producto de pago

...entonces tienes argumentos concretos para defender tu posición y tu equipo.

Tipos de métricas que debes trackear:

Awareness/Alcance:

• Impresiones y alcance de contenido

• Seguidores y crecimiento de comunidad

• Menciones de marca

Engagement:

• Tiempo de visualización (no solo views)

• Comentarios y discusiones generadas

• Contribuciones de la comunidad

Conversión:

• Signups atribuibles a tu contenido

• Usuarios activos de la comunidad que convierten a producto

• Reducción de tickets de soporte

Retención:

• Net Promoter Score de la comunidad

• Tasa de retención de miembros activos

• Advocacy generado (miembros que crean contenido propio)

Mi experiencia personal

En Appsmith produje más de 500 videos. Pero el número de videos no es la métrica que importa. Lo que importa es que esos videos redujeron significativamente los tickets de soporte — eso es ROI tangible que cualquier ejecutivo puede entender.

He tenido videos con pocas vistas pero altísimo viewership (la gente que los ve, los ve completos) que resolvieron problemas específicos de usuarios. Esos "fracasos" en métricas de vanidad fueron éxitos rotundos en métricas de negocio.

La lección: No te dejes engañar por métricas de vanidad. Un artículo con 20 lecturas que posiciona tu producto correctamente en la mente de los 20 decision-makers correctos vale más que un artículo viral que no convierte a nadie.

7. Aprende a hablar en público

Este parece obvio, ¿verdad? Pero, ¿cómo empezar?

Yo comencé hablando en meetups locales en Costa Rica. Estos son lugares perfectos para iniciar porque las audiencias suelen ser pequeñas. No han invertido mucho dinero para asistir, así que serán menos críticos si tienes algún tropiezo.

También existen grupos de Toastmasters (sí, algo nerds pero increíbles 🤓) que se dedican específicamente a ayudar a las personas a practicar oratoria y mejorar sus habilidades de comunicación.

Las lightning talks (charlas relámpago de 5 minutos) son excelentes para empezar porque es mucho más fácil preparar 5 minutos que 50 minutos de material. Ganarás experiencia hablando en un evento "real" y podrás usar esa referencia para aplicar a eventos más grandes.

Mi consejo: Prepara lo que yo llamo una charla "production-ready" — algo que practiques hasta conocerlo como la palma de tu mano, con un título y descripción pulidos. Puedes usar esta misma charla para aplicar a docenas de eventos. Si te aceptan en más de uno, no tendrás tanto estrés porque ya dominas el material, y ganarás experiencia valiosa.

Un secreto sobre hablar en público: Nunca se vuelve completamente fácil. Se vuelve MÁS fácil, pero probablemente nunca caminarás frente a una audiencia sin sentir al menos algo de ansiedad. He hablado con muchos speakers experimentados que sienten lo mismo. La clave es, como dice Nike, Just Do It. Una vez que abres la boca y empiezas a hablar, la ansiedad comienza a disiparse.

Mi experiencia personal: Hoy en día he sido Keynote Speaker en eventos como Google I/O, DevRelCon, DrupalCon, Nerdearla, etc Pero empecé exactamente igual que todos — nervioso, en meetups pequeños, aprendiendo de mis errores. La diferencia está en la persistencia, he participado en más de 100 “Drupeleadas” que son meetups pequeños mensuales de la comunidad Drupal en Costa Rica, muchas de ellas fueron pésimas, otras un poco mejor.

8. Enseña mientras aprendes

Recuerdo vívidamente escribir mi primer artículo técnico "serio". Estaba aprendiendo algo nuevo, luchando con la documentación, y mientras avanzaba, fui escribiendo lo que entendía. Antes de darme cuenta, tenía algo digno de compartir.

Cuando escribí ese artículo, de ninguna manera era un experto. Pero docenas de personas me contactaron diciéndome cuánto habían aprendido de él.

Esto conecta con el primer punto: enseñar o escribir sobre algo te fuerza a entenderlo a un nivel a veces incómodo, lo cual es bueno si tu objetivo es ayudar a otros a entenderlo también.

El concepto de "Learn in Public" (Aprender en Público), popularizado por Shawn "Swyx" Wang, es algo que deberías considerar adoptar. La idea es compartir tu proceso de aprendizaje públicamente — tus dudas, tus descubrimientos, tus errores. Esto no solo te ayuda a ti, sino que ayuda a otros que están en el mismo camino.

9. Alienta a otros constantemente

Una de las cosas más fáciles que podemos hacer, especialmente con la cantidad de negatividad que existe en el mundo hoy, es levantar a las personas y alentarlas. Esto se vuelve especialmente importante a medida que creces tu red y tienes la oportunidad de ayudar a quienes tienen menos voz o menos privilegios.

Ser una de esas personas que es incansablemente servicial y alentadora no solo te beneficiará como miembro de la comunidad, sino que genuinamente ayudarás a personas a superar barreras mentales, conseguir trabajos, obtener contratos de freelance — incluso ayudarles a compartir su propio conocimiento e ideas.

Lo más importante a recordar: Tu trabajo principal en DevRel es habilitar y abogar en nombre de otros desarrolladores y miembros de la comunidad, NO de la empresa que eventualmente te contrate. Sí, trabajas para una empresa, pero tu lealtad principal es hacia la comunidad.

10. Actúa como si ya fueras DevRel

El punto más importante de todos: simplemente empieza a SER uno, independientemente de tu rol actual.

Sigue a otras personas haciendo lo que te gustaría hacer. Aprende de ellas. Empieza a hacer lo que ellas hacen — escribe, habla, contribuye, construye comunidad.

Si haces esto, ya estás en camino a conseguir el rol. Cuando apliques o tengas una entrevista, será obvio que ya tienes un track record.

Mi experiencia personal: Antes de tener el título oficial de "Developer Advocate", ya estaba haciendo el trabajo. Escribía artículos, daba charlas, contribuía a proyectos open source, ayudaba a otros desarrolladores. Cuando llegó la oportunidad formal, fue una transición natural porque ya había demostrado que podía hacer el trabajo.

Reflexión final

La mayoría de la gente piensa que DevRel significa que tu título debe ser "Developer Advocate" o "Developer Evangelist". Esto no es cierto. Hay cada vez más personas en roles tradicionalmente de ingeniería que también asumen el rol de advocate. Muchas veces, estas personas usan su talento y posición en la comunidad como una oportunidad para ayudar a otros.

Ayudar y empoderar a las personas es de lo que se trata este rol, pero con inteligencia, planeamiento, estrategia y métricas de por medio.

Si estás leyendo esto y sientes que DevRel es para ti, empieza hoy. No esperes permiso. No esperes el título oficial. Empieza a construir puentes, a escribir, a enseñar, a alentar. El rol llegará como consecuencia natural de hacer el trabajo.

¿Tienes preguntas sobre cómo entrar a DevRel? Conéctate conmigo en LinkedIn y únete a nuestra comunidad.

1. 1. Sitio Web: https://latamdevrel.com

      2. Youtube: https://www.youtube.com/@LATAMDevRel

      3. Grupo de LinkedIn: https://www.linkedin.com/groups/12880221/

      4. LinkedIn: https://www.linkedin.com/company/latamdevrel/

      5. Twitch: https://www.twitch.tv/latinodevrel

2. Comparte tus experiences y únete a la conversación en el nuestro chat de discord: https://discord.gg/kwugZvJS

Para tu sorpresa, recibes una respuesta rápida y detallada de alguien que se identifica como parte del equipo de la plataforma. No solo te ayudan a resolver tu problema, sino que también te invitan a un evento local donde podrás conocer a otros desarrolladores y aprender más sobre las últimas características de la plataforma, además, te da acceso a una librería de videos más detallados sobre la plataforma para que aprendas a más profundidad sobre ciertas herramientas que te pueden servir en tu día a día.

Impresionada por la experiencia, decides asistir al evento. Allí, conoces a María, una Developer Advocate de la empresa. María no solo entiende perfectamente tus desafíos técnicos, sino que también está genuinamente interesada en tu proyecto. Te presenta a otros miembros del equipo, incluyendo ingenieros que trabajan en las características que más te interesan.

Semanas después, recibes un correo electrónico de María. La empresa está considerando una nueva funcionalidad y quieren tu opinión, a cambio de tu tiempo y opinión te enviaron una mochila y camisa de la empresa. Te sientes valorada, escuchada y parte de algo más grande que tu propio proyecto.

Esta experiencia que has vivido como Ana es DevRel en acción.

Developer Relations, o DevRel, es mucho más que un departamento en una empresa de tecnología. Es una filosofía, una estrategia y un conjunto de prácticas diseñadas para crear conexiones significativas entre las empresas y los desarrolladores que utilizan sus productos o plataformas.

En su núcleo, DevRel se trata de construir y nutrir una comunidad. Es reconocer que los desarrolladores no son solo usuarios o clientes, sino colaboradores valiosos en el ecosistema tecnológico. A través de DevRel, las empresas no solo promocionan sus productos, sino que crean un ambiente donde los desarrolladores pueden crecer, aprender y contribuir.

El ejemplo de Ana ilustra los diversos aspectos de DevRel:

1. Soporte comunitario: La ayuda inicial en el foro, pero podría iniciar en otros medios.

2. Educación y eventos: La invitación al evento local donde puedes conectar en persona.

3. Networking: La conexión con otros desarrolladores y el equipo de la empresa es clave, da un sentimiento de pertenencia.

4. Advocacy: María actuando como puente entre Ana y la empresa, y puede que en el futuro María sea ella misma una Advocate del programa de la empresa.

5. Feedback y co-creación: La solicitud de opinión sobre nuevas características, escuchar activamente a las personas que usan el producto.

En un mundo donde el software está en el corazón de casi todos los aspectos de nuestras vidas, DevRel juega un papel crucial en la forma en que se desarrolla y evoluciona la tecnología. No se trata solo de vender un producto, sino de crear un ecosistema donde tanto los desarrolladores como las empresas puedan prosperar juntos.

En las siguientes secciones, profundizaremos en qué hace que DevRel sea único, sus diferentes facetas, los desafíos que enfrenta y cómo puedes embarcarte en este emocionante campo. Ya seas un desarrollador curioso sobre cómo las empresas interactúan con su comunidad, un profesional de marketing buscando entender mejor a la audiencia técnica, o alguien considerando una carrera en DevRel, este artículo te proporcionará una visión completa de este fascinante mundo.

¿Por qué DevRel es único?

DevRel se distingue de otras prácticas empresariales por varias razones:

1. Audiencia especializada: Los desarrolladores son un público único, con necesidades, preferencias y expectativas específicas, para hablar su idioma, tienes que conocer a profundidad la tecnología, es decir, requiere especialización.

2. Enfoque técnico y humano: DevRel requiere una combinación de habilidades técnicas profundas y excelentes habilidades interpersonales. No solo porque sepas sobre cierto tema quiere decir que sepas comunicarlo y enseñarlo. Debes aprender sobre métodos de comunicación y enseñanza efectivos .

3. Conocimiento multidisciplinario y colaboración interdepartamental:

DevRel requiere un entendimiento profundo de múltiples áreas dentro de la organización, aunque no se forme parte directa de estos equipos. Un profesional de DevRel debe:

• Comprender la visión y estrategia del producto para poder comunicarla efectivamente a los desarrolladores y retroalimentar al equipo de producto con las necesidades de la comunidad.

• Conocer los objetivos y procesos de ventas para alinear las actividades de DevRel con la generación de leads y la conversión de clientes, sin comprometer la confianza de la comunidad.

• Entender las métricas y estrategias de marketing para colaborar en campañas que resuenen con la audiencia técnica y complementen los esfuerzos de marketing general.

• Familiarizarse con los procesos de soporte para identificar problemas comunes, crear contenido educativo relevante y facilitar la resolución de problemas en la comunidad.

• Colaborar con el equipo de ingeniería para transmitir las necesidades técnicas de los desarrolladores externos y ayudar a priorizar características y mejoras.

• Trabajar con el equipo legal para navegar cuestiones de licencias, términos de servicio y privacidad que afectan a la comunidad de desarrolladores.

  4. Variedad de responsabilidades: Los profesionales de DevRel pueden desempeñar roles que van desde la educación técnica hasta la gestión de comunidades y la estrategia de productos.

Las diferentes aristas de DevRel

DevRel abarca una amplia gama de actividades y responsabilidades, no todos los DevRel hacen lo mismo, es una práctica muy amplia, así que entendamos solamente algunas, que hacen en su día a día - y que se necesita para serlo:

Developer Marketing:

1. Día a día:

   • Crear y ejecutar campañas de marketing dirigidas a desarrolladores

   • Gestionar la presencia en redes sociales técnicas

   • Analizar métricas de campañas y ajustar estrategias

   • Colaborar con el equipo de producto para comunicar nuevas características

Métricas de éxito:

• Número de nuevos registros/descargas

• Engagement en redes sociales técnicas

• Tráfico al sitio web de desarrolladores

• Conversión de leads a usuarios activos

Perfil ideal:

• Experiencia en marketing digital

• Conocimientos técnicos sólidos

• Habilidad para escribir contenido técnico atractivo

• Comprensión de las necesidades y motivaciones de los desarrolladores

  Developer Education:

Día a día:

• Crear y actualizar tutoriales, guías y cursos

• Diseñar programas de certificación

• Impartir webinars y talleres

• Colaborar con el equipo de producto para entender nuevas funcionalidades

Métricas de éxito:

• Número de desarrolladores que completan cursos/certificaciones

• Valoraciones de los recursos educativos

• Tiempo de adopción de nuevas características

• Reducción en tickets de soporte relacionados con la falta de conocimiento

Perfil ideal:

• Experiencia en desarrollo de software

• Habilidades pedagógicas

• Capacidad para explicar conceptos complejos de manera simple

• Pasión por la enseñanza y el aprendizaje continuo

  Developer Experience (DX):

Día a día:

• Revisar y mejorar la usabilidad de APIs y SDKs

• Realizar pruebas de usuario y recopilar feedback

• Colaborar con ingeniería para implementar mejoras

• Diseñar procesos de onboarding eficientes

Métricas de éxito:

• Tiempo para completar tareas comunes (ej. "time to hello world")

• Tasa de adopción de nuevas características

• Satisfacción del desarrollador (NPS)

• Reducción en el número de problemas/errores reportados

Perfil ideal:

• Sólida experiencia en desarrollo de software

• Conocimientos de UX/UI

• Habilidad para analizar datos y patrones de uso

• Empatía y capacidad para ponerse en el lugar del usuario

  Community Management:

Día a día:

• Moderar foros y canales de comunicación

• Organizar y facilitar eventos comunitarios

• Identificar y apoyar a miembros destacados de la comunidad

• Recopilar y analizar feedback de la comunidad

Métricas de éxito:

• Crecimiento de la comunidad

• Nivel de engagement (posts, respuestas, etc.)

• Satisfacción de la comunidad

• Número de problemas resueltos por la comunidad

Perfil ideal:

• Excelentes habilidades de comunicación

• Capacidad para manejar conflictos

• Conocimiento técnico suficiente para entender las discusiones

• Habilidad para construir relaciones y fomentar la colaboración

  Developer Advocade:

Día a día:

• Representar a la empresa en conferencias y eventos

• Crear contenido (blogs, videos, podcasts)

• Interactuar con desarrolladores en diversos canales

• Recopilar feedback y transmitirlo internamente

Métricas de éxito:

• Alcance e impacto de las presentaciones

• Engagement con el contenido creado

• Número de desarrolladores influenciados

• Cantidad y calidad del feedback transmitido a la empresa

Perfil ideal:

• Fuerte experiencia técnica

• Excelentes habilidades de comunicación y presentación

• Red de contactos en la industria

• Pasión por la tecnología y la comunidad

  Technical Writing:

Día a día:

• Escribir y mantener documentación técnica

• Colaborar con ingeniería para entender nuevas características

• Revisar y editar contenido técnico de otros equipos

• Implementar mejores prácticas de SEO en la documentación

Métricas de éxito:

• Claridad y precisión de la documentación (medida por feedback)

• Reducción en tickets de soporte relacionados con la documentación

• Tráfico y tiempo de permanencia en las páginas de documentación

• Velocidad de actualización de la documentación con nuevas versiones

Perfil ideal:

• Sólidas habilidades de escritura técnica

• Conocimientos de desarrollo de software

• Atención al detalle y organización

• Capacidad para simplificar conceptos complejos

  Developer Success:

Día a día:

• Proporcionar soporte técnico avanzado

• Realizar sesiones de consultoría con desarrolladores

• Identificar y compartir mejores prácticas

• Colaborar con otros equipos para resolver problemas complejos

Métricas de éxito:

• Tasa de resolución de problemas

• Tiempo de respuesta y resolución

• Satisfacción del cliente

• Tasa de retención de desarrolladores

Perfil ideal:

• Amplia experiencia en desarrollo y resolución de problemas

• Excelentes habilidades de comunicación y atención al cliente

• Capacidad para trabajar bajo presión

• Conocimiento profundo de los productos de la empresa y sus casos de uso

Los retos de DevRel

A pesar de su importancia creciente, DevRel enfrenta varios desafíos:

Medición del impacto:

1. • Dificultad para cuantificar el valor de las relaciones a largo plazo

     • Falta de métricas estándar en la industria para medir el éxito de DevRel

     • Desafío de vincular las actividades de DevRel con los resultados del negocio

     • Necesidad de equilibrar métricas cuantitativas y cualitativas

       Equilibrio entre las necesidades de la empresa y la comunidad:

     • Mantener la confianza de la comunidad mientras se cumplen los objetivos empresariales

     • Comunicar decisiones impopulares de la empresa a la comunidad

     • Defender las necesidades de los desarrolladores dentro de la empresa

     • Manejar expectativas divergentes entre la empresa y la comunidad

       Mantenerse actualizado:

     • Necesidad de aprendizaje continuo en un campo tecnológico en rápida evolución

     • Mantenerse al día con las últimas tendencias y mejores prácticas en DevRel

     • Equilibrar el tiempo entre el aprendizaje y las responsabilidades diarias

     • Adaptarse a nuevas plataformas y canales de comunicación

       Burnout:

     • Alto nivel de interacción social que puede ser agotador, especialmente para introvertidos

     • Presión para estar siempre "conectado" y disponible para la comunidad

     • Desafío de manejar múltiples responsabilidades y proyectos simultáneamente

     • Viajes frecuentes a eventos y conferencias que pueden afectar el equilibrio trabajo-vida

       Reconocimiento interno:

     • Educar a otros departamentos sobre el valor y la importancia de DevRel

     • Justificar el presupuesto y los recursos para actividades de DevRel

     • Superar la percepción de que DevRel es solo "marketing técnico"

     • Establecer DevRel como una función estratégica dentro de la organización

El Camino hacia DevRel: Una Travesía de Descubrimiento

Imagina que estás en una encrucijada en tu carrera. Has pasado años escribiendo código, resolviendo problemas y construyendo cosas increíbles. Pero últimamente, te has dado cuenta de que lo que realmente te emociona no es solo el acto de codificar, sino compartir tu conocimiento, ayudar a otros desarrolladores y ser parte de algo más grande. Bienvenido al comienzo de tu viaje hacia DevRel.

No existe un mapa definitivo para convertirse en un profesional de DevRel, pero hay algunos senderos comunes que muchos han recorrido antes que tú.

Todo comienza con la curiosidad. Empiezas a asistir a meetups locales, no solo para aprender, sino para conocer a otros desarrolladores. Te encuentras compartiendo tus experiencias, ofreciendo consejos, y antes de que te des cuenta, estás dando tu primera charla improvisada sobre ese error extraño que resolviste la semana pasada.

Animado por la experiencia, empiezas a escribir. Quizás un blog sobre tus aventuras en el mundo del desarrollo. Al principio, sientes que estás escribiendo para nadie, pero poco a poco, la gente comienza a comentar, a compartir, a agradecer. Estás construyendo una comunidad sin siquiera darte cuenta.

Un día, te encuentras en una hackathon, no solo programando, sino ayudando a otros equipos, conectando personas, resolviendo conflictos. Te das cuenta de que te sientes más vivo haciendo esto que pasando horas frente a la pantalla escribiendo código.

Mientras tanto, en tu trabajo diario, comienzas a involucrarte más con otros equipos. Marketing te pide ayuda para entender las necesidades de los desarrolladores. El equipo de producto quiere tu opinión sobre nuevas características. Estás convirtiéndote en un puente entre diferentes mundos.

Decides dar el salto y solicitas tu primer trabajo en DevRel. Puede que no tengas toda la experiencia que piden, pero tienes algo más valioso: pasión, empatía y una auténtica conexión con la comunidad de desarrolladores.

Recuerda, DevRel no es un destino, es un viaje continuo. Seguirás aprendiendo, adaptándote, creciendo. Un día estarás escribiendo documentación, al siguiente dando una charla en una gran conferencia, y al otro mediando un debate acalorado en un foro en línea.

Pero en el corazón de todo esto, seguirás siendo un desarrollador. Esa es tu superpotencia. Tu capacidad para entender profundamente los desafíos técnicos, combinada con tu deseo de conectar y ayudar a otros, es lo que te hace único en este campo.

Así que, si sientes ese llamado, si te encuentras más emocionado por ayudar a otros desarrolladores y quieres unirte a nosotros, es el mejor momento para hacerlo.

Siguientes Pasos

Si estás interesado en aprender más sobre DevRel o en conectarte con otros profesionales en Latinoamérica:

1. Únete a la comunidad de DevRel Latinoamérica:

   1. Sitio Web: https://latamdevrel.com

   2. Youtube: https://www.youtube.com/@LATAMDevRel

   3. Grupo de LinkedIn: https://www.linkedin.com/groups/12880221/

   4. LinkedIn: https://www.linkedin.com/company/latamdevrel/

   5. Twitch: https://www.twitch.tv/latinodevrel

2. Comparte tus experiences y unete a la conversación en el nuestro chat de discord: https://discord.gg/H5FzyCQ5

3. Escucha nuestro Podcast donde aprenderás directamente de DevRel Latinos.