Aller au contenu

Product Builder

Définition

Chez Bricks, "product builder" recouvre deux profils distincts qu'il ne faut pas confondre. Le terme générique a longtemps masqué ce dédoublement.

Pourquoi on en parle

Romain et Alban cherchaient chacun à recruter "un product builder". Au meeting 2026-04-30, Denis pose la question frontalement : "vous mettez le même mot, mais vous ne cherchez pas la même personne." Décision à clarifier pour ne pas envoyer Charlotte (recrutement) sur des candidats qui ne fittent pas le besoin.

État actuel (auto)

Dernière mise à jour : 2026-05-05

Deux définitions distinctes (ADR 2026-04-30), avec une évolution V1 du Profil B entérinée le 5 mai 2026 (voir grille).

Profil A — Dev autonome avec sens produit (recherché par Alban / Denis)

  • Background tech solide (ancien dev), à l'aise avec Cursor et les outils IA.
  • Capable de prendre la responsabilité du code en autonomie : du cadrage au code en prod.
  • Sens produit suffisant pour comprendre les enjeux UX et discuter avec les utilisateurs internes (ex : Mélanie).
  • Rattaché à la team tech. Respecte le process tech (review plan, criticité, stack commune).
  • Use case immédiat : passation gestion des projets d'Alban → ce dev en reprend l'ownership tech.

Profil B — Product Builder produit-first qui shippe ses V1 (recherché par Romain)

  • Ownership produit-first. Beaucoup de parties prenantes, beaucoup de data, beaucoup d'allers-retours UX.
  • Évolution V1 (mai 2026) : avec Cursor + agents IA, le PB shippe lui-même les V1 fonctionnelles, il ne se contente plus de cadrer. La tech reste conséquence du cadrage produit, mais le PB met les mains dans le code (assisté).
  • Rattaché côté produit, collabore étroitement avec les devs pour l'industrialisation.

Conséquences

  • Deux fiches de poste séparées, deux process de recrutement, deux référentiels d'évaluation.
  • Process tech utilisé pour le Profil A (5 étapes, exigeant — adapté long terme).
  • Process plus léger pour freelances / missions courtes / profils exploratoires.

Référentiels d'évaluation

  • Profil B (Squad Analyse) → Product Builder Career Path V1 (ADR 2026-05-05). 3 piliers (Mindset / Build AI-Assisted / Discovery-Mesure-Collaboration), 13 dimensions, 6 sous-paliers PB1− → PB3+. Répartition cible 60% build / 20% discovery / 20% analytique.
  • Profil PM (Squad Investisseur) → grille distincte PM Career Path V1 (rôle Product Manager, pas Product Builder).
  • Profil A → process tech existant (criticité, review plans). Pas de grille career path formalisée pour ce track.

Frontière de sortie — cadre AI Coding & Vibe Coding (mémo Denis 21/05 + synchro adoption 21/05 PM)

Le mémo opérationnel partagé par Denis le 21/05 matin (source, ADR proposed, concept ai-coding-vibe-coding) posait initialement la frontière Karpathy : « Le PB s'arrête au POC validé. » La synchro d'adoption du 21/05 après-midi (fiche meeting) a assoupli cette frontière.

« N1 et N2, c'est vibe coding OK. N2, c'est un vibe coding un peu cadré. N3, c'est un dev qui fait. » — Denis (synchro 21/05 PM, 44:36)

  • Profil B Bricks = vibe-codeur produit-first, peut shipper N1 et N2 (avec Tech Buddy nominal sur N2), pas N3.
  • Frontière Karpathy générique (« stop POC ») = applicable au profil Karpathy abstrait, pas au Profil B Bricks tel que recruté.
  • La V1 du Profil B du 5 mai (« le PB shippe lui-même les V1 fonctionnelles ») reste valide pour une V1 d'outil interne N1 ou d'un outil métier N2 supervisé.
  • Cas concret validé en synchro : un wrapper Manus pour un PB freelance reste fine en mode vibe code par PB, même si ce n'est pas un POC pur.

Critère de classification (apport Vincent en synchro) : « probabilité de bug × scope d'impact × irréversibilité ». Ce n'est pas l'état du projet (proto vs prod) qui détermine le niveau, c'est le scope d'impact si bug.

Recrutement aligné : - PB recrutable pour N1 et N2 (pas seulement N1 comme initialement écrit dans le mémo). - Pairing Tech Buddy nominal sur les sujets N2 dès l'onboarding. - N3 = Développeur uniquement. Plus de N3 lancé en solo par PB. Les sujets N3 actuellement portés en build solo (gestion projets / défauts par Alban, outil d'analyse modalités/contrats) sont des reliques du passé, prioritaires pour passation.

Lien recrutement TPC en cours (mission PM Squad Investisseur) : la frontière retenue est plus large que celle du draft Denis. Ce qui peut être restitué aux candidats : « le PM Bricks ship N1 et N2 lui-même, accompagné d'un Tech Buddy sur les sujets N2. Sur N3, on co-construit avec la Tech mais on ne porte pas le code seul. »

Décisions liées

Référentiels

Projets et areas impactés

Sources