Cuando todas las funcionalidades parecen urgentes, el riesgo no es elegir mal: es no elegir. Estos criterios ayudan a tomar decisiones de prioridad sin depender de la intuición ni de quién grita más fuerte.
Hay un momento en todo proyecto de producto digital en que la lista de funcionalidades pendientes supera por mucho lo que se puede construir en cualquier plazo razonable. El fundador las quiere todas. El equipo de ventas necesita tres para cerrar un cliente. El equipo de operaciones pide otras cuatro para dejar de hacer trabajo manual. El desarrollador sugiere dos más de infraestructura que "son importantes para después". Y todas suenan razonables. Todas parecen urgentes. Todas vienen con un argumento convincente.
Cuando todo parece importante, el riesgo más grande no es elegir mal. Es no elegir. Es intentar avanzar con todo en paralelo, repartir al equipo entre ocho frentes distintos y terminar con ocho cosas a medio hacer pero ninguna lista para que un usuario la use de verdad.
Priorizar no es un ejercicio técnico. Es un ejercicio de disciplina y de criterio. Requiere aceptar que postergar duele, pero hacer todo al mismo tiempo duele más —y sale más caro.
Existen decenas de métodos formales para priorizar: MoSCoW, RICE, matriz de esfuerzo versus impacto, valor versus riesgo. Todos funcionan en teoría. En la práctica, cuando estás en una reunión con cinco personas defendiendo cinco funcionalidades distintas, ninguno de esos métodos resuelve el problema de fondo: que los criterios de evaluación son subjetivos y cada persona los ajusta para que su funcionalidad favorita salga primera.
El método MoSCoW clasifica en "must have", "should have", "could have" y "won't have". Pero cuando todo el mundo insiste en que su funcionalidad es "must have", las categorías pierden sentido. La matriz de esfuerzo versus impacto requiere estimar ambas variables para cada funcionalidad, y esas estimaciones suelen ser opiniones disfrazadas de números.
Si después de una sesión de priorización más del veinte por ciento de las funcionalidades quedaron en la categoría de máxima prioridad, la sesión no sirvió. Priorizar es discriminar. Si todo es prioritario, nada lo es.
Un enfoque que funciona mejor que los métodos tradicionales en contextos de mucha presión es el de la única funcionalidad indispensable. La pregunta no es "¿qué es más importante?" sino "si solo pudiéramos construir una funcionalidad en el próximo mes, ¿cuál sería?".
Esta pregunta fuerza a todos los involucrados a comparar funcionalidades entre sí en lugar de defender cada una por separado. No alcanza con argumentar que la funcionalidad A es importante: hay que argumentar que es más importante que la B, la C y la D.
El resultado de este ejercicio suele ser revelador. Muchas funcionalidades que en abstracto parecían críticas pierden urgencia cuando se las compara con otra que resuelve un problema más inmediato o que destraba una restricción que impide avanzar con todo lo demás.
Una distinción útil al priorizar es separar las funcionalidades que agregan valor de las que desbloquean valor. Las primeras mejoran el producto para el usuario final: una nueva forma de pago, un reporte más detallado, una integración con otra herramienta. Las segundas permiten que algo que ya existe funcione mejor o que el equipo pueda moverse más rápido.
En las etapas tempranas de un producto, las funcionalidades que desbloquean suelen tener más impacto que las que agregan. Por ejemplo, mejorar el tiempo de carga de la pantalla principal puede tener más efecto en la retención de usuarios que agregar una funcionalidad nueva. Automatizar un proceso interno que hoy consume cuatro horas por día del equipo libera capacidad para construir más rápido. Resolver un problema de estabilidad que causa quejas de los usuarios existentes vale más que atraer nuevos usuarios a un producto que todavía falla.
Este criterio ayuda a resolver discusiones donde los argumentos a favor de cada funcionalidad son igualmente válidos pero responden a lógicas distintas. Una funcionalidad que desbloquea el trabajo del equipo probablemente debería ir antes que una que agrega una mejora marginal al usuario, incluso si esta última es más visible.
Otro eje de priorización que genera mucha fricción es la tensión entre lo que pide un cliente importante ahora y lo que el producto necesita para ser sostenible en el tiempo.
Cuando un cliente grande dice "si no tienen esta funcionalidad en dos meses, nos vamos", la presión para priorizarla es enorme. Y muchas veces hay que hacerlo: perder un cliente clave puede ser más costoso que postergar una mejora estructural. Pero cuando esto se repite con cada cliente, el producto se convierte en una colección de funcionalidades a pedido sin una dirección propia. El equipo deja de construir un producto y pasa a hacer desarrollo a medida para cada cliente, con los costos de mantenimiento y la fragmentación que eso genera.
La solución no es ignorar a los clientes ni negarse a sus pedidos. Es tener un criterio claro y explícito para decidir cuándo una excepción se justifica y cuándo no. Ese criterio debería incluir el costo real de la excepción: no solo el tiempo de desarrollo, sino el costo de mantener esa funcionalidad para siempre, el impacto en la arquitectura, y el precedente que sienta para futuros pedidos.
La forma más efectiva de sacar la priorización del terreno de las opiniones es llevarla al terreno de los datos. Antes de discutir si la funcionalidad A es más importante que la B, preguntar: ¿qué evidencia tenemos de que los usuarios necesitan A? ¿Cuántos usuarios pidieron B? ¿Qué pasa si no construimos ninguna de las dos?
Cuando la respuesta es "yo creo que" o "me parece que", la funcionalidad debería bajar en la prioridad hasta que exista alguna evidencia concreta. Esa evidencia puede ser cualitativa —entrevistas con usuarios, reclamos recurrentes, observación de cómo usan el producto actual— pero tiene que ser externa al equipo que está decidiendo.
Este criterio es especialmente útil cuando el founder o el gerente tiene una funcionalidad "mascota" que quiere priorizar por razones que no necesariamente coinciden con lo que los usuarios necesitan. Pedir evidencia no es cuestionar su criterio: es aplicar el mismo estándar que se le aplica a cualquier otra funcionalidad.
Cuando dos personas defienden funcionalidades distintas con argumentos igualmente razonables, preguntá: "¿qué tendría que pasar en las próximas dos semanas para que cambies de opinión sobre la prioridad de esto?". Esa pregunta convierte una discusión de opiniones en un plan de validación.
No priorizar no significa que todo se hace al mismo tiempo. Significa que la prioridad la define lo que grita más fuerte, lo que está más cerca de la fecha de entrega, o lo que el desarrollador decide empezar porque le pareció más interesante. Es decir, se prioriza igual, pero sin criterio, sin visibilidad y sin posibilidad de discutir si la decisión fue correcta.
El costo de esa falta de criterio se paga en plazos que se estiran, en funcionalidades que se completan al ochenta por ciento pero nunca llegan a estar listas, y en un equipo que pierde la noción de qué es lo más importante porque todo es "urgente".
Establecer un criterio de priorización —el que sea, siempre que sea explícito y compartido— es una de las inversiones más baratas y de mayor retorno que puede hacer un equipo de producto. No elimina las discusiones, pero las ordena. Y sobre todo, evita que la decisión más importante —qué construir primero— quede librada a la inercia. Sobre este mismo punto, el artículo acerca de por qué una buena idea no garantiza un buen producto explica cómo la disciplina de ejecución termina pesando más que la inspiración inicial.
Si estás en las etapas iniciales de definición de tu producto, puede servirte revisar cómo definir el alcance de un MVP sin quedarte corto ni excederte, que aborda el problema complementario de decidir qué incluir en la primera versión.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →