Product Owner

Mainloop AI est une société d'ingénierie à Barcelone. Nous détenons ce que nous construisons et nous ne rendons de comptes qu'à nous-mêmes. Vous avez la partie intéressante d'une société nouvelle, avec un vrai client et de vrais produits dès le premier jour.

Ce que nous construisons, c'est le logiciel qui automatise le travail des services professionnels — dans une quinzaine de pays, pour des entreprises qui se noient dans l'administratif : les formulaires, les validations, les rapprochements, le tableur que quelqu'un refait chaque mois. Nous travaillons en deux moitiés. L'une entre dans une entreprise, découvre ce qui s'y passe réellement, et prouve vite si une idée vaut la peine d'exister. L'autre — la vôtre — reprend ce qui est prouvé et le porte pendant des années : recueille les besoins, continue à construire, obtient l'adoption, et veille à ce que cela continue d'en valoir la peine. La plupart des équipes d'automatisation s'arrêtent à la démo. Tout l'intérêt de la nôtre est que nous ne nous arrêtons pas.

Nous ne cherchons pas un gestionnaire de backlog. Si votre dernier poste consistait à transformer les décisions des autres en tickets et à animer les cérémonies autour, c'est un autre métier. Ici, vous êtes le product manager et le product owner : personne au-dessus n'écrit la stratégie de vos produits, et personne en dessous n'écrit les user stories. Ce qui devrait exister, dans quel ordre, et si ce qui a été livré est juste — c'est à vous.

En quoi consiste vraiment le poste

Un produit arrive avec un dossier de transmission — déjà prouvé auprès de ses parties prenantes par la première moitié de l'équipe, déjà durci pour la production. Dès le premier jour, il vous appartient, à vous et à un développeur, en binôme, pour toute sa vie.

• Vous portez la relation avec le métier. De vraies personnes, dans de vrais bureaux, dont votre produit améliore ou non la journée de travail. Vous allez vous asseoir avec elles. Pas une file de tickets — de la confiance, bâtie en personne, tenue sur des années.
• Vous recueillez les besoins et vous décidez. Vos utilisateurs ne peuvent pas partir — ils sont dans l'immeuble, et ils vous apporteront plus de demandes qu'aucune équipe ne pourrait en construire. L'essentiel de ce métier consiste à choisir : ce qui déplace le résultat, ce qui attend, et ce que vous refusez avec une raison que le demandeur peut respecter. Bien dire non est la compétence qui définit ce poste, et vous aurez une vision produit depuis laquelle le dire.
• Vous écrivez ce qui devrait exister, précisément. Dans notre équipe, des agents de code construisent l'essentiel de ce qui est livré, dirigés par votre développeur. Les agents amplifient ce qu'on leur donne : une spécification affûtée devient du logiciel qui marche à une vitesse stupéfiante, une spécification vague devient mille lignes de code faux avec assurance. Vos besoins, règles, cas limites et critères de recette sont les documents les plus porteurs de la société. Les écrire précisément est l'heure la plus rentable de votre semaine.
• Vous recettez, ou pas. Quand quelque chose est livré, vous êtes la personne qui vérifie le comportement face à ce que vous avez écrit — de vos propres mains, dans le produit, contre les critères que vous aviez fixés avant le développement. « La démo avait l'air correcte » n'est pas une recette. Vous deviendrez très bon à définir ce que « bien fait » signifie d'une façon réellement vérifiable.
• Vous obtenez l'adoption, et vous mesurez. Nos produits n'ont pas un chiffre d'affaires derrière lequel se cacher. Un produit livré et non utilisé est un échec avec de bonnes notes de version. Vous portez le suivi, la prise en main des nouveaux utilisateurs avec le métier, et le chiffre qui dit si la chose fonctionne — temps gagné, taux d'erreur, adoption — et vous rapportez ce chiffre qu'il nous flatte ou non.
• Vous portez un portefeuille, pas un produit. Chaque produit que nous détenons est bâti sur le même squelette et arrive sous la même forme, ce qui rend possible qu'un seul PO en mène plusieurs — chacun avec son développeur, chacun avec son métier. Ici, la variété est structurelle : de nouveaux produits arrivent en continu de l'autre moitié de l'équipe.
• Votre premier produit est réel. Une plateforme vivante sur laquelle une entreprise tourne chaque jour — de vrais utilisateurs, une vraie histoire, de vrais enjeux. Vous en héritez de la personne qui la portait, et une partie de vos premiers mois est prise par la chose la plus utile qu'un nouveau PO puisse faire : l'apprendre correctement avant de la changer.

