Product Manager, Product Layer of the CTRM System

Read this part first

Most of this system is built by coding agents. Delivery capacity is not our constraint — deciding what should exist is. That is the whole of this role.

You will not receive requirements. You will go and find out what a trader, an operator, an economist and a financier actually do, write the definition of each of those jobs yourself, and turn it into a working prototype of the system. You will own the backlog and the sprint scope for your layer: what is ready, what enters a sprint, what ships, what gets cut. And you will say no to the business when no is the right answer, and defend it in the demo, with the people who asked for it in the room.

If that reads as too much authority for one person, it is not the job you are looking for. If it reads as the first product job in years that isn't ticket administration, keep going.

The product

We are building the system an international oil-products trader will run its business on: the full deal lifecycle from contract to settlement. Pricing against Platts and Argus formulas. Costs accumulating across a chain of vessels, rail, trucks and storage. Invoicing, inventory, losses, claims, hedging. The purpose of the whole thing is that anyone involved in a deal can reconstruct the P&L between any two points of the chain, at any moment, on an agreed basis.

Real money moves on the numbers it produces. Correctness is the product.

Today that business runs on spreadsheets, email and phone calls, plus six years of an attempt that never shipped. Our backend team is well ahead — the transactional core is being built. What does not exist anywhere, in any document or any legacy screen, is the product logic: what each role sees, in what order, with what hidden from them, and what the system should already know before it asks.

That is the layer you own.

About the role

Four core users, each with a completely different relationship to the same deal:

• The trader — orchestrates and monitors, does not type. Open and closed positions, where the goods are, what was earned and lost.
• The operator — the coordination surface. Routes, vessels, counterparties, load and discharge, documents, the thousand small facts that make a cargo happen.
• The economist — deal economics, and matching every invoice line against contract terms. Target: heavy automation.
• The financier — cash, payments, allocation, offset, what is needed tomorrow and in which currency.

Plus logistics roles, inspectors, and management who want the business explained to them rather than tabulated.

The interesting constraints are real ones. Junior and head trader use the same screens with different scope. The system pre-fills what it can infer and asks only what it cannot, with reasons attached. No two deals have the same contract terms, so forms cannot be a fixed checklist. And the executive sponsor of this platform will never be a daily user, while the daily users have been asked for their input for six years and have watched nothing ship. Holding those two audiences together is not a communication tax on the job — it is a large part of the job.

Day to day

• Interview the trading company's own people and read their documents until you can argue with them; write the role definitions yourself- Take prototypes to the business, get them signed off, and keep them signed off- Own readiness and sprint scope for your layer, in two-week sprints against an explicit Definition of Ready and Definition of Done
  
• Cut things. Explain the cut to the person who wanted it.
• Decide what each screen needs from the platform underneath — which data, which calculation, which service — and get engineering to commit to it
• - Prototype the whole system as screens, early and fast, with AI producing the first version of nearly everything

What you need

• 5+ years in product management on complex B2B systems — trading, fintech, logistics, ERP, or anything where a wrong number costs somebody money
• AI as your primary way of working. This is a requirement, not a preference. Agents draft our role descriptions, specifications, screen flows, test data and analysis. Your value is direction and verification: framing the problem, structuring the context, and catching the answer that is fluent and wrong. If your use of AI is asking a chatbot to tidy your prose, you will be slower than this team runs
• You can absorb an unfamiliar domain at speed — pricing formulas, Incoterms, demurrage, cost accrual, netback — through interviews and documents, without losing the detail that turns out to matter
• Fluent Russian; English good enough to run a working session with the client's people

Strongly preferred

• Commodity trading, CTRM/ETRM, or a middle/back-office system in a trading house
• Having designed screens yourself — wireframe level, not visual
  
• Experience where the sponsor of the project was not one of its users
• You decide with incomplete information, and you can be publicly wrong and correct it without losing the room
• You source information yourself. No BA upstream of you, no analyst to delegate discovery to
• At least one large system you personally took from nothing to daily use. Not a redesign, not a module inside someone else's roadmap, not a pilot that ended at the pilot. People whose jobs depend on it, using it every day

What we offer

• Ownership of the product layer, end to end, with the authority that requires
• Direct access to founders and decision-makers on both sides; no account manager in between
• A serious, unsolved domain problem rather than another CRUD product
• Generous AI tooling budget — frontier models are a working expense, not a perk
• Fully remote and long-term, with regular travel to Dubai
• Competitive compensation, discussed individually

Honestly about the pace

The first production release is scheduled for February. Until then the intensity is high and the domain is unforgiving. That is the trade for the autonomy.

How to apply

Send your CV plus answers to all four questions. Applications without answers are not reviewed.

1. Pick one specific job title you have built a product for. What did you decide that person should not see on their screen, and how did you hold that position when they asked for it?

2. A senior stakeholder who is not a user signs off on your prototype, then rejects it at the demo two weeks later, in front of the team that has to build it. What do you do that week — and what do you change so it does not repeat?

3. Show us a real piece of work you produced by directing an AI: a specification, a role description, a research synthesis. Include the brief you gave it. Then one case where the output was plausible and wrong — how you caught it, and what check you now run every time.

4. Something you cut or refused to build under pressure. What was your argument, who was unhappy, and what actually happened.