The Product Management Toolkit for Payments: Frameworks That Survive Regulators and Settlement

Product management frameworks were mostly written for software where features are independent, the cost of a feature is engineering time, and the worst outcome of a bad launch is that nobody uses it. Payments breaks all three assumptions. A feature can raise reconciliation load, change fraud exposure and add a licence obligation at the same time; its cost includes operations and compliance; and the worst outcome is money in the wrong place.

The frameworks still work. They need adjustment. This is the toolkit I use at Simpaisa, with the adjustments and the reasons.

Problem framing: the one-page problem statement

Before any framework, a single page: who has the problem, how we know, what it costs them and us, what "solved" would look like as a number, and what we are explicitly not solving. Every other artefact refers back to it.

The payments adjustment: the page must name the money-state implication. If the problem is "merchants wait too long for payouts", the statement has to say whether the solution changes when we fund payouts, from which account, and what happens if a payout precedes settlement. That sentence, written early, prevents the most expensive class of surprise.

Discovery: talk to the exception queue

Standard discovery means customer interviews, usage data and support tickets. In payments, add the reconciliation and exception queues. The operations analyst who clears breaks every morning knows which product rules produce them. The merchant who calls about a settlement mismatch is describing a product defect in accounting terms.

We run a standing monthly review of exception categories with operations, and it has produced more roadmap items than any survey.

Prioritisation: RICE with a risk multiplier

RICE (reach, impact, confidence, effort) is a reasonable starting point, and I have written a full RICE walkthrough for a payments roadmap. The adjustment is that "effort" must include operations and compliance effort as well as engineering, and a fifth factor is needed: risk.

The version we use scores each candidate on regulatory exposure (does it change what the licence or a scheme rule requires), settlement exposure (does it change when or how money moves), and operational load (does it add exceptions). A feature with high scores on those three can have a good RICE number and still be wrong to build next, because the organisation cannot absorb it safely this quarter. Making that explicit in the scoring, rather than in a hallway objection from compliance, is what keeps the roadmap honest.

One real example: a merchant-requested instant payout feature scored well on reach and impact. The risk column showed it would move payouts ahead of settlement for one rail and create a funding gap that treasury would have to cover daily. The adjusted score put it a quarter later, after the settlement timing on that rail was changed. Without the adjustment the feature would have shipped first and the funding gap would have been discovered in production.

Goals: OKRs measured in money state

OKRs work in payments when the key results are the numbers a regulator or a merchant would recognise: authorisation rate, settlement accuracy, time to onboard, fraud loss as a share of volume, straight-through processing rate, exceptions per thousand transactions. They fail when they are borrowed from SaaS: activation, engagement, feature adoption. A merchant does not "engage" with a settlement file. I have compared the two in OKRs for billion-dollar TPV goals versus SaaS.

Our own operating targets over the past few years have been of this kind: onboarding reduced from weeks to hours, straight-through processing at ninety percent, fraud under a tenth of a percent of volume. Each one is a product goal that operations, risk and finance can read without translation.

Requirements: the PRD with a controls section

The product requirements document keeps its usual shape (problem, users, scope, flows, acceptance criteria) and gains one mandatory section: controls. Who can override the behaviour, what is logged, what an auditor would see, what the rollback is. In a regulated product this section is where compliance reviews, and writing it forces the product manager to design the failure path.

I maintain an open-source set of templates and skills for this, Product Manager OS, which includes PRD, decision-memo and launch-readiness templates with the regulated-product sections built in. It is free and plain Markdown.

Decision records: one page per material decision

Problem, options considered, evidence, decision, reasoning, what would change our mind. Stored where the team can find them. This is the artefact that makes a product organisation learn rather than repeat. It is also what a new Director of Product reads first when they join.

Roadmap: two speeds

A payments roadmap has to hold two kinds of work: mandated change (scheme mandates, regulatory deadlines, partner migrations) with dates set by others, and discretionary product work. Mixing them in one prioritised list produces a roadmap where the mandated items always win and the product work is always "next quarter".

The structure that works is two lanes with a fixed capacity split, reviewed quarterly. Mandated work is planned backwards from its deadline; discretionary work is prioritised with the adjusted RICE. The split itself is a decision the executive team makes, with the record of why.

Launch: readiness as a checklist with owners

A payments launch checklist has sections most software launches skip: operations trained on the new exception types, reconciliation rules updated and tested with real files, partner notified and cut-over agreed in writing, compliance sign-off recorded, rollback rehearsed. Each item has a named owner. A launch with an unowned checklist item is a launch with a known gap.

Review: the miss review

Every quarter, one session on the feature that did not move its number. What the decision record said, what actually happened, what we would change about how we decided. This is where product judgment is built. Skipping it because the quarter was busy is the most expensive time saving available.

Tools

The tools matter less than the artefacts. A document system with history for problem statements, decision records and PRDs. The engineering team's tracker for delivery, read by product, not duplicated. A spreadsheet for prioritisation scoring, because every dedicated tool eventually hides the formula. Direct read access to transaction data, because a product manager who has to ask for every number cannot do discovery.

FAQ

What frameworks do product managers use? Problem statements, discovery interviews, prioritisation methods such as RICE, goal frameworks such as OKRs, requirements documents, decision records and launch checklists. Payments product managers adjust prioritisation and goals for regulatory and settlement risk.

What is the best prioritisation framework for a fintech product? RICE with two adjustments: count operations and compliance effort as well as engineering, and add an explicit risk score for regulatory, settlement and operational exposure so that a feature the organisation cannot yet absorb safely is visibly deferred.

What product management tools do you need? A document system with version history, the engineering team's existing tracker, a spreadsheet for scoring, and direct access to product and transaction data. Dedicated roadmap tools are optional.

Are there free product management templates? Yes. Product Manager OS is a free, open-source set of Markdown templates and skills for PRDs, decision memos, launch readiness and other product artefacts, with sections for regulated products.

How do OKRs work for payments products? Key results should be numbers a regulator or merchant would recognise: authorisation rate, settlement accuracy, onboarding time, fraud as a share of volume, straight-through processing. Engagement-style metrics borrowed from SaaS rarely fit.