En algunas empresas de consumo te hacen rellenar un formulario antes de aceptarte una devolución. Tienes que explicarles qué falla, por qué los quieres cambiar, dar detalles del problema.

En algunas ocasiones no hay nadie leyendo lo que escribiste y poniendo un sello de solicitud aprobada o denegada. Todas son aprobadas. El coste de leerlas, estudiarlas y aprobarlas o atender las reclamaciones cuando lo niegas tiene un coste mayor que simplemente cambiarte el producto por otro igual.

Hay empresas que sí revisan esos formularios, pero en otras solo están para tratar de introducir fricción para reducir el numero de solicitudes. El simple hecho de obligarte a explicar el motivo hace que muchas personas piensen dos veces si realmente merece la pena.

Ese mismo principio aparece continuamente en el desarrollo de productos software y no software.

Cuando como Product Manager te llega una petición «urgente» y todo el mundo quiere que empieces con ella hoy mismo (present bias), pero dos semanas después aparece otra prioridad descubres que muchas urgencias tienen fecha de caducidad.

Dejar pasar algo de tiempo y tratar de averiguar primero qué coste o qué beneficios tiene para la empresa o el producto esa nueva solicitud de desarrollo o cambio te va a ayudar a dar reposo y estabilidad al flujo de trabajo.

El tiempo filtra las falsas urgencias. Es, a veces, la mejor herramienta para priorizar tu producto. Incluso mejor que Jira.

No se trata de dejar todo para mañana. Se trata mejor de no dejarse llevar por los impulsos o por esa sensación de «tengo que hacer algo, lo que sea» (action bias) para mostrar una diligencia que en realidad solo nos está atropellando nuestro proceso de decisión.