Un product operating model parte dai diritti decisionali

Un product operating model non parte da una nuova cerimonia. Parte da una frase che molti team evitano: chi può prendere quale decisione di prodotto?

Molte aziende hanno già i segnali visibili del lavoro prodotto moderno. Hanno standup, planning, interviste con i clienti, dashboard, review di roadmap, critique di design e magari un offsite trimestrale sulla strategia. Da fuori il sistema sembra maturo. Dentro, però, le decisioni continuano a rimbalzare tra founder, product manager, designer, engineering lead, sales, customer success e finance.

Il problema è lì. I rituali creano movimento, ma non creano automaticamente ownership. Un product operating model diventa utile quando chiarisce i diritti decisionali: chi decide, chi porta evidenza, chi approva il rischio e chi possiede il follow-through.

Marty Cagan e SVPG descrivono il product operating model come il modo in cui un’azienda decide cosa costruire e come costruirlo, non solo come un insieme di ruoli o cerimonie. Questa distinzione conta perché un team può copiare i rituali delle organizzazioni prodotto più mature e continuare a tenere ogni decisione importante centralizzata, lenta o negoziata politicamente. Il modello operativo diventa reale solo quando le decisioni diventano esplicite. SVPG introduce questo concetto nel suo articolo sul product operating model.

I rituali non sono un operating model

Un rituale risponde alla domanda quando ci incontriamo. Un diritto decisionale risponde alla domanda quale autorità esiste dopo l’incontro.

Sembra una differenza ovvia, finché non si osserva come si muove davvero il lavoro prodotto. Un product manager fa discovery, ma non può fermare una feature già promessa dal team sales. Una designer vede un rischio di usabilità, ma nessuno sa se quel rischio può bloccare il rilascio. Un engineering lead segnala debito tecnico futuro, ma la roadmap è già stata comunicata. Un founder chiede più autonomia ai team, poi approva personalmente ogni modifica a pricing, onboarding e packaging.

Niente di tutto questo si risolve aggiungendo riunioni. Spesso, anzi, più riunioni nascondono il problema. Quando mancano diritti decisionali chiari, ogni rituale diventa il luogo in cui si rimette in scena la stessa domanda irrisolta. Chi decide se questo segmento cliente conta davvero? Chi decide se l’evidenza è sufficiente? Chi decide se il rischio è accettabile? Chi decide cosa togliere quando entra qualcosa di urgente?

Per questo considero i diritti decisionali il primo artefatto di un product operating model utile. Non l’organigramma. Non il template della roadmap. Non la cadenza della discovery. Tutte queste cose contano, ma dovrebbero appoggiarsi a un sistema decisionale più chiaro.

Se il tuo team ha già rituali ma continua a sentirsi bloccato, probabilmente il prossimo miglioramento non è un nuovo framework. È una mappa delle decisioni.

Cosa deve contenere una mappa dei diritti decisionali?

Una mappa pratica dei diritti decisionali non deve diventare burocrazia. Può partire da una tabella semplice con quattro colonne: tipo di decisione, owner della decisione, evidenza richiesta e cadenza di revisione.

La prima colonna nomina il tipo di decisione. Alcuni esempi: cliente target, priorità del problema, scelta dell’opportunità, direzione della soluzione, scope del rilascio, esperimento di pricing, impegno go-to-market, accettazione del rischio tecnico e follow-up post lancio.

La seconda colonna nomina l’owner decisionale. È la persona, o il ruolo, che ha l’autorità di prendere la decisione dopo aver raccolto input. Ownership non significa decidere da soli. Significa che il gruppo sa dove atterra la decisione.

La terza colonna definisce l’evidenza richiesta. Una decisione sul cliente target può richiedere interviste, dati comportamentali, concentrazione del fatturato e fit strategico. Una decisione sullo scope di rilascio può richiedere impatto utente, confidenza di delivery, readiness del supporto e opzioni di rollback. Un esperimento di pricing può richiedere ipotesi di segmento, piano di misura, rischio commerciale e piano di comunicazione ai clienti.

La quarta colonna definisce la cadenza di revisione. Alcune decisioni sono durevoli e si rivedono ogni trimestre. Altre sono tattiche e si rivedono ogni settimana. Altre ancora vanno riaperte solo quando compare un trigger, per esempio ticket di supporto oltre una certa soglia, calo dell’activation o blocco su un account strategico.

La tabella è semplice. Il suo valore non sta nel formato, ma nella conversazione che obbliga ad avere. Un founder può scoprire che sta chiedendo outcome ai team senza concedere loro le decisioni che modellano quegli outcome. Una Head of Product può vedere che la discovery produce evidenza, ma quell’evidenza non ha il permesso formale di cambiare le priorità. Un fractional product lead può accorgersi che l’approvazione del rischio non vive da nessuna parte, quindi ogni decisione rischiosa torna alla persona più senior o più rumorosa nella stanza.

Questa non è autonomia. È ambiguità con riunioni.

L’evidenza deve entrare prima che la decisione diventi politica

I diritti decisionali non riducono il valore dell’evidenza. Le danno un posto in cui entrare.

