Stakeholder conflict management

Gestire un conflitto tra stakeholder è una pratica di mediazione con evidenze. Sales vuole accelerare, finance chiede margine, prodotto difende la qualità e operations segnala capacità limitata. Il lavoro analitico tiene insieme questi interessi senza fingere che un solo numero risolva il conflitto. L’analyst efficace chiarisce le definizioni, separa i fatti dalle preferenze e costruisce opzioni che rendono visibili trade-off e conseguenze.

Il problema da risolvere

Il problema non è conoscere il concetto in astratto, ma decidere cosa fare quando i dati sono incompleti, le metriche ambigue e i vincoli rendono fragile la lettura. Una lezione utile separa il segnale dal rumore, indica quale baseline usare e mostra quale azione diventa più difendibile dopo l’analisi.

Nei conflitti sui dati c’è una difficoltà in più: l’analyst non è un osservatore neutrale di un fenomeno tecnico, ma un mediatore tra persone con incentivi diversi. Ignorare questa dimensione organizzativa equivale a un medico che prescrive farmaci senza fare l’anamnesi: rischia di curare il sintomo sbagliato.

Una mappa di lavoro

Davanti a un conflitto conviene seguire una sequenza fissa, così che la mediazione non diventi un rituale. Prima si nomina la decisione: cosa cambia davvero se chiariamo il disaccordo. Poi si cerca il segnale osservabile che riduce l’incertezza. Si fissa la baseline rispetto a cui leggere il risultato. Si dichiara il vincolo che può falsare la lettura. Infine si indica l’azione operativa.

Step	Question to ask	Expected output
Decision	Cosa cambia se capiamo meglio il conflitto?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Cosa può falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Ogni passaggio dovrebbe rendere più chiaro il costo di una decisione sbagliata.

Rendere esplicite le assunzioni

Una formalizzazione rende visibili le assunzioni, così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità. Conviene fissare cinque elementi e il controllo minimo di ciascuno.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che può restare dopo l’analisi	Sensitivity check o revisione qualitativa

La logica è solida quando un altro analista può riprodurla, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati.

The root of data conflicts

I conflitti tra stakeholder sui dati raramente sono tecnici. Quasi sempre nascono da tre divergenze. La prima riguarda le definizioni: “utente attivo” significa login negli ultimi 7 giorni o negli ultimi 30? La seconda è la metodologia: attribuzione last-click, multi-touch o Shapley. La terza, la più profonda, sono gli incentivi: marketing è pagato sugli MQL, sales sui closed deal, quindi i loro KPI ottimali sono diversi per costruzione. Un analyst che entra in un conflitto senza capire questa dimensione organizzativa finisce per curare il sintomo sbagliato.

The RAPID framework for contested decisions

Bain & Company ha sviluppato il framework RAPID per chiarire chi decide cosa.

Role	Meaning	In the data context
Recommend	Proposer	The analyst presenting the data and recommendation
Agree	Approver	Stakeholder with veto power (e.g. CMO on marketing metrics)
Perform	Executor	The team that will implement the decision
Input	Input provider	Domain experts, other teams affected by the decision
Decide	Decision maker	Una persona sola, tipicamente il VP o il C-level

Il punto più importante è che D è una persona sola. Se “decide il team” o “decidiamo insieme”, nessuno decide e il conflitto si cronicizza. Il VP Data deve nominare un D per ogni decisione contesa, anche quando è scomodo.

Conflitti sulle metriche: un playbook in quattro passi

Quando due team presentano numeri diversi per la stessa domanda, il primo passo è concordare un’unica fonte di verità: entrambi devono accettare di usare la stessa tabella o lo stesso modello dbt. Se marketing usa Google Analytics e prodotto usa Amplitude, il conflitto è nei dati grezzi, non nell’interpretazione.

Il secondo passo è una definizione scritta, non detta. Per esempio: “MRR uguale somma dei canoni mensili dei contratti attivi, esclusi i trial, misurato l’ultimo giorno del mese in EUR.” Le definizioni orali sono ambigue per costruzione.

