Software Engineering

Negocio, IT, UX y producto miran el mismo problema y ven cosas distintas

6 de septiembre de 2026
3 min
1 vistas0 likes
ProductoProduct ManagementUX

Un producto digital falla casi siempre por lo mismo: cuatro áreas miraron el mismo problema, cada una vio algo distinto, y nadie tradujo entre ellas.

No es un problema de comunicación. Es que cada disciplina tiene una definición legítima y diferente de "esto está bien", y las cuatro son ciertas a la vez.

Cuatro definiciones de éxito

ÁreaPregunta que haceFracaso que teme
Negocio¿Esto mueve la aguja?Construir algo que nadie monetiza
Tecnología¿Esto se sostiene?Deuda que paraliza el roadmap
UX¿Alguien lo entiende?Que funcione y nadie lo use
Producto¿Es lo siguiente que toca?Resolver el problema equivocado

Ninguna está mirando mal. El vendedor que pide una funcionalidad para cerrar un trato no es cortoplacista: tiene una cuota. El ingeniero que se resiste no es lento: sabe lo que cuesta mantener eso tres años. La diseñadora que insiste en investigar antes no está frenando: ha visto lanzarse cosas que nadie usó.

Dónde se rompe

Se rompe cuando una perspectiva gana por jerarquía en vez de por argumento.

Cuando negocio manda solo, sale un producto que cumple la meta del trimestre y se vuelve inmantenible. Cuando tecnología manda sola, sale una arquitectura preciosa para un problema que nadie tenía. Cuando UX manda sola, sale algo impecable que no se puede sostener económicamente. Cuando producto manda solo, sale un roadmap coherente en la presentación y desconectado de lo que el equipo puede construir.

El síntoma es siempre el mismo: alguien dice "eso es un detalle técnico" o "eso es un tema de negocio" para sacar una preocupación legítima de la conversación.

Lo que hace product management

El trabajo no es decidir quién tiene razón. Es hacer explícito el intercambio para que la decisión se tome sabiendo qué se está cediendo.

Hay una diferencia enorme entre estas dos frases:

  • "Vamos con la solución rápida."
  • "Vamos con la solución rápida: entregamos en dos semanas en vez de seis, a cambio de rehacer la integración en el primer trimestre. Negocio gana el trato, tecnología asume la deuda, y lo ponemos en el backlog con fecha."

La segunda no es más lenta de decir. Es la misma decisión, con el costo sobre la mesa. Y cambia por completo lo que pasa seis meses después, cuando alguien pregunta por qué esa parte del sistema es un desastre.

El usuario final no ve las áreas

Esto es lo que se olvida en las discusiones internas: quien usa el producto no percibe cuatro perspectivas. Percibe una sola cosa.

Percibe que el registro tiene un paso de más. Que la app tarda. Que el precio no cuadra con lo que recibe. No sabe si eso viene de una decisión de negocio, de una limitación técnica o de un flujo mal diseñado, y no le importa.

Por eso la pregunta que ordena la discusión no es "¿quién tiene razón?" sino "¿qué va a experimentar la persona del otro lado?". Es la única pregunta que las cuatro áreas pueden responder juntas, porque es la única donde comparten el mismo objeto.

Cuando una reunión se traba, esa pregunta la destraba más rápido que cualquier framework de priorización.