Cómo priorizar features de IA por impacto y esfuerzo

La escena se repite: un backlog con quince ideas de IA, todas “prioritarias”, y un equipo que decide por la que sonó mejor en la última reunión o por la que pidió el cliente más ruidoso. Tres meses después, la feature está en producción, casi nadie la usa y la factura de tokens sube cada mes.

El problema no es la idea. Es que priorizar features de IA no es como priorizar features normales, y casi todo el mundo las mete en el mismo embudo de siempre. Este es el criterio que uso para ordenar un backlog de IA sin quemar roadmap ni presupuesto.

Si aún no tienes claro qué flujos son siquiera candidatos, empieza por dónde aplicar IA en tu producto SaaS: este artículo asume que ya tienes una lista de oportunidades y hay que ordenarla.

Por qué la IA rompe la priorización clásica

En software tradicional, cuando una feature está construida, su coste marginal tiende a cero: la usen diez o diez mil personas, el código es el mismo. Por eso priorizamos casi solo por esfuerzo de desarrollo contra impacto esperado.

La IA rompe esa lógica en dos puntos:

• El coste no termina en el lanzamiento. Cada uso gasta tokens, añade latencia y abre casos límite nuevos. Una feature barata de construir puede ser cara de mantener para siempre.
• La incertidumbre es mayor. No sabes de antemano si el modelo va a funcionar lo bastante bien en tu caso concreto hasta que lo pruebas con datos reales. Eso es riesgo, y el riesgo pertenece al eje de esfuerzo.

Si priorizas IA con la matriz de siempre, subestimas sistemáticamente el coste real y sobreestimas la certeza. De ahí salen los backlogs llenos de demos que nadie mantiene.

Los dos ejes que de verdad importan

No necesitas un framework nuevo. Necesitas los dos ejes de siempre, pero midiendo bien lo que va en cada uno.

Impacto en una métrica de negocio real contra esfuerzo de construir y operar. Lo segundo es lo que casi todo el mundo deja fuera de la ecuación.

Cómo estimar el impacto

El impacto solo cuenta si se ata a una métrica que ya te importaba antes de la IA:

• Activación o time-to-value: ¿la feature acorta el camino del usuario a su primer resultado?
• Retención: ¿resuelve algo que hoy hace que la gente se caiga?
• Coste de soporte: ¿reduce tickets repetidos o trabajo manual de tu equipo?
• Tiempo por tarea: ¿le ahorra minutos reales al usuario en algo que hace a menudo?

Si una feature de IA no mueve ninguna de estas, no tiene impacto de producto: tiene impacto de marketing. Es legítimo, pero priorízala como lo que es y no le robes sitio a lo que sí mueve el negocio.

Cómo estimar el esfuerzo (aquí está la trampa)

El esfuerzo de una feature de IA tiene tres capas, y la mayoría solo estima la primera:

1. Construir: el desarrollo hasta la primera versión. Suele ser lo más rápido.
2. Operar: tokens por uso, latencia aceptable, evaluación continua de la calidad, gestión de errores y casos límite. Esto no acaba nunca.
3. La confianza: el trabajo de diseño para que el usuario se fíe del resultado y lo use. Una feature en la que nadie confía tiene coste de operación cero porque nadie la toca, y también impacto cero.

Un truco práctico: para cada candidata, escribe cuánto costaría al mes tenerla funcionando para tu volumen real de usuarios. Si no sabes contestar, esa incógnita ya es una señal de esfuerzo alto por riesgo.

Un método que cabe en una tarde

No hace falta un comité de tres reuniones. Con la lista de candidatos:

1. Puntúa impacto de 1 a 5 contra la métrica concreta que elegiste para cada una. Sé honesto: la mayoría son un 2.
2. Puntúa esfuerzo de 1 a 5 sumando las tres capas de arriba, no solo el desarrollo.
3. Ordena por impacto alto y esfuerzo bajo. Esa es tu primera apuesta.
4. Elige una sola. Constrúyela con una salida verificable, mídela contra su métrica durante unas semanas y solo entonces pasa a la siguiente.

La disciplina de elegir una es lo que separa un roadmap de IA que aprende de uno que acumula features muertas. Cada apuesta validada te dice algo real sobre si la IA funciona en tu producto; cinco a medias no te dicen nada.

Los errores que veo una y otra vez

• Priorizar por lo vistoso, no por lo rentable. El chat con IA en el dashboard suele ser mucho menos rentable que el prellenado aburrido de un formulario en el onboarding. (Sobre esto último: cómo reducir la fricción en el onboarding.)
• Ignorar el coste de operación hasta que llega la factura. Métete el coste mensual en el eje de esfuerzo desde el día uno.
• Comprometer roadmap antes de validar. Con IA, el orden es prototipo con datos reales, medir, y luego comprometer. Nunca al revés.
• Confundir “podemos” con “deberíamos”. Que el modelo pueda hacerlo no significa que mueva tu métrica ni que el usuario lo quiera.

Por dónde empezar

Resumido: prioriza features de IA por impacto en una métrica real contra el esfuerzo de construir y operar, y apuesta por una sola cada vez. El coste de operación y la incertidumbre son las dos variables que la priorización clásica ignora y las que hunden la mayoría de backlogs de IA.

Este es exactamente el trabajo de la Product & AI Audit Express: reviso tus flujos, saco las oportunidades de IA y te las devuelvo ya ordenadas por impacto y esfuerzo, con el coste de operación estimado. Y si quieres hacer la primera pasada tú, el checklist de oportunidades de IA en producto lleva este mismo criterio, flujo por flujo, en un PDF para una tarde.