Aller au contenu

Lean Product Management — cadre opératoire Bricks

Contexte

Cadre opératoire Bricks pour tout sujet produit : priorisation, cadrage, specs, meetings, projects wiki, tickets Linear. Pas un cours — une lentille imposée aux points de décision (cf. règle lean-product, AGENTS.md § Lentille produit).

Pour choisir les sujets : priorisation produit. Pour cadrer un sujet retenu : cadrage produit.

Ce concept unifie le vocabulaire et câble les principes lean dans le second cerveau.

Lexique imposé

Terme Définition Bricks
Problème Qui souffre, de quoi, aujourd'hui — avant toute solution (JTBD en 1 phrase)
Hypothèse Pari falsifiable : « Si on [action], alors [métrique] passera de X à Y parce que [mécanisme] »
Bet / pari Initiative dont le statut est incertain — à traiter comme expérience, pas comme livraison garantie
Outcome Changement mesurable pour l'utilisateur ou le business (conversion, temps, rétention, EBITDA…)
Output Artefact livré (feature, endpoint, écran, doc) — nécessaire mais insuffisant
MVP / plus petit test Expérience testable chez de vrais users, pas une version allégée du produit final
Learning goal Ce qu'on veut apprendre même si le pari échoue
Kill criteria Seuil ou date après laquelle on stop, pivot ou scale — formulé avant de builder

Marqueurs wiki quand l'info manque : [hypothèse non formulée], [outcome non formulé], [non sourcé].

Distinction outcome / output — exemples Bricks

Output Outcome associé (exemple)
Endpoint read statuts projet Ops passe de 15 min à 3 min pour détecter une désynchro (outil d'analyse)
Export CSV back-office Réduction des allers-retours Slack support de N/semaine à M
Écran KYC update Taux de complétion KYC périodique ≥ X% à J+30

Frameworks autorisés (pas exhaustif)

Utiliser au moins un quand on priorise ou cadre — pas besoin de tous :

  • Build-measure-learn — cycle court, itérations, POC avant investissement tech
  • ICE / RICE — priorisation dans le flou (impact × confiance × effort)
  • OST light — outcome → opportunité → solution (Teresa Torres, version allégée)
  • JTBD — reformuler une demande feature en job utilisateur

Ne pas imposer RICE partout : imposer la question (« impact estimé sur quelle métrique, avec quelle confiance ? ») suffit.

Règles Bricks spécifiques

  1. Équilibrer build, discovery et organisation — efficience > perfection ; ratio valeur/effort explicite.
  2. Discovery en solo, synchro = validation — la discovery se fait avant la réunion ; la synchro tranche un pari déjà formulé (cadrage produit).
  3. N1/N2/N3 ≠ validation produit — la grille criticité features classe le risque technique, pas le risque d'hypothèse produit. Un POC N1 doit quand même avoir outcome + kill criteria.
  4. Bet vs delivery — statut incertain → vocabulaire bet / experiment ; exécution connue → delivery.
  5. Priorisation — levier = impact, déblocage ou invalidation du pari le plus risqué. Déroulé : priorisation produit.

Garde-fou IA — humain d'abord, IA en challenge

Confier immédiatement le contexte à l'IA et lui demander une conclusion accélère la production, mais court-circuite une partie du travail produit : lire la matière, faire des connexions et former son propre jugement.

L'IA peut intervenir tôt pour retrouver, trier ou résumer des faits. Elle ne doit pas produire la première solution d'un sujet structurant à la place du DRI.

Ordre attendu :

  1. Le DRI fait une première lecture — faits, tensions, connexions, questions.
  2. Il formule le problème et, si le champ est encore ouvert, esquisse plusieurs directions.
  3. L'IA challenge ensuite — preuves manquantes, contradictions, hypothèses fragiles, edge cases et options oubliées.
  4. Le DRI tranche ce qu'il garde et porte la recommandation.

Si une seule proposition existe, le premier challenge ne consiste pas à la polir. Il force d'abord la divergence : quelles autres manières de résoudre le même problème n'ont pas été explorées ?

L'objectif n'est pas de moins utiliser l'IA. Il est de l'utiliser après la formation d'un premier jugement humain, quand elle peut élargir et éprouver le raisonnement sans devenir son point de départ.

Checklist — 5 questions (toute initiative produit)

  1. Quel problème utilisateur ou business ?
  2. Quelle hypothèse falsifiable ?
  3. Quel outcome (métrique + baseline + target + date) ?
  4. Quel plus petit test shippable ?
  5. Qu'est-ce qui invalide le pari (kill criteria) ?

Anti-patterns

Anti-pattern Signal Correction
Feature request « Il nous faut un bouton X » Reformuler en problème + outcome
Output = succès « C'est livré en prod » Demander la métrique bougée
Roadmap sans pari Liste de livrables Ajouter hypothèse + kill criteria par item
Discovery en réunion Atelier pour « comprendre le besoin » Solo d'abord, synchro pour valider
Scope creep zélé Ticket qui embarque 3 sujets Découper ; plus petit test d'abord
Urgence sans impact Priorité High sans métrique ICE en 1 ligne ou [outcome non formulé]

Où la lentille s'applique dans le repo

Point de friction Artefact / règle
Choix du portefeuille priorisation-produit — arbitrage entre sujets
Déroulé d'un cadrage cadrage-produit — cycle, boucle, reprise
Conversations Cursor lean-product.mdc
Agents cloud prompts/_SHARED_RULES.md
Ingest meetings prompts/ingest.md, meeting-summary.md
Projects wiki projects/TEMPLATE/README.md
Tickets Linear specs-pour-agent.mdc
ADR produit prompts/adr-draft.md

État actuel

Dernière mise à jour : 2026-09-16

Sources