Un stakeholder insistió en una funcionalidad visual descrita como "simple, quick win", mientras el backlog real de negocio seguía sin completarse. Sostener la prioridad correcta —no la más ruidosa— fue lo que permitió que el proyecto escalara a todas las oficinas del cliente.
El "quick win" que sonaba razonable
Durante la construcción de un MVP para un cliente financiero, un stakeholder del lado del negocio insistió, en más de una reunión, en que agregáramos un ajuste visual a la vista de mapa de su aplicación móvil — diferenciar tareas de campo por ciertos criterios visuales. Sonaba razonable. Sonaba, en sus palabras, como "algo simple, un quick win". Mientras tanto, el proyecto todavía tenía un backlog importante de procesos de negocio core sin implementar — los que realmente iban a permitir que la aplicación escalara a todas las oficinas del cliente.
Sostener la prioridad correcta
Sostuve la posición, junto con el líder técnico del propio cliente: ese cambio visual no era más valioso para el negocio que terminar los procesos que le permitían a los agentes de campo analizar distintos productos de crédito y reducir las horas dedicadas a gestión de casos. Acordamos desestimarlo formalmente, mantuvimos al equipo enfocado en completar el alcance de negocio completo, y lo dejamos para una revisión futura en vez de dejar que se colara en la fase actual.
El resultado, medible
El resultado: mantuvimos al equipo enfocado en lo que realmente movía el caso de negocio, y la aplicación logró escalar a todas las oficinas del cliente. Hoy, todas esas oficinas siguen usando exactamente los procesos que se decidieron priorizar en esa fase — no el ajuste visual que en su momento sonaba urgente.
Respaldado por datos, no solo intuición
Un estudio de referencia de Pendo sobre adopción de funcionalidades encontró que apenas 6.4% de las funcionalidades de un producto generan 80% del volumen de uso real — el resto compite por recursos de ingeniería sin mover el negocio. Las empresas de software gastaron un estimado de $29,500 millones de dólares en 2025 construyendo funcionalidades que casi nadie usa. "Simple" y "quick win" no siempre significan lo mismo que "valioso" — sostener esa línea, sobre todo frente a un stakeholder insistente, es incómodo en el momento, y es exactamente el trabajo que un líder de entrega debe hacer.
Fuentes de datos: Pendo — estudios/benchmarks sobre adopción de funcionalidades (6.4% de las funcionalidades generan 80% del uso real); estimación de la industria sobre software no utilizado: ~$29,500 millones USD invertidos en 2025 construyendo funcionalidades que casi nadie usa.
Artículo relacionado: el 30% de los casos que nunca debieron ser nuestrosArtículo relacionado: el feature de 6 horas que nunca debió construirseEn este tema
Ver todo el temaRespuesta rápidaDetail
¿Cómo priorizar el backlog cuando un stakeholder insiste en una funcionalidad de bajo impacto?
Un stakeholder insistió en una funcionalidad visual descrita como "simple, quick win", mientras el backlog real de negocio seguía sin completarse. Sostener la prioridad correcta —no la más ruidosa— fue lo que permitió que el proyecto escalara a todas las oficinas del cliente.
Escrito y revisado por Rogelio Barajas González — Auditor Líder certificado ISO 27001:2022 e ISO 9001:2015, con experiencia directa en SOC 1 Tipo 2 y SOC 2 Tipo 2. Fundador de Barajas Advisory.
Verifica sus credenciales en LinkedIn:linkedin.com/in/rogelio-barajas-gonzalezÚltima actualización: agosto 2026
Este es uno de nueve casos reales
Cicatrices de Nube — ¿quieres el resto de las historias?
Los nueve casos documentados —FinOps, Release Management, Service Delivery, Compliance y gobernanza de IA— con un checklist de autodiagnóstico por capítulo y un scorecard general al cierre.
Descarga el playbook gratis