Mejor lanzarlo que admitir el error

En pocas palabras: La falacia del coste hundido hace que los equipos confundan lo que ya gastaron con lo que los usuarios necesitan ahora. Detener el trabajo parece demasiado caro, así que se lanza algo roto solo para sentir que el esfuerzo estuvo justificado.

Sabías que había que parar y seguiste igualmente. No solo porque lo dijera la hoja de ruta. Seguiste porque el equipo ya había dedicado tanto tiempo que cancelarlo se sentía peor que lanzar algo en lo que no confiabas.

Esa es la trampa del coste hundido. El tiempo y el esfuerzo ya se fueron, pero siguen pesando sobre la siguiente decisión. En vez de preguntar qué tiene sentido ahora, el equipo busca cómo hacer que el gasto pasado parezca menos inútil.

Por qué los equipos protegen trabajo que deberían descartar

Un coste hundido es dinero, tiempo o esfuerzo que no puedes recuperar. La decisión correcta debería ignorarlo. Hal Arkes y Catherine Blumer mostraron lo mal que lo hacemos. Cuando la gente ya ha invertido algo, siente el impulso de continuar aunque la evidencia diga que pare. Lo llamaron «una tendencia a continuar una actividad una vez realizada una inversión» (traducción del inglés).

Richard Thaler ayuda a explicar por qué. Las pérdidas duelen. Si pasaste meses en una función, cancelarla se siente como hacer oficial esa pérdida. Lanzarla puede parecer una oportunidad de salvar algo todavía. La lógica es mala. El impulso es real.

El plan puede haber desaparecido. La fecha puede haberse movido. Los equipos siguen manteniendo algo malo con vida porque no soportan mirar de frente el coste que ya está ahí.

Eso distingue al coste hundido de la presión de la hoja de ruta. Ya ni siquiera tiene que haber alguien pidiendo la función. El trabajo sobrevive porque el propio equipo no soporta dar por perdido el esfuerzo. El pasado sigue sentado en la sala.

Microsoft lanzó Kin de todos modos

En 2010, Microsoft lanzó Kin, dos teléfonos dirigidos a usuarios jóvenes. La empresa había dedicado unos dos años y alrededor de mil millones de dólares a construir la plataforma. Después lanzó un producto que duró 48 días.

Lo que hace útil a Kin aquí no es solo que fracasara. Es que las advertencias existían antes del lanzamiento. En 2012, Wired publicó vídeos internos de usabilidad donde los participantes se atascaban en tareas básicas y describían los teléfonos como frustrantes y confusos. Los problemas no eran sutiles. Microsoft los lanzó igualmente.

Así se ve el coste hundido en un producto. Años de trabajo. Un gasto enorme. Demasiado construido ya. A esas alturas, cancelarlo habría significado admitir la pérdida sin rodeos.

Y cuando un equipo llega ahí, casi cualquier parche empieza a sonar atractivo. Otro ciclo de trabajo. Otra revisión. Otra capa de explicación alrededor de la parte rota. No porque esas medidas resuelvan el problema de fondo. Porque retrasan el momento en que alguien tiene que decir que la inversión original no dio resultado.

Cómo se ve esto en los equipos de producto

Concorde es la versión famosa del patrón. El avión era una obra de ingeniería extraordinaria, pero las cuentas habían dejado de tener sentido mucho antes de terminar el proyecto. Los gobiernos siguieron apoyándolo, en parte porque ya se había gastado tanto que parar parecía aceptar la pérdida de lleno.

Kin está más cerca del tipo de decisión que toman los equipos de producto. El equipo ya había construido el producto. Los resultados de las pruebas eran malos. La gente se atascaba en tareas básicas. Era confuso de formas difíciles de pasar por alto.

Entonces alguien dice que quizá podemos parchearlo. Añadir etiquetas. Añadir orientación. Darle otra vuelta. No porque eso resuelva el problema. Porque tirarlo se siente peor que lanzar una versión rota. He visto a equipos hacerlo después de meses de trabajo, de una gran demostración, de anunciar una fecha interna de lanzamiento. La función sobrevive porque nadie quiere admitir el coste que ya está sobre la mesa.

Esa es la pregunta aquí. Olvida «¿lo prometimos?». Olvida «¿está en la hoja de ruta?». Pregunta esto: ¿seguimos protegiendo el trabajo por lo que ya nos costó? He oído esa lógica aparecer como preocupación por la consistencia, la marca, el impulso y la moral del equipo.

Aquí los equipos empiezan a vestir la misma decisión con lenguaje educado. Dicen que la función está casi lista. Que los usuarios la aprenderán. Que lanzar les enseñará más. A veces lanzar sí enseña más. A veces el equipo ya sabe suficiente y el aprendizaje adicional solo encubre la negativa a asumir la pérdida.

Qué preguntar antes de lanzarlo de todos modos

Haz una pregunta: si esto llegara hoy a tu mesa sin ninguna historia detrás, ¿lo lanzarías?

Esa pregunta elimina lo que tu cerebro sigue introduciendo a escondidas. Las horas. Las demostraciones. El estrés. Los trastornos en los plazos. Nada de eso ayuda al usuario si el producto sigue estando mal.

Kahneman es útil aquí porque insiste en la misma corrección: sal de la historia en la que estás atrapado y mira la decisión desde un lugar más frío. El gasto pasado es real, pero sigue sin tener derecho a decidir nada.

Me gusta esta pregunta porque saca la historia de la sala por un segundo. Si hoy el producto no sobreviviría al primer contacto, los meses que tiene detrás no lo hacen más fuerte. Solo hacen más difícil cancelarlo. Ese suele ser el momento en que la sala por fin ve la función como es ahora y no como parecía hace tres meses.

Eso es un problema de gestión, no del usuario. No se lo pases al usuario.