Stakeholder Management: l'arte di dire no

Un buon sviluppo del prodotto richiede l'identificazione e la ricerca della magica sovrapposizione tra desiderabilità, fattibilità e fattibilità, dove vive l'innovazione. I product manager sono costantemente nella posizione di dover difendere l'equilibrio tra questi domini, contrastando le forze che competono per trascinare un prodotto troppo in una direzione a spese delle altre. Ciò significa dire di no, molte volte ea molte persone, nel corso del percorso di sviluppo del prodotto.

All'inizio della mia carriera, ho lavorato a un progetto nel settore automobilistico, sviluppando un'app che utilizzava l'apprendimento automatico informato dai dati ambientali e dal comportamento degli utenti per fornire suggerimenti intelligenti ai conducenti. Quando sono entrato a far parte del team, l'app era pronta per il lancio e il management era ansioso di rilasciarla, ma presto mi sono reso conto che era tutt'altro che pronta per la produzione.

Sebbene l'app fosse visivamente accattivante, alcune delle domande di progettazione più fondamentali sono state ignorate, come "Quale problema stiamo risolvendo e per chi?" e "Quanto sono disperate le persone per risolvere questo problema?"

L'app vantava una funzione che mostrava il tempo a destinazione del conducente. Dalle abitudini degli utenti e dai dati sul traffico, l'algoritmo potrebbe dedurre dove potrebbe essere diretto un conducente e quanto tempo ci vorrebbe per arrivarci, e una semplice integrazione dell'API meteo mostrava le previsioni del tempo per la destinazione al momento dell'arrivo. Sembrava un bel caso d'uso, ma in realtà a nessuno importava. Quando ho condotto la mia ricerca sugli utenti, incluso un sondaggio retribuito sui conducenti europei, la risposta è stata un sonoro "Mah". Questo è probabilmente il peggior feedback che puoi ottenere: significa che il tuo prodotto ha risolto un problema irrilevante e indica che la dimensione della desiderabilità è estremamente bassa. La fattibilità è quindi una causa persa: è impossibile costruire un'attività redditizia con un prodotto che nessuno vuole. Abbiamo dovuto demolire tutto.

Come è potuto succedere? La risposta è complicata, ma si riduce al fatto che una parola critica non è stata pronunciata quando avrebbe dovuto essere: No.

Le competenze e le risorse principali dell'azienda erano i motori di inferenza dell'apprendimento automatico e la progettazione di architetture altamente scalabili. Il responsabile della scienza dei dati era un potente stakeholder che voleva vedere i suoi motori di inferenza messi a frutto in un'applicazione del cliente. La sua influenza, in parte, aveva portato a un prodotto completamente incentrato sulla tecnologia. Lo sviluppo era stato guidato da ciò che era tecnologicamente fattibile invece di ciò che i clienti desideravano.

Sembrava che nessuno avesse detto di no a questo stakeholder e, se ci avessero provato, non sarebbe stato efficace.

Strategia del prodotto significa dire di no

Dire di no è difficile. Alla gente non piace sentire la parola, e spesso si teme che dirlo danneggi le relazioni importanti. In qualità di product manager, le relazioni sono centrali per il nostro ruolo, ma lo è anche garantire che i nostri prodotti abbiano successo e rimangano in equilibrio.

Quindi, come rifiutare la richiesta di qualcuno mantenendo intatta la relazione? Consiglio queste pratiche:

• Preparati per il successo.
• Non dire di no troppo in fretta.
• Riformula la richiesta.
• Favorire un clima di contributo.

Preparati per il successo

All'inizio di un progetto, è essenziale che tutti siano d'accordo su una visione condivisa per il successo del prodotto (“Perché lo stiamo facendo?”) e su una serie di metriche che verranno utilizzate per misurare i progressi (“Come sapremo se lo stiamo facendo bene?”). Se non sei d'accordo sull'aspetto del successo, è solo questione di tempo prima che sorgano conflitti.

È utile utilizzare un framework per documentare gli obiettivi e mapparli su qualcosa di misurabile. Mi piace utilizzare una versione libera del framework HEART di Google, che organizza l'esperienza dell'utente in categorie per Felicità, Coinvolgimento, Adozione, Conservazione e Successo delle attività, quindi articola obiettivi, segnali e metriche per ciascuna di queste categorie. Gli obiettivi riguardano ciò che stai cercando di ottenere, i segnali scompongono ogni obiettivo in azioni dell'utente e le metriche tengono traccia di tali azioni per valutare come stai facendo in un modo quantificabile.

In un recente progetto di app per consumatori, volevo condurre un progetto pilota limitato per determinare se gli utenti trovassero utile il nostro prototipo e volessero continuare a interagire con esso; Mi sono concentrato principalmente sulla categoria Engagement del framework HEART. Ho quindi dovuto identificare segnali e metriche per monitorare i progressi verso tale obiettivo:

