Ideia principal

No B2B, quem usa o software e quem compra o software raramente são a mesma pessoa. Quem compra paga, decide entre projetos concorrentes, leva este aqui à sua hierarquia, assume o risco se der errado e se pergunta se a implantação vai se sustentar. Os critérios dele, portanto, não são os do usuário: ele avalia uma decisão, não uma ferramenta.

Daí saem três situações, e elas aparecem com frequência. Um produto querido no campo que não vende. Um produto que resolve um problema real e é barrado na hora da compra. Um produto bom, mas incompatível com o jeito como a organização decide — procedimento, alçadas de aprovação, exigências de reversibilidade, capacidade da equipe interna de sustentar a implantação.

Ter sucesso com o usuário e ter sucesso com o cliente são, então, duas provas distintas, e passar na primeira não dispensa a segunda.

Por que isso importa

Isso separa dois diagnósticos que costumamos confundir quando uma venda fracassa. Um produto que não vende apesar de usuários satisfeitos não tem um problema de valor de uso; tem um problema de valor para quem compra, e melhorar a experiência do usuário não corrige isso.

Também diz o que é preciso descobrir além dos usos: o que motiva e o que trava a compra, para quem quem compra precisa se justificar, e o que a organização dele exige antes de assinar.

Nuances e limites

A separação nem sempre é nítida: numa estrutura pequena, o usuário e o comprador podem ser a mesma pessoa, e o raciocínio se reduz a um único conjunto de critérios.

E a adoção pelos usuários pesa na decisão de compra — ela é um argumento para quem compra, não uma garantia.

Questões em aberto

• Em que momento de uma descoberta de produto é preciso ir falar com quem compra, já que o acesso ao campo é mais fácil e mais rico?