Qui spesso si rompe il lavoro di discovery. I team parlano con i clienti, raccolgono note, taggano insight e condividono readout, ma l’evidenza non cambia il sistema decisionale. La roadmap continua a muoversi secondo pressione interna, preferenze executive o ultima richiesta enterprise.

Per questo servono decision log. In Le interviste discovery servono decision log, il punto centrale è che le interviste non sono preziose perché producono citazioni interessanti. Diventano preziose quando cambiano, confermano o scartano decisioni. Una mappa dei diritti decisionali estende questa logica oltre la discovery. Chiede: per ogni tipo di decisione, quale evidenza serve, chi la porta e dove viene registrata la decisione finale?

Per esempio, se la decisione è investire o meno sull’onboarding, le interviste possono mostrare confusione, analytics può mostrare drop-off, i ticket di supporto possono rivelare frizioni ripetute e sales può spiegare aspettative sbagliate. Ma serve comunque un owner della decisione. Altrimenti ogni funzione mantiene la propria interpretazione e la direzione prodotto resta sospesa.

Lo stesso vale per acquisition e qualità della trial. Se la trial è piena di utenti che non erano mai stati in target, il team può leggere male i dati di activation e dare la colpa al prodotto. In La trial non è rotta: stai portando dentro gli utenti sbagliati, il problema non è solo la qualità del marketing. È ownership decisionale lungo il funnel. Chi decide per quale tipo di utente è fatto il prodotto? Chi decide quando la qualità del traffico diventa un vincolo prodotto? Chi decide se viene prima lavorare sull’activation o filtrare meglio l’acquisizione?

Senza diritti decisionali, queste domande restano opinioni. Con diritti decisionali, diventano lavoro prodotto.

Approvare il rischio non è possedere tutto il prodotto

Un errore frequente è rendere il product owner responsabile di ogni decisione, incluse quelle che richiedono approvazione del rischio business. Sembra empowerment, ma spesso produce escalation nascosta.

Un product lead può possedere la scelta delle opportunità e la direzione della soluzione, mentre un founder o un executive mantiene l’approvazione di alcune soglie di rischio. Per esempio, un team può essere libero di fare esperimenti sull’onboarding, ma avere bisogno di approvazione prima di cambiare il packaging dei piani annuali. Una squad può possedere lo scope del rilascio, ma richiedere approvazione engineering prima di accettare rischio infrastrutturale. Un product manager può decidere di rimuovere una feature poco usata, ma customer success può dover approvare il piano di comunicazione per gli account coinvolti.

Il punto non è diluire l’ownership. Il punto è separare i tipi di decisione.

Una buona mappa distingue almeno quattro ruoli. Il decider prende la decisione. I contributor portano evidenza e vincoli. I risk approver definiscono i limiti per esposizione legale, finanziaria, di brand, sicurezza o operatività. I follow-through owner fanno sì che la decisione diventi reale dopo la riunione.

Quest’ultimo ruolo manca spesso. Il team decide di cambiare onboarding, ma nessuno possiede la strumentazione analytics. Decide di restringere il segmento target, ma nessuno aggiorna i materiali sales. Decide di mettere in pausa una feature, ma nessuno informa il supporto. La riunione crea accordo, poi il sistema perde pezzi.

Il follow-through fa parte dei diritti decisionali perché una decisione senza ownership operativa è solo una preferenza.

Come si parte senza creare burocrazia?

Parti dalle ultime cinque decisioni prodotto che hanno creato attrito.

Non iniziare da un operating model teorico. Scegli casi concreti: un item di roadmap che continuava a tornare, una richiesta cliente che ha bypassato la prioritizzazione, un rilascio uscito con rischio irrisolto, un insight di discovery ignorato o una review metriche che non ha prodotto azioni.

Per ogni caso, fai quattro domande. Chi ha deciso davvero? Chi avrebbe dovuto decidere? Quale evidenza era disponibile prima della decisione? Chi ha posseduto il follow-through dopo la decisione?

I pattern emergono rapidamente. Forse i founder stanno approvando troppe decisioni tattiche. Forse i product manager facilitano discussioni ma non decidono. Forse engineering viene coinvolta per le stime ma non per il giudizio sul rischio. Forse sales può introdurre priorità ma non deve portare evidenza. Forse customer success ha contesto essenziale ma arriva troppo tardi.

Quando i pattern sono visibili, costruisci la prima versione della mappa. Tienila piccola. Cinque o dieci tipi di decisione bastano. Rivedila ogni mese per il primo trimestre. Usa decisioni reali per migliorarla.

Qui un fractional product lead può aiutare molto. Il lavoro non è importare un framework generico. È rendere visibile il sistema implicito di potere, poi ridisegnarlo affinché le persone giuste possano decidere con la giusta evidenza e alla giusta cadenza.

Se il tuo team ha rituali ma le decisioni continuano a rimbalzare tra persone, al tuo operating model non manca una riunione. Mancano diritti decisionali. Mappa quelli per primi, e il resto del sistema prodotto avrà una base solida su cui reggersi.