Product Owner - Mainloop

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 bus