La Vision non dovrebbe restare nelle slide

È lunedì mattina, sprint planning, dal board arriva la richiesta di un cliente importante: un modulo di export personalizzato, da consegnare entro fine trimestre perché il rinnovo del contratto dipende da quello.

Il product manager chiede se è coerente con la direzione del prodotto, il designer fa notare che complicherebbe una sezione appena semplificata, lo sviluppatore stima sei settimane.

Nessuno riesce a dire con certezza se la richiesta sia dentro o fuori dalla strategia, e la decisione finisce per prenderla chi ha più urgenza.

Eppure quell’azienda una vision ce l’ha, è scritta nella presentazione del piano triennale, è stata raccontata all’ultimo evento di team building e compare persino nella pagina “chi siamo” del sito.

Il problema è che non arriva mai nel prodotto e nella sua UX.

C’è un modo semplice per capire se succede anche nella tua azienda, facendo questo esercizio:

prova a chiedere a cinque colleghi di funzioni diverse quali siano le priorità del prodotto per i prossimi dodici mesi (senza appunti davanti), per poi confrontare le risposte con la UX del prodotto.

La tesi di questo articolo è che la vision si perda per assenza di metodo e processo, soprattutto quando l’azienda cresce ed il prodotto scala.

Manca un passaggio che la trasformi in pochi criteri di decisione condivisi, abbastanza concreti da essere applicati a una singola richiesta in uno sprint planning qualunque.

Senza questo, il prodotto finisce per diventare la somma delle pressioni che ha subito e delle decisioni prese senza strategia.

Prima di vedere come si costruisce quel passaggio, conviene capire dove la vision si perde.

Perché la vision si perde

Il 95% dei dipendenti non conosce o non capisce la strategia della propria azienda.

Il dato viene da Robert Kaplan e David Norton, che lo hanno riportato su Harvard Business Review.

Questo studio nasce dall’esperienza di consulenza degli stessi autori, che proponevano la Balanced Scorecard come soluzione al problema descritto.

Un quadro più solido arriva da una ricerca pubblicata nel 2015 sempre su Harvard Business Review da Donald Sull, Rebecca Homkes e Charles Sull.

Il gruppo ha interpellato circa 7.600 manager in 262 aziende, scegliendo non dipendenti qualsiasi ma le persone che le stesse aziende indicavano come responsabili dell’esecuzione della strategia.

Solo il 55% dei manager intermedi è riuscito a nominarne almeno una tra le cinque indicate dal vertice.

Il problema della Vision

Perché una vision, anche ben scritta, non aiuta a prendere decisioni?

Richard Rumelt, in Good Strategy Bad Strategy, offre la risposta più decisa: le aziende chiamano strategie quelle che, in realtà, sono aspirazioni.

Una strategia vera è fatta di tre elementi: una analisi della sfida, una linea guida che indica come affrontarla e un insieme di azioni coerenti con quella direzione.

Una vision come “diventare la piattaforma di riferimento per la logistica europea” non esclude nulla.

Qualunque richiesta, dal modulo di esportazione personalizzato all’integrazione con il gestionale di un singolo cliente, può essere giustificata come un passo in quella direzione.

È per questo che, in assenza di criteri, il backlog si riempie a vista d’occhio assecondando qualsiasi richiesta.

Così le aziende smettono di misurare se il prodotto cambia davvero il comportamento degli utenti e iniziano a misurare quante funzioni rilasciano.

Quando il founder non basta più

In un’azienda di dieci persone la vision non ha bisogno di troppi strumenti.

Il founder siede accanto a chi progetta e sviluppa, analizza i prototipi, si siede al tavolo con i clienti, e la direzione si trasmette per osmosi. La vision funziona così bene che nessuno si rende conto che andrebbe formalizzata.

Il problema emerge quando l’azienda cresce.

Superata la ventina di persone, il fondatore non può più essere presente in ogni decisione, ma spesso continua a esserne il riferimento implicito.

I team decidono da soli cercando di indovinare cosa penserebbe il founder, e ciascuno “indovina” in modo diverso.

In Italia, molte aziende software di medie dimensioni sono nate come fornitori su commessa, con un fondatore che gestisce in prima persona i clienti storici e accetta modifiche al prodotto dentro trattative private.

In queste organizzazioni la vision non manca affatto, ma vive nelle relazioni del fondatore.

La soluzione è rendere esplicito il modo in cui decide.

Come riportare la vision nel prodotto

Dalla vision ai criteri

Se la vision serve a indicare la direzione, servono strumenti intermedi che la rendano applicabile a decisioni piccole e quotidiane.

Principi di prodotto

Il più diretto sono i principi di prodotto.

“Il prodotto deve essere semplice” non è un principio; “opinionated by default, flexible under the hood”, uno dei principi con cui Intercom guida lo sviluppo del proprio prodotto, sì.

Significa che il software propone un modo preciso di lavorare e nasconde la personalizzazione sotto la superficie, e significa anche dire di no a molte richieste di configurazione avanzate dai clienti.

Mission command

