Product Owner

¿Quiere enviar su solicitud? Lea toda la información sobre este puesto a continuación y luego pulse el botón de solicitar.

Own the product, not the ticket queue — the business relationship, the backlog, acceptance, and whether the thing actually gets used.

Mainloop is a new engineering team inside an established international group. We are in Barcelona, we are being built from scratch this year, and we have the backing, the customers and the product portfolio of a company that has been around for decades. You get the interesting part of a new team without the part where you check whether payroll clears.

Two more things about where this comes from and where it goes. The group has been running a techlab in Casablanca for more than eight years — Barcelona is its second, built to sit closer to the teams we build for, and AI-native from the first commit, because it starts from a blank page. And the plan does not stop at internal work: within about a year and a half we intend to externalise— external clients, our products sold on the market, products developed for it. The first eighteen months are deliberately spent building as much as possible for the group while the machine gets set up. You would arrive at the start of that curve, not after it.

What we build is the software that automates professional-services work — across roughly fifteen countries, for businesses drowning in administration: the forms, the approvals, the reconciliations, the spreadsheet somebody rebuilds every month. We work in two halves. One half goes into a business, finds out what really happens there, and proves fast whether an idea is worth having. The other half — your half — takes what is proven and owns it for years: gathers the needs, keeps building, gets it adopted, and makes sure it stays worth having. Most automation teams stop at the demo. The entire point of ours is that we do not.

We are not looking for a backlog administrator. If your last role was turning other people's decisions into tickets and running the ceremonies around them, this is a different job. Here you are the product manager and the product owner: there is no one above you writing the strategy for your products, and no one below you writing the stories. What should exist, in what order, and whether what shipped is right — that is yours.

What the job actually is

A product arrives with a handover pack — already proven with its stakeholders by the first half of the team, already hardened for production. From day one it belongs to you and one developer, as a pair, for its life.

-

- You own the relationship with the business. Real people, in real offices, whose working day your product either improves or does not. You go and sit with them. Not a ticket queue — trust, built in person, held over years.

- You gather the needs and you decide. Your users cannot churn — they are in the building, and they will bring you more requests than any team could build. Most of this job is choosing: what moves the outcome, what waits, and what you decline with a reason the person asking can respect. Saying no well is the defining skill here, and you will have a product vision to say it from.

- You write what should exist, precisely. In our team, coding agents build most of what ships, steered by your developer. Agents amplify whatever they are given: a sharp specification becomes working software astonishingly fast, and a vague one becomes a thousand lines of confidently wrong code. Your needs, rules, edge cases and acceptance criteria are the most load-bearing documents in the company. Writing them precisely is the highest-leverage hour of your week.

- You accept, or you don't. When something ships,



you are the person who checks the behaviour against what you wrote — with your own hands, in the product, against the criteria you set before the build. "The demo looked right" is not acceptance. You will get seriously good at defining what "done right" means in a way that can actually be checked.

- You get it adopted, and you measure. Our products do not have revenue to hide behind. A product that ships and is not used is a failure with good release notes. You own the follow-up, the onboarding of new users with the business, and the number that says whether the thing is working — time saved, error rate, uptake — and you report that number whether it flatters us or not.

- You carry a portfolio, not a product. Every product we own is built on the same scaffold and arrives the same shape, which is what makes it possible for one PO to run several — each with its own developer, each with its own business. Variety is structural here: new products keep arriving from the other half of the team.

- Your first product is real. A live platform that a business runs on every day — real users, real history, real stakes. You inherit it from the person who has been carrying it, and part of your first months is taken up with the most useful thing a new PO can do: learning it properly before changing it.

Why this job exists — the honest version

Here is the thing our industry has just learned, and it is the reason we are hiring you: AI made building fast, and it did not make building the right thing any more likely. Surveys now find most companies shipping faster with AI while almost none can point to the return. It has never been easier to run, at speed, in the wrong direction.

