Planteamiento y alcance
Una guía pública de entrevistas para product manager de 2026 incluye la pregunta: “Cuéntame sobre alguna ocasión en la que diste de baja una funcionalidad o un proyecto”. En ella se solicita a los candidatos que indiquen los datos que cambiaron la decisión, el costo hundido, el impacto en las partes interesadas y la lección aprendida. El objetivo no es demostrar que una funcionalidad fracasó; es mostrar que puedes redirigir la capacidad operativa desde una vía de bajo valor hacia un resultado más importante para el usuario. Este artículo aborda la estructura de la decisión y de la narrativa, no una regla de baja automática basada en una sola métrica.
Qué evalúa el entrevistador
El entrevistador busca ver un resultado para el usuario definido antes de seleccionar las métricas, así como una distinción entre “nadie la descubrió”, “el descubrimiento no aportó valor” y “el uso perjudicó la experiencia principal”. La investigación HEART de Google propone asociar Objetivos con Señales y Métricas (Goals-Signals-Metrics), y luego triangular la evidencia conductual y actitudinal. Una respuesta sólida expone el costo de oportunidad de continuar invirtiendo, la prueba reversible empleada y la condición de salida.
Preguntas de clarificación que debes hacerte
- ¿Estás finalizando una fase de exploración, pausando un lanzamiento o eliminando una funcionalidad ya adoptada? Cada ciclo de vida conlleva riesgos de migración y comunicación diferentes.
- ¿A qué resultado del usuario responde la funcionalidad? Si el objetivo es el tiempo de finalización de una tarea, guiarse solo por los clics puede ser engañoso.
- ¿Qué usuarios requieren cohortes separadas? Los usuarios nuevos, de pago y de alta frecuencia pueden presentar tasas de adopción y retención distintas.
- ¿Existen compromisos legales, contractuales o de migración? Estos pueden requerir acceso de solo lectura o un período de notificación más prolongado.
- ¿La evidencia es correlacional o causal? Los experimentos, grupos de control, entrevistas y tickets de soporte respaldan distintos niveles de certeza.
Una respuesta en 30 segundos
“Fui responsable de la funcionalidad X, cuyo objetivo era el resultado de usuario Y, basado en el supuesto Z. Tras el lanzamiento, segmenté la adopción, el éxito en la tarea y las contramétricas. La evidencia no respaldó el supuesto y continuar invirtiendo habría desplazado al proyecto Q. Realicé una prueba reversible de pausa o despliegue gradual, alineé a ingeniería, soporte y clientes afectados respecto a la migración, y luego di de baja la funcionalidad para transferir la capacidad operativa a Q. Sustituye el resultado por tu métrica real; mi lección aprendida fue definir un criterio de salida desde la fase de descubrimiento.”
Respuesta paso a paso
1. Define por qué continuar podría ser valioso
Redacta el objetivo como un resultado visible para el usuario, por ejemplo “una configuración inicial se completa en una sola sesión”, y luego enumera señales observables: finalización, tiempo hasta obtener valor, uso recurrente y contactos de soporte. El proceso Goals-Signals-Metrics de Google advierte contra el uso de un conteo de visitas a páginas (fácil de recopilar) como sustituto del éxito real.
2. Utiliza cohortes y contramétricas para localizar el problema
Compara usuarios nuevos y existentes, niveles de planes, plataformas y frecuencia de uso. Una baja adopción puede indicar una descubribilidad deficiente o poca relevancia; una alta adopción aun así puede coincidir con errores, reembolsos o sobrecarga en soporte. Emplea embudos de conversión, retención y retroalimentación cualitativa para distinguir entre “sin uso” y “perjudicial”, indicando la cobertura de los datos y los límites de la muestra.
3. Compara tres caminos y su costo de oportunidad
Plantea la iteración continua, una pausa de aprendizaje y la baja definitiva con migración en una sola matriz de decisión. Iterar preserva el potencial de mejora pero consume capacidad de ingeniería; una pausa pone a prueba el supuesto clave a bajo costo; la baja libera capacidad pero conlleva costos de migración, contractuales y de confianza. No necesitas una precisión ficticia, pero debes declarar los criterios de priorización y los efectos irreversibles.
4. Diseña la salida y la migración
Dar de baja no consiste en presionar un botón de eliminar. Congela el punto de entrada para nuevos usuarios, preserva el acceso de lectura o exportación para los usuarios existentes, anuncia la vía de sustitución y, posteriormente, elimina tareas programadas, métricas y documentación de soporte. Asigna a cada paso un responsable, una fecha y una condición de reversión. Si la evidencia solo justifica una pausa, no la califiques como una eliminación definitiva.
Respuesta modelo
“Fui responsable de una funcionalidad de exportación de reportes para equipos pequeños. Esperábamos que redujera las exportaciones asistidas por soporte técnico. Tras el lanzamiento, segmenté los datos por tamaño de equipo y plan: las cuentas grandes la adoptaron, pero los equipos pequeños rara vez completaban una primera exportación, y las fallas incrementaron los tickets de soporte. Realizamos un pequeño experimento con una guía más sencilla y confirmamos que el problema principal radicaba en la explicación de los permisos, no en la falta de formatos. Aun después de corregir los textos, la tasa de finalización no alcanzó el umbral previamente acordado, mientras que ingeniería preparaba un nuevo modelo de permisos. Propuse congelar el acceso a nuevos usuarios, preservar las descargas y la migración de datos para los reportes existentes, notificar a los clientes afectados y trasladar la capacidad operativa a un reporte de mayor frecuencia de uso. Sustituye el resultado con tu métrica real. Mi lección aprendida fue incorporar la adopción segmentada y el costo de soporte dentro de los criterios de salida desde la fase de descubrimiento.”
Errores comunes
- “La adopción era baja, así que la eliminamos” → falta de objetivo de usuario o cohorte → define el objetivo, las señales, la muestra y las contramétricas.
- Usar únicamente el promedio → el riesgo concentrado desaparece → segmenta por ciclo de vida, plan y plataforma, e informa la cobertura.
- Llamar baja a una pausa → se omite la responsabilidad de la migración → distingue entre experimento, congelamiento, modo de solo lectura y eliminación definitiva.
- Dejar que el costo hundido justifique la continuidad → el gasto pasado no garantiza valor futuro → compara el gasto restante frente a la oportunidad alternativa.
- Inventar un porcentaje → el resultado no resiste las preguntas de seguimiento → utiliza una métrica real o aclara que es un valor de ejemplo.
- Ignorar las contramétricas → los clics pueden subir mientras la confianza cae → monitorea errores, reembolsos, quejas o retención.
Preguntas de seguimiento y extensiones
¿Qué pasa si un cliente de alto valor aún depende de la funcionalidad?
Verifica primero el contrato, el plazo de migración y la alternativa de reemplazo, y luego calcula el costo de retención por cohorte de clientes. Mantén el acceso de solo lectura o de exportación, amplía el período de notificación y documenta las excepciones; no ocultes el riesgo concentrado detrás de un promedio general.
¿Qué pasa si los datos no son lo suficientemente sólidos para justificar la baja?
Convierte la mayor incertidumbre en un experimento mínimo viable con una muestra, ventana de observación y regla de detención predefinidas. Congela la inversión no esencial durante el aprendizaje para que el equipo no amplíe la apuesta sin evidencia.
¿Cómo respondes si el equipo de ingeniería muestra resistencia tras haber invertido mucho esfuerzo?
Reconoce el trabajo realizado, separa los componentes reutilizables de los costos irrecuperables y compara la inversión futura, el resultado para el usuario y el proyecto alternativo. Involucra al equipo en la migración y la reutilización para que la decisión no se perciba como un rechazo a su trabajo.
¿Qué pasa si las métricas repuntan tras la baja?
Revisa la estacionalidad, los fallos de migración y las modificaciones en las mediciones antes de restaurar cualquier elemento. Si el resultado del usuario realmente empeoró, revisa la condición de salida original mediante un despliegue gradual y reversible; un repunte no implica un retorno automático a la hoja de ruta anterior.