Framework JTBD applicato alla gestione

Il framework Jobs to be Done diventa utile quando lo traduci in metriche di completamento, segmenti e baseline. Il cuore, però, è un cambio di prospettiva che precede qualsiasi tabella: non chiederti quale soluzione comprare, ma quale progresso cerca il cliente. Due clienti di 25 e 60 anni che comprano lo stesso trapano vogliono entrambi un foro nel muro.

L’idea in una frase

Il framework Jobs to be Done sposta la decisione dalla soluzione desiderata al progresso concreto che il cliente cerca di ottenere.

Il percorso in cinque passi

1. Scrivi il job come progresso cercato dal cliente, in una frase senza nominare soluzioni.
2. Separa la dimensione funzionale del job da quella emotiva.
3. Assegna a ogni job una metrica di completamento con unita di analisi e baseline.
4. Segmenta la tabella per job e non per demografia.
5. Scegli l’intervento che alza il tasso di completamento del job al minor costo.

I principi JTBD per l’analisi dati

Il job e il progresso che il cliente cerca, non il prodotto che compra. Tre principi reggono tutto il resto.

1. Non segmentare per demografia, segmenta per job: due clienti di 25 e 60 anni che comprano lo stesso trapano vogliono entrambi un foro nel muro, non il trapano in se.
2. Il job e stabile nel tempo, la soluzione cambia: ascoltare musica in movimento e il job, mentre Walkman, iPod e servizi di streaming sono soluzioni diverse dello stesso job.
3. Misura il successo del job, non l’uso della feature: conta quanti utenti hanno completato il confronto tra prodotti con successo, non quanti hanno cliccato il pulsante confronta.

Quando demografia e job sono in conflitto, il job vince perche spiega il comportamento osservato in tabella.

Mappare i dati sui job

Per collegare il framework alle metriche, affianca a ogni job la dimensione funzionale, quella emotiva e la metrica che dimostra il completamento.

Job funzionale	Job emotivo	Metrica di successo
Prenotare un volo senza sorprese sui costi	Sentirsi in controllo della spesa	Tasso di completamento booking, tempo medio di prenotazione
Sapere se il pacco arriva in tempo	Stare tranquillo che il regalo arrivi	Quota di tracking aperto, ticket sul dove e il mio ordine

Il manager che chiede un nuovo tool spesso nasconde il vero job: ridurre l’incertezza prima della riunione settimanale. La domanda utile non e quale soluzione comprare, ma quale progresso misurare. La tabella seguente aiuta a leggere ogni segnale con prudenza prima di finanziare un intervento.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmento
Un segmento cambia piu degli altri	La media aggregata nasconde una differenza	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	L’impatto va letto sul margine	Stimare trade-off e sostenibilita

Tra feature cliccate e job completati, finanzia solo cio che alza il completamento del job.

La vista di controllo in SQL

Per leggere il completamento dei job per canale e dispositivo, il pattern seguente crea una base analitica con metrica, segmento e finestra temporale.

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 rende confrontabili periodi e gruppi. Verifica cosi se un intervento ha davvero alzato il completamento del job.

Il controllo di stabilita in Python

Una metrica di job 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 un job merita una nuova indagine qualitativa.

Gli errori tipici da evitare

Il primo errore e segmentare per eta o ruolo invece che per job. Mescola cosi bisogni diversi nella stessa media. Il secondo e ottimizzare i clic sulla feature invece del completamento del job. Premia interazioni che non creano progresso. Il terzo e ignorare la qualita del dato: eventi duplicati, tracking incompleto e cambi di definizione producono job apparentemente completati. Ogni analisi deve includere definizione esplicita della metrica di job, confronto per segmento di job e controllo contro un periodo precedente.

Un caso reale: il test di Superhuman

Tra il 2017 e il 2019 Rahul Vohra applica a Superhuman il test di Sean Ellis sul dolore da distacco dal prodotto. L’azienda chiede agli utenti quanto sarebbero delusi senza il prodotto e lavora finche oltre il 40% risponde molto deluso. Raggiunta la soglia, Superhuman raddoppia sul segmento che completa davvero il job invece di inseguire tutti gli utenti. Il caso, raccontato da First Round Review nel 2018, mostra il framework in azione: il job non e la posta in generale, ma finire le email due volte piu in fretta per un profilo preciso, e ogni decisione discende da quella misura.

Verdetto: quando demografia e job sono in conflitto, il job vince: segmenta per job, misura il completamento e non i clic, e finanzia solo gli interventi che alzano il tasso di completamento al minor costo.

Domande per verificare la tua comprensione

1. Quale job stai misurando e come lo distingui dalla soluzione attuale?
2. Quale metrica dimostra il completamento del job meglio dei clic sulla feature?
3. Perche segmenti per job invece che per demografia in questa tabella?
4. Quale soglia di completamento ti farebbe raddoppiare l’investimento sul segmento?