Leía el otro día el artículo de Alejandro Casserra y lo confieso, yo también he caído en la telaraña. En estos años liderando productos digitales, he cometido el error de manual que asola, como poco, al 90% de la industria del software y al que dije "a mí no me la cuelas". Creía que las fórmulas de priorización se rellenaban con intuición basada en la experiencia en una "hoja de cálculo" a puerta cerrada.

Como muchos, calculaba el "Impacto" o el "Valor de Usuario" basándome en corazonadas, en lo que yo creía que era "cool" a nivel técnico, o peor aún, cediendo ante el stakeholder que gritara más fuerte en la reunión de los lunes. Creo que a muchos les resonará esta historia.

¿El resultado? Entregábamos funcionalidades impecables a nivel de diseño y código pero que no movían ni un solo céntimo la cuenta de resultados de la empresa. Éramos una fábrica ciega de software , no un negocio rentable. Hoy, mi filosofía es radicalmente opuesta: si no hay datos que respalden el impacto en el P&L (Profit and Loss), no se escribe ni una línea de código. Y esto amig@ mía, es lo verdaderamente complicado de aplicar; no porque lo sea per se, sino porque nadie nos ha enseñado a hablar el idioma del dinero.

La paradoja de la velocidad en la era de la IA

Vivimos en un momento histórico. Con la democratización de la Inteligencia Artificial y herramientas como Claude, Codex o Cursor o incluso agentes autónomos que empiezan a aparecer, los equipos de ingeniería pueden desarrollar a una velocidad vertiginosa. Pero aquí se esconde una trampa mortal: la paradoja de la velocidad generativa.

Si tu sistema de priorización está roto, la IA solo servirá para que construyas el producto equivocado ¡muchísimo más rápido!.

Antes, equivocarte te costaba semanas de desarrollo y podías corregir el rumbo. Hoy, priorizar mal te cuesta meses de impacto financiero esfumados en un par de sprints, inflando tu deuda técnica y tus costes de infraestructura a un ritmo récord, mientras ves como la competencia te adelanta por la derecha sonriendo. Si sigues priorizando únicamente por "urgencia" o por "puntos de historia" y no te interesas por la salud financiera de tu producto, estás navegando directo hacia el iceberg.

El choque de los frameworks tradicionales (y por qué están rotos)

Para decidir qué construir, solemos movernos entre tres grandes frameworks. Entender sus diferencias es la clave para saber si estás gestionando tareas o liderando un negocio.

Pero ojo, estos frameworks asumen que el input que les metes ya está limpio. Que la "feature" que estás puntuando realmente corresponde a una señal validada, con una decisión clara detrás y un nivel de confianza entendible. Si metes pedidos crudos sin analizar, cualquier fórmula te va a dar resultados basados en humo. Antes de aplicar el Outcome Score, o cualquier modelo de priorización, necesitas un paso previo: analizar si lo que estás priorizando es señal real o ruido disfrazado de solución. De eso hablamos en el artículo anterior El arte del Discovery.

1. WSJF (Weighted Shortest Job First): Es el estándar de SAFe y las grandes corporaciones. Su obsesión es el flujo: que nada se detenga. Se basa en el Cost of Delay (Coste de Retraso), pero suele pecar de una subjetividad extrema en su definición de "Valor" y premia sistemáticamente lo pequeño frente a lo verdaderamente estratégico.

2. RICE (Reach, Impact, Confidence, Effort): Popularizado por Intercom, fue un gran salto adelante al introducir el Alcance y la Confianza. Sin embargo, en la mayoría de los equipos el "Impacto" se sigue puntuando del 1 al 5 por pura intuición, convirtiéndose en un nido de métricas inventadas (inventmetrics).

