La pianificazione vuole prove, non sicurezza

La pianificazione prodotto spesso fallisce con buone maniere. Nessuno dice che la previsione sia certa, però la roadmap si comporta come se lo fosse. Il team sostiene che la domanda enterprise arriverà nel quarto trimestre, che l’attivazione migliorerà dopo il redesign, o che un canale partner coprirà il buco di pipeline. L’ipotesi viene scritta una volta, rivestita di linguaggio sicuro, e poi diventa struttura. Assunzioni, sequenze, date di lancio e promesse iniziano a dipendere da quella frase.

Il problema non è fare previsioni. Un team prodotto deve farle. Il problema è che molte previsioni non hanno un meccanismo di aggiornamento. Nascono in una presentazione di planning e muoiono in un postmortem. In mezzo si discute di velocity, scope e allineamento, mentre l’assunzione originaria sfugge al riesame.

La pianificazione vuole prove pubbliche, non previsioni sicure. La fiducia serve per agire, ma solo se è legata a un rituale che la fa cambiare quando arrivano nuove evidenze.

La fiducia nella previsione non è una prova

Una previsione è una tesi su una condizione futura. Può riguardare la domanda di mercato, il comportamento dei clienti, la capacità commerciale, la fattibilità tecnica, i tempi normativi o l’adozione interna. Una previsione espressa con sicurezza resta comunque una tesi. Se il team tratta la sicurezza come prova, il planning diventa teatro: la roadmap sembra disciplinata, ma la disciplina sta nella forma, non nell’apprendimento.

La domanda utile non è se il team si sente certo. La domanda utile è se la previsione è esposta a informazioni che non provengono dalla stessa stanza. Il Working Paper n. 1532 della Banca d’Italia studia come le imprese formano le aspettative sull’inflazione e mostra che fornire informazioni pubbliche affidabili sull’inflazione corrente ha migliorato l’accuratezza delle previsioni e ridotto l’effetto dell’eccesso di fiducia. La pianificazione prodotto non è una previsione macroeconomica, ma la lezione è trasferibile: le prove esterne non rendono perfette le previsioni, però danno al team un modo per correggere le convinzioni prima che il costo dell’errore cresca. Vedi il Working Paper n. 1532 della Banca d’Italia.

Questa distinzione conta per founder e product leader. Una roadmap è un portafoglio di scommesse condizionali. Se le condizioni cambiano e la roadmap no, il piano smette di essere un piano. Diventa il ricordo di una riunione.

Per questo una previsione dovrebbe stare vicino alla logica di ledger descritta in Le roadmap hanno bisogno di bet ledger. Un bet ledger tiene traccia di ciò che il team credeva quando ha preso un impegno. Un rituale di aggiornamento delle previsioni interviene ancora prima e chiede: che cosa ci farebbe credere meno, credere di più, o cambiare decisione prima che l’impegno si irrigidisca?

Che cosa deve stare nel rituale di aggiornamento?

Il rituale non deve essere pesante. Anzi, se richiede un offsite strategico, non sopravvive. La versione utile è un piccolo registro collegato a ogni assunzione materiale della roadmap.

Si parte dall’ipotesi. Va scritta come una frase che può essere falsa. Non “i clienti vogliono report migliori”, ma “almeno cinque dei nostri venti account principali si impegneranno a usare il nuovo workflow di reporting prima del ciclo di rinnovo”. Non “il self-service crescerà”, ma “i nuovi team raggiungeranno il primo valore senza assistenza sales in meno di un giorno lavorativo”. Un’ipotesi vaga protegge il piano. Un’ipotesi concreta protegge l’azienda.

Poi si registra la fiducia attuale. Basta una scala semplice, come bassa, media, alta, più una frase che spiega il motivo. La frase conta più dell’etichetta. Costringe l’owner a mostrare se la fiducia nasce da evidenze clienti, intuizione interna, pressione esecutiva, movimento dei competitor o assunzioni in un foglio di calcolo.

Il passo successivo è aggiungere prove esterne. Non significa avviare un grande progetto di ricerca. Possono essere note win-loss recenti, ticket di supporto, utilizzo osservato del prodotto, dati sul ciclo di vendita, comportamento pubblico del mercato, documenti normativi, feedback di procurement o interviste svolte dopo il piano originale. Conta che la prova abbia una fonte e una data. “Lo chiedono tutti” non è una prova. “Sette call di espansione negli ultimi trenta giorni hanno citato lo stesso workflow bloccato” è già diverso.

Poi servono trigger di aggiornamento. Un trigger è una condizione che obbliga al riesame. Per esempio: meno di tre design partner qualificati entro il 15 settembre, attivazione sotto la soglia concordata dopo due coorti, un competitor che rilascia un workflow simile nello stesso segmento, review legale oltre una data specifica, o effort di integrazione superiore alla stima di una quantità definita. Il trigger trasforma l’incertezza in calendario e regola decisionale.