Il secondo strumento arriva dalla dottrina militare. Invece di dettagliare ogni richiesta, il comando comunica lo scopo dell’operazione, i confini e lo stato finale desiderato, lasciando a chi è sul campo la libertà di adattarsi agli imprevisti.

Nel software B2B il corrispettivo è un obiettivo di prodotto formulato come risultato da ottenere, non come funzione da consegnare: ridurre il tempo che un operatore impiega a chiudere una pratica, non “rilasciare il nuovo modulo pratiche entro marzo”.

Architectural Decision Records

Il terzo è il registro delle decisioni, nato in ambito architetturale con gli Architectural Decision Records, e sempre più usato anche per le scelte di prodotto.

Un breve documento per ogni decisione rilevante, con contesto, scelta, alternative scartate e conseguenze accettate, impedisce che la stessa discussione si riapra ogni volta che cambia una persona o arriva un nuovo cliente importante.

Altri strumenti utili sono riportati nella tabella qui sotto

Strumento	Cosa traduce della vision	Errore tipico
Principi di prodotto e di design	Quale valore prevale quando due esigenze sono in conflitto	Principi generici che nessuno contesterebbe e quindi non escludono nulla
Obiettivi espressi come risultati (OKR applicati al prodotto)	Il cambiamento di comportamento che il prodotto deve produrre	Key result trasformati in elenchi di funzioni da consegnare
North Star metric	Il valore centrale che il prodotto genera per l’utente	Metriche di vanità o puramente finanziarie, che non orientano le scelte di design
Mission command	Scopo, confini e stato finale desiderato di un’iniziativa	Requisiti dettagliati calati dall’alto che tolgono contesto ai team
Registro delle decisioni	Perché una scelta è stata fatta e cosa è stato scartato	Documenti scritti a posteriori, solo per giustificare decisioni già prese

Allinearsi guardando gli utenti, non le slide

Se il disallineamento nasce tra le funzioni, non si risolve con un’altra presentazione della vision.

Le presentazioni trasmettono informazioni, ma non cambiano il modo in cui commerciale, prodotto, design e sviluppo valutano una richiesta, perché ciascuno continua a leggerla attraverso le proprie priorità.

Quello che sposta davvero le persone è vedere lo stesso problema, nello stesso momento, con gli stessi occhi.

È qui che il design e la ricerca smettono di essere attività di esecuzione e diventano strumenti di allineamento.

Un workshop ben costruito può partire da un esercizio semplice, raccomandato anche da Nielsen Norman Group: prima di mostrare i risultati della ricerca, si chiede a ogni funzione di scrivere cosa pensa che gli utenti vogliano.

Il confronto tra queste ipotesi e i comportamenti osservati rende evidenti, senza bisogno di discussioni, le differenze di prospettiva tra i reparti e i punti in cui ciascuno si sbagliava.

Il test dei cinque colleghi, fatto bene

Torniamo all’esercizio dell’introduzione

1. Scegliere cinque persone di funzioni diverse. Una figura della direzione, una del commerciale, una del prodotto, una del design e una dello sviluppo. Non serve che siano le più senior, ma devono prendere o influenzare decisioni sul prodotto.
2. Fare a ciascuna tre domande, separatamente e senza documenti davanti. Quali sono le tre priorità del prodotto per i prossimi dodici mesi? Che cosa abbiamo deciso di non fare, o di non fare adesso? Come capiremo se la funzione su cui stiamo lavorando in questo momento ha funzionato?
3. Mettere le risposte una accanto all’altra. La prima domanda misura quanto la direzione è condivisa, la seconda se la strategia contiene delle rinunce, la terza se il lavoro quotidiano è collegato a un risultato. Di solito la seconda è quella in cui le risposte divergono di più, o in cui nessuno sa cosa rispondere.
4. Confrontare le risposte con il lavoro rilasciato negli ultimi sei mesi. Quante delle funzioni consegnate rispondono alle priorità su cui tutti e cinque concordano, e quante sono nate da richieste di singoli clienti o da urgenze del momento? È la verifica che trasforma un’impressione in un dato.

Se le risposte coincidono e il lavoro rilasciato le rispecchia, la vision sta facendo il suo mestiere.

Se invece divergono, la tentazione sarà di riscriverla o di presentarla di nuovo con più enfasi, ed è la reazione sbagliata: usa questo articoli come guida, condividilo con un collega.

---

eyestudios è uno studio di Experience Design che lavora dove la complessità è reale: prodotti digitali articolati, organizzazioni con molti stakeholder, ecosistemi in trasformazione. Non ci fermiamo alla superficie: portiamo strategia, ricerca e metodo nei progetti che richiedono più di un buon wireframe.

Abbiamo lavorato con Unox, Aiko, Shampora, Deliveristo, Restworld, Ulixe Group, Confindustria, Flying Tiger, The North Face, Reply, Gruppo Hera, Alkemy, Mondo Convenienza, Verisure, Unipol, Almaviva, We Are Marketers, PhotoSì, ESA, Reale Mutua.