Coordinar el rol del Platzi Learn Engineer en la cuenta

El mayor riesgo en un deal enterprise no es recibir un "no" del cliente, sino obtener un "sí" y que el piloto falle. Un piloto fallido destruye credibilidad, cierra la puerta al despliegue completo y le regala argumentos al competidor. La clave para evitar ese escenario está en dominar la coordinación con una figura determinante: el Platzi Learn Engineer (PLE).

En fases previas del proceso comercial, el equipo ya diagnosticó latencia organizacional con el modelo tridimensional y ejecutó un discovery que convierte hipótesis en compromisos medibles. El cliente admitió la brecha, cuantificó el impacto y designó un patrocinador. Ahora se necesita a alguien que valide si el piloto prometido es realmente factible.

¿Qué hace exactamente el Platzi Learn Engineer?

El PLE no es un creador de cursos genérico. Es un consultor pedagógico que toma el conocimiento interno de una empresa —documentos desactualizados, manuales que nadie lee, expertise atrapada en las cabezas de unas pocas personas— y lo convierte en experiencias de aprendizaje ejecutables [0:42].

Su impacto se conecta directamente con los ejes de latencia organizacional:

• Cuando existe latencia en el eje I (conocimiento institucional que no fluye), el PLE resuelve el bloqueador.
• Cuando hay urgencia en el eje Z, el PLE entrega en setenta y dos horas lo que una agencia tradicional tarda ocho semanas en producir [1:08].
• Adapta materiales por rol: un operador de planta necesita información diferente que un gerente regional, aunque aprendan el mismo protocolo.
• Verifica resultados con métricas de negocio, no solo tasas de completación.

¿Cuándo se debe involucrar al PLE en el proceso?

Este es el punto donde muchos equipos comerciales se equivocan. Traerlo demasiado pronto desperdicia su tiempo en deals sin calificar. Traerlo demasiado tarde genera promesas que nadie validó [1:31].

La regla es clara: el PLE entra después de la alineación de stakeholders, pero antes de prometer el piloto. El ciclo de discovery ya debe estar completo: pregunta, evidencia, impacto, siguiente paso, con un compromiso escrito que incluya nombre, métrica y acción.

En esa fase, el PLE opera en modo descubrimiento: evalúa si los materiales del cliente pueden transformarse, identifica brechas y estima timelines realistas. Una vez que el cliente se compromete formalmente, cambia a modo arquitecto: estructura rutas de aprendizaje, adapta contenido y mide resultados post despliegue [2:12].

¿Qué señales de riesgo se deben detectar antes de escalar al PLE?

Antes de llevar un caso, es necesario pasarlo por un filtro de señales de riesgo [2:30]:

• El cliente espera una transformación completa en una semana: no entiende el alcance.
• No hay un dueño claro del contenido que proporcione el conocimiento interno.
• No existe documentación de ningún tipo: el PLE parte de cero y los tiempos cambian radicalmente.
• El liderazgo no puede definir qué significa éxito en términos medibles.
• No hay infraestructura técnica confirmada: acceso a plataforma, permisos de firewall.
• No hay patrocinio ejecutivo: el piloto se desprioritiza con la primera urgencia.

Es como un diagnóstico prequirúrgico: se necesitan radiografías, análisis de sangre y disponibilidad del cirujano antes de entrar al quirófano.

¿Cómo estructurar el brief de una página para el PLE?

La calidad del hand off determina si el piloto se diseña en días o se estanca en semanas de ida y vuelta. El brief necesita cinco categorías de información [3:17]:

• Objetivo de negocio del cliente. No decir "necesitan capacitación"; decir "están lanzando un producto nuevo en tres semanas y necesitan que ochocientos vendedores ejecuten la nueva propuesta de valor".
• Evidencia de latencia capturada en discovery. Por ejemplo: "hoy tardan tres meses en capacitar a la fuerza de ventas".
• Scope del piloto sin features. Número de personas, marco temporal, proceso específico, métrica de éxito y qué queda fuera.
• Materiales de muestra. Capacitación reciente, procedimientos operativos estándar, anuncios de cambios recientes y datos de desempeño base.
• Constraints técnicas confirmadas con el equipo de TI del cliente.

La analogía es precisa: el mesero toma el pedido, pero el chef decide cómo cocinarlo [4:07]. El equipo comercial reúne la necesidad y el PLE la transforma en experiencia de aprendizaje.

¿Qué significa estar listo para piloto?

El estándar es setenta y dos horas para crear un curso desde que el PLE recibe materiales completos. Si el cliente entrega materiales en piezas, el reloj no empieza [4:22]. Es fundamental exigir un único punto de contacto del lado del cliente con autoridad de decisión.

Listo para piloto significa cinco cosas verificables [4:40]:

• Un problema de negocio con fecha límite.
• Audiencia definida por rol y número.
• Materiales identificados.
• Criterios de éxito con fuente de datos.
• Un stakeholder comprometido que pueda dar luz verde al roll out.

Antes de enviar el brief, hay que validarlo con cinco preguntas: ¿el scope está delimitado? ¿Los materiales están identificados con su estado real? ¿Las constraints están explícitas? ¿La métrica de éxito tiene unidad y fuente de datos? ¿Se puede describir en una oración qué va a poder ejecutar el empleado después de completar el programa? [4:55]

Si pasa los cinco filtros, el PLE arranca diseño en horas. Si no, se sabe exactamente qué falta y se puede pedir antes de prometer nada. Este brief es el eslabón entre el diagnóstico comercial y la ejecución técnica. ¿Ya identificaste qué información te falta para armar el tuyo? Comparte tu experiencia coordinando pilotos enterprise.