Dans cet article je vous présente un autre angle de vue pour réfléchir à votre produit et vous permettre d'alimenter votre continuous discovery en opportunités à qualifier : le Job.

On va parler de Job 2 Be Done (J2BD) et de Lean, et comment ça peut nous aider à découvrir des nouvelles idées.

Note : ces conseils sont orientés B2B, ils peuvent ne pas s'appliquer dans un autre contexte.

Le Job pour se détacher du produit

C'est un peu compliqué d'avoir une définition précise du Job. Il y a même deux teams en compétition pour dire qu'ils ont inventé le J2BD, avec bien sûr des définitions légèrement différentes.

L'idée principale du Job, c'est que c'est quelque chose que l'utilisateur cherche à accomplir, et il va se servir de votre produit pour y arriver. Finalement, il se moque de votre produit, seul le résultat importe.

Attention : Une tâche à accomplir dans un outil n'est pas un job. Par exemple, un utilisateur ne va pas acheter un outil pour "remplir le formulaire".

Dans cet article, on va se dire que le job c'est :

• une activité que doit ou souhaite faire l'utilisateur,
• de taille variable,
• avec un début et une fin,
• un objectif
• et un moyen de savoir s'il a réussi ou non.

Les Jobs peuvent être imbriqués les uns dans les autres, comme des poupées russes.

Votre produit en entier peut couvrir intégralement plusieurs jobs, ou seulement une étape d'un seul job.

Souvent, dans la littérature sur les J2BD, les jobs sont des jobs "high level" utilisés comme positionnement stratégique pour l'entreprise entière. Mais ici on va plutôt parler des jobs et sous-jobs au niveau des features, pour se donner un point de vue détaché du produit existant et probablement découvrir de nombreuses opportunités.

Axe d'exploration 1 : Rendre les choses possibles

L'idée de ce premier axe, c'est de suivre le parcours du point de vue du job et de voir quels éléments ne sont pas encore possibles en ligne. Ce sont autant de pistes pour étendre votre produit.

Le job en détail

On peut découper le job en étapes (source : Tony Ulwick), selon les actions entreprises par l'utilisateur avant (Define, Locate, Prepare, Confirm), pendant (Execute) et après (Monitor, Modify, Conclude) le déroulement du job. :

Ces étapes sont comme une checklist de situations à prendre en compte quand on reconstitue le parcours d'un job.

On ignore souvent les étapes avant l'exécution, mais il se passe pas mal de choses à cet endroit : comprendre ce qu'on s'apprête à faire et s'y préparer, s'assurer qu'on est prêts. Plus le job est important ou plus il y a d'enjeux et plus ces étapes préalables seront intéressantes à explorer.
Si, par exemple, vous allez contracter un emprunt, vous allez devoir vous assurer d'avoir bien tous les documents avant de vous déplacer, ce qui veut dire obtenir la liste de ces documents et les retrouver.

Pendant l'exécution, aussi, il peut y avoir des actions faites en dehors de l'application et qui sont autant d'idées à qualifier.
Imaginons que vous ayez trouvé un AirBNB pour un voyage entre amis. Avant de conclure la transaction, vous allez demander leur confirmation, probablement en envoyant le lien en messagerie. Tout cet échange se fait en dehors de l'application.

Enfin, une fois l'action principale du job effectuée, on s'attend à pouvoir suivre et vérifier, corriger si besoin et enchaîner avec la suite.
Exemple : vous venez de faire un virement et vous allez vouloir bien vérifier que l'argent a été envoyé à la bonne personne et avoir l'opportunité de rectifier si besoin, surtout si le montant est important.

Pour plus de détails sur ces étapes, je vous conseille cet article et surtout cette cheat-sheet.

Des opportunités pour compléter le job

Il y a trois catégories d'opportunités qu'on peut découvrir en décortiquant le job et son parcours :

L'étape non couverte. En observant l'utilisateur vous allez pouvoir vous rendre compte qu'il y a des choses qu'il fait en dehors de l'outil et que vous gagneriez à couvrir. Une étape ou une partie d'une étape. Ce sont autant d'opportunités d'étendre votre produit.

L'utilisateur adjacent. Il se peut que le job implique que l'utilisateur interagisse avec quelqu'un d'autre. Cette autre personne suit son propre parcours, a son propre job et peut être même son propre outil. Mais comme cet autre utilisateur vient en intersection avec votre produit, il y a des opportunités de le servir aussi.

