Priorizar no se trata de elegir qué construir, sino de decidir qué vas a sacrificar. Esa es la habilidad que separa a un Product Manager operativo de uno estratégico. Cada elemento que agregas a tu roadmap consume recursos limitados, y cada "sí" que das implica un "no" rotundo a otra oportunidad que podría haber generado más valor. Entender esta dinámica es fundamental para tomar decisiones informadas y defender esas decisiones ante el resto de la organización.
¿Qué es realmente el costo de oportunidad en producto?
La contabilidad tradicional mide el costo de una iniciativa como el salario de los ingenieros multiplicado por el tiempo de desarrollo. Pero eso es un error [0:34]. El costo de oportunidad real es todo el valor que pierdes por no haber elegido la alternativa descartada.
Imagina dos opciones concretas [0:50]:
- Opción A: mejorar la performance de tu aplicación. Tarda un mes y mejora la retención de inmediato.
- Opción B: una integración de video que ventas pide con urgencia, pero tardará seis meses en estar lista.
Si cedes a la presión y eliges el video, tu costo no es solo el desarrollo. Estás perdiendo cinco meses de flujo de caja que la mejora de performance te habría dado mucho antes. Este concepto se conoce como Time to Money [1:12]: el tiempo que transcurre hasta que una decisión genera retorno económico.
Además, existe un costo invisible que se denomina el impuesto por falta de enfoque [1:19]. Si intentas hacer ambas cosas dividiendo a tu equipo, el cambio de contexto destruirá su productividad. No avanzas el doble; avanzas a la mitad de velocidad en ambos frentes. Aceptar esta realidad es el primer paso para priorizar con honestidad.
¿Cómo nivelar el terreno al comparar iniciativas?
El error más común es poner en la misma balanza una iniciativa validada con datos (confianza del 100%) contra una corazonada de un directivo (confianza del 50%) y tratarlas como iguales [1:41]. No puedes priorizar una especulación sobre un hecho comprobado sin ajustar el riesgo.
¿Qué es el factor de legado en estimaciones de esfuerzo?
Las estimaciones de ingeniería suelen ser optimistas en el vacío. El Factor de Legado [2:02] corrige esa distorsión con multiplicadores según el tipo de código:
- Código nuevo: factor 1.
- Código existente con tests: multiplica por 1.3.
- Sistemas legacy sin documentación ni pruebas: multiplica por 3.
La analogía es clara: pintar una pared nueva es rápido; renovar una casa con cimientos podridos es otra historia [2:24].
¿Cómo funciona la ecuación de justificación con el semáforo de deuda técnica?
Para validar si el sacrificio vale la pena, aplica la Ecuación de Justificación usando un semáforo de deuda técnica [2:29]:
- Verde: la iniciativa reduce deuda.
- Amarillo: es neutral.
- Rojo: genera deuda nueva.
La regla es estricta: si una iniciativa requiere alto esfuerzo y está en rojo —es decir, te cobrará intereses técnicos en el futuro—, debe tener un impacto astronómico para entrar en el roadmap [2:48]. Si el impacto es solo "bueno", recházala. No hipoteques el futuro por una ganancia marginal.
Aquí entra el Modelo Kano como defensa final [3:01]. Nunca sacrifiques un atributo básico por un delighter. Si tu proceso de pago falla, no importa cuán innovadora sea tu nueva función de inteligencia artificial: estarías construyendo un ático de lujo sobre cimientos rotos. Los básicos aseguran la viabilidad; los delighters son un lujo que solo te puedes permitir cuando la casa está en orden.
¿Cómo comunicar y documentar decisiones de trade-off?
Cuando tengas que rechazar una petición, no digas "no tenemos capacidad" [3:30]. Eso suena a debilidad. Transforma tu negativa en una narrativa estratégica. Por ejemplo: "No haremos el dashboard de reportes este trimestre porque estamos priorizando la integración de pagos, que impacta directamente nuestro OKR de ingresos del Q3".
El secreto para sobrevivir a la política interna es documentar el sacrificio [3:54]:
- Registra explícitamente la alternativa descartada y por qué perdió.
- Escribe algo como: "Elegimos la integración de pagos y sacrificamos el dashboard para asegurar el OKR de ingresos".
Seis meses después, cuando alguien pregunte por qué falta el dashboard, tendrás la evidencia del trade-off estratégico, no una excusa vaga sobre falta de tiempo.
Como ejercicio mental rápido [4:18]: piensa en la última funcionalidad que agregaste al backlog "por si acaso". Pásala por el filtro: ¿genera deuda técnica roja? ¿Su confianza es menor al 80%? Si la respuesta es sí, probablemente deberías eliminarla ahora mismo. Un roadmap estratégico se define más por lo que dejas fuera que por lo que pones dentro.
