El Roadmap como Herramienta de Comunicación
El roadmap de producto es, junto con el backlog, el artefacto más importante que produce un Product Manager. Pero la mayoría de los PMs lo entienden mal: un roadmap no es una lista de features con fechas. Es una herramienta de comunicación que muestra cómo el equipo planea alcanzar sus objetivos estratégicos a través del tiempo.
En el contexto de LATAM, donde los stakeholders (especialmente founders y C-level) tienden a pedir features muy específicas basadas en feedback anecdótico de clientes o competidores, un buen roadmap es tu mejor defensa contra el "featuritis" — la enfermedad de construir todo lo que alguien pide sin priorización estratégica.
Tipos de Roadmap
Existen diferentes formatos de roadmap, y cada uno sirve para una audiencia diferente:
- Roadmap basado en Outcomes (recomendado): Organizado por objetivos o problemas a resolver, no por features. "Q1: Reducir fricción en checkout" en lugar de "Q1: Agregar MercadoPago". Da flexibilidad al equipo para encontrar la mejor solución.
- Roadmap Now-Next-Later: Tres columnas que muestran qué estás haciendo ahora (alta certeza), qué harás después (media certeza), y qué podrías hacer más adelante (baja certeza). Ideal para startups LATAM que necesitan agilidad.
- Roadmap de Features (el clásico): Lista de features con timeline. Útil para comunicar externamente (clientes enterprise, partners), pero peligroso internamente porque genera expectativas de fechas fijas.
| Audiencia | Tipo de Roadmap | Nivel de Detalle |
|---|---|---|
| Board / Inversores | Outcome-based, trimestral | Alto nivel (temas estratégicos) |
| C-Level / Founders | Now-Next-Later | Medio (iniciativas y métricas) |
| Equipo de Producto | Sprint-level con user stories | Alto detalle (specs y acceptance criteria) |
| Clientes Enterprise | Feature-based con trimestres | Features principales sin fechas exactas |
Frameworks de Priorización
La priorización es donde se gana o se pierde como PM. No puedes construir todo — necesitas elegir las 2-3 cosas de mayor impacto y decir "no" al resto. Estos frameworks te ayudan a tomar esas decisiones con datos:
RICE Score
El framework más popular en equipos de producto. Evalúa cada oportunidad según:
- Reach (Alcance): ¿Cuántos usuarios impacta en un trimestre?
- Impact (Impacto): ¿Cuánto mejora la experiencia? (0.25 = mínimo, 3 = masivo)
- Confidence (Confianza): ¿Qué tan seguros estamos de los estimados? (100% = alta, 50% = baja)
- Effort (Esfuerzo): ¿Cuántas personas-semana requiere?
RICE Score = (Reach x Impact x Confidence) / Effort. Mayor score = mayor prioridad.
💼 Dato Importante
Un error común en startups LATAM es priorizar basándose únicamente en lo que el cliente más grande o más ruidoso pide. Los PMs que usan frameworks como RICE toman decisiones 2.5x más consistentes y logran 40% mejor impacto en métricas según un estudio de Intercom. La priorización basada en datos no es burocracia — es disciplina estratégica.
Opportunity Solution Trees (OST)
Teresa Torres popularizó este framework visual que conecta outcomes deseados con oportunidades descubiertas y posibles soluciones. La estructura es:
- Outcome deseado: El resultado que quieres lograr (alineado con tus OKRs)
- Oportunidades: Problemas o necesidades del usuario que, si resuelves, te acercan al outcome
- Soluciones: Múltiples posibles soluciones para cada oportunidad
- Experiments: Tests rápidos para validar qué solución es mejor
Diciendo "No" Efectivamente
La habilidad más importante de un PM es saber decir "no" — y hacerlo de forma que no destruya relaciones. En culturas latinas, donde la confrontación directa puede ser mal vista, necesitas técnicas específicas:
- "Sí, pero no ahora": Valida la idea, pero explica que hay cosas de mayor impacto primero. Muestra los datos (RICE score, métricas) que respaldan tu decisión.
- "Ayúdame a entender": Cuando un stakeholder pide una feature, pregunta "¿qué problema resuelve esto para el usuario?". Frecuentemente, el problema se puede resolver de forma más simple.
- El roadmap como escudo: Cuando tienes un roadmap claro basado en outcomes y datos, puedes señalarlo y decir "para incluir esto, ¿qué sacamos?"
Recuerda: cada "sí" a una feature es un "no" implícito a todo lo demás. Tu trabajo como PM es asegurar que los pocos "sí" que das sean los correctos para el negocio, los usuarios y el equipo.