Cómo anunciar una función nueva (sin silencio)
6 min de lectura
La mayoría de los anuncios de funciones mueren en un canal que nadie lee dos veces: un tuit que pasa desapercibido, un correo del día del lanzamiento enterrado bajo los otros doce que recibió una suscriptora esa semana, un mensaje de Slack en un canal que la mitad del equipo silenció hace meses. La función se lanzó. Casi nadie que la hubiera usado se enteró. Arreglar eso tiene menos que ver con escribir un mejor anuncio y más con elegir el canal correcto para la lectora correcta, y llegar directamente a quienes lo pidieron en lugar de confiar en que noten un mensaje general.
¿Dónde debería anunciarse realmente una función nueva?
En más de un sitio, porque “todo el mundo lee el mismo canal” nunca es cierto. Una entrada de changelog o feed sirve a la lectora que revisa según su propio ritmo y quiere el registro permanente y fechado. Un aviso dentro de la app sirve a la lectora que ya está usando el producto y usaría la función hoy si supiera que existe. El correo sirve a la lectora que no está actualmente en el producto pero volvería por la actualización adecuada. Las redes sociales sirven alcance más allá de las usuarias existentes, casi sin segmentación.
| Canal | Mejor para | Debilidad |
|---|---|---|
| Changelog / feed | El registro permanente; lectoras que revisan a su ritmo | No hace nada por quien nunca revisa |
| Aviso en la app | Usuarias que ya están ahí y actuarían hoy | No llega a nadie que no esté conectado ahora mismo |
| Correo | Usuarias inactivas que volverían por esto | Fácil de enterrar bajo otro correo; necesita un buen asunto |
| Redes sociales | Alcance más allá de las usuarias actuales | Casi sin segmentación; vida útil corta |
Ninguno de los cuatro basta por sí solo. El changelog es el único documento que debería llevar todo lanzamiento sin importar el tamaño, porque es el registro al que todo lo demás remite; los otros tres son amplificación añadida encima, elegida según lo grande que sea realmente la función.
¿Qué debería decir primero el anuncio?
El resultado, no el mecanismo. “Añadimos una capa de caché al endpoint de informes” describe lo que construyó el equipo. “Los informes ahora cargan en menos de un segundo” describe lo que cambió para la lectora, y esa es la frase que consigue el clic, porque responde “qué gano yo con esto” en la primera cláusula en vez de en la tercera. El mecanismo pertenece a la entrada del changelog o a la página de detalle, no al titular.
Ir con datos concretos por delante de los adjetivos. “Una experiencia de informes más rápida y potente” no le dice a la lectora nada sobre lo que puede hacer; “los informes ahora cargan en menos de un segundo y se pueden filtrar por estado” le dice exactamente qué cambió y qué probar. La segunda versión también resulta más creíble, porque una afirmación vaga suena exactamente como suena el texto de marketing cuando no hay nada concreto que decir.
¿En qué se diferencia de un correo de actualización de producto?
Se solapan pero no son lo mismo. Correo de actualización de producto cubre el canal de correo específicamente, incluida la cadencia, los asuntos, y cuándo un resumen supera a un envío puntual. Un anuncio de función nueva es el evento subyacente; el correo es uno de los cuatro canales anteriores que podría llevarlo, elegido cuando la función es lo bastante grande como para justificar un envío dedicado en lugar de ir dentro del próximo resumen. Una función pequeña se gana una entrada de changelog y quizá un aviso en la app. Una significativa se gana los cuatro canales, coordinados en el tiempo.
¿Cómo llegar a las personas concretas que lo pidieron?
Este es el anuncio con mejor retorno que casi todos los equipos se saltan. Si diez clientes
pidieron una función por su nombre, esas diez personas merecen una nota directa y personal en el
momento en que se lanza, al margen de cualquier anuncio más amplio que salga. Cerrar el círculo de feedback con el cliente
cubre la mecánica completa; el resumen aquí es que esto solo funciona si la solicitud original
quedó vinculada a quien la pidió, lo cual es más un problema de seguimiento
que un problema de anuncio. En changeloop, cuando el feedback del widget se convirtió en un issue
de GitHub y el pull request mergeado lo cierra (fixes #142), aprobar la entrada del changelog
publica una sola vez el comentario “Shipped —
¿Cómo se escribe la propia entrada?
La misma disciplina que cualquier otra entrada de notas de la versión: empezar con lo que la lectora ya puede hacer, seguir con la configuración necesaria, y saltarse la justificación interna. Cómo escribir notas de la versión cubre el método completo; un anuncio de función nueva es el caso de mayor riesgo, porque es la entrada con más probabilidades de capturarse en pantalla, reenviarse y ser leída por alguien que nunca ha visto el changelog del producto.
¿Cuándo no conviene anunciar algo ampliamente?
Cuando la función todavía se está desplegando a un subconjunto de cuentas, es realmente una beta, o tiene un precio o un bloqueo tal que nueve de cada diez lectoras de un anuncio amplio todavía no podrían usarla. Un anuncio amplio para una función que nueve de cada diez lectoras no pueden usar se lee como un anzuelo, y quema la confianza en el próximo anuncio más de lo que genera entusiasmo en este. La solución no es el silencio, es el alcance: avisar directamente a las cuentas elegibles y guardar los canales amplios hasta que la disponibilidad alcance al anuncio.
FAQ
¿Toda función nueva merece su propio anuncio? Todas se ganan una entrada de changelog. Solo las lo bastante significativas como para cambiar cómo alguien usa el producto, o las que se pidieron por nombre explícitamente, se ganan los canales más amplios como el correo o las redes sociales.
¿Cuál es el mejor canal para una función pequeña? Solo el changelog, más un aviso en la app si la función es descubrible dentro de un flujo en el que la usuaria ya está. El correo y las redes sociales merecen la pena para funciones que justifican pedir atención.
¿Cómo se anuncia una función a las personas que específicamente la pidieron? Mantener la solicitud vinculada a quien la pidió desde el momento en que se registra, y notificar individualmente cuando se lanza, aparte de cualquier anuncio más amplio. Una etiqueta de estado compartida que quien pidió algo pueda comprobar también reduce cuántos mensajes individuales hacen falta en primer lugar.
¿Necesita una captura de pantalla el anuncio de una función? Para cualquier cosa visual, sí; una función descrita pero no vista se salta con mucha más frecuencia que una de la que las lectoras pueden ver una vista previa. Para una API o una capacidad de backend, un fragmento de código breve cumple la misma función que una captura de pantalla en un cambio de interfaz.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.