• Obiettivo: gli utenti desiderano interagire con l'app e continuare a utilizzarla.
• Segnale: gli utenti aprono frequentemente l'app.
• Metrica: percentuale di utenti che aprono l'app almeno due volte al giorno.

Questo processo di identificazione e allineamento sugli obiettivi può sembrare semplice, ma non è facile. In questo caso, si trattava di chiamate con il cliente e il nostro team di vendita, ricerche indipendenti e workshop con più team. Sulla base delle informazioni che ho raccolto da questa scoperta, sono stato in grado di presentare il framework HEART completato durante l'incontro iniziale con il cliente. Abbiamo esaminato tutti gli elementi e adattato dove necessario.

Garantire che tutte le parti interessate siano coinvolte nel processo di definizione degli obiettivi è fondamentale e convincere tutti a concordare su quali segnali e metriche devono essere monitorati elimina la necessità di dire di no ripetutamente man mano che un progetto avanza. Ti fornisce anche dati a cui puntare se qualcuno si avvicina a te con una richiesta che non rientra nei parametri del piano.

Non dire di no troppo in fretta

Anche quando le parti interessate chiave sono d'accordo sull'aspetto del successo e la strada da percorrere sembra chiara, una cosa è certa: qualcuno, da qualche parte, si avvicinerà a te con una domanda imprevista.

Quando ciò accade, non dire di no troppo in fretta. Anche se sei certo che la richiesta sia irragionevole, rifiutarla interrompe la conversazione e potrebbe danneggiare la relazione. Mina anche il processo di scoperta del prodotto. In qualità di product manager, dobbiamo vedere il quadro completo e ascoltare le persone che non sono d'accordo con noi riduce i nostri punti ciechi.

Puoi ancora dire di no, ovviamente, ma devi evitare risposte istintive. Questi portano a discussioni binarie che sono il risultato di un pensiero in bianco e nero, giusto o sbagliato, vincente o perdente: o implementi qualcosa o non lo fai.

Per passare a discussioni più efficaci e articolate, è necessario organizzare le richieste in base ai criteri concordati che hai stabilito come parte del processo di definizione degli obiettivi.

Invece di chiedere a uno stakeholder "Questa funzione è preziosa per te?" chiedi "Quanto è preziosa per te questa funzione?" La conversazione risultante dovrebbe darti le informazioni necessarie per collaborare a un elenco di "desideri", ordinato in termini di importanza. È essenziale che questa classifica vada da 1 a n, senza consentire a più elementi di condividere lo stesso posto nella gerarchia. Questo dà a tutti voce nel processo di definizione delle priorità e ti esonera dal dover rifiutare le richieste unilateralmente. Alcune richieste cadranno nel dimenticatoio quando il gruppo le declasserà a favore di quelle più importanti.

Riformula la richiesta

Una richiesta che inizialmente sembra irragionevole può produrre risultati positivi con qualche sottile riprogettazione. Per prima cosa, ascolta ciò che viene detto. Ascolta davvero. Metti da parte le tue supposizioni e cerca di capire da dove viene l'altra persona, quindi trova un terreno comune. Se scavi un po' più a fondo chiedendo "Perché", non necessariamente le cinque volte di cui hai sentito parlare; da due a tre generalmente sono sufficienti: potresti portare alla luce un fattore che parla di un obiettivo condiviso.

Anche una richiesta perfettamente sensata può beneficiare di un'immersione più profonda e di un po' di riformulazione. Ricordo una situazione in cui stavo lavorando a uno strumento di business intelligence per un servizio di mobilità B2B. Il mio cliente mi ha chiesto, non inaspettatamente, di aumentare il numero degli iscritti. Sebbene la motivazione per aumentare il numero di abbonati paganti possa sembrare ovvia, volevo assicurarmi di avere il quadro completo, quindi ho chiesto: "Perché?"

Si è scoperto che il prodotto in questione si stava avvicinando alla fine del suo ciclo di vita e il mio cliente voleva spremere le ultime gocce di profitto prima di sostituirlo con un nuovo prodotto. Con queste informazioni, ho riformulato la richiesta in "Come potremmo aumentare considerevolmente le entrate a breve termine gettando le basi per il prossimo lancio del prodotto?"

In definitiva, la soluzione migliore è stata quella di non preoccuparsi affatto dei numeri degli abbonati, ma di allineare meglio i prezzi con il valore. I clienti pagavano un abbonamento mensile fisso, indipendentemente dalla frequenza con cui utilizzavano lo strumento per le transazioni dei motociclisti. Più transazioni dei motociclisti hanno elaborato, tuttavia, maggiore è il valore che hanno ricavato dallo strumento. I clienti andavano da singoli tassisti che effettuavano solo una manciata di transazioni mensili a vettori di merci multinazionali, con dozzine di filiali e migliaia di veicoli, che effettuavano centinaia di migliaia di transazioni mensili. Lo stesso abbonamento mensile fisso era troppo alto per i piccoli clienti e troppo basso per i grandi.

