JTBD and the value of collected data

Anche in questa lezione il binario è tabellare: i job dei clienti diventano eventi in tabelle, e il tasso di completamento si legge con query settimanali. Un team traccia decine di micro-eventi ma non sa quale progresso del cliente rappresentino. Il Jobs-to-be-Done ribalta la domanda. Non chiede cosa possiamo misurare. Chiede quale lavoro l’utente cerca di completare e quale segnale lo rende visibile. Solo così il tracking torna a collegarsi all’utilità.

L’idea in una frase

Il framework Jobs-to-be-Done collega ogni evento tracciato al progresso che il cliente cerca così che la raccolta misuri valore e non solo attività.

Come si applica il framework

1. Elenca i lavori principali che i clienti cercano di completare.

2. Collega ogni lavoro agli eventi che dimostrano progresso o abbandono.

3. Applica a ogni evento il test di valore su metrica, decisione e costo.

4. Elimina gli eventi ornamentali senza decisione collegata.

5. Misura il tasso di completamento per lavoro su base settimanale.

Mappatura tra job ed eventi

Ogni evento deve rispondere a un lavoro, a un ostacolo o a un momento di progresso. Altrimenti misura attività senza spiegare perché conti.

Customer jobs	Company jobs	Events to track
Trovare il prodotto giusto	Ottimizzare ricerca e navigazione	search_performed, product_viewed, filter_applied
Confrontare opzioni	Aumentare add-to-cart	product_compared, review_read, size_selected
Completare l’acquisto senza attriti	Ridurre abbandono checkout	checkout_started, payment_method_selected, purchase_completed
Sentirsi sicuro dopo l’acquisto	Aumentare retention	order_tracked, review_submitted, return_initiated

Verdetto: quattro job mappati a eventi espliciti battono cinquanta micro-click senza significato.

Il test del valore e i job completati

Per ogni evento del plan servono tre risposte. Primo: quale metrica alimenta, per esempio conversion rate o retention a 30 giorni. Secondo: quale decisione supporta, come ridisegnare il checkout o spostare budget. Terzo: quale è il costo di non tracciarlo, per esempio decidere al buio su modifiche che impattano milioni di ricavi. Se manca una risposta, l’evento non deve esistere. In pratica conviene tracciare job completati come filter_applied, product_saved e payment_added invece di segnali tecnici come button_clicked.

Verdetto: job completato con metrica e decisione batte click tecnico senza owner.

Una vista SQL per il completamento dei job

La vista seguente crea una base settimanale per fonte e dispositivo per confrontare periodi e gruppi senza riscrivere la logica.

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;

Usala per leggere il completamento dei job per segmento invece della media globale.

Un controllo Python di stabilità

Una metrica di job deve restare stabile per decidere e sensibile per segnalare 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']])

Sotto soglia osservi, sopra soglia verifichi qualità del dato e poi cause di business.

Typical mistakes

Il primo errore è aggregare troppo presto e nascondere segmenti opposti. Il secondo è ignorare la qualità: duplicati, tracking incompleto e timezone incoerenti producono conclusioni false. Il terzo è confondere correlazione e causalità: chi usa una feature e converte di più era forse già più motivato. Ogni analisi richiede definizione esplicita, confronto per segmento e verifica su periodo precedente.

Verdetto: metrica per job con baseline e controllo batte conteggio di click senza contesto.

Il caso del milkshake

Il caso più citato dei Jobs-to-be-Done arriva da Clayton Christensen in Competing Against Luck del 2016. Una catena di fast food vuole vendere più milkshake e scopre intervistando i clienti che il lavoro del mattino non è placare la sete. Il milkshake serve a tenere compagnia durante un lungo tragitto in auto: denso, lento da finire, consumabile con una mano. La soluzione tocca formato e momento di acquisto, non il gusto. Per la data collection la morale è operativa: se tracci solo cosa viene comprato e non in quale contesto di lavoro, ottimizzi il prodotto sbagliato.

[SQL]Try it yourself

Write a query that finds the date of the first order and the first page_view event for each user. Show name, first order date, first page_view date.

RunCtrl+Enter to runHintSolution

Domande per verificare

1. A quale lavoro del cliente colleghi ogni evento del plan?

2. Quale metrica dimostra che un lavoro è stato completato con successo?

3. Come distingui un job completato da un click tecnico ornamentale?

4. Quale baseline usi per leggere il tasso di completamento per segmento?