The Biggest Mistakes Product Managers Make in Payments

The mistakes in product management books (building without talking to users, shipping without metrics, saying yes to everyone) are real and I have made most of them. The mistakes that actually hurt in payments are a different list. They are the ones where the feature worked exactly as designed and the money did not. This is that list, from running product at a payments infrastructure company through five market launches and the reconciliation queues that followed each one.

1. Shipping the screen without the money state

The success page shows, the merchant is happy, and three days later the settlement file does not match. The feature defined what the customer sees and left what the ledger records, when settlement happens and how exceptions surface to be worked out later. Later is production.

What to do instead: every requirement that touches a transaction states the money state at each step and who reconciles it, before engineering starts.

2. Treating scheme rules and regulations as someone else's requirements

A product manager hears "compliance needs this" and adds it to the backlog as a chore. Scheme rules, central-bank circulars and licence conditions are requirements with an external owner, and they are product surfaces: how a control is implemented decides whether it becomes a manual queue or a feature. Delegating them means the product is designed by whoever in compliance had time that week.

3. Optimising authorisation rate without owning the loss

Raising approval rates is the most satisfying number in payments, and the easiest to raise badly: loosen a rule, watch authorisations climb, watch fraud and chargebacks arrive sixty days later in a different team's report. The product manager who owns the conversion number must own the loss number, on the same page, or the first will be bought with the second.

4. Letting the roadmap become the sales queue

The largest merchant wants a feature; the sales team promises it; the roadmap rearranges. Six months later the roadmap is a list of one-off features for six merchants, and the product has no shape. The fix is not to refuse sales; it is a prioritisation framework with a risk column that every request passes through, and a written record of why each one landed where it did.

5. Designing only the happy path

Payments products fail in the exception paths: the payout that fails after the balance was debited, the refund on a transaction that has already settled, the partner that returns an unknown response code. A product manager who designs the success flow and leaves failures to engineering will get failures handled however engineering guessed. Design the failure path with the same care, and decide what the customer is told.

6. Mistaking a partner integration for a product

Connecting a new rail or wallet is an integration. Running it as a product means owning its success rate, its cut-offs, its failure reasons, its cost per transaction and its reconciliation, and knowing when to route away from it. Teams that treat integrations as done at go-live accumulate a portfolio of rails nobody watches.

7. Onboarding faster than you can underwrite

Merchant onboarding time is a real competitive metric; we cut ours from weeks to hours. The mistake is to automate onboarding before the risk rules are written, so that speed is achieved by skipping the checks rather than by encoding them. Our automation worked because the risk team wrote tier rules first and product then reduced the touchpoints around them. Reverse that order and the fraud arrives with the growth.

8. Measuring in SaaS metrics

Activation, engagement, retention, feature adoption. Borrowed from software, meaningless for a settlement file. Merchants do not engage with a payout; they receive it or they do not. The numbers that matter are authorisation rate, settlement accuracy, time to onboard, fraud as a share of volume, straight-through processing, exceptions per thousand transactions. A product manager who cannot state last month's values for those is not yet managing the product.

9. Learning about operations from the incident

Product managers who have never sat with the reconciliation team, never watched an exception being cleared, never taken a merchant call about a mismatch, design products that generate all three. The exception queue is the best discovery tool in a payments company and it costs nothing to attend.

10. Not writing the decision down

The most general mistake and the root of several above. A decision made in a meeting, without the options, the evidence and the reasoning recorded, cannot be reviewed when it turns out wrong, and will be re-argued every time a new stakeholder arrives. The decision record is thirty minutes of work that saves quarters.

The pattern underneath

Every item on the list is the same mistake in a different costume: treating a payments product as a piece of software with money attached, rather than as money movement with software around it. The product managers who do well in payments are the ones who reverse that, ask "what happens to the money when this fails" before anything else, and treat operations, risk and compliance as designers rather than reviewers.

The companion essay, why fintech products fail, covers the same failure modes at the level of whole products and companies.

FAQ

What is the biggest mistake product managers make? In payments: defining what the customer sees without defining what happens to the money at each step. The feature works, the settlement does not, and the cost lands in operations weeks later.

What are common product management mistakes? Shipping without money state, treating regulation as someone else's requirement, optimising conversion without owning loss, letting the roadmap become a sales queue, designing only the happy path, measuring in borrowed SaaS metrics, and not recording decisions.

How do product managers avoid mistakes? Write the money-state implication into every requirement, design the failure path with the success path, own conversion and loss on the same page, pass every request through a prioritisation framework with a risk column, spend time in the exception queue, and keep a decision record.

Why do product managers fail in fintech? Most often because they bring consumer-software habits (speed, engagement metrics, happy-path design) to a domain where money state, external rules and failure handling decide the outcome.

What should a new payments product manager learn first? How to trace a transaction from initiation through authorisation, clearing, settlement and reconciliation, and who holds the money at each step. Everything else in the role builds on that.