Product Owner

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. 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 the cost of relocating, and we would rather say what we cover than leave you to ask.

• We pay to get you here. Flights, your first month's accommodation while you find somewhere of your own, the visa and paperwork costs, and an agent to handle the bureaucracy — the NIE, the TIE appointment, the apostilles — instead of leaving you to meet the Spanish administrative system alone. Spanish lessons if you want them — and in this seat they will pay for themselves.
• A relocation bonus, paid on arrival rather than dripped out. It is repayable only if you leave within the first eighteen months, and that condition is the reason we can pay it up front — moving countries costs money at the start, not in year two.

Three things here are worth more than they look on an offer comparison, particularly against a US one:

• Healthcare with no premium, no deductible and no network — from day one, and not tied to staying in this job.
• Thirty calendar days of holiday — that is 22 working days — plus fourteen public holidays, roughly seven weeks in total. That is the statutory floor in Spain, not a benefit we are being generous with.
• Nobody is on call. Ever. It has its own line above and we mean it literally.

If you are coming from the United States, two things are usually worth more than the headline salary gap and almost nobody has done the arithmetic: a salary here can sit below the Foreign Earned Income Exclusion, and federal student loans on an income-driven plan are assessed on the income that exclusion has already removed. We are not your tax advisor and you should get one — but ask in the first conversation and we will walk you through the comparison we ran, including the parts where the number comes out smaller.

What we are looking for

One bar sits above everything else, so here it is plainly. You can own a product end to end — the need, the decision, the specification, the acceptance, the outcome — and you are technical enough to contribute to an engineering discussion and to judge what an AI agent built. You do not need to code for a living. You do need to have no fear of the inside of the machine. If you read that and thought that is the job I want, keep reading.

Read the rest as a description of the person you will be here, not a checklist you have to arrive with. Almost nobody ticks all of it on day one, and we would rather hire the judgement and train the rest.

• You have owned something real. A product, a platform, a module — something in production, with users, where the backlog, the priorities and the outcome were genuinely yours. We will ask you to walk us through it, and to justify specific decisions inside it.
• You are interested in how businesses actually work. Processes, the mess in them, and why people do the odd things they do. Our products automate administrative work, and the PO who finds that boring will be bored.
• You write with precision, and you like it. The spec, the acceptance criteria and the "no, because…" are all documents, all read by people (and agents) who were not in the room. If your writing is where your thinking happens, you will be at home.
• You can say no to someone senior, with a number. And keep the relationship.
• You use AI seriously — for prototyping, for analysis, for your own writing — and you read what it produces the way you would read a colleague's work: with respect and suspicion.
• You are comfortable with engineers, and they with you. Our model is one PO and one developer owning each product together. That pair only works if you feed each other context instead of passing tickets over a wall.
• English, fluently. It is our working language — we work across roughly fifteen countries. Spanish is a genuine advantage day to day, and for your first product especially. Catalan is not required.
• Barcelona, with travel to your businesses.

We do not care what you studied, and a Scrum certification is neither required nor an advantage. We care what you have owned, what happened to it, and whether you can talk us through the decisions in it.

How we hire

Our process is unusual, so here it is up front. Four rounds, and none of them is a puzzle.

• Fifteen minutes with Edouard. A short first conversation — who you are, what you are after, and what this actually is. Enough for both of us to work out whether the next one is worth an hour.
• A thirty-minute conversation. What you have owned, how you work, and how you think about it. We will ask you to walk us through a product you owned, and then to justify one specific prioritisation decision inside it: why that, why then, what you declined to do instead. There is no way to prepare for that and it is not meant to catch you out; it is how we tell ownership from proximity.
• A conversation with our Casablanca team. The group has run a tech lab there for more than eight years. You get people who have run production at real scale asking their own questions — and you get to ask them yours, including the ones you would rather not ask the person hiring you.
• A working session built around a real product. You read a real handover pack, sit with a real stakeholder, decide what matters, write the specification and the acceptance criteria — and then watch what our agents and your developer counterpart build from it, and tell us whether you would accept it, and what it would be worth. It is the closest thing to the real job we could design, and it works both ways: you will know a great deal about whether you want to work here by the end of it.