Los primeros 90 días de un roadmap de producto nuevo son desproporcionadamente importantes. Lo que publiques en la semana 12 se convierte en la línea base contra la que se medirá cada cambio posterior. Promete demasiado y pasas el año siguiente explicando retrasos. Promete demasiado poco y los stakeholders concluyen en silencio que el equipo no tiene ambición. La trampa es que ambos fracasos se sienten como "ir a lo seguro" mientras estás dentro.

Este artículo es una guía práctica para los primeros 90 días de un roadmap, seas un PM nuevo en un producto existente o un equipo lanzando una iniciativa nueva. Los principios también beben de la estructura de la guía starter de roadmap de Aha!, adaptada con las siete trampas que los PMs experimentados se advierten mutuamente.

El arco de 90 días, en tres fases

Días 0-30: escucha, no te comprometas

El instinto es enviar un roadmap para la semana 2 para demostrar que estás trabajando. Resístelo. El primer mes es para reunir señal: entrevistas a clientes, feedback de ventas, patrones de soporte, analíticas, movimientos de competidores, capacidad del equipo, deuda técnica. Producir un roadmap confiado antes de tener la señal te lleva a comprometerte con las cosas equivocadas.

Lo que sí puedes publicar la semana 2: un documento de una página titulado "preguntas que estoy intentando responder". Los stakeholders ven movimiento sin que te comprometas a una respuesta.

Días 31-60: borrador, comparte, revisa

Para el día 30, deberías tener señal suficiente para un borrador de roadmap con 3-5 outcomes trimestrales y los experimentos bajo cada uno. Compártelo primero con un grupo pequeño de confianza (engineering lead, design lead, un stakeholder por área). Toma el feedback, revisa dos veces, después comparte más ampliamente.

Días 61-90: publica, comunica, defiende

Para el día 60, el roadmap está en forma. Los 30 días restantes son para asegurarte de que todos los que necesitan actuar sobre él lo entienden, han tenido oportunidad de empujar y han acordado la cadencia hacia adelante.

Las 7 trampas

Trampa 1: enviar una lista de features en lugar de un roadmap

La trampa del PM nuevo. Bajo presión por parecer estratégico, producen una lista de features por trimestre. Eso no es un roadmap. Es un plan de proyecto disfrazado. Arreglo: lidera con outcomes. Cada feature de la lista debe conectar con un outcome que alguien fuera del equipo entienda.

Trampa 2: copiar el roadmap del predecesor

Si te uniste a un producto existente, el primer roadmap más fácil es el que tu predecesor ya estaba corriendo. El instinto es lealtad; el resultado es heredar sus prioridades sin saber por qué las eligió. Arreglo: reconstruye el roadmap desde primeros principios. Si la respuesta correcta resulta parecida, bien. Pero deberías saber por qué cada ítem está en la lista.

Trampa 3: sobre-prometer para ganar la primera reunión de stakeholders

Los stakeholders que te conocen por primera vez quieren sentir que las cosas se mueven. La tentación es comprometerte ambiciosamente para ganar la sala. El coste llega en el mes 4 cuando no puedes entregar. Arreglo: sub-comprométete un 20% en el primer roadmap. Siempre puedes añadir. No puedes quitar fácilmente.

Trampa 4: ignorar la deuda técnica que el equipo ha estado escondiendo

El equipo de ingeniería tiene una lista de cosas que llevan esperando arreglar. No la van a ofrecer hasta que confíen en ti. Si el primer roadmap tiene 0% asignado a deuda e infraestructura, señalas que no te importa cómo se construye el producto, solo qué se construye. Arreglo: asigna 10-20% del primer trimestre a deuda de infraestructura que el engineering lead recomiende.

Trampa 5: saltarse el mapa de dependencias

El roadmap tiene 8 iniciativas que dependen todas del mismo equipo de servicios compartidos. O de la misma persona que está de baja parental desde julio. O de una integración de terceros que aún no se ha negociado. Arreglo: antes de publicar el roadmap, mapea dependencias explícitamente. Si una sola dependencia invalidaría tres o más ítems, rediseña o secuéncialos.

Trampa 6: confundir audiencias del roadmap interno y externo

Los roadmaps internos necesitan detalle: quién, qué, cuándo, dependencias. Los externos (públicos o cara a cliente) necesitan dirección: hacia dónde vamos, por qué, cuándo a grandes rasgos. Un solo documento intentando servir a ambos falla en ambos. Arreglo: publica dos roadmaps desde la misma fuente de verdad, formateados distinto para cada audiencia. Canny, Roaderly y herramientas similares están diseñadas para esta vista dual.

Trampa 7: no hay plan para el siguiente ciclo de planificación

El primer roadmap se publica, todos respiran, y después no pasa nada hasta que algo se rompe. Arreglo: en el día 90, publica el siguiente ciclo de planificación junto al roadmap. Revisiones mensuales de experimentos, revisiones trimestrales de outcomes, chequeos anuales de visión. El ritmo importa más que el documento.

El primer roadmap que publicas se vuelve el contrato implícito. El segundo es la primera oportunidad de demostrar que puedes adaptarte. Publica el segundo a propósito, antes de que la presión te obligue.

Qué evalúan realmente los stakeholders en los primeros 90 días

Más allá del documento, los stakeholders observan:

  • ¿El PM escuchó antes de producir el plan? Hablar con 20 clientes en el mes 1 produce un roadmap más creíble que leer 20 docs internos.
  • ¿Las prioridades son defendibles? Cada ítem del roadmap debe tener una respuesta clara a "¿por qué esto y por qué ahora?".
  • ¿El PM actualiza el roadmap cuando la realidad cambia? Si el mes 3 revela que un ítem estaba mal, ¿ajustas o lo escondes?
  • ¿Cómo comunica el PM? Updates escritos semanales contra el roadmap valen más que decks mensuales.

Una plantilla para la publicación del día 90

El roadmap que se envía al día 90 debe contener:

  • Una página de visión (cambia raramente)
  • 3-5 outcomes para el trimestre actual con métricas y estado
  • Experimentos en marcha, en cola y recién enviados bajo cada outcome
  • Mapa de dependencias (una página)
  • El ritmo de planificación (semanal, mensual, trimestral, anual)
  • Log de decisiones (qué consideramos y elegimos no hacer, con razonamiento)

Cualquier cosa más es ruido. Cualquier cosa menos deja espacio para malinterpretación.

Para llevar

Los primeros 90 días de un roadmap de producto nuevo fijan expectativas que duran años. Escucha 30 días, borrador y revisa 30, después publica y defiende 30. Evita las siete trampas (listas de features, roadmaps copiados, sobre-prometer, ignorar deuda, saltar dependencias, confundir audiencias, sin ritmo de planificación) y envías un roadmap que sobrevive el contacto con la realidad. El roadmap en sí importa menos que el ritmo que establece para los meses que siguen.