3. El fallo de las Matrices de ROI Estimado: El intento clásico de las organizaciones por crear un "Business Case" en formato de tabla paramétrica. Se intenta cruzar un impacto financiero intuido en una escala del 1 al 10 con un denominador de "Esfuerzo" medido en puntos de historia (ej. 0.5 puntos vs 13 puntos). La matemática se rompe por un problema de escalas: una tarea minúscula, cosmética e irrelevante para el negocio, pero con un esfuerzo técnico cercano a cero, siempre obtendrá un score gigante, canibalizando por completo a los proyectos estratégicos de alto impacto en el P&L que requieren varios sprints.

   Característica	1. WSJF (Estándar Corporativo)	2. RICE (Estándar Product-Led)	3. Matrices de ROI Estimado (Tradicional)
   Driver principal	Urgencia. Evitar retrasos a toda costa.	Valor de Usuario y Alcance.	Retorno intuido a corto plazo.
   Tratamiento del riesgo	El riesgo de no hacerlo suma puntos (RROE).	La confianza multiplica (filtra intuiciones).	Ignora el riesgo; asume que el PowerPoint se cumplirá al 100%.
   Visión de costes	Tiempo de desarrollo (Job Size).	Esfuerzo técnico en tiempo (Person-months).	Estimación arbitraria de coste o puntos de historia.
   Contexto ideal	Factorías de software masivas (SAFe).	SaaS maduros centrados en adopción masiva.	Comités de negocio tradicionales basados en proyectos cerrados.

La fórmula "Outcome Mindset" (Outcome Score)

Para solucionar esto, he evolucionado el modelo hacia una fórmula mixta. Cogemos el foco financiero en el P&L, eliminamos las suposiciones abstractas del alcance y adoptamos un concepto clave de metodologías ágiles modernas como Shape Up (de Basecamp): el Apetito.

En lugar de desgastar al equipo de ingeniería preguntándoles "¿Cuánto tardas?" para que intenten adivinar el futuro, es el negocio el que define el presupuesto de antemano: "¿Cuánto tiempo/recursos estamos dispuestos a invertir (gastar) para resolver este problema específico?".

La fórmula matemática definitiva queda configurada así:

La teoría es preciosa. Pero la gran barrera que paraliza a los equipos es "¿de dónde saco los datos exactos sin convertirme en un científico de datos?".

Y no es que yo sea amante de las formulitas mágicas si no que más allá del framework, lo que más me gusta de esto es que nos obliga a dialogar, priorizar y pensar estratégicamente.

Desgranemos detalladamente las variables de esta ecuación:

1. Revenue Impact (Impacto en Ingresos)

• La pregunta clave: ¿Nos traerá esto más dinero directo al P&L?

• Cómo se mide objetivamente: Escala del 1 al 10, pero vinculada a proyecciones financieras reales o datos del CRM. En B2B, es la suma del valor de los contratos perdidos y etiquetados en Salesforce por la falta de esta feature. En B2C, se calcula según el volumen del embudo afectado multiplicado por el ticket medio (ARPU).

2. Cost Efficiency (Eficiencia en Costes / OpEx)

• La pregunta clave: ¿Nos hará esto gastar menos dinero operativo?

• Cómo se mide objetivamente: Escala del 1 al 10. Se extrae directamente de las facturas de tus proveedores (AWS, OpenAI, APIs de terceros) o calculando las horas de trabajo interno que se logran automatizar (horas ahorradas al mes $\times$ coste de la hora del empleado). Si reduce directamente el margen operativo, el CFO te aplaudirá.

3. Confidence (Confianza)

• La pregunta clave: ¿Cómo de seguros estamos de estos números?

• Cómo se mide objetivamente: Olvídate de los porcentajes al azar. Usamos una escala de evidencia científica:

  • 1.0 (Certeza absoluta): Tenemos datos históricos de un MVP exitoso o facturas reales sobre la mesa.

  • 0.5 (Media): Datos cualitativos medianamente validados (entrevistas con usuarios, análisis de competencia).

  • 0.1 (Baja): Es una corazonada del CEO o una suposición de pasillo sin validar. Si la confianza es baja, la fórmula destruirá el score, obligándote a hacer Discovery antes de picar código.

