Vise juste comme Basecamp
Et au train où vont les choses, il est sûr
Que n’ayant pas pour but de faire du romanesque
Mes mots auront effet toujours avec la même justesse
Par ces rimes, les mots du groupe NTM reflètent bien mon approche du design : le design est utile avant d’être beau.
👉 Concentrer mon effort sur le “juste problème” me hante quasiment. L’équipe produit de Basecamp a posé les jalons d’une potentielle réponse. Let’s dive in 🐳!
La démarche, un prétexte au service d’un objectif
En l’an 2000, NTM mettait tout le monde d’accord dans le rap game avec son album Suprême. Le titre Je vise juste — s’il est moins connu que d’autres titres de l’album— n’en est pas moins utile pour nous rappeler une qualité essentielle dans la démarche d’un.e designer.
Le rap conscient dénonce des maux de la société
Il y a une multitude de genre de rap. Le rap de NTM se rapproche le plus du rap dit conscient. La démarche artistique ne se suffit pas à elle même, elle a un but dénonciateur. D’ailleurs, leurs meilleurs titres parlent tous de sujets de société.
Le design est utile avant d’être beau
L’art peut se suffire à lui même, simplement en procurant de l’émotion. Au mois de juin dernier, j’ai eu la chance de voir de mes propres yeux La naissance de Vénus de Boticelli. Bien que novice dans l’art de la Renaissance, je suis resté 15 minutes devant ce tableau … et j’ai kiffé ! L’art pour l’art.
Le rap et le design partagent un même point commun : derrière la démarche, un objectif. Dénoncer certains maux de la société pour l’un, et résoudre un problème pour l’autre.
Une équipe produit, c’est comme un collectif de rap engagé
Le rôle d’une équipe produit est d’identifier des problèmes. Explorer des solutions. Trouver une solution. Pas de faire du beau uniquement, comme dénoncé sur Dribbble qui fait parfois l’éloge du superficiel.
Comment s’assurer que le problème est bien identifié ? Comment ne pas donner un coup d’épée dans l’eau en développant une fonctionnalité non utilisée ? Comment viser juste ?
La recherche du geste juste
Tout équipe, quelle que soit sa taille, agit sous contrainte. Elle doit faire des choix. L’utilisation de notre temps est notre plus précieuse ressource. La définition du problème est ainsi l’élément central d’une démarche produit efficace.
Voilà pourquoi.
Un LiveMission, en veux-tu en voilà
Chez LiveMentor, on s’est largement inspiré des InterMission d’Intercom pour définir le problème qu’on cherche à résoudre. C’est un document partagé pour toute l’équipe. Un brief du projet. C’est formidable pour :
- Aligner les parties prenantes d’une feature: ingénieurs, designers, mentors, sales, student success managers
- Eliminer les “à peu près” : s’assurer que le problème est le même dans toutes nos têtes
- Décider de façon ferme sur l’approche et la solution à adopter
La génèse d’un LiveMission
Dans notre équipe, la génèse d’un LiveMission démarre souvent de cette manière.
- Un élève nous contacte, il se plaint de quelque chose.
- Delphine, notre Student Success Manager s’entretient avec lui pour bien comprendre son besoin.
- Edouard, un mentor ou moi-même discutons en direct avec Delphine des problèmes rencontrés par nos élèves.
De façon très concrète la discussion ressemble à cela :
Delphine : Certains élèves demandent à changer de mentor.
FX : Ha oui ? Sais-tu pourquoi ?
Delphine : J’ai l’impression que la façon de coacher de ce mentor ne fonctionne pas avec cet élève.
FX : Comme si les deux personnalités ne s’accordent pas ?
Delphine : Oui, on dirait bien que c’est cela. Ce serait top si l’on avait un moyen de connaitre mieux connaître la personnalité de chaque élève pour l’associer au bon mentor.
J’appelle l’élève.
J’échange avec d’autres par email.
On pense effectivement cerner le problème. On va croiser cela avec des données factuelles, comme le nombre de changement de mentors, relire les échanges écrits à ce sujet.
Je commence à rédiger un LiveMission.
Je réalise un Kickoff avec l’équipe Tech. Et je propose un début de solution en mode low-fidelity ou flow élève.
Mais est-ce suffisant ?
- Quel est notre niveau de confiance pour designer puis coder cette feature ? Le problème d’origine est-il réellement le bon ?
- Combien de temps cela-va-il nous prendre ?
- Tous les edge cases ont ils été découverts ?
👉 Faisons un zoom une étape de l’équipe produit de Basecamp : formaliser une étape avant celle du LiveMission. Et si ça permettait de viser encore plus juste ?
Viser PLUS juste avec l’approche de Basecamp
Basecamp est une entreprise américaine, basée à Chicago. Elle développe un logiciel de gestion de tâches.
Elle est connue en grande partie par ses deux fondateurs, Jason Fried et David Heinemeier Hansson très présents dans les média en terme de prise de position sur la culture du travail. Ce contre-pied se manifeste sur leur page de recrutement ou dans leur dernier bouquin “It doesn’t have to be crazy at work”.
Dans leur approche, ils différencient bien 2 étapes dans un projet :
- l’étape de conceptualisation d’un projet Figuring Things Out (celle qui nous intéresse aujourd’hui)
- l’étape de réalisation Making it Happen
Dans chaque projet à la sauce Basecamp, il y a trois étapes :
- Shaping
- Betting
- Building
“Shape up” en 2 étapes
Récemment Ryan Singer, lead Product de leur équipe a sorti un livre sur la façon de travailler de leur équipe Produit : Shape Up. Le chapitre éponyme m’a particulièrement interpellé.
Shaping work is qualitatively different from building. It’s unknown in advance which ideas will turn into bettable projects and which ones won’t. Some projects are shaped quickly, some take multiple cycles, and some never come together.
Shaped Pitch = LiveMission
L’étape du Pitch ressemble de très près à notre LiveMission décrit plus haut. Tous les ingrédients y sont comme ils le décrivent eux-même :
Ok ! Tout semble plutôt raccord. Pourtant …
Avant le pitch, on fait quoi papa ?
C’est cette étape avant le Pitch sur laquelle j’aimerais faire un zoom. La lecture de cet ouvrage de Basecamp me donne envie d’itérer à nouveau sur le process produit de LiveMentor.
Prochaine étape
Concrètement, j’ai envie de tester dans un futur proche les choses suivantes. Avant de rentrer dans les specs du LiveMission :
- Mieux définir l’intention de la fonctionnalité : “savoir dans quel pays on se rend”
- Mieux définir la direction de la fonctionnalité : “savoir quel chemin on va prendre, et surtout quel chemin on ne va pas prendre !”
- Mieux définir l’inconnu :” savoir ce qui pourrait mal se passer en chemin”. Avoir plus de questions ouvertes sur ce qui pourrait mal tourner. Essayer le plus en amont possible de s’interroger sur ce qu’un changement produit pourrait entraîner comme conséquences négatives sur nos utilisateurs, mais également sur le quotidien d’autres équipes.
Parlons-en
👉Je suis toujours partant pour échanger sur le meilleur process produit
👀 Si vous êtes designer, product manager, ou tout simplement intéressé par ces problématiques, laissez un commentaire
