En los dos artículos anteriores vimos cómo medir la adopción y a detectar fricción cuando una funcionalidad no mejora su uso. Hay un tercer escenario que la mayoría de equipos evitan, y que tiene tanta importancia como construir: retirar una funcionalidad del producto.
En el día a día probablemente lo llamas sunsetting o deprecación, que es como se conocen en la jerga de producto. En este artículo lo voy a llamar retirar o retirada de funcionalidades porque es lo natural en castellano y porque es el primer aviso a tu equipo: una retirada es un acto activo de producto, no una rendición.
Quédate con:
Tu producto no son solo las funcionalidades que tiene, es también las que ha decidido no tener.
En este artículo vas a ver cuándo plantearte una retirada de funcionalidades, cinco pasos con datos para tomar la decisión, cómo comunicarla interna y externamente, y un matiz importante: no toda funcionalidad mal adoptada se retira, algunas se reposicionan.
Seguimos usando el ejemplo de Algora porque tienen el candidato perfecto sobre la mesa: «compartir borrador», el «falso aha» del artículo cómo encontrar los aha moments de tu producto.
Por qué retirar también es construir producto
Hay una idea que conviene asentar antes, los productos buenos crecen tanto por lo que añaden como por lo que quitan a tiempo. Y, sin embargo, casi todos los equipos pasan diez veces más horas debatiendo qué construir que qué retirar. Construir tiene narrativa, presentaciones, lanzamientos, retirar es silencioso, incómodo, y casi siempre se pospone hasta que la deuda de producto se vuelve insoportable.
Cuando se hace bien, retirar tiene tres beneficios concretos para tu producto:
- Experiencia más limpia: Menos opciones en la navegación, menos confusión para el usuario nuevo, menos decisiones que tomar para empezar a usar el producto.
- Menos coste de mantenimiento: Cada funcionalidad viva consume tiempo de ingeniería, de soporte, de documentación, de QA en cada lanzamiento.
- Menos confusión interna: Cuando un PM nuevo entra al equipo, las funcionalidades zombi le hacen perder semanas entendiendo qué se usa y qué no.
Y hay un cuarto beneficio menos obvio que es liberar atención del equipo, cada funcionalidad existente sigue compitiendo por sprints, por discusiones de roadmap, por dashboards. Retirarla saca esa funcionalidad del ruido y deja espacio mental para lo que sí importa.
Cuándo plantearte una retirada
No toda funcionalidad poco usada es candidata. Hay tres catalizadores que justifican abrir la conversación:
- Uso bajo y decreciente sostenido durante varios trimestres: No un mal mes, sino una curva que lleva cayendo más de seis meses sin causa puntual identificable.
- Aparece una funcionalidad nueva que la reemplaza mejor: Tienes el equivalente funcional dentro del producto y mantener las dos solo desorienta.
- Feedback recurrente que la señala como obsoleta: No «no me gusta», sino «esto ya no resuelve mi problema porque ahora hago las cosas de otra manera».
Conecta con la matriz de ejemplo del artículo 13 que tienes abajo, las candidatas a retirada viven en el cuadrante baja adopción + baja retención (sunset o fix). Pero antes de retirar nada, conviene plantear la siguiente pregunta ¿es realmente baja adopción global, o solo lo es en el segmento que estás mirando?
Cuándo NO retirar (los tres falsos positivos típicos)
Como contrapunto al apartado anterior, conviene saber cuándo lo que parece una funcionalidad candidata a retirada no lo es.
Los tres falsos positivos que he vivido:
- Confundir baja adopción con baja visibilidad: Si la funcionalidad existe y funciona pero está enterrada en un submenú o no aparece en el onboarding, el problema puede ser de distribución, no de valor. Antes de retirar, prueba con una palanca de visibilidad (ver artículo 15) y mide tres meses después.
- Confundir baja adopción con mala activación: Hay funcionalidades que la gente nunca llega a usar porque se atascan en el camino. No es que no aporten valor, es que el usuario no llega. Eso es problema de fricción (ver artículo 16), no de funcionalidad. Atacar la fricción y reevaluar antes de plantear retirada.
- Confundir baja adopción con valor concentrado en un segmento crítico: Es el más caro de los tres. Una funcionalidad con 8% global y 75% en tus mejores cuentas Enterprise no es una candidata a retirada, es una palanca de retención de tu segmento más valioso, mira siempre por segmento antes de decidir.
Las tres confusiones tienen algo en común: se cometen cuando se mira la métrica agregada y no se baja al detalle, cualquier retirada que se proponga «solo viendo el dashboard» debería pasar por estos tres filtros antes de entrar en discusión.
Los cinco pasos para retirar con datos
Una vez identificada la funcionalidad candidata, el proceso de decisión es el que evita romper la retirada.
1. Empieza por el uso
¿Es uso esporádico o habitual? ¿Hay estacionalidad? Una funcionalidad de «exportación anual para auditoría» puede parecer muerta once meses al año y ser crítica en uno de ellos. Antes de declarar baja una funcionalidad, mira la curva con un horizonte de al menos un año.
2. Profundiza en engagement
Aquí estás midiendo comportamiento, tiempo en pantalla, número de clics, paths antes y después. ¿La gente que la usa la usa de verdad, o entra por accidente y se va? Una funcionalidad con muchos accesos pero engagement muy bajo casi siempre es ruido (clics involuntarios, entradas desde navegación), no uso real.
3. Mira segmentos
Es uno de los pasos que más decisiones cambia, una funcionalidad puede tener un 8% de adopción de media y un 75% en tus diez mejores cuentas Enterprise. Retirarla cuando es el segmento valioso quien la usa es un error que te saldrá caro. Mira siempre quién la usa por rol, plan, segmento y antigüedad antes de decidir.
Y aquí va el error más común que conviene tener en cuenta: asumir que una funcionalidad con pocos usuarios tiene poco valor. Muchas veces ocurre justo lo contrario, algunas funcionalidades tienen poca adopción porque resuelven un problema muy específico, pero ese problema lo sufren los usuarios más valiosos del negocio. Baja adopción no equivale a bajo valor, equivale a valor concentrado, que es una cosa muy distinta y a menudo más interesante.
4. Usa feedback para entender el porqué
Aquí estás midiendo motivación, que es algo muy distinto del paso anterior, los datos te dicen qué hacen, las conversaciones te dicen por qué lo hacen. Habla con los que la usan, no con los que se quejan. Es probable que tengan un caso de uso que ni tu equipo había imaginado, y en ese caso de uso, puede ser legítimo o puede revelar que la funcionalidad está supliendo un agujero de otra parte del producto.
5. Monitoriza el impacto tras la retirada
Después de quitarla, mira durante al menos dos meses cuatro cosas: churn en los segmentos afectados, NPS, tickets de soporte, paths que toman los usuarios que antes la usaban (¿van a una alternativa o salen del producto?).
La retirada no termina el día del deslanzamiento, termina cuando confirmas que no rompió nada.
El caso de Algora ¿retirar «compartir borrador»?
Apliquemos el proceso al ejemplo que llevamos durante todo el artículo, en el artículo 13, Algora tenía la funcionalidad «compartir borrador» en el cuadrante de falso aha (82% adopción, 35% retención semanal). Mucha gente la tocaba, pero pocos volvían. Parecía candidata clara a retirada: no por baja adopción, sino porque estaba ocupando un espacio central del producto (home + paso 1 del onboarding) sin generar retención. Una funcionalidad que se come la atención del usuario nuevo y no le entrega valor es, en la práctica, igual de cara que una funcionalidad muerta.
El PM aplica los cinco pasos antes de decidir:
- Uso: confirmado. El 82% de cuentas la tocan al menos una vez al mes. No hay estacionalidad.
- Engagement: la mayoría la toca una o dos veces y la abandona. Solo el 15% de los usuarios la usa de forma sostenida.
- Segmentos: ese 15% no son cuentas Enterprise (el objetivo del año). Son cuentas pequeñas que llevan más de seis meses en el producto.
- Feedback: las cuentas pequeñas y medianas que la usan explican que les sirve para «ver el borrador del contrato como lo va a recibir el cliente final antes de mandárselo», caso de uso real, no anomalía.
El PM se sienta a decidir y aparece la nota más importante del artículo: no toda funcionalidad mal adoptada se retira, algunas se reposicionan.
La decisión final no es retirar, es reposicionar y simplificar:
- Mover de la home a un menú secundario, fuera del flujo principal.
- Renombrar a «vista previa para compartir», que describe mejor el caso de uso real.
- Sacarla del onboarding obligatorio, donde estaba induciendo a falso aha.
- Revisar en seis meses con datos nuevos para confirmar que el 15% de SMB sigue usándola y decidir entonces si retirar de verdad.
Una funcionalidad en el cuadrante «falso aha» no siempre se retira. A veces solo se le quita el protagonismo que no merecía. Esa distinción es lo que separa un equipo que entiende su matriz de uno que la aplica de forma mecánica.
Cómo comunicar una retirada (interna y externa)
Si la decisión es retirar de verdad, la comunicación importa tanto como la decisión. Una retirada mal comunicada genera más churn que la propia retirada.
Comunicación interna
Los equipos de customer success, ventas y soporte deben enterarse mucho antes que los clientes. Si descubren la retirada el día del anuncio público, te van a llamar a las dos horas pidiendo explicaciones.
Pasos lógicos a seguir:
- Aviso al equipo interno con al menos 2 semanas de antelación.
- Documento corto con el porqué (uso, datos, caso de uso, alternativa).
- Plantilla de respuesta para soporte y ventas: cómo explicarlo al cliente.
- Lista de cuentas afectadas para que customer success las contacte una a una si son cuentas grandes.
Comunicación externa
No es un anuncio masivo a toda la base, identifica con datos a quienes aún la usan (los del 15% de Algora) y comunícalo en orden:
- Aviso anticipado (60-90 días antes de la retirada).
- Educación sobre la alternativa: si hay una funcionalidad que la reemplaza, enseña cómo migrar con un vídeo de dos minutos o una guía in-app.
- Instrucciones de migración de datos si la funcionalidad almacena algo del cliente. Esto es no negociable, el cliente debe poder exportar o conservar su trabajo.
- Recordatorio a 30 días y a 7 días.
- Botón de contacto directo para cuentas grandes que tengan dudas.
Y cuidado, nunca retires en el peor momento del cliente. Cierre fiscal, periodo de auditoría, vuelta tras vacaciones grandes, lanzamiento de su temporada alta. Si tu producto sirve a operadores turísticos, retira en noviembre, no en junio. Esto parece obvio, pero se olvida todo el rato.
Retira cuando menos pueda afectar a tus clientes.
Resumen rápido
- Retirar también es construir producto: Un buen producto se define tanto por las funcionalidades que quitas (o rechazas) como por las que añades.
- Tres señales para abrir la conversación: uso bajo decreciente sostenido, funcionalidad sustituta dentro del producto, feedback que la marca como obsoleta.
- Tres falsos positivos que conviene descartar antes de retirar: baja adopción confundida con baja visibilidad, con mala activación o con valor concentrado en un segmento crítico.
- Cinco pasos con datos: Uso, engagement (comportamiento), segmentos, feedback (motivación) y monitorización post-retirada. Mirar segmentos es lo que más decisiones cambia.
- No toda funcionalidad mal adoptada se retira: Algunas se reposicionan, quitarles protagonismo y revisarlas con datos nuevos meses después.
- La comunicación importa tanto como la decisión: Equipos internos avisados con cuatro semanas, clientes afectados identificados con datos, no comunicación masiva. Nunca retires en el peor momento del cliente.
Siguiente paso
Cerramos el bloque IV del curso de analítica de producto, hemos visto los cinco casos prácticos del PM con analítica: aha moments, priorización, adopción, fricción y retirada.
Y fíjate en algo del caso de ejemplo de Algora que conviene rescatar antes de seguir: la decisión sobre «compartir borrador» no se tomó mirando solo adopción, se tomó entendiendo qué impacto tenía sobre el negocio (los Enterprise que son objetivo del año) y sobre los clientes que más importaban (las pequeñas y medianas cuentas de seis meses que sí la usan).
Durante cinco artículos has aprendido a medir comportamiento, a partir de ahora toca responder la pregunta que de verdad importa a un PM:
¿Qué impacto tiene ese comportamiento en el negocio?
Ese es precisamente el siguiente nivel y abre el bloque V del curso.
De product outcomes a business outcomes: cómo conectar producto y negocio →
