Aplicando «Buena Estrategia / Mala Estrategia» a los Roadmaps de Producto
Revisé mis notas sobre "Buena Estrategia / Mala Estrategia" de Rumelt antes de nuestra última sesión de planificación trimestral. Fue un ejercicio útil, porque el roadmap que habíamos estado construyendo era exactamente lo que Rumelt advierte: una lista de cosas que queríamos hacer, organizada por prioridad, sin lógica conectora.
Teníamos 14 elementos. Funcionalidades, infraestructura, integraciones, un vago elemento de "exploración de IA" que nadie podía definir. Cada stakeholder había contribuido con 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 kernel 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 requiere honestidad. No la versión pulida para el deck de la junta. La verdad incómoda sobre lo que realmente está frenando tu producto.
La mayoría de los equipos se lo saltan por completo. Se van directamente a "¿qué deberíamos construir?" sin preguntarse primero "¿qué problema estamos resolviendo?" El resultado es un roadmap que aborda 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 específico, por lo que no puede guiar acciones específicas.
Buen diagnóstico: "Los usuarios hacen churn en el día 7 porque el onboarding es confuso. El 62% de los usuarios de prueba nunca completan la configuración. Nuestro ticket de soporte más común es '¿cómo conecto mi fuente de datos?' — un flujo que diseñamos en 2021 y no hemos tocado desde entonces."
Nota la diferencia. El buen diagnóstico es específico, basado 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í: Analiza los datos de retención, lee los últimos 100 tickets de soporte, habla con cinco clientes que se fueron (no con los felices) y pregunta a tus ingenieros qué arreglarían primero. Ellos lo saben — han estado viviendo con ello. El diagnóstico debe caber en una o dos frases.
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 restringe qué soluciones considerarás. Es la decisión que elimina categorías enteras de trabajo de tu roadmap.
Para nuestro ejemplo de 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: "Priorizaremos la retención sobre la adquisición este trimestre. Sin nuevas funcionalidades para prospectos hasta que los usuarios existentes puedan hacer el onboarding con éxito sin intervención del soporte."
Eso es una política guía porque toma una decisión. Dice "haremos esto, no aquello." Le dice a ventas que la integración que quieren no va a suceder este trimestre. Le dice a marketing que el rediseño de la landing page está desprioritizado. Crea incomodidad — y así es como sabes que es una decisión real.
La prueba de una buena política guía: ¿Hace que al menos un stakeholder sea infeliz? Si todos sonríen y asienten, no has tomado una decisión. Has escrito una platitud.
Paso 3: Acciones Coherentes — Lo que Realmente Harás
Las acciones coherentes son los movimientos específicos y coordinados que implementan la política guía. La palabra clave es coherentes — las acciones deben reforzarse mutuamente.
Para nuestro trimestre enfocado en retención:
- Rediseñar el flujo de conexión de fuente de datos — el ticket de soporte más frecuente se convierte en la prioridad de ingeniería número uno. Nuevo flujo tipo asistente con validación en cada paso. Entrega en la semana 4.
- Añadir guía de onboarding en la app — tooltips contextuales e indicador de progreso. Esto solo funciona si el flujo subyacente (acción 1) está limpio.
- Construir un dashboard de salud del onboarding — rastrear tasa de completado de configuración, tiempo hasta el primer valor y volumen de tickets de soporte para nuevos usuarios.
- Ejecutar una campaña de re-engagement para usuarios atascados en la configuración — emails activados por el producto al 62% que abandonó, ofreciendo un recorrido guiado con el nuevo flujo.
Estas cuatro acciones son coherentes. Cada una apoya a las demás. Elimina cualquiera de ellas y la estrategia se debilita.
Lo que no está en esta lista importa tanto como lo que está. ¿La integración que pidió ventas? No este trimestre. ¿La exploración de IA? Cancelada. ¿El rediseño de la app móvil? Aplazado.
Por Qué la Mayoría de los Roadmaps Son Estrategia-como-Lista-de-Deseos
He revisado docenas de roadmaps de producto de las startups con las que trabajamos. El patrón es consistente:
El bufet de stakeholders. Ventas quiere integraciones. Marketing quiere una landing page. El CEO quiere IA porque un competidor lo anunció. Ingeniería quiere abordar la deuda técnica. El roadmap se convierte en un bufet — un poco de todo, sin satisfacer a nadie del todo.
La ilusión de la matriz de prioridades. Los equipos usan puntuación RICE o MoSCoW para clasificar elementos. Parece riguroso. Pero clasificar una lista de deseos no es lo mismo que tener una estrategia.
La fábrica de funcionalidades trimestral. El roadmap se convierte en un programa de producción: "En Q4 entregamos funcionalidades A a E." Sin diagnóstico, sin política guía, sin explicación de por qué estas cinco funcionalidades juntas abordan un problema específico.
Cómo Decir No Usando el Kernel de Estrategia
El kernel de estrategia es la mejor herramienta que he encontrado para decir no sin que parezca arbitrario. Cuando un stakeholder presiona por su funcionalidad favorita, no dices "no es una prioridad." Dices:
"Nuestro diagnóstico es que los usuarios hacen churn en el día 7 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 que hemos comprometido."
Documenta el kernel. Escríbelo. Una página. Diagnóstico, política guía, acciones coherentes. Compártelo con cada stakeholder al inicio del trimestre. Cuando lleguen solicitudes de funcionalidades a mitad de trimestre (y llegarán), señala de vuelta al documento.
La Reunión de Planificación, Rediseñada
Así es como he reestructurado la planificación trimestral:
- Semana 1: Taller de diagnóstico. Producto, ingeniería y customer success en una sala con datos. Un output: la declaración de diagnóstico.
- Semana 2: Política guía. El liderazgo revisa el diagnóstico y toma las decisiones difíciles.
- Semana 3: Acciones coherentes. Ingeniería y producto traducen la política en entregables coordinados.
- Semana 4: Comunicar. Compartir el kernel con toda la empresa.
En Conectia, los ingenieros senior que integramos en equipos de clientes no solo ejecutan elementos del roadmap — desafían el roadmap mismo. Han visto suficientes productos para reconocer cuándo un roadmap es una lista de deseos disfrazada de estrategia.
¿Necesitas ingenieros que desafíen el roadmap, no solo que lo ejecuten? Habla con un CTO — nuestros ingenieros senior de LATAM aportan el pensamiento estratégico para convertir listas de funcionalidades en ejecución de producto enfocada.
