Own the product, not the ticket queue — the business relationship, the backlog, acceptance, and whether the thing actually gets used.
The relationship with the businessNeeds, backlog and roadmapAcceptanceAdoption and follow-upMainloop is an engineering company in Barcelona. We own what we build and we answer to ourselves. You get the interesting part of a new company, with a real customer and real products from day one.
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 isA product arrives with a handover pack — already proven with its stakeholders by the first half of the team, already made ready for production. From day one it belongs to you and an engineer, as a pair, for its life. We keep one Product Owner seat, for the products big enough that the business relationship is a job on its own — most of our smaller products are run end to end by a Full-Stack Product Engineer, and part of your week is helping them with the product work that is hardest to do alone.
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 work in the same offices, 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 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 versionHere 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 neede

📌 Product Owner (Barcelona)
🏢 Mainloop
📍 Barcelona