Pregunta y escenarios aplicables
Diriges un SaaS de analítica B2B. Una funcionalidad heredada de envío programado de correos con PDF es utilizada mensualmente por solo el 3% de los espacios de trabajo activos, pero entre sus usuarios se incluyen 14 clientes empresariales que representan el 18% del ARR de la empresa. Nueve de esos clientes renuevan en los próximos seis meses. La funcionalidad depende de un motor de renderizado antiguo, cuesta alrededor de tres meses-ingeniero por trimestre mantenerla y genera el 22% de los tickets de soporte relacionados con reportes.
La empresa ha lanzado suscripciones a paneles que cubren aproximadamente el 80% de los flujos de trabajo heredados, pero aún no admiten personalización de marca ni entrega de archivos adjuntos. Decide si mantener, reinvertir, detener la expansión o, en última instancia, retirar la funcionalidad heredada. Explica los datos que validarías, el plan de migración, la cadencia de comunicación, las métricas de éxito y las condiciones de pausa.
Todos los números son supuestos de entrevista, no puntos de referencia de la industria. Una tasa de uso del 3% no demuestra que la funcionalidad deba eliminarse, y el 18% del ARR no demuestra que deba conservarse para siempre. El candidato debe descubrir la dependencia oculta tras la baja adopción, comparar el costo total de retención y migración, y convertir una eliminación irreversible en una secuencia de decisiones que puedan probarse y pausarse.
Los bancos de preguntas para product managers en 2026 todavía preguntan a los candidatos qué producto mejorarían y cuál cancelarían. Una rúbrica independiente de entrevistas de PM pregunta explícitamente cómo un candidato utilizó datos para retirar una funcionalidad, distinguió el bajo uso del valor para un segmento pequeño, gestionó la resistencia y minimizó las interrupciones. Esta es una pregunta de producto porque evalúa los trade-offs del portafolio, la segmentación de clientes, las decisiones del ciclo de vida y la ejecución interfuncional.
Qué evalúan los entrevistadores
En primer lugar, ¿el candidato valida la definición de los datos? Una respuesta sólida cuestiona si el denominador del 3% incluye todos los espacios de trabajo activos, solo los espacios de trabajo con derecho a la funcionalidad o solo aquellos que completaron la configuración. También verifica si las llamadas a la API, los envíos activados por administradores o los trabajos programados eluden la ruta de interfaz de usuario medida. Un mal denominador o una telemetría incompleta invalidan la conclusión.
En segundo lugar, ¿puede el candidato separar la adopción del valor de la dependencia? Un reporte de cumplimiento normativo enviado una vez al mes puede tener una frecuencia baja pero seguir siendo esencial para una auditoría o un proceso de junta directiva. La segmentación debe considerar la criticidad del flujo de trabajo, la dificultad de cambio, el valor de la cuenta, los compromisos contractuales y los tiempos de renovación, en lugar de basarse únicamente en el recuento promedio de eventos.
En tercer lugar, ¿el candidato compara opciones reales? La respuesta debe incluir más que simplemente conservar o eliminar:
- mantener la funcionalidad actual;
- repararla o reconstruirla;
- ponerla en modo de mantenimiento, deteniendo la nueva adopción mientras se da soporte a los dependientes existentes;
- cerrar las brechas del reemplazo durante la migración;
- retirarla por etapas, con excepciones por tiempo limitado para un grupo pequeño de clientes.
En cuarto lugar, ¿el candidato trata la migración como una entrega de producto? Publicar una fecha no completa una migración. Una respuesta sólida define brechas de reemplazo, responsables de cuentas, exportación de datos, herramientas de migración, acuse de recibo de notificaciones, rutas de soporte, cierres por cohortes y compuertas de reversión (rollback).
En quinto lugar, ¿puede el candidato resolver la tensión entre los ingresos y la integridad del producto? Catorce clientes representan el 18% del ARR, por lo que un apagado abrupto inmediato es riesgoso. La funcionalidad también consume unos 12 meses-ingeniero al año e impide que la infraestructura de reportes converja. El candidato necesita una recomendación actual y la evidencia que la cambiaría, en lugar de terminar con un simple “los clientes importan” o “la deuda técnica es demasiado alta”.
Preguntas clarificadoras antes de responder
- ¿Son confiables el denominador del 3% y la telemetría? Si solo mide los clics en la interfaz de usuario y omite programaciones, API o configuraciones del administrador, corrige los datos antes de decidir.
- ¿Qué trabajo (job) completan los clientes con la funcionalidad? Los archivos de cumplimiento, la entrega a clientes externos, los reportes semanales internos y las pruebas ocasionales tienen costos de interrupción muy diferentes.
- ¿Qué tan profundamente dependen de ella los 14 clientes empresariales? Separa a los usuarios continuos, a los usuarios ocasionales y a los clientes que pueden migrar pero no han actuado.
- ¿El 18% de ARR está correlacionado o es atribuible? Usar una funcionalidad no significa que el valor total del contrato dependa de ella. Valida la intención de cancelación, el riesgo de renovación y las promesas contractuales.
- ¿Qué hay dentro del 20% faltante? Si la personalización de marca y los adjuntos son bloqueadores contractuales, el 80% de cobertura no justifica el retiro. Un puente de migración estrecho podría cambiar la decisión.
- ¿Cuál es el costo total de la funcionalidad heredada? Más allá de los 12 meses-ingeniero por año, incluye incidentes, soporte, seguridad, accesibilidad, infraestructura y el costo de oportunidad en el roadmap.
- ¿Existe un riesgo de seguridad, cumplimiento o integridad de datos? Un riesgo grave puede justificar un apagado acelerado. El costo de mantenimiento ordinario no justifica omitir un aviso razonable y la migración.
- ¿Qué restricciones existen en contratos y notificaciones a clientes? Las renovaciones, los términos de servicio y las promesas de adquisiciones determinan el cronograma de anuncios, las excepciones y la secuencia de apagado final.
Estructura de respuesta de 30 segundos
“No eliminaría la funcionalidad basándome únicamente en el uso del 3% porque el grupo de usuarios incluye cuentas empresariales que representan el 18% del ARR, y el reemplazo presenta brechas sustanciales. Validaría la telemetría y el denominador elegible, y luego segmentaría a los 14 clientes por criticidad del flujo de trabajo, esfuerzo de cambio, contratos y riesgo de renovación.
Dados los hechos actuales, detendría de inmediato la venta y habilitación de la funcionalidad heredada para nuevos clientes y la pondría en modo de mantenimiento. En paralelo, ejecutaría una auditoría de dependencias y una prueba piloto de migración de aproximadamente cuatro semanas para determinar si se pueden cerrar las brechas de marca y archivos adjuntos. Anunciaría una fecha definitiva solo después de que el reemplazo supere los flujos de trabajo críticos, la exportación, la confiabilidad y las revisiones contractuales, y los clientes de alta dependencia cumplan con las compuertas de migración predefinidas.
Las nueve renovaciones a corto plazo recibirían planes individuales, y las migraciones avanzarían por cohortes con condiciones de pausa. Si las brechas críticas no se pueden cerrar económicamente, o el churn previsto y el costo de migración superan el costo de mantenimiento y oportunidad que podemos liberar, conservaría una versión acotada o reconsideraría una reconstrucción en lugar de forzar la fecha original.”
Análisis detallado paso a paso
Paso 1: Convertir el “bajo uso” en un mapa de dependencias verificado.
Construye un inventario a nivel de cuenta en lugar de depender de un solo panel agregado:
| Dimensión | Pregunta a responder | Impacto en la decisión |
|---|---|---|
| Denominador elegible | Cuántos espacios de trabajo tienen derechos y están configurados | Corrige si el 3% está artificialmente diluido |
| Profundidad de uso | Programaciones, envíos exitosos, destinatarios y meses continuos | Separa las pruebas de la dependencia real |
| Criticidad del flujo de trabajo | Si una falla causa inconvenientes, pérdida de ingresos o incumplimiento normativo | Establece la prioridad de migración y el aviso |
| Dificultad de reemplazo | Si las suscripciones, el trabajo manual u otra herramienta pueden completar la tarea | Estima el costo de migración |
| Exposición comercial | ARR, renovaciones, términos contractuales e intención de cancelación | Estima el riesgo real de ingresos |
| Costo del producto | Mantenimiento, soporte, incidentes, seguridad y bloqueo del roadmap | Estima el costo total de retención |
Entrevista también a quienes no la adoptaron. Determina si carecen de la necesidad, no pueden descubrir la funcionalidad, fallan durante la configuración o consideran que la experiencia es inadecuada. Si la baja adopción se debe a problemas solucionables de descubribilidad o confiabilidad mientras que la necesidad subyacente sigue siendo amplia, reinvertir puede ser más racional que retirar.
Paso 2: Definir compuertas estrictas antes de comparar opciones.
El apagado final no debe proceder hasta que:
- los datos de uso cubran cada ruta de activación significativa y no tengan brechas sustanciales conocidas;
- se hayan revisado contratos, obligaciones legales, cumplimiento y requisitos de retención de datos;
- los flujos de trabajo críticos dependientes tengan un reemplazo aceptable o una ruta de migración aprobada por el cliente;
- los clientes puedan exportar los datos históricos requeridos y el equipo haya ensayado la exportación y recuperación;
- la confiabilidad, permisos, accesibilidad y soporte del reemplazo estén listos para producción;
- cada cuenta empresarial afectada tenga un responsable, un estado y una ruta de escalamiento.
Los problemas de seguridad, confiabilidad crítica o integridad de datos pueden acortar el cronograma, pero la empresa aún debe explicar el motivo y proporcionar una ruta de migración. Algunas políticas públicas de API especifican períodos de aviso formales. Por ejemplo, la regla general de Atlassian para las API REST públicas en la nube mantiene disponible la forma original durante al menos seis meses, con excepciones para problemas críticos de seguridad, confiabilidad e integridad de datos. Ese es un ejemplo de política específico, no un plazo universal para cada funcionalidad de producto.
Paso 3: Comparar mantenimiento, reinversión, modo de mantenimiento y retiro.
| Opción | Apropiada cuando | Costo principal |
|---|---|---|
| Continuar mantenimiento | El flujo de trabajo es crítico, las alternativas fallan y el riesgo de ingresos supera el costo de retención | Persisten la deuda técnica, el soporte y el costo de oportunidad |
| Reconstruir | El problema del usuario es de interés general pero la implementación heredada reprime la adopción | El nuevo trabajo puede duplicar la infraestructura de reportes de reemplazo |
| Modo de mantenimiento | Los clientes existentes dependen de ella, pero la adopción no debe expandirse más | Requiere un horizonte de soporte explícito para evitar demoras permanentes |
| Migrar y luego retirar | El reemplazo es confiable, las brechas son salvables y el valor a largo plazo es claro | Herramientas de migración, comunicación y operación dual temporal |
| Excepción por tiempo limitado | Unos pocos clientes valiosos enfrentan bloqueos contractuales o críticos | Puede crear una bifurcación (fork) duradera sin responsable ni condición final |
El lenguaje de ciclo de vida publicado por AWS resulta útil aquí: el mantenimiento detiene la incorporación (onboarding) y las mejoras mientras se sigue dando soporte a los usuarios existentes; el retiro (sunset) solicita a los usuarios existentes que migren y tiene una fecha de finalización; el apagado completo elimina el servicio y el soporte. El uso de etapas evita que la respuesta en la entrevista reduzca la obsolescencia programada (deprecation) y la eliminación inmediata a una sola acción.
Bajo los supuestos actuales, la recomendación es el modo de mantenimiento seguido de un retiro condicionado por compuertas de migración. La adopción agregada del 3% y los aproximadamente 12 meses-ingeniero de mantenimiento anual justifican reducir la inversión a largo plazo, mientras que el 18% del ARR, nueve renovaciones a corto plazo y una brecha de capacidad del 20% hacen que un apagado inmediato sea inaceptable.
Paso 4: Validar la recomendación con acciones reversibles.
Antes de anunciar una fecha definitiva:
- deja de habilitar la funcionalidad para nuevos clientes y elimínala de las promesas de ventas;
- revisa los flujos de trabajo con los 14 clientes empresariales, señalando brechas de personalización de marca, archivos adjuntos, retención y permisos;
- realiza una prueba piloto de migración con clientes en diferentes niveles de dependencia, incluyendo configuración, exportación histórica, entrega y soporte;
- redacta compuertas de migración y condiciones de pausa antes de la ejecución para que la fecha límite no se imponga sobre la evidencia de fallas.
El piloto debe probar el mismo trabajo de extremo a extremo: entrega exitosa, experiencia del destinatario, corrección de archivos adjuntos y personalización de marca, permisos, registros de auditoría, comportamiento de reintento, volumen de soporte y tiempo de finalización. Un reemplazo probado solo en clientes simples no valida la afirmación del 80% de cobertura.
Paso 5: Proporcionar a cada segmento una ruta de migración diferente.
Utiliza cuatro grupos de cuentas:
- sin uso actual significativo: oculta la funcionalidad manteniendo el aviso y el acceso a la exportación;
- baja dependencia con reemplazo completo: ofrece migración de autoservicio y recordatorios;
- alta dependencia con brechas subsanables: brinda asistencia de producto y Customer Success;
- bloqueadas por contratos o brechas críticas: otorga una excepción por tiempo limitado con una fecha de decisión de brecha, renovación o salida.
El aviso debe indicar qué está cambiando, por qué, la última fecha disponible, las alternativas, los pasos de migración, el acceso a datos y los canales de soporte. Los clientes de alto valor no deben recibir únicamente un correo masivo. Un responsable confirma que cada cliente comprende el impacto y registra la aceptación del plan de migración. Si la funcionalidad incluye API o automatización, las respuestas, los registros de cambios (changelogs) y la documentación para desarrolladores también deben permitir detectar la obsolescencia y el retiro.
Paso 6: Utilizar compuertas por etapas y condiciones de pausa.
Una secuencia viable es:
| Etapa | Acción | Evidencia requerida para avanzar |
|---|---|---|
| Modo de mantenimiento | Detener nueva adopción, corregir datos, construir inventario de cuentas | Dependientes y alcance contractual identificados |
| Preparación para migración | Cerrar brechas críticas y ensayar exportación y soporte | El reemplazo supera flujos de trabajo críticos |
| Cohortes pequeñas | Migrar clientes de bajo riesgo y dispuestos | Las tareas se completan con éxito y las métricas de control se mantienen saludables |
| Migración empresarial | Gestionar individualmente a clientes con alta dependencia y renovaciones | Las cuentas afectadas cumplen con las compuertas definidas por el equipo |
| Apagado final | Deshabilitar puntos de entrada heredados, tareas y estructura | Sin bloqueos contractuales ni de datos pendientes |
| Limpieza y revisión | Eliminar código, documentación, material de ventas, alertas y copias de datos | Los límites operativos y del producto convergen |
Pausa si un flujo de trabajo crítico falla, las exportaciones están incompletas, la confiabilidad del reemplazo es inadecuada, la carga de soporte excede sustancialmente lo planeado, la intención de cancelación cruza el límite de riesgo predefinido o los problemas legales y de cumplimiento quedan sin resolver. Una pausa debe activar una nueva elección entre cerrar brechas, extender una cohorte, otorgar una excepción por tiempo limitado o cambiar la recomendación. No debe convertirse silenciosamente en una retención permanente.
Paso 7: Comparar la economía completa.
La retención incluye aproximadamente 12 meses-ingeniero por año, el 22% de los tickets de soporte relacionados con reportes, la exposición a incidentes e infraestructura del motor antiguo y el costo de oportunidad de no trasladar ingenieros a la nueva pila de reportes. El retiro incluye el desarrollo del reemplazo, herramientas de migración, trabajo de soporte y Customer Success, operación dual temporal y posibles descuentos, churn o compensaciones contractuales.
No registres todo el 18% del ARR como “pérdida por retiro”. Estima qué clientes cancelarían debido a brechas no resueltas, cuáles migrarían y cuáles solo necesitan asistencia. No registres los 12 meses-ingeniero completos como “ahorro por retiro”, porque el reemplazo también necesita mantenimiento. Compara rangos de escenarios:
- si las brechas críticas se pueden cerrar a un costo razonable;
- cuántos ingresos asociados están genuinamente en riesgo;
- cuánto durará la operación dual;
- qué trabajo de mayor valor utilizará la capacidad liberada;
- si las excepciones impiden que el costo heredado disminuya.
Paso 8: Medir los resultados de la migración, no la fecha de apagado.
La métrica principal debe ser la finalización de los flujos de trabajo dependientes, no el envío de notificaciones. Da seguimiento a:
- finalización de la migración para cuentas genuinamente dependientes y tareas programadas;
- éxito en la entrega y finalización de tareas críticas en el reemplazo;
- uso residual de la funcionalidad heredada y cuentas que no han acusado recibo;
- tickets de soporte de reportes, solicitudes de migración y escalamientos;
- renovación, intención de cancelación y riesgo contractual para los clientes afectados;
- éxito en la exportación histórica y finalización del trabajo de retención de datos;
- incidentes heredados, esfuerzo de mantenimiento y capacidad de ingeniería realmente liberada.
Tras el apagado, elimina procesos en segundo plano, puntos de entrada, permisos, feature flags, documentación, promesas de ventas, manuales de soporte (playbooks), alertas de monitoreo y copias de datos innecesarias. Gestiona los datos históricos de acuerdo con la política de retención acordada. Ocultar un botón mientras se conservan todas las responsabilidades operativas no captura el valor principal del retiro.
Ejemplo de respuesta de alta calidad
“Primero cuestionaría la cifra del 3%. El denominador debería ser los espacios de trabajo que tienen derecho y tienen la necesidad de reportes relevante, y verificaría que se incluyan las tareas programadas y los disparadores de API fuera de la interfaz de usuario. Luego segmentaría a los 14 clientes empresariales por criticidad del flujo de trabajo, dificultad de cambio, compromisos contractuales y tiempos de renovación. Un reporte de cumplimiento normativo utilizado una vez al mes puede ser poco frecuente pero esencial.
No daría de baja la funcionalidad de inmediato. Consume tres meses-ingeniero por trimestre y genera el 22% de los tickets de soporte relacionados con reportes, por lo que conservarla implica un costo sustancial a largo plazo. Sus usuarios también representan el 18% del ARR, nueve renuevan pronto y el reemplazo carece de personalización de marca y entrega de adjuntos. Mi recomendación es ponerla en modo de mantenimiento: detener nuevas habilitaciones y promesas de ventas, corregir únicamente problemas graves e iniciar una auditoría de dependencias y un piloto de migración.
Determinaría si la personalización de marca y los archivos adjuntos son requisitos contractuales o de flujos de trabajo críticos, y luego migraría a los clientes según diferentes niveles de dependencia. El piloto debe verificar la entrega, los permisos, la auditabilidad, la recuperación ante fallas, la exportación histórica y las operaciones de soporte, en lugar de limitarse a comparar listas de funcionalidades. Cada cuenta empresarial recibe un responsable, con planes individuales para las renovaciones a corto plazo.
Anunciaría una fecha definitiva solo después de que el reemplazo supere los flujos de trabajo críticos, se complete la revisión contractual y de cumplimiento, los datos puedan exportarse y los clientes con alta dependencia cumplan con las compuertas de migración predefinidas. Migraría primero las cohortes de bajo riesgo y pausaría la siguiente cohorte si las tareas críticas fallan, las exportaciones están incompletas, la confiabilidad es inadecuada o el riesgo de cancelación se vuelve inaceptable.
En términos económicos, compararía los 12 meses-ingeniero de mantenimiento anual, soporte, incidentes y costo de oportunidad en el roadmap con las brechas de reemplazo, la migración, la operación dual y el churn probable. No todo el 18% de ARR desaparecerá necesariamente, y no todos los 12 meses-ingeniero se convertirán en ahorros netos, por lo que actualizaría la recomendación utilizando rangos y evidencia de los clientes.
Si las brechas críticas se pueden resolver económicamente, completaría un retiro escalonado. Si son requisitos contractuales insustituibles, o las pérdidas esperadas por la migración siguen siendo mayores que el valor liberado, conservaría una versión acotada o reconsideraría una reconstrucción. Después del apagado, eliminaría tareas, código, documentación, material de ventas, alertas y responsabilidades sobre los datos para que el equipo salga realmente de la infraestructura heredada.”
Errores comunes
- Eliminarla tras ver el 3% de uso → el denominador, la frecuencia o la criticidad del flujo de trabajo pueden ser erróneos → valida los datos y segmenta por dependencia primero.
- Conservarla para siempre tras ver el 18% de ARR → el ingreso asociado no es ingreso atribuible, mientras que los costos técnicos y de oportunidad continúan → valida el riesgo real de cancelación y compara la economía completa.
- Tratar el 80% de cobertura como preparación para la migración → el 20% faltante puede contener bloqueos contractuales o de cumplimiento → valida los flujos de trabajo individualmente en lugar de contar funcionalidades.
- Ofrecer solo conservar o eliminar → desaparecen el modo de mantenimiento, los puentes de migración y las excepciones por tiempo limitado → divide una eliminación irreversible en decisiones escalonadas.
- Anunciar la fecha antes de diseñar el reemplazo → la fecha límite puede imponerse sobre la evidencia de fallas → define primero compuertas, pruebas piloto y condiciones de pausa.
- Enviar a todos los clientes el mismo correo → las cuentas empresariales con alta dependencia necesitan confirmación de impacto, responsables y escalamiento → segmenta la comunicación por dependencia y exposición comercial.
- Medir el éxito por la entrega del aviso → los clientes pueden recibir el mensaje sin completar la migración → mide la migración de flujos de trabajo, el éxito de las tareas y las métricas de control.
- Detenerse tras ocultar la interfaz de usuario → las tareas, el código, los datos, los documentos y las promesas de ventas siguen generando responsabilidad → completa la limpieza y revisión del ciclo de vida.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: El cliente más grande dice que cancelará si se elimina la funcionalidad. ¿Qué haces?
Determina si se trata de una condición de cancelación confirmada, una postura de negociación o una preocupación sobre el riesgo de la migración. Aísla el flujo de trabajo insustituible, el lenguaje contractual y la exposición de ingresos; luego compara cerrar la brecha, brindar servicio de migración, otorgar una excepción por tiempo limitado o conservar una versión acotada. Un cliente grande puede cambiar los plazos, pero no debería recibir automáticamente una excepción indefinida. Cualquier excepción necesita precio, un límite de soporte, un responsable y una condición de finalización.
Pregunta de seguimiento 2: El motor de renderizado heredado tiene una vulnerabilidad crítica de seguridad. ¿Puedes mantener el cronograma original?
No sigas el cronograma original mecánicamente. El liderazgo de seguridad debe determinar si el riesgo puede aislarse, parchearse o si se puede restringir la exposición. Si sigue siendo inaceptable, detén nuevas tareas, restringe la disponibilidad o acelera el apagado. Aún así, proporciona exportación, un flujo de trabajo alternativo y una explicación clara de por qué se acortó el plazo de aviso. Un riesgo urgente cambia el cronograma; no elimina la responsabilidad de migrar a los clientes.
Pregunta de seguimiento 3: El reemplazo nunca cubrirá más del 80%. ¿Deberías abandonar el retiro de la funcionalidad?
Mapea la brecha con los flujos de trabajo genuinamente dependientes y analiza si el puente crearía otro sistema heredado. Si la personalización de marca y los archivos adjuntos pueden ser manejados por una capa de migración estrecha, el retiro puede continuar. Si la brecha contiene requisitos esenciales de entrega o de cumplimiento insustituibles, orienta la estrategia hacia una versión heredada acotada, una reconstrucción de la capacidad crítica o un reemplazo diferente. El porcentaje por sí solo no puede decidir.
Pregunta de seguimiento 4: Los datos de uso no son confiables, pero ingeniería quiere eliminar urgentemente el código antiguo. ¿Cómo procedes?
Detén la expansión de la adopción y luego concilia registros, programaciones, llamadas a la API, registros de soporte, conocimiento de Customer Success y cuentas de facturación. Se puede ejecutar una ocultación reversible o una prueba piloto de migración en cuentas de bajo riesgo, pero la eliminación permanente es insegura mientras se desconozca la dependencia. Si no se puede construir un inventario confiable rápidamente, trata la incertidumbre de los datos como un bloqueador en lugar de interpretar “no se observa uso” como “nadie lo usa”.
Pregunta de seguimiento 5: Dos clientes exigen acceso permanente. ¿Deberías crear una versión dedicada?
Compara los ingresos con el costo de mantener una bifurcación (fork) permanente, incluidos parches de seguridad, infraestructura, guardias on-call, pruebas y conocimiento del personal. Da preferencia al reemplazo estándar, a una migración de pago o a una excepción por tiempo limitado. Una versión dedicada de larga duración es razonable solo si el valor del contrato y la importancia estratégica cubren de manera sostenible su responsabilidad operativa y la empresa lo acepta como un compromiso formal de producto. Una excepción temporal no debe convertirse silenciosamente en un sistema heredado indefinido.