Cómo aplicar «Buena estrategia / mala estrategia» al roadmap de producto
Antes de nuestra última sesión de planificación trimestral repasé mis notas sobre «Buena estrategia / mala estrategia» de Rumelt. Fue un ejercicio útil, porque el roadmap que llevábamos meses construyendo era exactamente aquello contra lo que Rumelt advierte: una lista de cosas que queríamos hacer, ordenada por prioridad, sin ninguna lógica que las conectara.
Teníamos 14 puntos. Funcionalidades, infraestructura, integraciones, un vago «exploración de IA» que nadie sabía definir. Cada stakeholder había aportado algo. La lista era exhaustiva y completamente inútil como estrategia, porque una lista de funcionalidades no es un plan: es un inventario.
Así se aplica el núcleo de tres partes de Rumelt — diagnóstico, política guía, acciones coherentes — a la planificación trimestral de producto.
Paso 1: Diagnóstico — ¿cuál es el verdadero desafío?
El diagnóstico es el paso más difícil porque exige honestidad. No la versión pulida para la presentación al consejo. La verdad incómoda sobre lo que de verdad está frenando tu producto.
La mayoría de los equipos se lo salta por completo. Pasan directamente a «¿qué deberíamos construir?» sin preguntarse antes «¿qué problema estamos resolviendo?». El resultado es un roadmap que ataca síntomas, no causas.
Mal diagnóstico: «Necesitamos más funcionalidades para competir.»
Eso no es un diagnóstico. Es ansiedad disfrazada de análisis. No identifica un desafío concreto, así que no puede guiar acciones concretas.
Buen diagnóstico: «Los usuarios abandonan al séptimo día porque el onboarding es confuso. El 62% de los usuarios de prueba nunca completa la configuración. Nuestro ticket de soporte más frecuente es "¿cómo conecto mi fuente de datos?" — un flujo que diseñamos en 2021 y no hemos tocado desde entonces.»
Fíjate en la diferencia. El buen diagnóstico es específico, se apoya en evidencia y nombra la restricción real. Es incómodo porque dice «construimos algo que no funciona bien». Pero te da algo sobre lo que actuar.
Cómo llegar ahí: saca los datos de retención, lee los últimos 100 tickets de soporte, habla con cinco clientes que se hayan ido (no con los contentos) y pregunta a tus ingenieros qué arreglarían primero. Ellos lo saben: llevan tiempo conviviendo con el problema. El diagnóstico debe caber en una o dos frases. Si ocupa una página, no lo has destilado lo suficiente.
Paso 2: Política guía — el enfoque
La política guía no es una solución. Es la dirección estratégica que acota qué soluciones vas a considerar. Es la decisión que elimina categorías enteras de trabajo de tu roadmap.
Para nuestro ejemplo del onboarding:
Mala política guía: «Mejoraremos la experiencia de usuario.» Demasiado vaga. Todo es «mejorar la experiencia de usuario». Esto no elimina nada.
Buena política guía: «Este trimestre priorizamos retención sobre adquisición. Ninguna funcionalidad nueva para prospectos hasta que los usuarios actuales puedan completar el onboarding sin que intervenga soporte.»
Eso es una política guía porque elige. Dice «haremos esto, y no aquello». Le dice a ventas que la integración que quieren no entra este trimestre. Le dice a marketing que el rediseño de la landing deja de ser prioridad. Genera incomodidad — y así es como sabes que es una decisión de verdad.
La prueba de una buena política guía: ¿deja descontento al menos a un stakeholder? Si todos sonríen y asienten, no has tomado una decisión. Has escrito una obviedad.
Paso 3: Acciones coherentes — lo que vas a hacer de verdad
Las acciones coherentes son los movimientos concretos y coordinados que ponen en práctica la política guía. La palabra clave es coherentes: las acciones deben reforzarse entre sí. Un conjunto de mejoras sueltas no es acción coherente, por útil que sea cada mejora por separado.
Para nuestro trimestre centrado en retención:
- Rediseñar el flujo de conexión de fuentes de datos — el ticket de soporte más frecuente pasa a ser la máxima prioridad de ingeniería. Nuevo flujo tipo asistente con validación en cada paso. En producción en la semana 4.
- Añadir guía de onboarding dentro de la app — tooltips contextuales y un indicador de progreso que muestre al usuario en qué punto de la configuración está. Esto solo funciona si el flujo subyacente (acción 1) está limpio.
- Construir un panel de salud del onboarding — medir la tasa de configuración completada, el tiempo hasta el primer valor y el volumen de tickets de soporte de los usuarios nuevos. Nos permite comprobar si las acciones 1 y 2 han funcionado.
- Lanzar una campaña de reactivación para los usuarios atascados en la configuración — emails disparados desde el producto al 62% que abandonó, ofreciéndoles un recorrido guiado con el nuevo flujo.
Estas cuatro acciones son coherentes. Cada una apoya a las demás. El rediseño del flujo hace útil la guía. El panel mide el impacto. La campaña de reactivación aplica el flujo mejorado a los usuarios que ya habíamos perdido. Quita cualquiera de ellas y la estrategia se debilita.
Lo que no está en esta lista importa tanto como lo que sí está. ¿La integración que pidió ventas? Este trimestre no. ¿La exploración de IA? Cancelada. ¿El rediseño de la app móvil? Aplazado. No porque sean malas ideas, sino porque no sirven a la estrategia de este trimestre.
Por qué la mayoría de los roadmaps son estrategia convertida en lista de deseos
He revisado decenas de roadmaps de producto de las startups con las que trabajamos. El patrón se repite:
El bufé de stakeholders. Ventas quiere integraciones. Marketing quiere una landing. El CEO quiere IA porque un competidor la anunció. Ingeniería quiere atacar la deuda técnica. El roadmap se convierte en un bufé: un poco de todo, sin satisfacer del todo a nadie.
La ilusión de la matriz de prioridades. Los equipos usan RICE o MoSCoW para ordenar elementos. Parece riguroso. Pero ordenar una lista de deseos no es lo mismo que tener una estrategia. Puedes puntuar 30 elementos con RICE y seguir sin tener un plan coherente, porque los elementos no conectan con ningún desafío diagnosticado.
La fábrica trimestral de funcionalidades. El roadmap se convierte en un calendario de producción: «En Q4 entregamos las funcionalidades A a E». Sin diagnóstico, sin política guía, sin explicar por qué esas cinco funcionalidades, juntas, atacan un problema concreto. El equipo entrega las cinco y el desafío de fondo sigue sin resolverse.
Cómo decir que no usando el núcleo de la estrategia
El núcleo de la estrategia es la mejor herramienta que he encontrado para decir que no sin que suene arbitrario. Cuando un stakeholder presiona por su funcionalidad favorita, no le dices «no es prioritario». Le dices:
«Nuestro diagnóstico es que los usuarios abandonan al séptimo día porque el onboarding está roto. Nuestra política guía este trimestre es retención sobre adquisición. Tu petición es una funcionalidad de adquisición. Es una buena idea para Q1, cuando hayamos estabilizado la retención, pero no sirve a la estrategia con la que nos hemos comprometido.»
Esto funciona porque no es personal ni es vago. Conecta el «no» con una comprensión concreta y compartida del problema. La mayoría de los stakeholders acepta un «ahora no» bien razonado si entiende la lógica. Lo que no pueden aceptar es «simplemente decidimos priorizar otras cosas» — eso suena arbitrario, y seguirán presionando.
Documenta el núcleo. Ponlo por escrito. Una página. Diagnóstico, política guía, acciones coherentes. Compártelo con cada stakeholder al inicio del trimestre. Cuando lleguen peticiones de funcionalidades a mitad de trimestre (y llegarán), remítelos al documento. «¿Esto sirve al desafío que hemos diagnosticado? Si no, va a la lista de candidatas para Q1.»
La reunión de planificación, rediseñada
Así he reestructurado la planificación trimestral:
- Semana 1: taller de diagnóstico. Producto, ingeniería y customer success en una sala con datos. Un único entregable: la declaración del diagnóstico.
- Semana 2: política guía. Dirección revisa el diagnóstico y toma las decisiones difíciles. El debate se espera; el alineamiento se exige.
- Semana 3: acciones coherentes. Ingeniería y producto traducen la política en entregables coordinados. Alcance, secuencia, dependencias.
- Semana 4: comunicar. Compartir el núcleo con toda la empresa. Qué haces, qué no haces, y por qué.
Esto lleva más tiempo que ordenar una hoja de cálculo — cuatro semanas en lugar de una reunión, y ese sobrecoste es la objeción honesta a todo el planteamiento. Lo que compras a cambio es un trimestre enfocado en lugar de disperso, que sale más barato que entregar puntualmente las cinco funcionalidades equivocadas.
En Conectia, los ingenieros senior que integramos en los equipos de nuestros clientes no se limitan a ejecutar elementos del roadmap: cuestionan el roadmap mismo. Han visto suficientes productos como para reconocer cuándo un roadmap es una lista de deseos disfrazada de estrategia. Ese reconocimiento de patrones, unido a la disciplina de preguntar «¿cuál es el problema real?», es lo que un ingeniero con experiencia aporta a un equipo.
¿Necesitas ingenieros que cuestionen el roadmap, no solo que lo ejecuten? Habla con un CTO — nuestros ingenieros senior de LATAM aportan el criterio estratégico para convertir listas de funcionalidades en ejecución de producto enfocada.
