Une mémoire de Product Manager, faite pour son premier utilisateur : son auteur. Des notes, des méthodes et des retours d'expérience qui existaient déjà, mais qui ne servaient pas au moment où un problème se posait.
Une bible de Product Manager tenue dans Word : notes, méthodes, frameworks, retours d'expérience. Elle existe, mais devant une difficulté il faudrait déjà savoir quoi y chercher.
Mon rôle
Utilisateur, produit, design et développement. Le brief, le resserrement du périmètre, puis une application construite.
Ce que ça démontre
Être son propre utilisateur n'épargne pas la démarche : un besoin écrit, un périmètre resserré, des règles de produit tenues par des tests.
Du problème à la réponse
Ce qui coince, et ce que fait Lantern
Le brief d'origine le disait ainsi : l'objectif n'est pas de stocker ou de rechercher des documents, mais de partir d'un problème concret et d'obtenir une réponse construite. Chaque irritant ci-dessous a sa réponse dans l'application.
Une liste de documents ne répond pas
« Mon directeur commercial veut ajouter une fonctionnalité demandée par un gros client » n'est pas une requête de recherche.
Résoudre : on raconte ce qui coince, comme à un pair, et il en sort une fiche de route - ce qui se joue, quoi faire, avec quoi, quoi éviter.
Les mots de la question ne sont pas ceux des fiches
On écrit « convaincre mon CODIR » ; la fiche, elle, parle d'alignement.
Un lexique du métier, radicaux et synonymes, fait le pont. Des questions réelles et la fiche qui doit sortir sont figées dans un test, à relire avant de toucher au classement.
Une question sans réponse disparaît
Quand la bibliothèque n'a rien, l'écran se ferme et le manque avec lui.
Les trous : la question est gardée en bas de la Bibliothèque, avec un bouton qui ouvre une fiche pré-remplie sur cette question. C'est ainsi qu'elle devient trouvable.
Un conseil lu n'est pas appliqué
La fiche de route est lue, puis la semaine reprend.
Le Carnet suit les étapes, pose la revue hebdo, et pré-remplit le REX qui repart enrichir la Bibliothèque. La boucle : Résoudre, Carnet, Capitaliser.
L'arbitrage s'oublie, et se re-débat
Entre ce qu'on va faire et ce qu'on en a appris, il manquait la décision elle-même.
Le journal de décisions garde ce qui a été tranché, les options écartées et leur raison, et l'hypothèse qui tenait dessous. La date de relecture se fixe au moment de décider.
Ce qui a été dit, et ce qu'on en conclut
Dans des notes d'entretien, le verbatim et l'interprétation finissent mélangés.
Entretiens découpe les notes en observations qualifiées - contournement, douleur, demande, besoin, contexte - sans réécrire le verbatim. Ce qui revient se compte par entretien, jamais par occurrence.
À l'écran
Du problème ouvert au retour d'expérience
Carnet
Ma semaine
Où l'on en est sur chaque problème ouvert, et ce qu'on en retient une fois fini. Les étapes des fiches de route sont épinglées dans le temps ; ce qui est capitalisé repart dans la Bibliothèque.
✓Aujourd'hui, cette semaine, plus tard, fait
✓Une revue hebdo pour faire le point
✓Un REX pré-rempli quand une fiche est terminée
Product + Design + Dev
Lantern est en bêta
L'application s'écrit encore : il reste des bugs, et tout peut bouger d'une semaine à l'autre. Elle s'ouvre sans compte.
