Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Idea principale
«Qualificare un incidente», «ritrovare il contesto prima di agire», «confrontare più entità», «coordinare più persone»: formulato così, un bisogno del cliente nomina un'azione di lavoro e nient'altro. Non dice attraverso quale schermata, quale feature o quale meccanismo il prodotto debba rispondervi.
È proprio questo a renderlo sfruttabile a lungo. Un bisogno registrato come «aggiungere un pulsante di confronto» ha già deciso la soluzione al momento della raccolta, e la traccia di ciò che il cliente cercava di fare è sparita — non la si può più riaprire per immaginare altro. Formulato al livello dell'azione, lo stesso feedback resta aperto a più risposte di prodotto, e resta confrontabile con altri feedback che miravano alla stessa azione attraverso richieste diverse.
Questo livello è anche quello che resiste meglio al tempo: le schermate cambiano, le feature vengono sostituite, ma qualificare un incidente resta ciò che fa un tecnico.
Perché è importante
Questo protegge la fase di discovery da una decisione presa troppo presto e dalla persona sbagliata. Un cliente che chiede un pulsante propone una soluzione; registrarla così com'è fa entrare la sua proposta nel repertorio come se fosse il bisogno.
Crea anche un punto di aggregazione. Tre richieste di feature senza legame apparente, ricondotte allo stesso job, rivelano una stessa azione supportata male dagli strumenti — un raggruppamento invisibile finché ogni richiesta resta classificata sotto la sua soluzione.
Sfumature e limiti
Risalire al job non deve diventare una risalita sistematica verso l'astrazione: un fastidio preciso riformulato come azione di business generica perde il dettaglio che permetteva di correggerlo. Il livello dell'azione è un livello in più, non un livello che assorbe gli altri.
E la formulazione come job non garantisce nulla sulla frequenza né sul valore: dice cosa cerca di fare il cliente, non quanti clienti lo cercano.
Domande aperte
- Come verificare che un job formulato dal team di prodotto corrisponda a ciò che il cliente fa davvero, e non a ciò che si è capito del suo racconto?