La méthode, en deux sections
La méthode
Un Product Builder porte un produit, d’un dossier de documents épars jusqu’à quelque chose qui tourne en production, front et back ; Design, Frontend, Backend et API, Data, les accès, la livraison et la revue sont les services partagés qui le rendent possible.
Être responsable du résultat ne signifie pas faire chaque travail de spécialiste ni diriger chaque contributeur. Les services horizontaux sont des partenaires de la livraison, pas une file de tickets sans lien entre eux.
Le principe
Les deux dimensions
Vertical
Un résultat produit
Un Product Builder responsable d’un produit, front et back : le problème, les décisions, le design accepté, le code, le backend et la vérification, du premier dossier de documents jusqu’à la production.
- Design OpsUn design system dans lequel puisent le prototype et le front : les composants et leurs états, les tokens, les règles d’usage, ce qui peut être étendu, et qui le maintient.
- Frontend OpsUn dépôt starter approuvé dans une version identifiée, avec son architecture, ses conventions de routing et de composants, le pattern de client d’API, les contrôles exigés sur une branche déployable, et une version qu’un agent peut relire avant chaque modification.
- Backend et API OpsUn catalogue d’API avec de vrais exemples, les règles d’authentification et de permissions, la forme des requêtes, des réponses et des erreurs, un environnement de test avec des identités sans risque, et une manière écrite de demander une API qui n’existe pas encore.
- Data OpsOù vivent les données de référence, le sens métier des champs clés et des valeurs de statut, un jeu de données de test sans risque, et les règles sur ce qui peut être exporté, par qui et vers où.
- Accès, livraison et revueUn circuit de demande avec un approbateur et un délai de réponse cible, un chemin du local au dépôt, puis au staging, puis à la production, un moyen de voir quelle révision est en ligne, et des devs qui relisent le code généré.
Un produit qui tourne en production
Vertical · Product Builder
Porter un résultat, front et back.
Portez le problème, les décisions, le design accepté, les contraintes et la vérification, de la discovery jusqu’à la production. Vous puisez dans les services partagés et vous gardez le résultat.
Horizontal · Services partagés
Rendre l’expertise réutilisable.
Fournir un responsable désigné, un pattern ou un contrat approuvé et ses limites, un circuit de réponse, et des preuves que la contribution fonctionne dans le produit en fonctionnement — à vous, et à tous ceux qui font le même travail.
Un contrat dans les deux sens
Le Product Builder fournit
- Le résultat, les utilisateurs et le contexte
- La contribution nécessaire
- Les contraintes dans lesquelles elle doit tenir
- Un critère d’acceptation
- Une échéance de décision
Le responsable Ops fournit en retour
- Un responsable désigné
- Un pattern ou un contrat approuvé, et ses limites
- Un délai cible de réponse ou de livraison
- Un circuit de revue
- Des preuves que cela fonctionne dans le produit en fonctionnement
Exemple
Sur un flow de partage, le Product Builder est responsable des permissions voulues par le produit et du comportement accepté par les personnes concernées. Design Ops fournit le pattern revu et ses états, Backend et API Ops le contrat d’autorisation, Frontend Ops le starter dans lequel le front est écrit, Data Ops les événements qui montrent l’usage. Le Product Builder parcourt le flow de bout en bout, avec ses états vides, ses erreurs et ses refus de permission, et le vérifie comme un seul produit.
Le parcours
D’un dossier de documents épars jusqu’à quelque chose qui tourne en production, seul, avec des agents de code et de design qui font le travail pour lequel vous les briefez : sept jalons dans un ordre, et deux choses qui les traversent tous.
Pourquoi l’ordre compte
- Un dossier de documents n’est pas une discovery.
- Une discovery n’est pas un PRD.
- Un PRD n’est pas un prototype dans lequel les personnes concernées reconnaissent leur outil.
- Un front sur lequel on peut cliquer n’est pas un produit dont les flows tiennent en profondeur.
La question. Lequel de ces éléments avez-vous réellement en main ? Commencez là où la réponse cesse d’être oui, et ne laissez pas une session franchir un jalon que vous n’avez pas fermé : demandez-lui, à chaque jalon, de dire à quel jalon elle est, ce qu’elle a, ce qui manque, et ce que vous devez décider avant qu’elle le franchisse. Une session qui ne sait pas répondre est sortie de la méthode.
“La phrase qui ferme un jalon, c’est ce que vous devez avoir en main avant de passer à la suite.”
Les sept jalons
Sept jalons, numérotés de 0 à 6. Rien au-dessus, et pas de sous-phases. Chacun dit ce que vous faites, ce que vous avez en main quand il se ferme, et les prompts et modèles qu’il utilise.
0 · Monter le dossier du projet
Ce que vous faites
Réunissez dans un seul dossier, créé pour lui, tous les documents dont le projet a besoin, et ouvrez la session sur ce dossier. Créez la mémoire et le journal avant que quoi que ce soit d’autre tourne, ainsi que le channel du projet, avec toutes les personnes concernées dedans. Le premier prompt convertit et indexe ; il n’interprète rien.
Mémoire et journal de projet
Pourquoi le produit a-t-il pris cette direction, et qu’est-ce qui s’est passé, et quand ? Deux fichiers créés avant tout le reste : la mémoire porte la position actuelle, les décisions et les arbitrages ; le journal porte la trace datée, jamais réécrite, y compris ce qui s’est révélé faux.
1 · Rassembler la discovery
Ce que vous faites
Faites l’inventaire de ce dont vous partez, quoi que ce soit, et parcourez les sources pour y chercher les contradictions, les responsabilités non attribuées et le même nom employé pour des surfaces différentes, plutôt que pour en tirer un résumé. Faites lire par un agent ce que personne n’a le temps de lire ; ce qui en revient est une entrée, jamais une décision.
Notes de discovery
Qu’ont réellement dit les sources, et où se contredisent-elles ? La liste des sources, les ambiguïtés, les questions pour les stakeholders, et une première hypothèse sur le périmètre du produit, écrite dans le dossier pour que le jalon suivant puisse l’ouvrir par son nom.
2 · Écrire le PRD
Ce que vous faites
Lancez le prompt d’analyse sur le dossier, faites-lui séparer ce qui est établi de ce qui se contredit et de ce qui manque, et répondez vous-même à ses questions d’alignement. Affinez ensuite le PRD et alignez-le avec le métier, parties techniques comprises.
Le PRD
Qu’est-ce qui est construit, et qu’est-ce qui ne l’est pas ? Un document dont la première section est le cadrage stratégique, chaque hypothèse marquée comme une hypothèse, avec la source sur laquelle elle repose ou la personne qui doit trancher.
3 · Prototyper les flows end to end
Ce que vous faites
Pour cette étape, l’agent de code prend le rôle de PM : il écrit le prompt pour l’outil de design et exige des flows end to end, pas seulement les écrans majeurs. Itérez dans l’outil de design, montrez le résultat aux personnes qui vont l’utiliser, et continuez jusqu’à ce qu’elles disent que c’est leur outil.
Le prototype que les gens ont accepté
Est-ce l’outil qu’il faut aux personnes concernées ? Les flows end to end, avec leurs états et leurs échecs, itérés dans l’outil de design et montrés à de vrais utilisateurs jusqu’à ce qu’ils disent que c’est le leur.
4 · Porter le prototype dans le code
Ce que vous faites
Partez du starter frontend approuvé de l’organisation et de ses conventions backend, jamais d’un dossier vide ni de l’export de l’outil de design. Puis faites les allers-retours : le front qui tourne à côté du design, vous nommez ce qui ne va pas, l’agent corrige, vous regardez de nouveau.
Le front qui tourne
Pouvez-vous parcourir les flows et cliquer dedans ? Un front construit dans le starter de l’organisation, parcouru flow par flow à côté du design, avec ce qui a été adapté et ce qui a été volontairement laissé différent, écrit noir sur blanc.
5 · Brancher le backend
Ce que vous faites
Remplacez les services mockés par les vrais, flow par flow, et allez au fond de chacun avant de passer au suivant : l’état vide, l’erreur, la réponse lente, la permission qui refuse. Les rôles et la confidentialité s’appliquent au niveau du modèle de lecture, pas dans le composant qui affiche les données.
Les flows branchés
Les flows tiennent-ils en profondeur, ou seulement en surface ? Chaque flow face au vrai backend, avec ses états vides, ses erreurs, ses réponses lentes et ses refus de permission, et les rôles appliqués là où les données sont lues.
6 · Tester, puis livrer
Ce que vous faites
Donnez des comptes aux personnes qui doivent tester pendant que le branchement continue, partagez la vie du produit dans le channel, et corrigez ce qui remonte au fur et à mesure. Prenez ensuite le feu vert avec les leads des corps de métier concernés, et shippez.
Le compte rendu de release
Qu’est-ce qui est parti, vérifié comment, et qui a donné le feu vert ? Ce qu’il y a dans la release flow par flow, ce qui a été testé et avec quels comptes, ce qui est connu comme cassé, et quelle revue n’a pas eu lieu quand elle n’a pas été possible.
Chaque jalon estvalidéouvert — un responsable nommé le traitebloqué — arrête le travail qui en dépend
Ce que ça prend. D’un dossier où la discovery est déjà rassemblée jusqu’à un front sur lequel vous pouvez cliquer : trois à quatre heures au mieux et vingt-quatre au pire, quand la discovery a déjà été en partie rassemblée. Environ un mois pour brancher le backend jusqu’à ce que les flows tiennent en profondeur, selon la taille de l’application. Et le code part quand même en revue chez des devs, et il passe, parce que l’agent travaille dans le starter et les conventions de l’organisation. Ces chiffres viennent de la pratique de l’auteur, pas d’une étude.
L’IA construit vite : les vérifications qui comptent sont donc humaines. Les personnes concernées acceptent le prototype au jalon 3, et convaincre a ici un seul sens : elles disent que c’est l’outil qu’il leur faut. Le code part en revue chez des devs avant la production, et les leads des corps de métier concernés donnent le feu vert. Aucune de ces deux vérifications n’est une étape ajoutée à la fin.
Deux choses traversent les jalons plutôt que de tenir dans l’un d’eux. La session de contrôle est une seconde session dont le seul travail est de challenger la première : elle lit, vérifie et challenge, elle ne modifie aucun code et ne décide d’aucun périmètre, et elle renvoie ses constats avec leurs preuves pour que vous décidiez. Le garde-fou permanent renvoie l’agent au starter frontend et aux conventions backend de l’organisation avant chaque modification du code — pas une fois au début, à chaque fois. Session de contrôle → · Contrainte permanente →
Continuité. La construction ne s’arrête pas au jalon 6. Le front reste démontrable et continue d’évoluer : vous revenez dans les flows, vous les approfondissez, vous branchez ce qui était resté de côté, et vous le remontrez dans le channel. Une seule chose est volontairement gelée, une seule : un MVP qui doit partir en production, où ce qui est dans la release cesse de bouger jusqu’à ce qu’elle soit sortie.
Adapter au risque
Correctif ciblé · démarre au jalon 6
Un libellé trompeur, remonté par un testeur.
Le produit est déjà entre de vraies mains et la formulation est tout le changement. Corrigez-le au fil de ce qui remonte, dans les conventions du starter, reparcourez le flow, et laissez-le descendre le chemin de livraison. Rien ici ne rouvre le PRD ni le prototype.
Nouveau produit · démarre au jalon 0
Un outil qui n’existe pas encore.
Un dossier avec tout dedans, la discovery rassemblée et ses contradictions nommées, un PRD aligné avec le métier, un prototype dont les personnes concernées disent que c’est leur outil, puis le portage, le backend flow par flow, et des comptes entre de vraies mains avant la production.
Ces deux exemples montrent quelle part du parcours un travail donné suit réellement. Ils ne décrivent pas un projet client.