La confianza perdida (Lost confidence)

• Los marcos de priorización basados en confianza como RICE son en su mayoría ruido, y hace falta una forma de tomar decisiones sin fingir que conocemos un futuro desconocido
• Los puntajes de confianza suelen asignarse altos para proyectos pequeños (small) y bajos para proyectos grandes (large), por lo que desplazan sistemáticamente los proyectos de mayor valor y distorsionan la priorización
• Los puntajes de confianza tienen una definición ambigua, faltan datos para validarlos y los proyectos casi siempre se retrasan y generan menos impacto del esperado, por lo que no son confiables
• La solución es preguntar, no en el terreno de la probabilidad, sino en el de la incertidumbre, qué acción es sensata bajo cualquier distribución de probabilidades
• En vez de confianza, es importante priorizar con técnicas como lo que siempre es cierto, el impacto en el cliente, preservar opciones y apuestas asimétricas

---

Juegos de confianza (Confidence games)

• Muchos marcos de priorización incluyen en su puntaje la confianza en que se puede lograr el impacto previsto con el esfuerzo estimado
  • Entre dos proyectos con el mismo valor y el mismo esfuerzo, elegir el que tiene mayor confianza de ejecución es razonable en sí mismo
  • Pero en la práctica no se usan como “1) puntuar → 2) ejecutar al ganador claro → 3) si hay empate, elegir el de mayor confianza”
• RICE mete la confianza directamente en la fórmula del puntaje del paso 1
  • Fórmula de RICE: Score = (Reach × Impact × Confidence) / Effort
  • Fórmula de RPS: Score = Reach × Potential × Solution Confidence
• Este enfoque trata dos escenarios distintos como si fueran equivalentes y crea una falsa equivalencia
  • Una funcionalidad incremental pequeña pero claramente ejecutable
  • Una funcionalidad grande, con mucho impacto potencial, pero con riesgo
• Como normalmente los proyectos pequeños tienen alta confianza y los grandes baja, multiplicar por confianza aleja sistemáticamente de maximizar el valor entregado
  • De hecho, una motivación central del movimiento Agile era la idea de que “el éxito de los proyectos grandes siempre debería tener baja confianza”
• Razones para no confiar en los puntajes de confianza
  • La definición es ambigua: no está claro qué significa “30%”. En teoría habría que registrar el puntaje de confianza de todos los proyectos y compararlo con los resultados reales para medir su precisión, pero en la práctica no se hace
  • Si cada año solo se lanzan unas pocas funciones importantes, incluso después del hecho faltan datos para validar
  • Los proyectos casi siempre se retrasan y su impacto es menor y más lento de lo esperado. Incluso un proyecto de 9 meses con 6 equipos empezó porque había “cierto nivel de confianza”
• Cita de Hofstadter's Law: “Siempre toma más tiempo del esperado, incluso si se toma en cuenta Hofstadter's Law”
• Si le preguntas a PMs con experiencia por “funciones de las que estaban seguros de que serían bien recibidas y no lo fueron”, todos tienen varios ejemplos
  • Aunque haya conversaciones con clientes, solicitudes explícitas o promesas de compra, cuando por fin se construye, casi nadie lo usa, ni siquiera quienes lo prometieron
  • Una técnica para mejorar la predicción: hacer que el cliente explique paso a paso cómo lo usaría en su flujo de trabajo real. Al recorrerlo, suele darse cuenta por sí mismo de cosas como “no, eso implicaría reescribir el código, así que no lo haría”
• A los creadores de contenido les pasa igual: textos publicados rápido y sin grandes expectativas terminan siendo los más vistos o comentados del año, mientras que trabajos elaborados durante decenas de horas pueden pasar desapercibidos
  • En la tabla 2×2 de “nivel de confianza × resultado (amado/ignorado)”, los cuatro cuadrantes están llenos de ejemplos

Qué usar en lugar de confianza y riesgo (What to use in place of confidence and risk)

• La respuesta está en el terreno de la incertidumbre, no de la probabilidad
  • La probabilidad supone que conoces la distribución. Si lanzas una moneda justa 100 veces, es muy razonable predecir que saldrá cara entre 40 y 60 veces
  • Casi todo en una startup es distinto. El éxito, la estrategia y las funcionalidades son inéditos, demasiado complejos o carecen de variables de entrada suficientemente precisas como para asignar probabilidades significativas
  • De ahí el concepto de “Knightian Uncertainty” de Frank Knight, originado en su obra de 1921
  • Incluso los métodos bayesianos requieren probabilidades previas numéricas y probabilidades condicionales, y en estos casos ninguna de las dos se conoce ni puede definirse
• La pregunta en un entorno de incertidumbre es: “qué acción es sensata sin importar la distribución de probabilidades”