Pourquoi ce poste existe — la version honnête

Voici ce que notre secteur vient d'apprendre, et c'est la raison pour laquelle nous vous recrutons : l'IA a rendu la construction rapide, et elle n'a pas rendu plus probable le fait de construire la bonne chose. Les enquêtes constatent aujourd'hui que la plupart des entreprises livrent plus vite grâce à l'IA alors que presque aucune ne sait montrer le retour. Il n'a jamais été aussi facile de courir, vite, dans la mauvaise direction.

Dans une équipe comme la nôtre, les ingénieurs dirigent des agents, et l'implémentation est rarement le goulet. Le goulet, c'est décider — quoi construire, pour qui, dans quel ordre, et si ce qui a été livré a réellement fait ce dont le métier avait besoin. Ce n'est pas un travail que font les agents. Ce n'est pas non plus vraiment un travail que veulent la plupart des ingénieurs. C'est ce travail, et dans une équipe native à l'IA c'est un poste plus senior et plus lourd de conséquences que ne l'a jamais été le même intitulé — parce que chaque décision que vous écrivez est construite, vite, exactement comme vous l'avez écrite.

Ce qui reste à vous, définitivement :

• Décider ce qu'il ne faut pas construire. Les agents construiront volontiers n'importe quoi. Quelqu'un doit être la personne pour qui « non » est une phrase complète avec un chiffre à côté.
• La relation. Être digne de la confiance d'un métier, lire ce dont il a besoin sous ce qu'il demande, et lui dire qu'une idée préférée n'en vaut pas la peine — il n'y a pas de modèle pour cela.
• La précision sur ce qui devrait exister. Transformer un besoin désordonné, humain et politique en une spécification n'ayant qu'une seule interprétation correcte est l'écriture la plus difficile qui soit, et c'est aujourd'hui ce que ce secteur a de plus proche du code source.
• Le jugement sur ce qui revient. La recette, dans un monde où le logiciel apparaît vite, est la barre de qualité. Cette barre, c'est vous.
• Le résultat. Le fait que le métier aille réellement mieux. Quelqu'un doit porter ce chiffre plutôt que la date de livraison, et c'est vous.

Vous définirez la façon dont le poste de PO fonctionne ici

Vous êtes le premier. Ce n'est pas un trou dans l'organigramme — c'est l'offre.

La façon dont la propriété produit fonctionne dans une équipe native à l'IA est une question réellement ouverte dans notre secteur en ce moment, et la réponse honnête est qu'aucun manuel existant ne convient encore. Le nôtre s'écrira ici, pendant votre première année, par vous et le Head of Engineering ensemble : comment les besoins deviennent des spécifications, comment la recette fonctionne quand ce sont des agents qui construisent, comment l'adoption se mesure, combien de produits un binôme peut porter. Les PO que nous recruterons après vous seront intégrés sur la façon que vous aurez bâtie.

Si vous avez déjà lu un document de processus en vous disant j'aurais mieux écrit cela, voici le poste où vous le ferez.

Vous allez devenir très bon en construction avec l'IA

