Planteamiento y contexto
Esta pregunta de entrevista de producto evalúa si puedes transformar un "bajo uso" en una decisión de producto verificable. Retirar una función afecta los user jobs, los compromisos de ventas, los flujos de trabajo de soporte y el mantenimiento de ingeniería, por lo que una sola métrica de uso no es suficiente. Necesitas definir el problema, identificar a los grupos afectados, comparar el costo de mantenimiento frente al de migración y diseñar una validación por etapas junto con controles de salida.
Qué está evaluando el entrevistador
- Si distingues entre tareas de baja frecuencia pero críticas y funcionalidades genuinamente de bajo valor.
- Si utilizas segmentos, rutas alternativas y evidencia de clientes en lugar de un único umbral universal.
- Si puedes estructurar por etapas el descubrimiento, la validación, la migración, la comunicación y el apagado.
- Si explicas en conjunto el valor para el cliente, el riesgo comercial, el costo técnico y las métricas de éxito.
Preguntas de clarificación para hacer
Primero, aclara el denominador y la ventana de tiempo detrás del "3%": ¿todas las cuentas, las cuentas activas o las cuentas elegibles para la función? ¿Cuál es la frecuencia de los usuarios, el éxito en sus tareas, su estado de renovación y sus compromisos contractuales? ¿Se utiliza la función indirectamente a través de una API, exportación, auditoría o flujo de soporte? ¿Existe una alternativa equivalente y cuáles son su tasa de finalización y su costo de migración? Aclara también las dependencias de versiones, los requisitos de cumplimiento normativo regional, los períodos de notificación al cliente y los plazos aceptables para el apagado.
Estructura para una respuesta de 30 segundos
No tomaría una decisión basándome únicamente en el 3%. Verificaría el denominador, los user jobs y la exposición a nivel de ingresos o cumplimiento, para luego segmentar a los clientes en usuarios críticos de alto valor, usuarios de baja frecuencia con alternativas viables y casos de uso ineficaz. Compararía el mantenimiento continuo, la limitación de nuevas activaciones, la migración y el apagado total; luego, ejecutaría una prueba piloto de migración reversible con un grupo pequeño y mediría el éxito de las tareas. Solo retiraría la función de forma gradual una vez que la alternativa cumpla con los umbrales predefinidos, los clientes críticos confirmen el plan y soporte y ventas estén preparados, contando con rutas explícitas de recuperación y excepciones.
Análisis detallado paso a paso
1. Traducir el bajo uso en user jobs
Segmenta por cuenta, rol, región, plan, compromiso contractual y antigüedad de uso. Observa los jobs, la frecuencia, la tasa de éxito y los motivos de falla. Más allá de los registros de acceso, inspecciona llamadas a API, exportaciones, tickets, compromisos de ventas y registros de cumplimiento. Una baja frecuencia puede significar "utilizada únicamente en un momento crítico", o bien una baja visibilidad o una experiencia fallida; estas situaciones requieren acciones de producto diferentes.
2. Definir el costo y las condiciones de la alternativa
Construye un modelo de costos para el mantenimiento continuo, la retención en modo de solo lectura, la migración y el apagado. Incluye el mantenimiento de ingeniería, el riesgo de incidentes, la capacitación de soporte y el costo de oportunidad; compáralos con la capacidad liberada, la complejidad reducida y las rutas de error eliminadas. Establece umbrales observables para la alternativa, tales como la finalización de tareas, el éxito de la migración, la confirmación de clientes críticos, el volumen de soporte y el riesgo de renovación, en lugar de una tasa de adopción global única.
3. Validar el impacto con un piloto reversible
Deshabilita los puntos de entrada primero para cuentas internas o clientes de bajo riesgo que opten por participar. Proporciona herramientas de migración, exportaciones y asistencia humana, y luego compara el éxito de las tareas, el tiempo de finalización, la tasa de errores y las solicitudes de ayuda. Cuando la asignación aleatoria no sea viable para cuentas enterprise, utiliza comparaciones de antes y después y entrevistas segmentadas, registrando lo que la evidencia no pueda determinar. El piloto debe ser pausible y reversible antes de cualquier migración amplia e irreversible.
4. Gestionar el riesgo de clientes clave, contratos y confianza
Crea una lista de excepciones para clientes con alto valor de renovación, compromisos explícitos, dependencias de cumplimiento o sin una alternativa viable. Haz que customer success, ventas, soporte, ingeniería y legal acuerden las notificaciones, fechas de migración, retención de datos y contactos de escalamiento. No permitas que unos pocos clientes grandes decidan por todos, y no fuerces el cierre de una tarea crítica solo para mejorar una métrica promedio. Las excepciones necesitan una fecha límite, un costo y una condición de salida.
5. Apagar por fases y verificar el resultado
Deja de habilitar la función para nuevos clientes, luego ofrece a los clientes existentes recordatorios de migración y una ventana de solo lectura, y finalmente deshabilita las escrituras y los puntos de entrada. En cada fase, monitorea la finalización de tareas, fallas de migración, tickets de soporte, rendimiento, reembolsos y señales de renovación, con umbrales de pausa definidos. Tras el lanzamiento, verifica que no haya llamadas a API ocultas, accesos anómalos a datos ni soluciones provisionales de los clientes. Elimina el código y los datos únicamente después de que los resultados sean estables, conservando los registros de auditoría y la documentación de migración.
Ejemplo de una respuesta sólida
El tres por ciento no demuestra que la función carezca de valor. Verificaría el denominador y la ventana de tiempo, segmentaría por valor de la cuenta, user job, compromiso contractual y alternativa disponible, e inspeccionaría APIs, tickets, promesas de ventas y dependencias de cumplimiento. Compararía los costos de mantenimiento, retención en solo lectura, migración y apagado, y luego establecería umbrales para el éxito de tareas, el éxito de migración, la confirmación de clientes críticos y el volumen de soporte. Ejecutaría un piloto pequeño y reversible con exportaciones, herramientas de migración y ayuda humana, y otorgaría a los clientes de alto riesgo excepciones con plazos delimitados, costos explícitos y condiciones de salida. Si el piloto es exitoso, detendría las nuevas activaciones, ofrecería a los clientes actuales una ventana de migración y de solo lectura, y luego retiraría el acceso progresivamente mientras monitoreo fallas, tickets, reembolsos y renovaciones. Eliminaría la implementación y los datos solo después de que la evidencia sea estable y conservaría un registro de auditoría.
Errores comunes
- Tratar el bajo uso como bajo valor sin verificar tareas en momentos críticos y uso indirecto.
- Utilizar solo promedios en lugar de segmentar por valor de cuenta, plan, región, rol y contrato.
- Anunciar el apagado antes de encontrar y validar una alternativa, trasladando el costo de migración a los clientes.
- Reemplazar evidencia de comportamiento reproducible por una sola entrevista o la solicitud de un solo cliente grande.
- Eliminar la función sin etapas de migración, solo lectura, notificación, excepción y rollback.
- Reportar horas de ingeniería ahorradas ignorando fallas en tareas, volumen de soporte, ingresos y salvaguardas de confianza.
Preguntas de seguimiento y respuestas
¿Se debería retirar una función que se usa solo una vez al año?
No basándose únicamente en la frecuencia. Verifica si ese uso respalda auditorías, cumplimiento, recuperación ante desastres o una tarea de negocio de alto valor, y si la alternativa es confiable. La habilitación bajo demanda, la retención en solo lectura o el mantenimiento de bajo costo pueden ser mejores opciones, pero la decisión requiere evidencia de éxito en tareas y de riesgos.
¿Qué pasa si un cliente clave se niega a migrar?
Determina si el impedimento es una brecha de funcionalidad, el costo de migración o un compromiso contractual. Ofrece una adaptación delimitada, migración asistida o una ventana de compatibilidad por tiempo limitado. Registra el costo, responsable, fecha límite y condición de salida; no mantengas la ruta heredada de forma indefinida.
¿Cómo demuestras que el apagado no perjudicó las renovaciones?
Haz seguimiento a la finalización de migraciones, el éxito en tareas críticas, tickets de soporte, reembolsos, puntajes de salud (health scores) y renovaciones por segmento, comparándolos con cuentas similares no migradas o períodos históricos. No puedes afirmar una causalidad perfecta, pero puedes predefinir umbrales de anomalías y acciones de pausa.
¿Qué sucede si ingeniería quiere eliminar el código inmediatamente?
Coloca los beneficios de la eliminación junto con los riesgos de migración, notificación, retención de datos y rollback en un único registro de decisión. Si los riesgos para los clientes o contratos siguen abiertos, detén las nuevas activaciones o pasa primero a solo lectura, completa la validación de la migración y luego elimina. Se puede definir una fecha clara de eliminación sin omitir las condiciones de salida.