• Lo que siempre es cierto (True always)

  • Enfocarse en lo que siempre es cierto en cualquier escenario: el principio de Bezos de las constantes de largo plazo (long-term constants)
    • Los usuarios casi siempre prefieren software rápido y responsivo. Valoran la sincronización en segundo plano, la interacción inmediata y que funcione en todos sus dispositivos
    • Incluso en el peor caso, a nadie le molesta la velocidad; y en el mejor, el rendimiento se vuelve un diferenciador clave, como en Notion, Figma, Miro, Gmail o Google Docs
  • No todas las funciones tienen atractivo universal. En lugar de descomponerlo en cifras muy precisas, conviene identificar funciones que prácticamente todos los clientes valoran o al menos aprecian
    • A veces es seguro porque es obligatorio. Requisitos empresariales como el cumplimiento de SOC 2 no son emocionantes, pero tienen valor claro si vendes a empresas
    • Esa certeza compensa la falta de diferenciación
  • Aun así, las ideas más innovadoras y diferenciadoras casi nunca entran en la categoría de “absolutamente seguras”
    • Lo seguro tiene valor, pero rara vez sirve como diferenciador estratégico
    • Un gran producto necesita tanto mejoras confiables como saltos innovadores

• Descubrimiento rápido, recuperación rápida (Quick discovery, quick recovery)

  • Durante mucho tiempo se ha defendido validar ideas entrevistando sistemáticamente a clientes potenciales antes de construir, pero eso también cae en la trampa de la confianza
    • Nunca se puede saber con certeza antes de construir
    • Aun así, antes de construir sí es posible invalidar hipótesis y evitar desperdiciar meses o años, por lo que sigue siendo un buen punto de partida
  • La solución típica es crear un SLC (una evolución del MVP): un producto simple pero completo para obtener retroalimentación real, basada en experiencia y no en predicción
    • Los productos existentes deberían mantener una cartera equilibrada entre victorias seguras y apuestas innovadoras, aplicando distintos métodos de validación a cada una
  • Ejemplo de “dummy features”: un botón que, al hacer clic, muestra “esta función todavía no existe; cuéntanos cómo la usarías”
    • Eso da una señal real, a partir del comportamiento, sobre cuántos usuarios están interesados y a quiénes conviene entrevistar
    • Es una señal 100 veces mejor que una encuesta. En una encuesta es fácil decir “sí”; hacer clic en un botón exige interés real. El comportamiento observado vence a la intención declarada

• Enfocarse en el impacto al cliente en vez de la confianza (Focus instead on customer impact)

  • Reemplazar la confianza por impacto. El impacto se define de dos formas
    • Regla de la mayoría (Majority rule): una función que la mayoría usa regularmente es claramente importante y probablemente es una razón clave de adopción y retención
    • Defensores apasionados (Passionate advocates): funciones que generan fans intensos dentro de una minoría. Personas que dicen “lo compré solo por esto”. No son universales, pero crean lealtad profunda en segmentos concretos (“magnificent delighters”)
  • Cuando los usuarios aman de verdad una parte específica, toleran otros defectos
    • El atractivo del iPod hizo que miles de millones de personas toleraran iTunes, el peor software del mundo
    • Un software hermosamente diseñado puede ser aceptado por la experiencia de diseño aunque le falten funciones o tenga limitaciones de plataforma
  • Definición cuantitativa de función de alto impacto
    • (1) al menos 51% de los clientes la usan regularmente, o
    • (2) al menos 15% de los clientes la mencionan entre sus 3 principales razones para elegir o seguir usando el producto
    • Es un criterio alto, pero las funciones innovadoras y riesgosas deben pasar un estándar alto; el tamaño de la recompensa debe justificar el riesgo

• Invertir en apalancamiento (Invest in leverage)

  • Hay áreas donde pequeños cambios incrementales producen resultados grandes
  • Existen zonas de apalancamiento que matemática y estructuralmente casi siempre se cumplen
    • (La parte promocional del libro relacionado se omite por ser publicidad)

• Maximizar la opcionalidad (Maximize optionality)

  • Si no puedes conocer el futuro, elige aquello que maximiza la cantidad de opciones que tendrás cuando llegues a él
    • Va más allá de la simple flexibilidad o de evitar lock-in; se trata de diseñar para poder responder a lo que sea que ocurra
  • Ejemplos
    • Mantener costos bajos → proteger la rentabilidad y conservar capacidad para experimentar con precios, packaging y resiliencia futura
    • Elegir librerías o frameworks de UI multiplataforma bien validados y activamente desarrollados → adaptarse a la evolución de plataformas y dispositivos
    • Arquitectura de plugins → permitir que tú y la comunidad construyan cosas que hoy ni siquiera imaginan
    • Arquitectura API-first → aislar equipos y conectar frontend, backend e integraciones de clientes
    • Wrappers sobre servicios de vendors → permitir reemplazar proveedores inestables, caros o rezagados
  • Asegurar opciones futuras exige trabajo extra hoy
    • Envolver un servicio externo con una API propia no agrega valor inmediato hoy
    • Puede ser una decisión inteligente en empresas maduras, donde importan la estabilidad y la previsibilidad, pero en una etapa temprana, donde hay que ganarle a incumbentes con velocidad, puede ser una mala decisión
  • La mejor manera de maximizar las opciones de toda la empresa es construir una gran empresa
    • Crecimiento sano y sostenido, gran margen bruto en expansión, amor del cliente demostrado por retención, upgrades y boca a boca, y amor de los empleados demostrado por permanencia larga y crecimiento profesional
    • Una gran empresa tiene muchas opciones: adquisición, continuidad, financiamiento, IPO, sucesión, etc.

