What Is Product Management? A Payments Operator's Definition

Product management is the discipline of deciding what a company builds, in what order, for whom, and then being accountable for whether it worked. The product manager does not write the code, close the sale or run the servers. The product manager owns the decision and the outcome.

That is the short definition. The rest of this essay is about what the definition means in practice, and what changes when the product moves money.

The three questions a product manager owns

Every product decision reduces to three questions, and the product manager is the person accountable for answering them together rather than one at a time.

Is it worth doing? Which customer problem is being solved, how many customers have it, and what happens to the business if it is solved. This is the value question. In consumer software it is usually answered with usage data and research. In payments it is answered with volume, take rate, risk exposure and, very often, a regulator's opinion.

Can it be done? What the engineering, operations, compliance and partner constraints are, and what the honest cost is. A product manager who cannot read an architecture diagram or a scheme bulletin will be told what is possible by people who each see one part of the picture.

Should it be done now? Sequencing. Every roadmap is a list of things that were not built so that something else could be. The product manager owns the order and has to defend it to engineering, sales, finance and the executive team with the same argument.

Everything else in the job, from writing requirements to running discovery interviews to reviewing metrics, exists to answer those three questions well.

What product management is not

The definition gets clearer at the edges.

Product management is not project management. A project manager delivers a defined scope on a date. A product manager decides what the scope should be and stays accountable after the date. The two roles overlap in a small company and separate as it grows; the difference is covered in program versus product management in fintech.

It is not product marketing. Marketing decides how the product is described and sold. Product decides what it is.

It is not being the boss of engineering. Engineers do not report to the product manager in most companies. The product manager leads through the quality of the decision and the evidence behind it, which is harder and, in the long run, works better.

It is not a ticket-writing service for sales. The fastest way to destroy a product is to let the roadmap become a queue of whatever the last prospect asked for. Part of the job is saying no with a reason.

What changes when the product moves money

I run product at Simpaisa, a payments infrastructure company operating in five regulated markets, and most of what I learned about product management in ecommerce and streaming still applies. Three things do not.

Money state is part of the product. A feature is not finished when the customer sees a success screen. It is finished when the ledger, the settlement file, the partner's records and the merchant's dashboard agree about what happened. A product manager who ships the screen and leaves the reconciliation to operations has shipped half a product, and the half that is missing is the half that generates support tickets, chargebacks and audit findings.

Some requirements are not negotiable. A scheme rule, a central bank circular or a PCI DSS control is a requirement with an external owner. You cannot trade it against a feature. What you can do is decide how it is implemented, how much of it becomes a product surface rather than a manual process, and what order it lands in. That is still product work, but the framing is different.

The cost of being wrong is asymmetric. A bad checkout flow loses conversion. A bad settlement rule loses money that has to be found, explained and sometimes returned. Product managers in payments learn to ask "what happens when this fails" before "what happens when this works", and to build the failure path as carefully as the happy path.

A day in the role, honestly

The textbook says a product manager spends the day on strategy, discovery and roadmaps. The real day in a payments company looks more like this.

A merchant's settlement did not match their expectation and the account team wants an answer. That is a product question, because the rule that produced the number is a product rule.

A partner bank has changed a limit and engineering wants to know whether to hard-code the new value or build configuration. That is a product decision about how much operational flexibility is worth.

A regulator has published a consultation and compliance wants product's view on what would have to change. That is a roadmap conversation with a deadline set by someone else.

Somewhere in between, the discovery interviews, the metrics review and the roadmap document happen. The job is to keep the long-term questions alive while the short-term ones keep arriving.

How to tell whether product management is working

Three signs, in order of how early they show up.

Engineers can explain why they are building what they are building, in customer terms, without asking. That means the decision reached them with its reasoning intact.

The roadmap changes for reasons that are written down. A roadmap that never changes is not being tested against reality; one that changes without recorded reasons is being pushed around.

Outcomes are reviewed, including the misses. In our own product reviews the most useful thirty minutes of any quarter is the one spent on the feature that did not move the number, and why.

FAQ

What does a product manager actually do all day? Decides what gets built and in what order, gathers the evidence for those decisions, writes them down so engineering can act on them, and reviews whether they worked. In payments, a large share of the day is spent on questions about money state and partner constraints that turn out to be product questions.

Do you need a technical background to be a product manager? Not a computer science degree, but you need to read an architecture diagram, understand an API contract and follow an engineering trade-off. In payments you also need to read scheme rules and regulatory circulars, which is a different kind of technical literacy.

Is product management the same in fintech as in other software? The core is the same: value, feasibility, sequencing. The differences are that money state is part of the product, some requirements have external owners, and failure is more expensive than a lost conversion.

How is a product manager different from a project manager? A project manager delivers an agreed scope by a date. A product manager decides the scope and remains accountable for the outcome after delivery. See program versus product management in fintech.

What is the first thing to learn if I want to become a product manager? How to write a decision down with its evidence and its alternatives, in one page, so that someone who disagrees can see exactly where they disagree. Everything else builds on that.