Jobs to be done : le vrai job que ton SaaS doit résoudre

Ton produit a dix fonctionnalités. Celui d'en face en a trois. Et pourtant c'est lui qui signe les clients. La raison tient dans une idée de Clayton Christensen, le professeur de Harvard derrière la théorie de l'innovation de rupture : les gens n'achètent pas un produit, ils « embauchent » quelque chose pour accomplir un job précis dans leur vie. Le framework jobs to be done (JTBD) part de là, et il change complètement l'ordre dans lequel tu construis ton SaaS.

Ce que veut dire « jobs to be done »

L'exemple le plus connu vient d'une chaîne de fast-food qui voulait vendre plus de milkshakes. Après des mois d'optimisation du goût et du prix, rien ne bougeait. Christensen et son équipe ont alors posé une autre question : quel job les gens cherchent-ils à faire quand ils achètent ce milkshake ? Réponse surprenante : la moitié des milkshakes partaient avant 9h du matin, achetés par des gens seuls, qui repartaient aussitôt en voiture. Le job n'était pas « boire quelque chose de bon ». C'était « occuper un trajet ennuyeux et tenir jusqu'au déjeuner », comme le raconte Harvard Business School.

Le vrai concurrent du milkshake n'était donc pas un autre milkshake. C'était une banane, un donut, ou l'ennui du trajet. Une fois le job compris, l'amélioration devient évidente : rendre le milkshake plus épais pour qu'il dure plus longtemps, le placer en libre-service pour aller plus vite. La leçon pour toi : tant que tu raisonnes en fonctionnalités, tu compares ton SaaS aux mauvais concurrents et tu passes à côté de ce qui fait vraiment acheter.

Les gens ne veulent pas une perceuse. Ils veulent un trou dans leur mur.

Un job, ce n'est ni un besoin vague ni une tâche technique. C'est un progrès que quelqu'un cherche à faire dans une situation donnée. « Gérer ma paie sans erreur », « rendre un rapport client qui a l'air pro », « savoir si ma pub est rentable avant de re-dépenser ». Le produit n'est qu'un moyen. Si un autre moyen fait le job mieux ou plus vite, il gagne.

Pourquoi cadrer le job avant d'écrire une ligne de code

Le réflexe quand on sait construire, c'est d'ajouter une feature de plus. C'est rassurant : tu contrôles ton éditeur, pas la réaction d'un inconnu. Sauf que c'est exactement là que meurent la plupart des produits. Ils sont bien faits, mais ils ne font le job de personne.

Les chiffres sont brutaux. Sur les startups analysées par CB Insights, 43 % de celles qui ferment citent une mauvaise adéquation produit-marché comme cause profonde : elles ont construit quelque chose que le marché ne réclamait pas assez fort. Et selon les travaux de Christensen relayés par MIT Professional Education, environ 95 % des nouveaux produits lancés chaque année échouent, souvent parce qu'ils partent de l'idée du fondateur et pas du job du client.

Cadrer le job en premier, c'est le vaccin contre ça. Tu ne demandes plus « quelle feature j'ajoute ? » mais « quel job je fais avancer, pour qui, et mieux que quoi ? ». Cette seule bascule t'évite des mois passés à polir un produit que personne n'embauche.

Comment formuler le job de ton SaaS

La bonne nouvelle : formuler un job ne demande pas de méthodologie lourde. Une formule, quelques conversations, et tu tiens l'essentiel. Voici la séquence à dérouler cette semaine.

Les trois dimensions d'un job (et pourquoi tu les rates)

Un job n'est jamais purement fonctionnel. Quand quelqu'un t'embauche, trois choses se jouent en même temps. La plupart des fondateurs ne travaillent que la première et se demandent ensuite pourquoi leur produit « logique » ne convertit pas.

Prends un outil de reporting pour freelances. Le job fonctionnel, c'est « générer un rapport ». Le job émotionnel, c'est « ne plus avoir honte de mes rendus bricolés ». Le job social, c'est « avoir l'air d'une vraie agence aux yeux de mon client ». Si ta page de vente ne parle que du fonctionnel, tu laisses les deux tiers de la motivation d'achat sur la table.

Du job à ton offre, ton persona et ton message

Une fois le job cadré, tout le reste se déduit. C'est là que le JTBD devient un outil de distribution, pas juste de produit. Voici comment le job irrigue chaque décision.

Le job devient ta boussole. Chaque idée de feature passe par un filtre unique : est-ce que ça fait mieux le job, ou est-ce que ça flatte mon envie de coder ? Cette discipline, c'est ce qui sépare un produit qui trouve son adéquation produit-marché d'un produit riche que personne n'adopte.

Ta checklist pour cadrer le job

Coche au fur et à mesure. L'objectif n'est pas la perfection théorique, c'est d'avoir une phrase de job assez nette pour la tester auprès de vraies personnes cette semaine.

Le lien avec le reste de ta stratégie

Le job to be done n'est pas un exercice isolé. Il alimente directement ton persona marketing, qui répond à la question « qui vit ce job le plus souvent ». Il donne aussi la matière brute de ta proposition de valeur : une promesse ancrée sur le progrès recherché convertit toujours mieux qu'une liste de fonctionnalités. Et avant même de coder, c'est ce qui structure ton étude de marché : tu ne cherches pas « est-ce que mon produit plaît », mais « ce job est-il assez douloureux pour qu'on paie pour le résoudre ».

Cadrer le job, c'est la moitié du chemin. L'autre moitié, c'est de trouver le canal où les gens cherchent déjà à faire ce job, et de leur parler avec leurs mots. C'est exactement le rôle du diagnostic ci-dessous.