Tout le monde dit “on est user-centric”. Mais dans la plupart des équipes produit, ça veut dire quoi, concrètement ? Des personas affichés au mur, des feedbacks clients triés dans Notion, des chiffres d’usage dans Amplitude.
Et malgré tout ça, les mêmes questions reviennent : “Pourquoi ils n’adoptent pas la feature ?”, “Pourquoi ils contournent le process qu’on a simplifié ?”
Parce qu’on connaît nos utilisateurs… sans comprendre ce qu’ils essaient de faire. On regarde leurs comportements, pas leurs intentions. On optimise des clics, pas des progrès.
👉 Le vrai sujet, ce n’est pas qui ils sont, c’est quel job ils essaient d’accomplir. Le framework Jobs to Be Done (JTBD) change cette focale : il ne décrit pas un utilisateur, il décrit une mission.
Chez Yield, on s’en sert pour réancrer les produits dans la réalité. C’est simple, puissant, et quand on le fait bien - ça change tout.
Comprendre la logique du “job” : un changement de focale
Le concept paraît simple. Un Job to Be Done, c’est ce que l’utilisateur essaie réellement d’accomplir - indépendamment de votre produit.
Clayton Christensen l’expliquait très bien : “Les gens n’achètent pas une perceuse, ils achètent un trou dans le mur.”
Mais la plupart des équipes s’arrêtent là. Elles oublient que le “trou” n’est qu’une étape vers un objectif plus profond : accrocher un cadre, décorer une pièce, se sentir bien chez soi.
👉 Un job, ce n’est pas une tâche. C’est une progression recherchée. Une transformation dans la vie ou le travail de l’utilisateur.
Concrètement
Prenez Slack. Les gens ne veulent pas “chatter”. Ils engagent Slack pour “se sentir alignés sans passer leur journée en réunion”.
Même logique pour Notion : ce n’est pas une app de notes, c’est “un moyen de garder de la clarté dans le chaos des projets”.
Chaque job a quatre dimensions :
- Le contexte – quand et pourquoi le besoin émerge.
- La motivation – ce que l’utilisateur cherche à changer.
- Les freins – ce qui l’empêche d’y parvenir aujourd’hui.
- Le résultat attendu – la preuve que le job est accompli.
⚠️ Le piège, c’est de vouloir inventer des jobs.
Les bons se découvrent sur le terrain, là où les utilisateurs bricolent des solutions temporaires pour pallier un manque. C’est dans ces moments de lutte que naît l’innovation.
Identifier les bons jobs : passer de l’intuition à la preuve
Tout le monde pense connaître les jobs de ses utilisateurs. Mais 80 % du temps, ce ne sont que des suppositions. Les vrais jobs se détectent sur le terrain - pas dans un atelier Miro.
Chez Yield, on s’appuie sur trois leviers concrets pour les faire émerger.
Observer les “moments de lutte”
Les jobs se révèlent là où l’utilisateur bricole. Là où il détourne un outil, crée une macro, duplique un tableau Excel pour contourner un manque.
C’est le signal qu’il se tourne vers une solution, même imparfaite, pour accomplir un progrès qu’aucun produit ne lui offre encore.
👉 Le bon réflexe : observer les usages réels, pas les intentions déclarées.
Les entretiens JTBD ne cherchent pas à savoir ce que l’utilisateur veut, mais comment il s’en sort aujourd’hui.
“Sur un projet bancaire qu’on accompagnait, on a découvert que les utilisateurs n’utilisaient pas le simulateur pour calculer un prêt, mais pour savoir jusqu’où ils pouvaient aller sans passer par un conseiller. Ce n’était pas un outil financier, c’était un espace de liberté. Cet insight a repositionné notre roadmap”
— Julien, Product Lead @ Yield.
Reconstituer le parcours d’embauche
Chaque job suit une séquence logique :
- Déclencheur : un moment précis où le besoin émerge.
- Exploration : l’utilisateur cherche des solutions.
- Décision : il choisit la plus “embauchable”.
- Usage : il évalue le progrès réalisé.
Cartographier ce parcours, c’est comprendre quand et pourquoi votre produit devient pertinent. Et souvent, on découvre que le vrai job n’est pas celui qu’on pensait résoudre.
“Sur une app RH interne, on croyait répondre à un besoin simple : déclarer un congé. Mais en écoutant les utilisateurs, on a compris que le vrai job, c’était pouvoir s’absenter sans se sentir jugé. Ce n’était pas une question de workflow, mais de posture. On a repensé l’expérience autour de la confiance, pas du contrôle.”
— Amélie, Product Designer @ Yield
Valider les jobs par la preuve
Un bon job, c’est une hypothèse mesurable. S’il ne peut pas être vérifié sur le terrain, c’est une opinion.
👉 Formulez votre job ainsi :
“Quand [situation], je veux [objectif] afin de [progrès attendu].”
Et confrontez-le à la réalité : est-ce que des utilisateurs paient, changent d’habitude, ou adoptent votre produit pour cette raison précise ?
💡 À retenir
Les jobs ne se devinent pas, ils se confirment. C’est leur validation qui distingue une idée séduisante d’une opportunité solide.
Transformer les Jobs to Be Done en leviers produit
Identifier les bons jobs, c’est une chose. Les transformer en décisions produit, c’en est une autre. Chez Yield, on voit souvent des équipes qui font d’excellentes analyses JTBD… puis retournent à leurs roadmaps comme si de rien n’était.
Le vrai enjeu, c’est d’opérationnaliser les jobs : les rendre visibles dans la stratégie, la Discovery, la Delivery et la mesure.
Prioriser les jobs, pas les features
Chaque job n’a pas la même valeur. Certains sont critiques (le produit est “embauché” pour ça), d’autres périphériques. Les bons arbitrages viennent de là.
“Quand on a audité un outil d’onboarding RH, tout semblait logique sur le papier : tutoriels, fiches de poste, parcours métier. Mais les entretiens ont révélé un tout autre besoin : se sentir attendu, pas simplement formé. Ce n’était plus un sujet d’information, mais d’appartenance. On a revu la roadmap de fond en comble : messages personnalisés, accueil préparé, premiers écrans pensés comme une rencontre.”
— Léa, Product Strategist @ Yield
Tracez une matrice Impact / Fréquence :
- Impact = importance du job dans la vie de l’utilisateur.
- Fréquence = combien de fois il se manifeste.
👉 Les jobs “haute fréquence / fort impact” sont vos vrais leviers d’investissement.
Repenser la Discovery autour des jobs
Les Jobs to Be Done deviennent votre boussole de Discovery.
Chaque hypothèse testée doit répondre à une question simple :
“Cette solution aide-t-elle vraiment l’utilisateur à accomplir son job plus vite, plus facilement, ou plus sereinement ?”
C’est ce qui permet de distinguer une bonne idée d’une preuve de progrès.
🔍 Exemple terrain
Une app de gestion de congés voulait lancer un chatbot pour simplifier les démarches.
En replaçant le job réel - ne pas interrompre ma journée pour une demande administrative - l’équipe a préféré un raccourci natif dans Teams. Résultat : adoption x2 en deux semaines, sans feature “wow”.
Relier les jobs à la Delivery et à la mesure
Un job validé doit se retrouver dans les critères d’acceptation et les KPIs. Sinon, il reste théorique.
👉 Exemple : si le job est garder une trace fiable de mes décisions, le KPI n’est pas taux de clics sur le bouton Save, mais % de décisions retrouvées sans erreur après 7 jours.
C’est ce lien entre job, fonctionnalité et métrique qui garantit que la Delivery reste alignée sur la valeur réelle.
Chez Yield, on formalise souvent les jobs dans un document “JTBD Canvas” partagé avec les PM, UX et devs. Chaque story doit référencer un job précis et expliquer comment elle contribue au progrès utilisateur.
Faire vivre les Jobs to Be Done dans la durée : culture, pas outil
Le piège des JTBD, c’est de les traiter comme un livrable de plus. Un beau tableau dans Notion, quelques post-its en Discovery, et on passe à autre chose.
Mais les Jobs to Be Done ne servent à rien s’ils ne changent pas la manière dont l’organisation pense la valeur.
Chez Yield, on a observé trois leviers qui font la différence entre une équipe qui “fait du JTBD” et une équipe qui raisonne JTBD.
Aligner toute l’équipe autour des mêmes jobs
Les JTBD ne sont pas la propriété du Product ou de l’UX. Ils deviennent un langage commun entre produit, design, tech et business.
Concrètement, chaque rituel (refinement, sprint review, value review) doit pouvoir répondre à une seule question :
“Est-ce qu’on aide vraiment l’utilisateur à accomplir son job principal ?”
Quand tout le monde parle la même langue, les arbitrages se font plus vite, les discussions se centrent sur la valeur, pas sur les goûts ou les intuitions.
Reconnecter les métriques aux jobs
Une métrique isolée ne raconte rien. Un KPI lié à un job donne du sens à la mesure.
👉 Plutôt que taux d’usage du module X, suivez % d’utilisateurs ayant atteint le résultat attendu du job. Ce n’est plus une mesure d’activité, c’est une mesure de progrès.
Et à long terme, ce sont ces indicateurs de progrès qui deviennent vos meilleures preuves d’impact produit - celles qu’on peut défendre devant un sponsor ou un board.
Faire évoluer les jobs avec le produit
Les jobs ne sont pas figés. Quand le produit grandit, ils changent de nature : ce qui était un job principal devient parfois un job secondaire. Le danger, c’est de rester accroché à la première version.
👉 Révisez vos JTBD tous les trimestres. Pas pour les réécrire, mais pour valider s’ils sont toujours vrais, toujours critiques, toujours mesurables.
Les équipes qui tiennent cette discipline gagnent un temps fou : moins d’effort gaspillé, plus de clarté sur la roadmap, et un lien continu entre ce qu’elles apprennent et ce qu’elles livrent.
Conclusion - Les Jobs to Be Done, ou l’art de reconnecter le produit à la réalité
Les Jobs to Be Done, c’est une manière de regarder le produit sans filtre. Quand une équipe les maîtrise, les discussions s’épurent, les roadmaps se recentrent, et la mesure reprend du sens. On ne parle plus de features, on parle de progrès utilisateurs.
Le JTBD n’est pas une innovation en soi : c’est un révélateur. Il met en lumière les vrais moteurs de valeur, ceux qui traversent les organisations et les cycles produits.
👉 C’est ça, la promesse des Jobs to Be Done : remettre le produit au service de la réalité, et non l’inverse.
Chez Yield, on s’en sert comme d’un filtre : si une idée ne répond à aucun job clair, elle ne mérite pas encore une ligne de code. Et c’est souvent cette rigueur-là qui redonne au produit son vrai rôle : créer du progrès mesurable.
Vous sentez que vos équipes livrent beaucoup mais peinent à démontrer l’impact ?
On peut cartographier vos Jobs to Be Done et identifier les 2-3 leviers concrets pour reconnecter vos décisions produit à la réalité utilisateur.
