Product Manager, Core Payments - Remote or Europe) · Junior to Mid level (Clone

About Gr4vy

Gr4vy is the cloud-native payments infrastructure platform that gives merchants the flexibility to build, manage, and scale their payments stack without the complexity. Our customers include some of the world's most recognisable brands across travel, non-profit, retail, and digital goods, and we work alongside leading PSPs, schemes, and fraud providers to power their payment flows globally.

We're hiring a Product Manager to own our core payments product, and to be the person the rest of the company asks when they need an answer about how payments actually work on our platform.

The surface area is the payment itself and everything immediately around it: the authorisation lifecycle - authorisation and its variants, capture, void, refund - 3DS and SCA, tokenisation and wallets, pay-by-bank, risk and anti-fraud services, the checkout experience merchants embed in their own sites and apps, and the data we carry on a transaction. It is the part of Gr4vy that merchants touch most, and the part where the details are least forgiving.

Your job is to decide what gets built here, write it down well enough that engineers can build it without asking you what you meant, and keep the roadmap honest about what will land and when. You'll run the planning cadence with the engineering leads you work with, shape ideas through discovery and sizing, and write the specifications yourself.

This is a hands-on product role on a small team. There is no product ops function, no BA writing your tickets, and no analyst preparing your case. You will read the payment provider's documentation, read enough of our code to check whether what you're proposing is true, and then write the thing. If you want a role where you brief other people to do that work, this isn't it.

** What sits outside this role.

Our connector portfolio - building and pricing new payment provider integrations - is scoped as a separate product area. You'll work with it constantly, because much of what you specify touches an integration, but that backlog isn't yours. Company-level product strategy and pricing stay with the CPO.

* Reporting line: *

reports to the Chief Product Officer. You'll work daily with engineering, delivery, and design, and with the Solution Engineering, Support, and Commercial teams.

• Own a live roadmap for your product area: shaping ideas from first request through discovery, sizing, commitment, delivery, and release.
• Make the calls that come with it - sizing work, setting what we commit to versus what stays exploratory, and shelving things with a written reason rather than letting them rot in the backlog.
• Keep delivery dates current, and tell people early when they move. We would rather hear a date slipped in week one than discover it in week six.
• Decide priority when two pieces of regulatory work collide, and be able to write down what the trade-off costs. That happens more often than you'd think.

• Write the product specs and the engineer-facing tickets yourself, to a standard where a new engineer can pick one up cold and build it correctly.
• Cite primary sources. If a spec turns on what the EMVCo 3DS specification says, or what a provider's docs claim, quote it and link it.
• Write an explicit "not in scope, and why" section on everything. Silent omissions cause more rework here than wrong decisions do.
• Name the risk that argues against shipping, when there is one. We would rather ship a smaller thing with clear eyes than a bigger thing on optimism.
• Check your claims against the codebase before you write them down. You don't need to be able to build it; you do need to be able to tell whether it's already half-built.

• Run sprint planning with the engineering leads you work with: assess how the sprint actually went against its goals, then set the next sprint's goals in terms of specific work items.
• Write the planning update - the one where everyone finds out what happened and what's next.
• Make sure committed work has groomed, refined tickets waiting before the sprint it's committed to starts. This is the single most common way a sprint goes sideways.
• Work with delivery on capacity, velocity, and what gets dropped when the numbers don't work.

• Be the front door for product questions on your surfaces from Support, Solution Engineering, Customer Success, and Commercial - and give answers that stick, in writing, in the channel where they were asked.
• Join merchant and provider calls when a question needs a product answer rather than a support answer.
• Turn recurring merchant asks into roadmap items with real demand attached, rather than a wishlist.
• Write the public release notes for what you ship, and work with Marketing on anything that needs more than a note.

• Real payments depth. You can hold a detailed conversation about the card lifecycle - authorisation, incremental authorisation, re-authorisation, full and partial capture, void,…