yuliana.goni
Durante años, cuando me preguntaban qué hacía como Project Manager, respondía con una lista de herramientas y metodologías.
Jira. Scrum. PMBOK. Kanban. Reuniones de seguimiento. Gestión de riesgos.
Y era verdad. Hacía todo eso. Y lo hacía bien.
Pero con el tiempo me di cuenta de algo que nadie me había dicho explícitamente: Hay dos tipos de Project Manager. Y el mercado los valora de forma muy diferente.
El PM técnico
El PM técnico es muy bueno ejecutando. Sabe gestionar el backlog, cerrar sprints, facilitar ceremonias, actualizar el tablero y reportar el estado del proyecto. Conoce las herramientas, aplica las metodologías y mantiene todo bajo control. Es imprescindible. Sin ese perfil, los proyectos no avanzan. Pero hay un límite en lo que puede hacer.
Porque su mirada está puesta, casi siempre, en el proceso. En el cómo:
👉 ¿Cómo organizamos el sprint?
👉 ¿Cómo gestionamos los bloqueos?
👉 ¿Cómo entregamos a tiempo?
Y esas son preguntas importantes. Pero no son las únicas preguntas que importan.
El PM estratégico
El PM estratégico también sabe gestionar un backlog. También conoce las metodologías. También facilita ceremonias.
Pero su mirada está puesta en otro lugar. Está puesta en el negocio. Se pregunta cosas diferentes:
👉 ¿Por qué estamos construyendo esto?
👉 ¿Qué problema real resuelve para el negocio?
👉 ¿Qué pasa si entregamos todo a tiempo pero nadie lo usa?
👉 ¿Estamos construyendo lo correcto, o solo construyendo bien?
Recuerdo un proyecto en el que el equipo técnico estaba muy contento. El modelo funcionaba, las métricas eran buenas, los sprints se cerraban en tiempo. Todo bajo control.
Y sin embargo, cuando llegó el momento de llevarlo al negocio, nadie sabía qué hacer con él. No había proceso. No había responsables. No había integración con la operación real.
El proyecto técnicamente fue un éxito. Estratégicamente, fue un fracaso.
Y la diferencia no estaba en el modelo. Estaba en cómo se había gestionado.
La diferencia en la práctica
Esto no es solo teoría. Lo he vivido en primera persona en proyectos de transformación digital y de inteligencia artificial. Y lo que marca la diferencia entre un PM técnico y uno estratégico no es la experiencia ni las certificaciones. Es la perspectiva.
| PM técnico | PM estratégico | |
|---|---|---|
| Foco | El proceso | El impacto |
| Pregunta clave | ¿Cómo lo entregamos? | ¿Por qué lo construimos? |
| Relación con el negocio | Reporta avance | Alinea expectativas |
| Gestión de stakeholders | Informativa | Consultiva |
| Valor que aporta | Eficiencia | Decisiones |
| En proyectos de IA | Gestiona tareas | Traduce entre tecnología y negocio |
Ninguno de los dos es mejor ni peor. Son perfiles distintos. Pero el mercado los remunera de forma muy distinta.
¿Y cuál pagan más?
La respuesta corta es: el estratégico. Pero no porque el técnico valga menos. Sino porque el estratégico es más escaso.
Hay muchos PMs que saben gestionar un proyecto. Hay pocos que sepan conectar ese proyecto con la estrategia de negocio, gestionar las expectativas de la dirección, anticipar los riesgos no técnicos y asegurarse de que lo que se entrega realmente se usa.
Esa combinación — dominio técnico del rol con visión estratégica de negocio — es la que abre las puertas a posiciones mejor pagadas, más senior y con mayor impacto.
En mi experiencia, los perfiles que más se valoran en el mercado tecnológico actual son los que pueden moverse en los dos mundos.
- Los que entienden cómo funciona un modelo de datos, pero también saben explicarle al director financiero por qué ese modelo importa para el negocio.
- Los que conocen Jira por dentro, pero también saben cuándo Jira no es la solución al problema real.
- Los que gestionan sprints, pero también se sientan en la mesa donde se toman las decisiones.
¿Cómo se pasa de técnico a estratégico?
No es una transición que ocurra de golpe. Ni que dependa solo de formación.
En mi caso, fue un proceso gradual. Hubo proyectos donde fallé por no tener esa visión estratégica. Hubo conversaciones incómodas con stakeholders que me enseñaron más que muchos cursos. Hubo momentos en los que tuve que dejar de gestionar tareas y empezar a gestionar decisiones. Y lo que más me ayudó no fue aprender más herramientas. Fue aprender a hacer mejores preguntas:
- ¿Qué problema real estamos resolviendo?
- ¿Quién lo sufre y por qué importa?
- ¿Qué pasa si no lo resolvemos?
- ¿Cómo sabremos que lo hemos resuelto de verdad?
Esas preguntas cambian la conversación. Y cambian el proyecto.
Lo que esto significa en proyectos de IA
En el contexto de la inteligencia artificial, esta diferencia es aún más crítica.
Los proyectos de IA tienen una característica que los hace especialmente sensibles a la falta de visión estratégica: el resultado final no es una funcionalidad. Es una capacidad. Por ejemplo: un modelo de churn no entrega una pantalla ni un botón. Entrega información. Y esa información solo tiene valor si alguien la usa para tomar decisiones mejores.
Si el PM no conecta ese modelo con el proceso real del negocio, con los responsables que deben actuar, con los sistemas donde debe integrarse… el modelo se queda guardado en un repositorio que nadie abre.
He visto ese escenario más veces de las que me gustaría.
Y siempre, sin excepción, la causa raíz no estaba en la tecnología. Estaba en la gestión.
En este blog sigo hablando sobre cómo está evolucionando el rol del PM en la era de la inteligencia artificial. Si te interesa profundizar, te dejo aquí un artículo sobre un proyecto de IA que parecía exitoso pero fracasó — y las lecciones que saqué de esa experiencia.
Porque al final, más allá de las herramientas y los frameworks, lo que define a un buen Project Manager sigue siendo lo mismo: entender el problema real y ayudar a que el equipo genere valor de verdad. 😉
