Jobs-to-Be-Done (JTBD) è una teoria dell'innovazione di prodotto che riformula le esigenze dei clienti come "compiti" che stanno cercando di realizzare, con dimensioni funzionali, emotive e sociali. Invece di studiare chi sono i clienti (dati demografici), JTBD studia ciò che i clienti stanno cercando di ottenere e le circostanze che li portano a "assumere" un prodotto per svolgere un compito specifico.
?
Qual è il concetto centrale della teoria Jobs-to-Be-Done?
Il framework JTBD, sviluppato da Clayton Christensen e reso popolare nel SaaS da Bob Moesta, propone che i clienti non comprano prodotti, ma li "assumono" per progredire in una situazione specifica. L'illustrazione classica: un negozio di ferramenta non vende punte da trapano; vende fori da 1/4 di pollice. E le persone non vogliono fori da 1/4 di pollice, vogliono appendere un quadro. E non vogliono solo appendere un quadro, vogliono sentirsi orgogliosi della loro casa. Questa stratificazione delle dimensioni funzionali, emotive e sociali di ogni "job" rivela che le decisioni di prodotto focalizzate unicamente sulla funzione delle feature perdono di vista i driver emotivi e sociali che influenzano più potentemente il comportamento e la lealtà del cliente. Applicato al SaaS: i clienti non "usano un CRM", lo "assumono" per "sentirsi in controllo della mia pipeline di vendita e sicuri nell'affrontare una riunione di previsione".
?
Come utilizza Product Ops il JTBD nella scoperta e nella specifica del prodotto?
Product Ops integra il JTBD formando i PM all'uso delle tecniche di intervista JTBD nella ricerca utente. Un'intervista JTBD si concentra sulla "storia del cambiamento" del cliente: i momenti che precedono la ricerca di una nuova soluzione, l'evento specifico che ha innescato la ricerca ("la spinta"), ciò che immaginavano la nuova soluzione avrebbe dato loro ("l'attrazione") e ciò che quasi li ha fermati dal cambiare ("le ansie"). Questa cronologia degli eventi rivela: il contesto specifico in cui i clienti sperimentano il "job", i concorrenti che hanno considerato (inclusa la non-consumazione, ovvero non fare nulla), i fattori che hanno guidato la loro decisione e le aspettative che avevano nei confronti del nuovo prodotto. Product Ops compila le intuizioni JTBD in un modello "Forces of Progress" che il team PM utilizza durante la prioritizzazione, garantendo che le feature siano progettate attorno al contesto completo del "job", non solo al compito funzionale.
?
Come si collega il JTBD all'Outcome-Driven Innovation e alla prioritizzazione della roadmap?
Outcome-Driven Innovation (ODI), l'implementazione di Tony Ulwick del JTBD, traduce la teoria in uno strumento di prioritizzazione quantitativa. ODI definisce gli "outcome desiderati" come le metriche specifiche che i clienti usano per valutare il successo nel loro "job", espresse nella forma "minimizzare il tempo necessario per [compito]" o "minimizzare la probabilità che [situazione indesiderata] si verifichi". I clienti valutano ogni outcome su due dimensioni: importanza (quanto è importante che il prodotto eccella in questo?) e soddisfazione (quanto sono soddisfatti delle prestazioni del prodotto attuale?). Il punteggio di opportunità = Importanza + max(Importanza - Soddisfazione, 0). Alta importanza + bassa soddisfazione = alta opportunità. Questo fornisce a Product Ops un elenco prioritario di "esigenze insoddisfatte" che è statisticamente fondato sull'input del cliente, resistente all'influenza del singolo cliente e direttamente utilizzabile per la costruzione della roadmap.
Sfida di Conoscenza
Hai padroneggiato Framework Jobs-to-Be-Done (JTBD)? Ora prova a indovinare la parola di 5 lettere correlata!
Digita o usa la tastiera