Le job adjacent. Il peut y avoir aussi dans le parcours des intersections avec d'autres jobs. Ces jobs adjacents sont peut-être même couverts par d'autres outils. La question intéressante et riche en opportunités c'est de trouver comment aider l'utilisateur dans sa transition entre ses activités.

Axe d'exploration 2 : Rendre les choses faciles.

L'idée de ce 2ème axe, c'est de se concentrer sur les opportunités de faciliter le parcours de l'utilisateur.

Généralement on va cartographier le parcours de l'utilisateur dans l'outil pour lister les pistes d'améliorations repérées lors des tests, replays de sessions ou interviews. On va essayer de rendre les choses explicites ou intuitives, apporter de l'aide contextuelle, et de manière générale aider l'utilisateur à atteindre son but.

Mais c'est intéressant de suivre, en plus, le parcours de l'utilisateur du point de vue du job et moins du point de vue de l'outil. Pour ça il faut faire des immersions : observer l'utilisateur travailler à son poste sans passer par l'intermédiaire du tracking.

Dans cette optique, un excellent moyen de rendre plus facile l'expérience de l'utilisateur, c'est de trouver et résoudre les inefficiences du parcours.

L'attente entre les étapes

Un premier niveau de lecture sur le job est de distinguer les temps d'attente entre les étapes.

On peut se servir d'un outil qui nous vient du Lean : la Value Stream Map. L'idée est de représenter sur la map l'enchaînement des étapes et de mettre en valeur leur temps de "processing" et les temps d'attente s'ils existent :

Dans cet exemple, on se rend compte que l'utilisateur attend 92% du temps entre le début et la fin du job. On voit aisément que l'attente entre les étapes C et D est l'opportunité la plus intéressante à explorer.

La valeur au sein des étapes

Regarder les temps d'attente entre les étapes est un bon début : c'est souvent là que se trouvent les gains importants et faciles à atteindre.

Ensuite, pour aller plus loin dans l'optimisation du parcours, on va tenter de réduire le temps passé sur chaque étape. L'optique qu'on adopte ici est de décliner chaque opération de l'étape et de diminuer ou supprimer ce qui nous ralentit et qui n'est pas directement utile.

Imaginons que le job soit "Envoyer un email" : rédiger le corps de l'email est une opération utile. Entrer l'email du destinataire est une opération utile. Fouiller son carnet et son historique parce qu'on arrive pas à retrouver l'email du destinataire est une opération inutile.

Les opérations inutiles sont appelées en Lean "gaspillages" ou "gâchis" (waste en anglais). Ces gaspillages sont regroupés en 7 familles, ce qui permet de les repérer plus facilement :

Le retravail. Ce sont toutes les causes qui vont faire recommencer une opération ou passer plus de temps que nécessaire dessus. Par exemple, si l'utilisateur fait une erreur ou rencontre un problème, il va devoir recommencer. Ou alors s'il n'est pas sûr de bien faire les choses, il va devoir vérifier et revérifier.

Le transport. On peut se dire que cette catégorie provoque des interruptions du flux : est-ce que l'utilisateur doit commencer son job à un endroit et le continuer ailleurs ? Ou est ce que plusieurs personnes sont impliquées et doivent se transférer des informations et s'attendre ?

Le stock. Ici le stock correspond à tout ce qui a été commencé mais pas fini. Souvent le stock va se matérialiser comme un backlog ou une todo liste, donc finalement un temps d'attente. Par exemple : un flux où plein d'opérationnels attendent une validation d'un unique superviseur.

La surproduction. La surproduction est tout ce qui est fait en trop, qui ne sera jamais fini ou qui va congestionner le flux en créant du stock. Comme dans le cas d'un Product Manager qui écrirait les spécifications de pleins de fonctionnalités qui ne seront ensuite pas priorisées ou qui seront réalisées très longtemps après.

Les gestes inutiles. En suivant le job, vous allez découvrir des opérations unitaires (gestes) qui sont supprimables. Soit parce qu'elles ne servent à rien, soit parce qu'elles sont facilement automatisables ou remplaçables. Par exemple : un utilisateur a imprimé un guide qu'il consulte à chaque fois pour savoir comment avancer. En simplifiant l'outil, vous allez rendre superflu le guide.

Les étapes inutiles. Parfois vous rencontrerez des étapes entières qui sont inutiles. Exemple : Quand on postule à une offre d'emploi et qu'il faut transmettre le CV puis ensuite saisir le contenu du CV dans un formulaire.

Les attentes. La plupart des gaspillages précédents entraînent des attentes, mais ce qui est intéressant à observer, c'est que les attentes entraînent des attentes : imaginons que vous lanciez un traitement qui prend une minute. Vous n'allez pas attendre à rien faire que la minute se passe, vous allez faire autre chose en attendant, mais vous allez y passer cinq ou dix minutes. Ces interruptions dégradent beaucoup l'expérience.