• Portafolio de apuestas (Portfolio of bets)

  • Un portafolio reduce la volatilidad, pero también reduce el máximo potencial al alza
    • La probabilidad de no tener ninguna victoria es baja, así que el piso no es tan malo; pero como las ganancias tienen que compensar las pérdidas, incluso un gran acierto ocasional no llega al nivel de una apuesta única
    • Analogía: comprar Amazon en su IPO y conservarla para siempre habría sido ideal, pero aplicar esa misma decisión a otros IPO de ese año podría haber terminado en $0. Un portafolio evita llegar a cero, pero su crecimiento máximo es mucho menor que el del mejor activo
  • Nota matemática: el portafolio funciona sin importar la distribución gracias al Teorema Central del Límite (Central Limit Theorem)
    • Si extraes repetidamente N muestras de una población con distribución estable pero desconocida y haces un histograma de las medias muestrales, esa distribución converge a una gaussiana (normal), con media igual a la poblacional y varianza igual a la varianza poblacional dividida por 1/n
    • El Lindeberg–Lévy CLT muestra que esto también se cumple cuando cada muestra proviene de distribuciones distintas, siempre que haya independencia, varianza finita y que ninguna variable individual domine
    • Pero en entornos de startups estas condiciones pueden romperse con frecuencia, por ejemplo en algunas distribuciones tipo Power Law donde la varianza es infinita
  • El portafolio sirve cuando buscas resultados predecibles pero promedio; no sirve cuando buscas outliers
    • Ejemplo de portafolios de venture capital o angel investing: 65% pierden dinero y apenas alrededor de 10% generan retornos que justifican el riesgo y la iliquidez
    • Si buscas outliers, no necesitas un portafolio sino una apuesta total (all-in), porque la distribución de retornos en startups sigue una Power Law que viola el criterio de Lindeberg
  • Conclusión: si la prioridad es encontrar diferenciación en el mercado o motores de crecimiento, el portafolio es la herramienta equivocada. Sirve para resultados pequeños, confiables e incrementales, y en ese caso no hace falta pelear por la confianza

• Apuestas asimétricas (Asymmetric bets)

  • Son el opuesto natural del portafolio. Si el portafolio busca confiabilidad, las apuestas asimétricas buscan outliers
    • No se trata de predecir si la apuesta saldrá bien o mal, sino de tomar apuestas con baja pérdida limitada y cuantificable, y gran potencial al alza
  • Si el peor caso es “perder 2 meses” y el mejor es “lograr diferenciación total”, la probabilidad casi no importa
    • Lo importante es que la pérdida sea sobrevivible y que una sola victoria pueda compensar diez fracasos
    • Puede que no conozcas la probabilidad exacta, pero sí puedes conocer la forma (shape) de cada apuesta
  • En el nivel estratégico, las apuestas asimétricas suelen venir con una forma bastante definida de antemano (como un mercado nuevo donde las recomendaciones compuestas se acumulan, o un moat que se profundiza con cada venta)
    • En el nivel de funcionalidad, la asimetría hay que diseñarla explícitamente, porque la forma por defecto de un proyecto de software tiende a derivar en “2 semanas → 2 meses → ya llevamos tanto invertido que hay que terminarlo”
    • El mecanismo es definir por escrito un presupuesto antes de empezar: “2 ingenieros, 3 semanas, después se detiene y se revisa”. El timebox es la pérdida limitada
  • También se puede reemplazar la confianza por “qué tan asimétrica es esta apuesta”
    • RICE exige estimar probabilidades que en realidad reconocemos que no se pueden conocer
    • La asimetría pregunta por dos cosas que sí pueden estimarse: el peor caso en tiempo y costo y el mejor caso en valor para el cliente. Ambas son concretas y, si se limitan todos los números a potencias de 10, suelen converger en cifras sobre las que un equipo puede ponerse de acuerdo

Conclusión

• Hay que dejar de fingir que la confianza puede cuantificarse o definirse
• En su lugar, usar técnicas que funcionan siempre que el futuro es impredecible — porque el futuro siempre es impredecible

[hmmhmmhm]

"En cambio, usar una técnica que funcione cada vez que el futuro sea impredecible, porque el futuro siempre es impredecible". Excelente.

[spilist2]

Es un texto excelente.