4. Apetito (Nuevo denominador de Esfuerzo)

• La pregunta clave: ¿Cuál es el presupuesto máximo de tiempo que merece esta apuesta?

• Cómo se mide objetivamente: Se mide en Sprints reales de desarrollo (ej. 1 sprint, 2 sprints, 4 sprints). Al situarlo en el denominador, la fórmula calcula el Retorno Financiero por Unidad de Tiempo. Cambia por completo la dinámica: el equipo ya no "estima horas en el aire", sino que recibe un contenedor de tiempo cerrado y debe diseñar la mejor solución técnica que quepa dentro de ese presupuesto del tiempo.

5. Strategic Fit (Alineación Estratégica)

• La pregunta clave: ¿Protege esto nuestra visión de compañía o es una distracción monetaria?

• Cómo se mide objetivamente: Funciona como un multiplicador final para premiar o penalizar la iniciativa según los OKRs corporativos:

  • x 1.5 (Foco total): Empuja directamente el objetivo prioritario del trimestre.

  • x 1.0 (Neutral): Es bueno para el P&L pero no es el foco del año.

  • x 0.5 (Distracción): Da dinero a corto plazo pero nos desvía de la visión o genera una deuda técnica inasumible.

El baño de realidad

Llegados a este punto, dejemos las cosas claras y no caigamos en la trampa de vender frameworks como si fueran dogmas de fe: la fórmula perfecta de forma automatizada, no existe. Si te fías a ciegas de este o de cualquier otro método matemático, sigues especulando.

Cualquier matriz que intente mezclar métricas financieras duras (como el ahorro en euros) con ponderaciones cualitativas (como la alineación estratégica) tiene costuras. Además, si un Product Manager se enamora de una idea, es ridículamente fácil "maquillar" los números (subiendo un punto de confianza aquí o inflando el impacto allá) para que la calculadora escupa el resultado que desea.

Entonces, ¿por qué la usamos? Porque las fórmulas son excelentes sirvientes, pero pésimos jefes.

El verdadero valor de este modelo no es el decimal que sale al final del cálculo. El valor real es el debate estructurado que fuerza en el equipo antes de llegar al número. Obliga a Marketing a defender sus proyecciones con datos, a Ingeniería a comprometerse con un presupuesto cerrado (Apetito) y al Product Lead a trazar una línea roja sobre qué es estratégico y qué es una distracción. No uses la fórmula para que tome las decisiones por ti; úsala como un filtro analítico para limpiar el ruido.

En tu Outcome Score, una funcionalidad que ayuda a retener usuarios o clientes (aumenta el LTV) o que hace el producto más "vendible" sin intervención humana (reduce el CAC) siempre debería tener prioridad absoluta sobre aquellas que solo generan ruido o engagement vacío. Si no puedes explicar cómo tu propuesta de trabajo impacta una de estas dos métricas, es probable que estés priorizando el gasto, no la inversión.

• ¿Impactas al LTV (Lifetime Value)? Si la feature mejora la retención (reduciendo el churn), permite un upsell hacia planes superiores o disminuye el coste de servicio (menos soporte humano), estás aumentando el valor total que cada cliente deja en la empresa. Una iniciativa que sube el LTV es una inversión en estabilidad financiera a largo plazo.

• ¿Impactas al CAC (Customer Acquisition Cost)? Si la feature mejora la tasa de conversión en el onboarding, potencia la viralidad o facilita que el producto se venda solo (Product-Led Growth), estás reduciendo drásticamente lo que te cuesta captar a cada nuevo usuario. Una iniciativa que baja el CAC es una inversión en crecimiento acelerado y eficiente.

Preguntas clave según tu modelo de negocio

Antes de puntuar el Revenue Impact o el Cost Efficiency, debes hacerte las preguntas correctas según si tu producto opera en un entorno B2C (volumen/masa) o B2B (valor/contrato).