In a team like ours the engineers steer agents, and implementation is rarely the bottleneck. The bottleneck is deciding— what to build, for whom, in what order, and whether what shipped actually did what the business needed. That is not a job the agents do. It is not really a job most engineers want. It is this job, and in an AI-native team it is a more senior, more consequential job than the same title has ever been — because every decision you write down gets built, quickly, exactly as you wrote it.

What stays yours, permanently:

-

- Deciding what not to build. The agents will cheerfully build anything. Somebody has to be the person for whom "no" is a complete sentence with a number attached.

- The relationship. Being trusted by a business, reading what they need underneath what they ask for, and telling them a favourite idea is not worth it — there is no model for that.

- Precision about what should exist. Turning a messy, human, political need into a specification with exactly one correct interpretation is the hardest writing there is, and it is now the closest thing this industry has to source code.

- Judgement about what came back. Acceptance, in a world where software appears fast, is the quality bar. You are it.

- The outcome. Whether the business is actually better off. Somebody has to own that number rather than the ship date, and it is you.

You will define how the PO role works here

You are the first. That is not a gap in the org chart — it is the offer.

How product ownership works in an AI-native team is a genuinely open question in our industry right now,



and the honest answer is that nobody's playbook fits yet. Ours will be written here, over your first year, by you and Edouard together: how needs become specs, how acceptance works when agents build, how adoption gets measured, how many products one pair can carry. The POs we hire after you will be onboarded onto the way you built.

If you have ever read a process document and thought I could have written this better — this is the job where you get to.

You will get seriously good at building with AI

We are an AI-native team, genuinely — not a team that added a Copilot licence. Everyone gets their own Claude Max subscription and the tooling to use it properly, and that includes you. The product people we admire in this market prototype with AI before they ask anyone to build: a rough working version of an idea, made in an afternoon, shown to a stakeholder — because a prototype communicates intent better than any document, and because it kills bad ideas cheaply. You will learn to do that here if you cannot already, and you will learn what makes a specification one an agent builds correctly the first time. That skill is being repriced upward across our entire industry, and this is one of very few jobs where you would practise it daily on products people depend on.

The Mainloop Barcelona certificate

Something we are building alongside the team, and we think it is genuinely unusual.

Over your first two to three years here you work through a defined body of knowledge — how we build, how we run products, how a need becomes a spec becomes working, adopted software — and when you can demonstrably run a product our way, you are awarded the Mainloop Barcelona certificate. It is yours: it goes on your CV, and we intend to make it mean something in this market. For a product person specifically, it certifies the thing the market is newly desperate for — that you can own products in an AI-native team, end to end, with proof.

How we build

Every product starts from the same scaffold, and it is the same in most of our repos — deliberately. For you that is the whole point: every product in your portfolio has the same shape, so carrying several does not mean holding several different worlds in your head. It also means the handover pack you inherit from the first half of the team actually tells you how the thing works — because it is built the way everything else is built.

You do not need to arrive knowing our tooling, and this ad deliberately lists no technologies. You need to be technical enough to hold your own in an engineering discussion, and to read what an agent produced closely enough to judge it. The rest — our architecture, our patterns, our method — is what we train you on.

Things worth knowing up front

-

- Barcelona is your base, and you will spend real time with the businesses. The products serve people across roughly fifteen countries, and the relationship is the job — expect regular travel to sit with your users, on us. It is a fraction of what our deployed engineers do, but it is not zero, and the POs who never leave the office are the ones whose products stop being used.

- Nobody is on call. Ever. No rota, no pager. Alerts post to a channel and wait for morning. We protect evenings with engineering, not with people.

- Nobody counts your hours or your tickets. What gets looked at is whether your products are used, whether the business is better off, and whether your specs held up. Outcomes, not throughput.

- We are building the team this year, and you will shape how it works. xcskxlj That is truest of all for this seat — see above.

If you would be moving to Barcelona for this

We do not expect you to absorb

#J-18808-Ljbffr

📌 Product Owner - Mainloop (Sant Cugat del Vallès)
🏢 Leyton
📍 Sant Cugat del Vallès