Partnership vuol dire avere gli stessi obiettivi (anche a costo di perdere il cliente)

La consulenza spesso lascia danni, e raramente per incompetenza. Li lascia perché chi la eroga ha obiettivi diversi da quelli del prodotto: rinnovare il contratto, vendere altre giornate, non scontentare nessuno. In anni passati dentro e fuori la consulenza ho imparato che il requisito fondamentale di una partnership è uno solo: avere gli stessi obiettivi di chi ti ingaggia. Anche quando questo significa rischiare il cliente.

I danni che ho visto

Un’azienda aveva affidato a una società di consulenza l’implementazione di un design UX/UI completo: almeno due anni di lavoro per un’applicazione che introduceva concetti nuovi, in parte rivoluzionari, in un mercato stabile e consolidato. La società ha ricevuto il design dal founder e non si è fatta domande. Nessuna verifica che le ipotesi e le innovazioni avessero davvero efficacia sul mercato, nessuna validazione con gli utenti: si è limitata a implementare quello che le era stato consegnato. Il risultato è stata un’applicazione che non risolveva i bisogni degli utenti ed era così inutilmente complessa da risultare inutilizzabile.

Altri danni sono più rapidi da raccontare. Per rispettare una deadline impossibile ho visto rilasciare stub al posto delle funzionalità: il bottone c’era, la form si apriva e mostrava un errore, il lavoro risultava consegnato, e l’implementazione vera rientrava dopo ribattezzata maintenance e bugfix, fatturata di nuovo. E ho visto società vendere alle startup marketing aggressivo insieme a uno sviluppo su framework custom scritto in fretta, senza test e senza architettura: velocissime all’inizio, immantenibili dopo un anno, con il rallentamento spiegato come naturale aumento di complessità. Il loro modello di business prevede di uscire entro diciotto mesi, prima che il conto arrivi.

Nessuno di questi comportamenti nasce dall’incompetenza. Chi implementava il design eseguiva il contratto, chi rilasciava stub rispondeva alla deadline, chi vendeva il framework rispondeva ai propri margini. Il problema è la direzione in cui puntano gli incentivi: quando gli obiettivi di chi lavora divergono da quelli del prodotto, il danno è garantito anche con le migliori competenze.

L’ordine di onestà

In una partnership il valore va portato al cliente finale e al committente, in quest’ordine. Chi mi ingaggia paga, ma il suo successo dipende dal valore che arriva a chi usa il prodotto: se manca valore per l’utente finale, non ce ne sarà neanche per il committente.

Le due cose non sempre coincidono, e quando entrano in tensione serve un metodo, non uno schieramento. Il mio approccio è empirico: evito lo scontro posizionale tra due persone in contrasto e propongo esperimenti imparziali, per raccogliere dati e verificare le tesi. E sposto il contendere dalle persone alle idee: non più il founder contro il team, ma un’ipotesi contro l’altra, con i dati ad arbitrare. Non faccio da arbitro o da giudice: la decisione spetta al committente. Il mio lavoro è portare gli strumenti e gli elementi per decidere con consapevolezza, non per fiducia.

Come si riconosce una partnership vera

Non dal contratto: dai comportamenti. Gli incentivi che puntano nella stessa direzione si vedono da pochi segnali concreti. Il successo è misurato sui tuoi obiettivi, non sulle giornate vendute o le feature rilasciate. La presenza di chi affianca il team è destinata a ridursi man mano che il team cresce, fino all’uscita, e chi lavora con te sa dirti di no quando serve, anche quando il sì sarebbe più facile e redditizio.

Il contratto può scrivere queste cose, e nel mio caso prova a scriverle. Ma è il comportamento quotidiano che le rende vere.

La partnership a tre

L’ingaggio arriva dal founder o dai C-level, che comprano un risultato strategico. Il lavoro quotidiano lo faccio dentro il team di prodotto, che vive a livello tattico. Gli obiettivi strategici non arrivano da soli fino al codice: vanno tradotti in obiettivi tattici che il team può raggiungere. Buona parte del mio lavoro sta in questa traduzione e nel tenere i due livelli collegati.

Quando founder e team entrano in conflitto, la radice è quasi sempre la stessa: disallineamento e mancanza di fiducia. La soluzione non è stare in mezzo al campo di battaglia a fare da arbitro tra due fronti contrapposti. La soluzione è facilitare l’allineamento: workshop in cui founder e team costruiscono insieme la visione e il modo di trasformare gli obiettivi in funzionalità di successo. L’allineamento costruito insieme è solido e tutti lo difendono; quello imposto, o mediato da un terzo che sta in mezzo, no.

Il prezzo della verità

La storia del design implementato senza domande ha un seguito. Quando sono arrivato, l’azienda aveva appena fondato un team di prodotto interno, piccolo: un designer, due sviluppatori e un product owner. Ricostruendo quello che era successo nei due anni precedenti, sono andato a parlare con founder e CEO. Quel modo di lavorare era sbagliato e non aveva portato risultati: zero feedback dal campo e un’applicazione uscita dalle intuizioni del founder senza validazione alcuna, incapace di risolvere i problemi reali degli utenti.

In quel periodo stavano nascendo i primi attriti tra il team di prodotto e la coppia founder-CEO, e l’incontro è stato teso, complicato sul piano umano e su quello professionale. Dovevo smontare un modo di lavorare durato oltre due anni mantenendo intatte le intuizioni non convenzionali del founder. Le ho tenute fuori dal bersaglio di proposito: erano ancora da validare sul campo e non potevano essere date per perdenti. Il problema era il metodo, non le idee.

La verità è emersa e il prezzo l’ho pagato subito: il founder, in un primo momento, mi ha allontanato. Ma il seme del dubbio era stato piantato. Qualche settimana dopo sono stato richiamato per aiutarli a definire una strategia efficace e a basso costo per validare quelle intuizioni e, con i feedback alla mano, capire come trasformarle in software partendo da quello che già avevano. Questa volta dentro il percorso c’era anche il team di prodotto.

Far emergere verità scomode fa parte del lavoro, anche a costo di perdere il cliente. Non è un rischio teorico: mi è capitato di essere scaricato e di non essere richiamato. Chi ti allontana per una verità compra conferme, non valore. E quando il cliente torna, torna per quel dubbio che le conferme non seminano mai.

Il requisito non è la simpatia, la seniority o il contratto giusto. È avere gli stessi obiettivi. Tutto il resto, workshop e metriche comprese, viene dopo.