Consejo PRO: No mezcles las métricas. Si eres una empresa híbrida (B2B2C), asigna los pesos de tu fórmula Outcome Score según el modelo que genere el 80% de tu margen operativo actual. Esto te mantendrá enfocado en lo que realmente paga las facturas a final de mes.

Pero ojo…

Si aplicas tu flamante Outcome Score directamente a una lista de "tareas" o features (outputs), sigues siendo una factoría de funcionalidades. Simplemente te habrás convertido en una factoría financieramente priorizada.

El arte de transformar insights en outcomes consiste en puntuar el problema a resolver, no la solución técnica.

Un insight es un hallazgo (un dato, una queja, un patrón). Un outcome es el cambio de comportamiento medible en el usuario que genera valor para el negocio. La "tarea" es solo la excusa para llegar ahí.

La forma de hacer esta traducción es radicalmente distinta si juegas al volumen (B2C) o al valor de contrato (B2B).

Caso práctico aplicado

Para ver cómo este enfoque transforma las decisiones, imaginemos que somos los Product Leaders de LingoFlow, una app móvil para aprender idiomas. El equipo debate qué priorizar en el próximo ciclo.

Opción A: Ligas virtuales de clanes (Gamificación)

Marketing está convencido de que esto disparará la retención porque el componente social está de moda.

• Revenue Impact: 7 (Alto potencial teórico de conversión).

• Cost Efficiency: 1 (No ahorra costes operativos).

• Confidence: 0.5 (Media-baja: intuición basada en la competencia, pero sin validar con nuestros usuarios).

• Apetito: Requiere un motor de matchmaking complejo. El negocio decide que el apetito máximo para esta apuesta es de 7 Sprints.

• Strategic Fit: 0.4 (Bajo: nuestro posicionamiento es el núcleo pedagógico, no los videojuegos).

Opción B: Migración a IA local para corrección oral

Actualmente, cada corrección de voz de los usuarios hace una llamada a la API en la nube de OpenAI, lo que nos cuesta una fortuna. La propuesta es pasar el procesamiento a un modelo de código abierto que se ejecute localmente en el móvil del usuario.

• Revenue Impact: 2 (Poco impacto directo en nuevas ventas).

• Cost Efficiency: 9 (Extremo: eliminará el 80% de la factura mensual de OpenAI).

• Confidence: 1.0 (Máxima: Ingeniería ya ha creado un MVP técnico con éxito y Finanzas tiene el desglose de las facturas).

• Apetito: Al estar el alcance técnico perfectamente acotado, se define un apetito de 4 Sprints.

• Strategic Fit: 0.8 (Muy alto: habilita fluidez sin latencia y uso offline).

El Veredicto Numérico

Al meter los datos en nuestro tablero de control, el resultado es el siguiente:

Bajo el WSJF o un RICE "mal tirado" (donde el impacto se inventa), Marketing habría presionado por las Ligas de Clanes. Habríamos bloqueado 7 sprints por una corazonada.

Con el Outcome Score, el resultado es implacable: 8.80 frente a 0.23. La migración a IA Local pasa a desarrollo. Cortamos la hemorragia de dinero y mejoramos el producto para el 90% de los usuarios.

Reflexión final

Adoptar un modelo basado en el P&L requiere coraje. Implica desmontar proyectos "mascota" de los directivos y aceptar que, a veces, la funcionalidad más invisible es la que salvará el año fiscal.

Cuando dejes de inventarte los números y empieces a exigir datos extraídos de facturas, CRMs y analíticas, darás el salto definitivo: dejarás de ser un mero "gestor de tickets" para convertirte en un verdadero estratega de negocio.

Sin embargo, de nada sirve tener una fórmula financiera perfecta si luego se la aplicas a una lista plana de botones y tareas técnicas. Para que este modelo funcione en la realidad, necesitas estructurar tu producto para que el código y el negocio hablen el mismo idioma y formen un engranaje perfecto. Y de esa estructura, a la que llamo el "Hilo Dorado", hablaremos en el próximo artículo.