Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Idea principal
En B2B, quien usa el software y quien lo compra rara vez son la misma persona. El comprador paga, decide entre proyectos rivales, defiende este ante su jerarquía, asume el riesgo si fracasa y se pregunta si el despliegue se sostendrá. Sus criterios no son, por tanto, los del usuario: evalúa una decisión, no una herramienta.
De ahí salen tres situaciones, y se constatan a menudo. Un producto apreciado sobre el terreno que no se vende. Un producto que resuelve un problema real y al que se bloquea en el momento de la compra. Un producto bueno, pero incompatible con la manera en que la organización decide — procedimiento, umbrales de validación, exigencias de reversibilidad, capacidad del equipo interno para llevar el despliegue.
Triunfar ante el usuario y triunfar ante el cliente son, por tanto, dos pruebas distintas, y superar la primera no exime de la segunda.
Por qué es importante
Separa dos diagnósticos que se confunden cuando una venta fracasa. Un producto que no se vende pese a tener usuarios satisfechos no tiene un problema de valor de uso; tiene un problema de valor para el comprador, y mejorar la experiencia de usuario no lo corrige.
También dice qué hay que descubrir además de los usos: qué motiva y qué bloquea la compra, ante quién debe justificarse el comprador, y qué exige su organización antes de firmar.
Matices y límites
La separación no siempre es nítida: en una estructura pequeña, el usuario y el comprador pueden ser la misma persona, y el razonamiento se reduce a un solo juego de criterios.
Y la adopción por parte de los usuarios pesa en la decisión de compra — es un argumento para el comprador, no una garantía.
Preguntas abiertas
- ¿En qué momento de un descubrimiento de producto hay que ir a ver al comprador, cuando el acceso al terreno es más fácil y más rico?