Escribe el anuncio de cada cambio desde el punto de vista de quien lo usa, con la jerarquía correcta según el impacto y el aviso previo cuando el cambio rompe algo.
Cuándo usarlo: Clasificar los cambios de producto por impacto y redactar notas de versión, avisos previos y guía interna para soporte y ventas
Herramienta recomendada: Claude
Actúa como product manager que ha visto dos cosas: notas de versión que nadie abre y cambios silenciosos que generan una avalancha de tickets. Quiero un sistema de comunicación de cambios proporcionado al impacto. ## Contexto que necesito 1. Los cambios de este ciclo, con una línea cada uno. 2. Quién usa el producto y con qué frecuencia entra. 3. Canales disponibles: notas en la app, correo, centro de ayuda, comunidad, comercial. 4. Si hay clientes con integraciones o API. ## Paso 1 — Clasificar por impacto | Nivel | Definición | Comunicación | |---|---|---| | Rompe | Algo deja de funcionar como antes | Aviso previo con plazo, correo directo, guía de migración | | Cambia el flujo | La tarea se hace de otra forma | Aviso en la app antes y durante, ayuda actualizada | | Añade | Función nueva opcional | Notas de versión, y anuncio si es relevante | | Mejora | Rendimiento, corrección, detalle | Notas de versión agrupadas | | Interno | Sin efecto visible | No se comunica | El error más caro es tratar un cambio de nivel «rompe» como si fuera «mejora». El segundo más caro es enviar un correo a toda la base por una corrección menor: eso entrena a la gente a ignorar tus correos. ## Paso 2 — Redacción, cambio a cambio Para cada uno, tres líneas con esta estructura: 1. **Qué puedes hacer ahora** (en segunda persona, con el verbo de la acción del usuario). 2. **Por qué te importa** (el problema que resuelve, no la tecnología). 3. **Cómo se usa** (dónde está, en una frase o con un enlace). Nada de «hemos refactorizado el módulo de exportación para mejorar la eficiencia». Sí a «ahora puedes exportar más de 10.000 filas sin que se corte». ## Paso 3 — El caso de los cambios que rompen Plantilla completa: qué cambia, cuándo exactamente, por qué lo hacemos, a quién afecta (con criterio para que cada uno sepa si le toca), qué tiene que hacer, hasta cuándo funciona lo antiguo, y a quién escribir si se atasca. Enviado con antelación proporcional al trabajo que exige, y repetido cerca de la fecha. ## Paso 4 — Formato de las notas - Agrupadas por área del producto, no por sprint ni por número de versión. - Lo importante arriba; las correcciones, en una lista al final. - Sin números de ticket internos ni jerga de equipo. - Con fecha y con enlace permanente para poder citarlas. ## Paso 5 — Uso interno Prepara la versión para el equipo: qué contar a soporte antes del lanzamiento (con las preguntas que van a llegar y su respuesta), y qué contar a ventas (qué se puede prometer y qué no). ## Entregables 1. Los cambios clasificados por nivel de impacto. 2. Notas de versión completas, listas para publicar. 3. El correo de aviso de los cambios que rompen. 4. Guía interna para soporte y para ventas. 5. Calendario de envíos, con antelación por tipo de cambio.