Au final, chaque temps d'attente et chaque gaspillage sont des pistes d'améliorations, des opportunités à ajouter à votre arbre.

Axe d'exploration 3 : Rendre les choses simples

Pourquoi je vous parle des jobs ? En fait, tout a commencé avec un tweet :

Notre travail ne s'arrête pas quand on a facilité la vie de l'utilisateur, mais quand on a complètement résolu son problème !

Du coup, l'idée de ce 3ème axe, c'est de trouver des pistes pour simplifier, automatiser et finalement faire complètement disparaître des opérations ou étapes du job.

Résoudre complètement un problème

Il y a un modèle de pensée à propos de la résolution de problème que j'aime bien, et pour l'illustrer, on va prendre comme exemple le renouvellement du passeport : on doit venir avec une liste précise de documents, sinon on ne peut pas continuer.

Le premier niveau de résolution, c'est la règle ou la checklist : on va former nos utilisateurs pour qu'ils évitent les problèmes. On va documenter le problème et donner des conseils pour qu'ils s'en sortent.
Appliqué au problème des documents pour le passeport, la solution serait de mettre sur le site une page qui contient la liste des documents avec un bouton pour que l'utilisateur puisse dire "j'ai lu et j'ai compris", sous entendu "s'il manque un document, c'est de ma faute".

Ensuite, le deuxième niveau, c'est le détrompeur : on va modifier le système pour que l'utilisateur ne puisse plus faire l'erreur ou rencontrer le problème. Il existe toujours, mais le détrompeur l'empêche d'impacter l'utilisateur.
On pourrait remplacer cette page checklist par un formulaire qui demande précisément chaque document et qui vérifie qu'ils sont corrects avant de continuer le process. Avec ce détrompeur, ce n'est plus possible d'arriver au guichet en ayant oublié un document.

Enfin le troisième niveau, et c'est l'idée de cet axe d'exploration, c'est de carrément supprimer le problème : s'il n'y a plus de problème, alors l'utilisateur ne risque plus de le rencontrer.
Ici, on irait récupérer automatiquement les documents avec une identité fédérée (comme France Connect). Il n'y a plus besoin de demander des documents, ni pour l'utilisateur de les chercher. Tout est là, le problème a disparu.

Ces opportunités sont les plus complexes à trouver, qualifier et réaliser, mais les fonctionnalités qui en résulteront seront des différenciants importants pour votre produit.

---

Bonus - Notre template de "Job Map"

Avec Yann Skargovskii mon binôme UX, on a créé une "Job Map" que je vous partage ici et qui est en fait une Experience Map focalisée sur le job et ses étapes, dans le but de représenter et consolider nos apprentissages et alimenter notre arbre des opportunités :

Au fil des entretiens utilisateurs, on a voulu enrichir notre connaissance de leur expérience en se posant les questions suivantes pour chaque étape du Job :

Qu'est ce que l'utilisateur fait ? Nos observations en immersion : les gestes, le temps passé sur l'étape, ce dont il a besoin pour commencer et pour terminer etc.. On va bien faire attention à lister ce qui est fait dans l'application et en dehors.

Quel est son but ? On essaye de déterminer ce que l'utilisateur attend de cette étape. Le résultat qu'il essaye d'obtenir pour passer à la suite.

Comment mesure-t-on le succès ? Il y deux succès : celui du point de vue de l'utilisateur et celui du notre. Comment on sait que l'étape s'est bien passée ? Que l'utilisateur a obtenu ce qu'il souhaitait ?

Quelles sont ses expériences et ses problèmes ? Du factuel sur le vécu des utilisateurs : Est ce que cette partie est couverte par le produit ? Est ce que c'est facile ? Est ce que ça avance ? Est ce qu'il y a des frustrations, des irritants etc.? On peut aussi représenter l'information ici sous forme de graphe, comme on le trouve souvent dans les journey maps.

Peut-on relever des "gaspillages" ? On en avait fait une catégorie à part, pour nous forcer à passer du temps sur chaque catégorie, comme une checklist. C'est là aussi où on va noter les temps d'attente entre les étapes.

Comment peut-on l'aider ? Nos idées du moment, en vrac, sur comment on pourrait améliorer l'expérience. Attention, ce n'est pas ici le futur backlog, mais plutôt une cache d'opportunités à ajouter à notre arbre, pour alimenter notre continuous discovery.