Il terzo passo è la riproducibilità: la query che produce il numero deve essere accessibile a tutti gli stakeholder. Non “fidati, l’ho calcolata io”, ma “ecco la query, eseguila tu stesso”.

Il quarto passo è un’escalation strutturata. Se dopo i primi tre passi il disaccordo persiste, il D decide e la decisione viene documentata, per esempio: “Il VP Data ha deciso di usare la metodologia X per il Q4. Il team Y ha dissentito per il motivo Z. La decisione sarà rivalutata a fine Q4.”

Real case: GitLab’s documented dissent

GitLab ha reso il dissenso strutturato parte della propria cultura aziendale. Quando un team dissente da una decisione basata sui dati, il dissenso viene registrato in un documento “disagree and commit”.

Decision: We will use 30 days as the window for "active user"
Dissent: The Product team believes 7 days is more appropriate for our category
Rationale: Data shows that 73% of users active at 30 days are also active at 7 days
Commit: The Product team will support the 30-day metric and contribute data to reevaluate at Q2

Il documento è pubblico internamente e non è una sconfitta per chi dissente: è un contributo documentato alla qualità della decisione. GitLab ha osservato che le decisioni con dissenso documentato hanno un tasso di revisione e miglioramento del 40% più alto rispetto a quelle unanimi.

Laboratorio pratico ed esercizi

Immagina di essere il data analyst neutrale chiamato a mediare un conflitto tra Sales e Product. Sales dice che il CRM mostra 340 nuovi clienti enterprise a Q3, Product dice che l’event tracking ne mostra 280 attivi, e il CEO vuole un numero solo per il board. Il primo compito è formulare cinque domande per capire la radice del disaccordo, non “chi ha ragione?” ma “come definite cliente enterprise?”. Il secondo è proporre una metodologia di riconciliazione, per esempio un match tra CRM ed event tracking per individuare chi manca in uno dei due. Il terzo è scrivere un mini decision memo con la definizione condivisa, il numero finale e chi ha dissentito.

Gli stessi principi si estendono ai conflitti più ampi. Quando finance chiede una riduzione dei costi, sales teme di perdere pipeline e operations avverte che il taglio peggiorerebbe gli SLA, l’analyst costruisce scenari comparabili invece di scegliere il lato politicamente più forte. La lettura prudente resta la stessa: un numero che migliora va confrontato con una baseline, un segmento che cambia più degli altri segnala che la media nasconde una differenza, e un costo che cresce con il risultato va letto sul margine.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Effetto reale o variazione normale	Look for comparison and segment
One segment changes more than others	The aggregated average hides a difference	Separate cohorts or use cases
Il costo cresce con il risultato	Impact must be read on the margin	Estimate trade-offs and sustainability

Typical mistake to avoid

L’errore più comune è trattare la gestione del conflitto come un’etichetta invece che come un processo: un grafico senza decisione, una metrica senza baseline, una conclusione senza l’assunzione che potrebbe invalidarla. La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione. Prima di portare i numeri al tavolo, controlla completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi, perché molti conflitti nascono proprio dal fatto che il dato di partenza misura un comportamento diverso da quello che il team crede di osservare.

Summary

Gestire un conflitto sui dati significa chiarire definizioni, separare fatti da incentivi e rendere visibili i trade-off, non imporre un numero. Il framework RAPID assegna a una sola persona la decisione finale, il playbook in quattro passi riconcilia metriche divergenti e il modello “disagree and commit” di GitLab trasforma il dissenso in qualità. La forma corretta dell’analisi resta sempre la stessa: decisione, segnale, baseline, rischio, azione. Categoria: Decisione. Difficoltà: advanced. Tempo stimato: 18 min.

References:

• Rogers, P. & Blenko, M. (2006). “Who Has the D? How Clear Decision Roles Enhance Organizational Performance.” Harvard Business Review.
• GitLab. (2024). “Disagree, Commit, and Disagree.” GitLab Handbook.
• Heath, C. & Heath, D. (2013). Decisive. Crown Business.