Apportando piccoli aggiustamenti ai prezzi, abbiamo aumentato le entrate mentre ci avviavamo verso una struttura dei prezzi a più livelli (basata sul numero di transazioni) per il prodotto di prossima uscita. Il nuovo modello ha ridotto il prezzo per la maggior parte dei clienti aumentandolo per i clienti più grandi, che ne avevano beneficiato in modo sproporzionato.

Riformulando le richieste in questo modo, puoi creare situazioni vantaggiose per tutti. La persona che presenta la richiesta si sente ascoltata e rispettata e tu acquisisci informazioni che possono aggiungere valore senza far deragliare il processo di sviluppo del prodotto.

Incoraggiare un clima di contributo

Uno dei maggiori rischi del dire di no è che i rifiuti possono minare lo spirito di apertura e collaborazione che stai cercando di promuovere, sia all'interno che all'esterno del tuo team. Le idee ispirano, indipendentemente dal fatto che diventino rilevanti o meno, e l'ultima cosa che vuoi fare è arginare il flusso di creatività e comunicazione.

Una volta ho lavorato con un ingegnere QA junior che aveva un sacco di idee. In quasi ogni riunione ha posto più domande e offerto suggerimenti volontari. Le sue soluzioni spesso non erano attuabili e alcune di esse avrebbero potuto essere liquidate come inutili o irrilevanti. Ma il suo impegno e il suo entusiasmo sono stati inestimabili. Era totalmente impegnato nella fornitura del miglior prodotto possibile e i suoi contributi hanno stimolato e ispirato gli altri. Un atteggiamento del genere è contagioso.

Vuoi creare un ambiente in cui le persone si sentano incoraggiate a condividere pensieri e idee e siano ricompensate per farlo. La tua squadra dovrebbe essere motivata dalla possibilità di migliorare le cose invece di essere scoraggiata dal pensiero di essere respinta, ignorata o ridicolizzata. L'implementazione di alcune semplici pratiche può aiutare a garantire la sicurezza psicologica della tua squadra.

Riconoscere idee e richieste pubblicamente. Questo crea fiducia e dimostra che apprezzi i suggerimenti e ti impegni a prenderli in considerazione. Imposta una casella di richiesta, una pagina Confluence o un altro forum pubblico a cui tutte le parti interessate possono accedere. Quando arriva una richiesta, registrala e invia un messaggio al richiedente, ringraziandolo per il contributo.

So che questo potrebbe rivelarsi controverso, ma a volte arrivo al punto di aprire il product backlog a tutti. Ciò può essere particolarmente utile per promuovere il coinvolgimento del team di prodotto, oltre a consentire ai membri del team come tester e designer di QA di annotare le cose che hanno riscontrato. Le regole sono semplici: chiunque può aggiungere alla fine del backlog e durante i perfezionamenti (o altri incontri settimanali) i membri del team condividono ciò che hanno aggiunto e spiegano perché. Solo il product manager può modificare l'ordine dei problemi o eliminare gli articoli. Molte persone presumono che garantire a tutti questo livello di accesso porterà al caos e all'anarchia, ma non è così. L'ho provato in organizzazioni di diverse dimensioni e fallisce solo quando le persone sono troppo timide per contribuire con le loro idee.

Dopo aver implementato una soluzione o rilasciato una funzionalità anche approssimativamente correlata a una di queste richieste registrate, accredita pubblicamente il richiedente. Ciò è particolarmente importante quando la soluzione non è un chiaro adempimento della richiesta originale ma più una versione riformulata. Mostrare apprezzamento per tutti coloro che sono coinvolti in un successo crea buona volontà, crea cameratismo e incoraggia le persone a continuare a partecipare.

Valutare i pro e i contro di dire di no

Se ti prendi il tempo per ascoltare davvero e capire da dove provengono le parti interessate, raramente devi rifiutare le proposte a titolo definitivo. L'ascolto attivo, la comunicazione trasparente e il rispetto reciproco sono ingredienti chiave nella gestione di richieste che inizialmente possono sembrare problematiche o fuori portata. La maggior parte delle volte, l'arte di dire di no non implica mai in realtà dire "No".

Ci saranno situazioni in cui risulta impossibile trovare un terreno comune ed è necessario un no diretto per tutelare il prodotto e il progetto. In altri casi, potresti essere costretto a portare a termine cose con cui non sei d'accordo. Per quanto il tuo lavoro sia quello di proteggere l'equilibrio tra desiderabilità, fattibilità e fattibilità, c'è una quarta dimensione da considerare: il pragmatismo. Per far andare avanti le cose, il compromesso è la chiave e, a volte, ciò significa evitare del tutto un no.

Il bello dello sviluppo del prodotto Agile è che la sua natura iterativa offre molte opportunità per correggere la rotta. Dopotutto, l'obiettivo è costruire-misurare-imparare, non discutere-disputare-deragliare.