Cómo priorizar un roadmap tecnológico
cuando todo parece urgente.

Cada CTO o head of engineering que conocemos tiene el mismo problema: 40 iniciativas en el backlog, 8 personas en el equipo, y 12 stakeholders cada uno con la opinión clara de que SU pedido es el más urgente. La pregunta no es qué hacer — es cómo priorizar sin pelearse con todos.

El framework que usamos en consultoría tiene tres ejes: impacto al negocio (en dólares de ingreso o ahorro cuantificables), esfuerzo técnico (días/persona reales, no estimaciones optimistas), y riesgo (técnico, regulatorio y de adopción). Cada iniciativa se puntúa en los tres ejes en escala 1-5. El score final es impacto / (esfuerzo + riesgo). Los top 5 son lo que vas a hacer este trimestre.

Lo crítico no es la fórmula — es la disciplina de aplicarla. La mayoría puntúa el impacto con generosidad y el esfuerzo con optimismo. Para corregirlo, el impacto tiene que estar respaldado por una hipótesis cuantitativa, y el esfuerzo lo estima alguien que va a programar, no alguien que va a presentar el roadmap.

El otro elemento clave: hacer este ejercicio con todos los stakeholders en la misma sala. No se trata de imponer una priorización técnica — se trata de que ventas, producto, finanzas y operaciones vean los mismos números y discutan trade-offs reales. Cuando alguien defiende su proyecto contra esta matriz, o tiene razones objetivas o no las tiene.

Lo que pasa después es predecible: tu equipo deja de operar en modo bombero (reaccionando al que grita más fuerte) y empieza a operar en modo arquitecto (decidiendo qué construir con criterio). Y los stakeholders, sorprendentemente, lo aceptan — porque la decisión no es arbitraria, está escrita.