Product Management Roles, Responsibilities and Skills in a Payments Company
Every product management job description lists the same ten responsibilities. What differs is which ones the company actually holds you to. In payments, it is the ones about money state.
In this essay
Job descriptions for product managers converge on the same list: own the roadmap, talk to customers, write requirements, work with engineering, track metrics, launch things. The list is true and not very useful, because it does not say which responsibilities the company will actually hold you accountable for. This essay is the version I use when hiring and growing product managers at Simpaisa, where product and programme grew from nothing to a team of twenty inside a company of more than fifty.
The responsibilities, ranked by accountability
1. The decision record. For every material product decision, a written statement of the problem, the options, the evidence and the choice. This is the responsibility everything else depends on. A product manager who cannot produce the record for last quarter's decisions is not managing the product; they are attending it.
2. The outcome. Not the launch. The number the launch was supposed to move, reviewed after the launch, including when it did not move. In payments the numbers are authorisation rate, settlement accuracy, onboarding time, fraud loss as a share of volume, and support tickets per thousand transactions.
3. Money state. In a payments product, the product manager owns the definition of what "done" means for a transaction: what the ledger records, when settlement happens, how exceptions are surfaced and to whom. This is the responsibility most product managers arriving from other industries do not expect, and the one that separates people who can run payments products from people who can run products.
4. Discovery. Direct contact with merchants, partners and the operations team who handle the exceptions. Not delegated to research, not replaced by dashboards. The best discovery in a payments company happens in the reconciliation queue.
5. Requirements. Written well enough that engineering can build without a meeting and compliance can review without a translation. In regulated products the requirement includes the control: who can override, what is logged, what the audit trail shows.
6. Sequencing. The roadmap, defended to engineering, sales, finance and the executive team with one argument. Covered in the product management toolkit for payments.
7. Partner and regulator interface. In payments, product managers meet scheme representatives, partner banks and, sometimes, regulators. The job is to translate product intent into the language each of them uses and to bring their constraints back as requirements.
8. Launch and adoption. Coordinating the release, the operational readiness, the merchant communication, and then watching whether it was used.
9. Metrics and instrumentation. Deciding what is measured, making sure it is measured, and reading it weekly.
10. Team growth. For senior product managers: hiring, coaching and building the decision-making capability of the team, so the company's product judgment does not live in one person.
Product management vs product operations
Product operations is the function that keeps the product machine running: tooling, process, data hygiene, release coordination, feedback routing, documentation. It exists so product managers can spend their time on decisions rather than on the mechanics of decision-making.
The boundary that works: product operations owns how the product team works; product management owns what the product team decides. When product operations starts owning decisions, the company has two product teams. When product management spends its week on release checklists and dashboard maintenance, the company has none.
In a payments company, product operations also tends to own the interface with the operations floor: exception categories, support tooling, the feedback loop from reconciliation into the roadmap. That is valuable precisely because it feeds responsibility three and four above.
Product management vs business analysis
A business analyst gathers and documents requirements from stakeholders and hands them to a delivery team. A product manager decides which requirements should exist. The business analyst asks "what do you need"; the product manager asks "what problem are we solving, and is this the right way to solve it".
In practice the roles overlap heavily in banks and large enterprises, where the "product" is often a system with internal stakeholders and the business analyst is the closest thing to a product owner. In a fintech, the roles separate: the product manager owns the decision and the outcome, and analysis is a skill the product manager uses rather than a job someone else does.
The skills matrix
This is the matrix I use for hiring and development conversations. Each skill is rated from one (can follow) to four (can teach), and the levels expected differ by seniority.
| Skill | What "good" looks like | Weight in payments |
|---|---|---|
| Problem framing | Writes a one-page problem statement others can disagree with precisely | Core |
| Evidence gathering | Runs discovery with merchants and operations; reads transaction data directly | Core |
| Decision writing | Produces the decision record with options and reasoning | Core |
| Domain: money movement | Can trace a transaction through authorisation, clearing, settlement and reconciliation | Core, payments-specific |
| Domain: rules and regulation | Reads a scheme bulletin or regulatory circular and derives product requirements | Core, payments-specific |
| Technical literacy | Reads an architecture diagram and an API contract; understands the trade-offs engineers present | Core |
| Sequencing and trade-offs | Defends a roadmap order with one argument across audiences | Core |
| Risk judgment | Asks "what happens when this fails" before "what happens when it works" | Core, payments-specific |
| Communication upward | Briefs an executive in two minutes with the decision, the risk and the ask | Senior |
| Partner management | Runs a scheme, bank or PSP relationship with clear commitments both ways | Senior |
| Team building | Hires, coaches and delegates decisions with a clear boundary | Lead and above |
The three payments-specific rows are what I test hardest in interviews, and they are where candidates from consumer software most often score low. They are learnable; the twelve interview questions I use show how we probe them.
What the interview actually tests
Beyond the matrix, a payments product interview tests four things, usually with a case.
Can you find the money-state question in an ordinary feature request? Given "merchants want instant payouts", a strong candidate asks about settlement funding, partner cut-offs and what happens when a payout is sent before the underlying transaction settles.
Can you sequence under an external constraint? Given a regulatory deadline and a revenue feature, a strong candidate does not pick one; they find the version of each that fits, and names what is being given up.
Can you say no with a reason that survives the sales call?
Can you describe a decision you got wrong, what the record said at the time, and what you would change in how you decided, rather than what you decided?
FAQ
What are the main responsibilities of a product manager? Deciding what gets built and in what order, gathering the evidence for those decisions, writing them down for engineering and other functions, launching the result and reviewing whether it moved the intended outcome. In payments, defining money state for each transaction is added to that list.
What skills does a product manager need? Problem framing, evidence gathering, decision writing, technical literacy, sequencing and trade-offs, risk judgment and communication. Payments adds domain skills: tracing money movement and reading scheme rules and regulation.
What is the difference between product management and product operations? Product operations owns how the product team works (tooling, process, data, release coordination). Product management owns what the team decides. The two support each other and should not overlap on decisions.
Is a business analyst the same as a product manager? No. A business analyst documents requirements from stakeholders. A product manager decides which requirements should exist and is accountable for the outcome. The roles overlap more in banks and large enterprises than in fintechs.
How do I prepare for a product manager interview in fintech? Be ready to trace a payment end to end, to derive a requirement from a regulatory constraint, to sequence a roadmap under a fixed deadline, and to describe a decision you got wrong in terms of how you decided rather than what you chose.
Closing thought and further reading
Every product management job description lists the same ten responsibilities. What differs is which ones the company actually holds you to. In payments, it is the ones about money state.
Building through similar complexity?
Discuss the operating decisions behind the essay, or explore where my experience can help.