Nous sommes une équipe native à l'IA, vraiment — pas une équipe qui a ajouté une licence Copilot. Chacun a son propre abonnement Claude Max et l'outillage pour s'en servir correctement, vous compris. Les profils produit que nous admirons sur ce marché prototypent avec l'IA avant de demander à quiconque de construire : une version grossière d'une idée, faite en une après-midi, montrée à une partie prenante — parce qu'un prototype communique l'intention mieux qu'aucun document, et parce qu'il tue les mauvaises idées à bas coût. Vous apprendrez à le faire ici si vous ne savez pas encore, et vous apprendrez ce qui fait qu'une spécification est de celles qu'un agent construit correctement du premier coup. Cette compétence est en train d'être revalorisée dans tout notre secteur, et voici l'un des très rares postes où vous la pratiqueriez quotidiennement sur des produits dont des gens dépendent.

Comment nous construisons

Chaque produit part du même squelette, et c'est le même dans la plupart de nos dépôts — délibérément. Pour vous, c'est tout l'intérêt : chaque produit de votre portefeuille a la même forme, donc en porter plusieurs ne veut pas dire tenir plusieurs mondes différents en tête. Cela veut dire aussi que le dossier de transmission dont vous héritez de la première moitié de l'équipe vous dit réellement comment la chose fonctionne — parce qu'elle est construite comme tout le reste.

Vous n'avez pas besoin d'arriver en connaissant nos outils, et cette annonce ne liste délibérément aucune technologie. Vous devez être assez technique pour tenir votre place dans une discussion d'ingénierie, et pour lire ce qu'un agent a produit d'assez près pour le juger. Le reste — notre architecture, nos motifs, notre méthode — c'est ce sur quoi nous vous formons.

Ce qu'il vaut mieux savoir d'emblée

• Barcelone est votre base, et vous passerez du temps réel avec les métiers. Les produits servent des personnes dans une quinzaine de pays, et la relation est le métier — comptez sur des déplacements réguliers pour vous asseoir avec vos utilisateurs, à notre charge. C'est une fraction de ce que font nos ingénieurs déployés, mais ce n'est pas zéro, et les PO qui ne quittent jamais le bureau sont ceux dont les produits cessent d'être utilisés.
• Personne ne compte vos heures ni vos tickets. Ce que l'on regarde, c'est si vos produits sont utilisés, si le métier va mieux, et si vos spécifications ont tenu. Des résultats, pas du débit.

Si vous déménagiez à Barcelone pour ce poste

Nous n'attendons pas de vous que vous absorbiez le coût du déménagement, et nous préférons dire ce que nous prenons en charge plutôt que vous laisser demander.

• Nous payons pour vous faire venir. Les vols, le logement du premier mois le temps de trouver le vôtre, les frais de visa et de dossier, et un intermédiaire qui s'occupe de la bureaucratie — le NIE, le rendez-vous TIE, les apostilles — plutôt que de vous laisser affronter seul l'administration espagnole. Des cours d'espagnol si vous les voulez — et à ce poste, ils se rembourseront d'eux-mêmes.
• Une prime de relocalisation, versée à l'arrivée plutôt qu'au goutte-à-goutte. Elle n'est remboursable que si vous partez dans les dix-huit premiers mois, et c'est cette condition qui nous permet de la verser d'avance : changer de pays coûte de l'argent au début, pas en deuxième année.

Trois choses valent ici plus qu'il n'y paraît dans une comparaison d'offres, en particulier face à une offre américaine :

• Une couverture santé sans prime, sans franchise et sans réseau imposé — dès le premier jour, et sans être liée au fait de rester à ce poste.
• Trente jours calendaires de congés — soit 22 jours ouvrés — plus quatorze jours fériés, environ sept semaines au total. C'est le plancher légal en Espagne, pas un avantage dont nous nous montrerions généreux.
• Personne n'est d'astreinte. Jamais. Cela a sa propre ligne plus haut et nous le pensons littéralement.

Ce que nous cherchons

