Cheat sheet della gestione data-driven

Questa pagina è pensata per essere consultata, non letta: ogni voce della checklist rimanda a una tabella o a un controllo verificabile. Se ti serve un promemoria rapido prima di una decisione, sei nel posto giusto: DECIDE, OKR e KPI, HADI e JTBD con le loro soglie operative, tutti in una sola sintesi.

A cosa serve questa sintesi

Questa sintesi raccoglie in una sola checklist le domande minime per decidere con dati, metriche e responsabilita chiare.

La checklist in cinque passi

1. Scrivi la scelta da prendere, chi decide e entro quando.
2. Fissa evidenza primaria, baseline e metriche di guardia.
3. Scegli Objective, Key Results e KPI con soglie scritte prima.
4. Esegui un ciclo breve con ipotesi, intervento minimo e misura.
5. Chiudi con decisione documentata, rischio residuo e prossimo controllo.

I tre pilastri in una riga

Tre principi reggono una cultura data-driven. Il primo e la data literacy diffusa: ogni manager sa leggere i dati. Il secondo e decidere per evidenza e non per gerarchia. Il terzo e la metrica condivisa, con una sola definizione per ogni concetto.

Se manca uno dei tre pilastri, la checklist non basta e va riparato prima il pilastro.

Il framework DECIDE in breve

Per strutturare una decisione importante segui Define, Evidence, Criteria, Investigate, Decide ed Evaluate. Definisci il problema, raccogli l’evidenza con i suoi limiti e fissa i criteri pesati. Indaga per segmenti, assegna la decisione a una persona e controlla l’esito a 30, 60 e 90 giorni.

OKR e KPI in breve

Gli OKR e i KPI rispondono a esigenze diverse. Un OKR e un obiettivo ambizioso con tre-cinque risultati misurabili, dove un risultato al 60-70% conta gia come successo. Un KPI e una metrica di salute, di solito tra cinque e dieci indicatori, per cui ci si attende un raggiungimento pieno.

OKR per cambiare comportamento e KPI per proteggere la salute, mai uno al posto dell’altro.

HADI e JTBD in breve

Il ciclo HADI scorre da Hypothesis ad Action, poi a Data e infine a Insights, con iterazioni di giorni e non di mesi. La domanda guida del Jobs to be Done e quale progresso cerca il cliente, tradotta sui dati come tasso di completamento del job e non come clic sulla feature.

HADI decide il ritmo dei test e JTBD decide cosa merita di essere testato.

Elemento	Definizione operativa	Controllo minimo
Unita di analisi	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 puo restare anche dopo l’analisi	Controllo di sensitivita o revisione qualitativa

La vista di controllo in SQL

Il pattern seguente crea una base analitica con metrica, segmento e finestra temporale. Confronta periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query e la superficie di osservazione comune a tutte le voci della checklist.

Il controllo di stabilita in Python

Una metrica utile resta stabile per orientare le decisioni e sensibile per segnalare i cambiamenti reali.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il controllo evita reazioni a oscillazioni casuali e segnala quando una voce della checklist merita una review.

Gli errori tipici da evitare

Il primo errore e leggere medie aggregate senza segmentare. Nasconde i gruppi che si muovono in direzioni opposte. Il secondo e ignorare la qualita del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo e usare la checklist come etichetta, con grafici senza decisione e metriche senza baseline. Ogni voce deve collegarsi a un outcome con definizione esplicita, confronto per segmento e controllo contro un periodo precedente o un gruppo di controllo.

Un caso reale: i memo di Amazon come checklist vivente

Dal 2004 Amazon richiede memo narrativi di sei pagine al posto delle slide nelle riunioni dirigenziali, letti in silenzio all’inizio. La regola costringe chi propone a esplicitare decisione, evidenze, nessi e numeri prima di chiedere budget. Vent’anni dopo la pratica e ancora in uso perche rende discutibili le assunzioni invece di nasconderle dietro i grafici. Il caso condensa l’intera checklist: domanda chiara, owner visibile, evidenza primaria dichiarata e rischio residuo esplicito.

Verdetto: prima di ogni decisione usa la checklist in cinque passi, e quando scegli tra i framework ricorda la gerarchia: OKR per cambiare comportamento, KPI per proteggere la salute, HADI per il ritmo dei test e JTBD per decidere cosa merita di essere testato.

Domande per verificare la tua comprensione

1. Quale scelta, quale owner e quale scadenza metteresti in cima alla checklist?
2. Quale evidenza primaria e quale metrica di guardia useresti per questa decisione?
3. OKR o KPI: quale strumento governa il cambiamento e quale la salute?
4. Quale rischio residuo accetti e quando ricontrollerai l’esito?