Manual (psicológico) para fracasar en proyectos digitales: Cuando sólo vemos lo que queremos ver

El boom del concepto Lean Startup nos hizo creer a muchos (ilusos) que iba a cambiar el modelo de afrontar proyectos digitales: por fin se daba la importancia requerida a comprobar las hipótesis de negocio, las de necesidad/problema del usuario…

Parecía que este cambio de perspectiva nos traería una nueva época donde la investigación y el contraste con la realidad se impondría. Esto, unido a la confianza en la experiencia de los profesionales, constructores de esos proyectos digitales, dibujaba un camino esperanzador, no ya sólo para los proyectos más tipo startup, sino para todo tipo de proyectos digitales, incluidos los de grandes marcas, etc.

Pero, en realidad, lo que se ha generado es más de lo mismo: “quiero mi proyecto así y así, y no necesito user research porque ya sé lo que quieren mis inexistentes usuarios (he preguntado entre mi círculo de confianza y mi proyecto les parece una idea genial), y además lo quiero barato y lo más grande posible porque los inversores no quieren maquetas que poder pivotar sino producto final…” , pervirtiéndose hasta el infinito la idea “lean startup” que lo inició todo.

Desde luego, nadie conoce mejor su negocio que su propio dueño. Por eso la riqueza está, precisamente, en poder combinar: ese conocimiento de negocio + el conocimiento de las necesidades de los usuarios + el expertise de quien va a modelar y construir el proyecto digital.

El problema es que no lo estamos haciendo a pesar de que pareciera que la filosofía Lean Startup iba a allanar el camino.

Muchos proyectos digitales se abordan sin comprobar si solucionarán un problema real del usuario, si hay mercado suficiente, sin paliar sus debilidades como marca y producto, sin testar las apuestas para hacerlas menos ruleta rusa…

En lo que a mi respecta, he decidido buscar algún atisbo de luz a los repetidos errores en una de mis más recientes pasiones: la psicología del comportamiento de usuario. Y es extrapolando “usuario” a “cliente”, “proveedor”, etc. :D, cuando tropiezo de frente, como una de las posibles causas, con el Sesgo de Confirmación.

El sesgo de confirmación y las oraciones

El sesgo de confirmación es la tendencia que tenemos las personas a buscar la evidencia que confirma nuestra expectativa, reduciendo (o anulando) el peso de las pruebas que la invalidan.

Los psicólogos Dick Nisbett y Lee Ross exponen el peligro de este sesgo a través de un ejemplo (referenciado por la Wesleyan University en su curso Social Psychology de Coursera) bastante claro:

¿Cómo comprobaríamos la hipótesis de si Dios contesta a las oraciones para salvar la vida de alguien a quien quieres? Para responder, tendríamos que conseguir varios datos:

A) Con qué frecuencia las personas que están al borde de la muerte sobreviven cuando se reza por ellas.
B) Con qué frecuencia mueren a pesar de haber orado por ellas.
C) Con qué frecuencia sobreviven cuando nadie reza por ellas.
D) Y también, ¿cuántas mueren cuando nadie reza por ellas?

Sufrimos el sesgo cuando partimos de una creencia sobre el resultado (por ej. que la oración ayuda a que nuestros seres queridos sobrevivan) y damos más peso a las pruebas que confirma esa teoría que al resto (ej. los resultados de A por encima o en lugar de los de B, C y D).

Parece evidente que no podemos quedarnos con al menos una sola de las casillas de la tabla para responder a la pregunta de las oraciones, ¿no? Sin embargo lo hacemos constantemente en nuestro día a día. Y por supuesto también cuando queremos comprobar las hipótesis que, incorrectamente validadas, sustentan nuestra idea de negocio. O la solución que aspiramos a crear. O…

En el caso de un proyecto a lanzar, necesitaremos comprobar, como mencionaba antes, si la idea de negocio va a tener la cuota de público necesaria, si ese público va a estar dispuesto a pagar por el producto/servicio ofrecido, si resolverá un problema real del público, si aportará algo diferencial frente a soluciones similares…
Pero, en la mayoría de ocasiones, ponemos esfuerzo en buscar los datos que validan la hipótesis mientras que obviamos los que la NIEGAN, sesgando el resultado y nuestro criterio.

Eso sí. Siempre podremos echarnos la culpa los unos a los otros: culpa del proveedor que nos ha montado el proyecto por modelar mal nuestra idea, culpa al UX por no saber lo suficiente sobre el comportamiento universal y repetitivo 😀 de los usuarios, culpa al cliente que no escucha y deja que le montemos algo que será éxito seguro :)), culpa a…

Y en esas seguimos (clientes, proveedores y usuarios), creyendo que alguno así conseguirá ganar este juego de sogatira. Y no es verdad. Lo cierto es que perdemos todos. Porque esto es un problema para el negocio. Para cualquier negocio. El del que provee y el del que paga.

Por cierto que este comportamiento tan “maduro” acrecienta los problemas, actuando nuevamente como sesgo de confirmación y provocando que la siguiente vez, por asociar el problema a un factor ajeno a nosotros mismos, nos comportemos exactamente igual que como en el pasado. El sesgo pasa a convertirse en una profecía autocumplida.
Vaya. Una fiesta.

Posibles soluciones

Me encantaría tener la receta para que estas situaciones no llegaran a darse 🙁 , pero mientras experimentamos para descubrirla, ahí van algunos ingredientes que considero necesarios:

¿Se te ocurre alguna otra acción que pueda combatir el Sesgo de Confirmación en los proyectos digitales?

Este post es parte de una serie futura de artículos sobre cómo fracasar con proyectos digitales y la búsqueda de soluciones para contrarrestar esto.