Idea principale

Nel B2B, chi usa il software e chi lo compra raramente sono la stessa persona. L'acquirente paga, sceglie tra progetti concorrenti, sostiene questo progetto davanti ai suoi superiori, si assume il rischio se fallisce e si chiede se il deployment reggerà. I suoi criteri non sono quindi quelli dell'utente: valuta una decisione, non uno strumento.

Ne derivano tre situazioni, che si osservano di frequente. Un prodotto apprezzato sul campo che non si vende. Un prodotto che risolve un problema reale e viene bloccato al momento dell'acquisto. Un prodotto buono, ma incompatibile con il modo in cui l'organizzazione decide — procedure, soglie di approvazione, requisiti di reversibilità, capacità del team interno di farsi carico del deployment.

Convincere l'utente e convincere il cliente sono quindi due prove distinte, e superare la prima non esonera dalla seconda.

Perché è importante

Separa due diagnosi che si confondono quando una vendita fallisce. Un prodotto che non si vende nonostante utenti soddisfatti non ha un problema di valore d'uso; ha un problema di valore per l'acquirente, e migliorare l'esperienza utente non lo risolve.

Dice anche che cosa bisogna scoprire oltre agli usi: che cosa motiva e che cosa blocca l'acquisto, davanti a chi l'acquirente deve giustificarsi, e che cosa la sua organizzazione esige prima di firmare.

Sfumature e limiti

La separazione non è sempre netta: in una piccola struttura, utente e acquirente possono essere la stessa persona, e il ragionamento si riduce a un solo insieme di criteri.

E l'adozione da parte degli utenti pesa sulla decisione d'acquisto — è un argomento per l'acquirente, non una garanzia.

Domande aperte

• In quale momento di una discovery di prodotto bisogna andare dall'acquirente, quando l'accesso al campo è più facile e più ricco?