Un critère prime sur tout le reste, alors le voici clairement. Vous savez porter un produit de bout en bout — le besoin, la décision, la spécification, la recette, le résultat — et vous êtes assez technique pour contribuer à une discussion d'ingénierie et pour juger ce qu'un agent d'IA a construit. Vous n'avez pas besoin de coder pour vivre. Vous avez besoin de n'avoir aucune peur de l'intérieur de la machine. Si vous lisez cela en vous disant c'est le poste que je veux, continuez.

Lisez le reste comme la description de la personne que vous serez ici, pas comme une liste avec laquelle il faut arriver. Presque personne ne coche tout le premier jour, et nous préférons recruter le jugement et former le reste.

• Vous avez porté quelque chose de réel. Un produit, une plateforme, un module — quelque chose en production, avec des utilisateurs, où le backlog, les priorités et le résultat étaient réellement les vôtres. Nous vous demanderons de nous le détailler, et de justifier des décisions précises à l'intérieur.
• Vous vous intéressez à la façon dont les entreprises fonctionnent réellement. Les processus, le désordre à l'intérieur, et pourquoi les gens font les choses bizarres qu'ils font. Nos produits automatisent du travail administratif, et le PO que cela ennuie s'ennuiera.
• Vous écrivez avec précision, et cela vous plaît. La spécification, les critères de recette et le « non, parce que… » sont tous des documents, tous lus par des personnes (et des agents) qui n'étaient pas dans la pièce. Si votre écriture est le lieu de votre réflexion, vous serez chez vous.
• Vous savez dire non à quelqu'un de senior, avec un chiffre. Et garder la relation.
• Vous utilisez l'IA sérieusement — pour prototyper, pour analyser, pour votre propre écriture — et vous lisez ce qu'elle produit comme le travail d'un collègue : avec respect et avec méfiance.
• Vous êtes à l'aise avec les ingénieurs, et eux avec vous. Notre modèle, c'est un PO et un développeur portant chaque produit ensemble. Ce binôme ne fonctionne que si vous vous nourrissez de contexte au lieu de vous passer des tickets par-dessus un mur.
• Anglais courant. C'est notre langue de travail — nous travaillons dans une quinzaine de pays. L'espagnol est un vrai atout au quotidien, et pour votre premier produit en particulier. Le catalan n'est pas requis.
• Barcelone, avec des déplacements vers vos métiers.

Ce que vous avez étudié nous est égal, et une certification Scrum n'est ni requise ni un atout. Ce qui compte, c'est ce que vous avez porté, ce qui lui est arrivé, et si vous savez nous détailler les décisions qu'il contient.

Comment nous recrutons — les deux tours bâtis pour ce poste

1. Un échange de trente minutes. Ce que vous avez porté, comment vous travaillez, et comment vous y réfléchissez. Nous vous demanderons de nous détailler un produit que vous avez porté, puis de justifier une décision de priorisation précise à l'intérieur : pourquoi celle-là, pourquoi à ce moment, ce que vous avez écarté à la place. Cela ne se prépare pas et ne cherche pas à vous piéger ; c'est ainsi que nous distinguons la prise en charge de la proximité.
2. Une session de travail bâtie autour d'un produit réel. Vous lisez un vrai dossier de transmission, vous vous asseyez avec une vraie partie prenante, vous décidez de ce qui compte, vous écrivez la spécification et les critères de recette — puis vous regardez ce que nos agents et votre développeur en construisent, et vous nous dites si vous l'accepteriez, et ce que cela vaudrait. C'est ce que nous avons su concevoir de plus proche du poste réel, et cela marche dans les deux sens : vous en saurez beaucoup, à la fin, sur votre envie de travailler ici.

Mainloop · Barcelone. Postulez avec un produit que vous avez porté et un paragraphe sur le meilleur « non » que vous ayez dit : ce qui était demandé, pourquoi vous avez refusé, et ce qui s'est passé ensuite.