---
name: roadmap-update
description: Redacta una actualización del roadmap de producto para las partes interesadas (dirección, ventas, CS, inversores o clientes) en formato Ahora, Después, Más adelante (Now, Next, Later), vinculada a resultados, con lo que se ha movido desde la última actualización y por qué, lo que el equipo no va a hacer, los compromisos firmes aparte y peticiones claras. Úsala cuando alguien pide una actualización del roadmap, una actualización de producto para el equipo, una revisión trimestral del roadmap o “qué viene y qué ha cambiado” a partir de un backlog, notas de planificación o el último roadmap.
---

# Actualización del roadmap

Quien lee una actualización del roadmap quiere saber tres cosas: qué ha cambiado, por qué y qué significa para su trabajo. Empieza por lo que se ha movido. Vincula cada elemento al problema o resultado al que sirve, pon fechas solo a los compromisos reales y di sin rodeos lo que el equipo no va a hacer, para que nadie planifique contando con ello.

## Cuándo usarla

- Revisiones mensuales o trimestrales del roadmap para dirección, ventas, CS o el consejo.
- Después de un cambio de prioridades, cuando la gente necesita saber qué se ha retrasado y por qué.
- Para una nota de “lo que viene” dirigida a clientes (con un filtro más estricto, ver el paso 6).
- No sirve para trabajo ya lanzado: usa release-notes. Tampoco para decidir prioridades: usa antes feature-prioritization.

## Qué necesitas

- El roadmap actual o la lista de iniciativas con su estado.
- La última actualización, para mostrar qué se ha movido. Si falta, pídela una vez; si no, escribe “primera actualización, sin cambios que mostrar”.
- Los motivos de cada cambio. Si no te dan un motivo, escribe “[comprobar: motivo]” en vez de inventarlo.
- El público. Por defecto, la dirección interna.

## Pasos

1. **Ordena en Ahora, Después, Más adelante.** El formato Now-Next-Later de Janna Bastow: Ahora = en curso y bien definido; Después = lo que sigue cuando termine Ahora, con menos detalle; Más adelante = problemas más grandes que todavía no se han desglosado en soluciones. Las columnas no tienen por qué tener el mismo tamaño.
2. **Escribe cada elemento como un problema o un resultado.** “Reducir el tiempo hasta la primera factura de 2 días a 1 hora”, no “Asistente de facturas”. Vincúlalo al objetivo de negocio al que sirve. Esto sigue la idea de Marty Cagan de que un roadmap debe indicar el problema y el resultado, no ser solo una lista de funciones.
3. **Muestra qué se ha movido y por qué.** Compara con la última actualización. Para cada elemento que cambió de columna, se añadió o se quitó, da un motivo: evidencia nueva, un compromiso con un cliente, capacidad, una dependencia. Pon esta sección primero.
4. **Separa los compromisos.** Los elementos con una fecha prometida (un contrato, un plazo legal, un evento de lanzamiento) van en su propia lista con la fecha y el responsable. Cagan los llama compromisos de alta integridad (high-integrity commitments); todo lo demás va sin fecha.
5. **Di lo que no vamos a hacer.** Enumera de 2 a 5 peticiones que el equipo decidió descartar o aparcar, con el motivo. Ventas y CS son quienes más lo necesitan.
6. **Adapta al público.** Dirección: resultados, riesgos, decisiones pendientes. Ventas y CS: qué decir a los clientes y qué no prometer. Clientes: solo Ahora y Después, sin nombres internos, sin fechas salvo las comprometidas, y “los planes pueden cambiar” dicho una vez.
7. **Termina con peticiones.** Nombra la decisión, el recurso o la aportación que necesitas, de quién y para cuándo. Si no hay peticiones, escribe “Sin peticiones esta vez”.

## Formato de salida