Infine si nominano owner e prossima data di revisione. L’ownership conta perché le previsioni sono sociali. Se nessuno possiede l’aggiornamento, tutti possiedono l’ottimismo originario. L’owner non deve far avverare la previsione. Deve riportare le prove dentro la decisione.

Che cosa deve far cambiare la fiducia?

Il rituale funziona solo se la fiducia può muoversi. Molti team raccolgono evidenze ma le usano come decorazione. Aggiungono citazioni cliente a una presentazione, aggiornano una dashboard, e poi proteggono comunque la vecchia roadmap perché cambiare direzione sembra costoso.

Una regola migliore è definire prima che cosa fa salire o scendere la fiducia. Un cliente enterprise che chiede una feature può non bastare. Cinque clienti dello stesso segmento che descrivono lo stesso workflow bloccato possono alzarla. Una richiesta fatta da un grande prospect durante il procurement può non essere sufficiente. Una partnership di design firmata, con accesso reale all’implementazione, può esserlo. Una demo promettente del prototipo può non ridurre il rischio tecnico. Un fallimento misurato in un ambiente realistico dovrebbe ridurlo.

Qui l’aggiornamento delle previsioni incontra i criteri di stop. In Le scommesse prodotto servono criteri di stop, il punto non è diventare pessimisti. È decidere in anticipo quali prove impediscono a una scommessa di consumare altro tempo. La stessa logica vale prima che la scommessa sia finanziata del tutto. Se un elemento di roadmap richiede tre assunzioni vere, ogni assunzione dovrebbe avere un livello di fiducia e un trigger.

Il trigger non cancella automaticamente il lavoro. Apre una decisione. La decisione può essere continuare, ridurre lo scope, cambiare segmento, rimandare, aggiungere discovery, sostituire la scommessa o diminuire l’investimento. Il valore non sta nel rendere corretta ogni previsione. Sta nello smettere di fingere che la previsione originale sia ancora fresca.

Dove le prove pubbliche battono la certezza interna

La certezza interna ha un ruolo. I founder spesso vedono segnali deboli prima che il mercato li sappia nominare. I product leader collegano frammenti che nessuna dashboard riesce a riassumere. Ma la certezza interna diventa pericolosa quando non può essere confrontata con informazioni pubbliche o esterne.

Le prove pubbliche hanno tre vantaggi. Primo, sono più difficili da riscrivere dopo. Un report datato, una call cliente, un benchmark, un documento di mercato o una coorte di utilizzo creano una traccia. Secondo, abbassano il costo di status del cambiare idea. La conversazione diventa “l’evidenza è cambiata”, non “il leader aveva torto”. Terzo, rendono produttivo il dissenso. Invece di discutere su chi abbia l’istinto migliore, il team discute quali prove debbano muovere il piano.

Per le decisioni di roadmap, pubblico non significa sempre disponibile su internet. Significa visibile oltre la convinzione privata del gruppo di planning. Una trascrizione cliente, una nota di procurement, una coorte d’uso o un trend di supporto possono essere pubblici dentro l’azienda se sono archiviati, datati e disponibili per la revisione.

Questo è essenziale quando il piano attraversa più funzioni. Sales può credere che la domanda sia urgente. Engineering può credere che la complessità sia sottostimata. Customer success può vedere un rischio di adozione più alto di quanto la roadmap ammetta. Finance può considerare fragile l’ipotesi sui tempi. Un registro di aggiornamento dà a queste funzioni un oggetto condiviso, invece di una discussione da corridoio.

Fai audit di una assunzione questa settimana

Non serve ridisegnare tutto il sistema di planning. Scegli una assunzione di roadmap che farebbe male se fosse sbagliata. Deve essere qualcosa che influenza assunzioni, sequenze, ricavi, impegni di lancio o focus strategico.

Scrivi l’ipotesi in una frase. Aggiungi la fiducia attuale e il motivo. Aggiungi almeno un campo di prova esterna con fonte e data. Definisci un trigger che obbliga al riesame. Nomina l’owner. Metti la data di revisione in calendario.

Il risultato dovrebbe essere un po’ scomodo. È un buon segnale. Vuol dire che l’assunzione è uscita dalla protezione del linguaggio sicuro ed è entrata nella disciplina dell’evidenza.

La pianificazione continuerà a richiedere giudizio. Le previsioni continueranno a sbagliare. I team dovranno ancora agire prima che arrivi la certezza. L’obiettivo non è eliminare l’incertezza dalla leadership prodotto. L’obiettivo è impedire che l’incertezza venga nascosta sotto previsioni sicure.

Una roadmap che si aggiorna con le prove non è più debole di una roadmap immobile. È più onesta sulle condizioni in cui l’azienda sceglie di muoversi.