```markdown
# Actualización del roadmap — [periodo]

**Para:** [público] · **Desde la última actualización:** [fecha]

## Qué ha cambiado
- **[Elemento]** pasó [de → a] — [motivo]
- **Añadido:** [elemento] — [motivo]
- **Quitado:** [elemento] — [motivo]

## Ahora
- **[Resultado]** — [objetivo al que sirve] · [estado: en plazo / en riesgo] · [responsable]

## Después
- **[Resultado]** — [objetivo al que sirve]

## Más adelante
- **[Problema que resolver]**

## Compromisos con fecha
| Compromiso | Fecha | Responsable | Estado |
|---|---|---|---|

## Lo que no vamos a hacer
- [Petición] — [motivo]

## Peticiones
- [Petición] — [a quién] antes del [fecha]
```

## Ejemplo

**Entrada:** “Actualización de mayo para dirección. Hacemos software de facturación para propietarios de pequeños negocios. El mes pasado, Ahora era: recordatorios automáticos de facturas vencidas, exportación a CSV. Después: licencias de solo lectura para que los propietarios compartan su contabilidad con su contador, app móvil. La exportación a CSV ya salió. Los recordatorios automáticos se retrasaron porque las entrevistas mostraron que los propietarios reclaman los pagos atrasados por SMS, no por email; los estamos redefiniendo para SMS. El SSO está prometido a Norvento para el 30 de junio. Dejamos la app móvil por ahora; solo el 2 % de las sesiones son desde el celular. Necesitamos decidir si CS puede prometer a los clientes las licencias de solo lectura.”

**Salida:**

```markdown
# Actualización del roadmap — mayo

**Para:** dirección · **Desde la última actualización:** [fecha]

## Qué ha cambiado
- **Exportación a CSV** lanzada (sale de Ahora).
- **Recordatorios de pago** sigue en Ahora, redefinido para SMS — las entrevistas mostraron que los usuarios reclaman por SMS, no por email.
- **Añadido:** SSO para Norvento — prometido a Norvento para el 30 de junio.
- **Quitado:** app móvil — el 2 % de las sesiones son desde el celular.

## Ahora
- **Cobrar las facturas vencidas sin perseguirlas a mano** (recordatorios de pago por SMS) — objetivo de retención [comprobar: nombre] · en riesgo (redefinido) · [responsable]
- **SSO para Norvento** — compromiso con un cliente · [comprobar: estado] · [responsable]

## Después
- **Que los propietarios compartan su contabilidad con su contador** (licencias de solo lectura) — objetivo de expansión [comprobar: nombre]

## Más adelante
- **Usar el producto desde el celular** — revisar si crecen las sesiones desde el celular.

## Compromisos con fecha
| Compromiso | Fecha | Responsable | Estado |
|---|---|---|---|
| SSO para Norvento | 30 de junio | [responsable] | [comprobar: estado] |

## Lo que no vamos a hacer
- App móvil — el 2 % de las sesiones son desde el celular; aparcada por ahora.
- Recordatorios solo por email — los usuarios nos dijeron que reclaman por SMS.

## Peticiones
- ¿Puede CS decir a los clientes que llegan las licencias de solo lectura? Está en Después, no comprometido. — decisión de [dirección] antes del [fecha]
```

## Comprobaciones antes de enviar

- [ ] “Qué ha cambiado” va primero y cada movimiento tiene un motivo sacado de la entrada o “[comprobar: motivo]”.
- [ ] Cada elemento de Ahora y Después está escrito como resultado o problema, no solo como nombre de una función.
- [ ] Solo los compromisos llevan fecha.
- [ ] “Lo que no vamos a hacer” tiene al menos 2 elementos, o dice por qué está vacío.
- [ ] Cada petición nombra quién decide y para cuándo.
- [ ] La versión para clientes no tiene nombres internos, responsables ni fechas no comprometidas.

## Errores comunes

- Poner fechas a los elementos de Después y Más adelante para parecer seguros. Esas fechas se reenvían como promesas.
- Esconder un retraso dentro de la lista de Ahora. Ponlo en “Qué ha cambiado” con el motivo.
- Enumerar 20 elementos. Deja en Ahora solo lo que el equipo está haciendo de verdad en este periodo.