Engineers usually tuck banking experience at the bottom of a résumé, slightly embarrassed. I do the opposite. More than three years with clients at BPS-Sberbank and MTBank gave me something no documentation teaches: a feel for where a product hurts.
Objections are free research
A client relationship manager spends the day hearing why a product doesn't fit. "Too expensive." "I don't get it." "What happens if…" "Last time someone told me something else." At first you treat this as objection handling. Then you notice the same questions coming back, and they stop being objections. They become a list of product gaps.
Product teams pay researchers to build that list. At a bank branch it walks in on its own, every day, in person. I didn't call it customer discovery back then, but that's what it was.
Complaints teach honesty
Complaints are the least pleasant part of the job and the most useful. Behind almost every complaint there's no "difficult customer" — there's a surprise. Someone expected one thing and got another. A surprise involving money is the worst kind.
That turned into a rule I carried into the platform I build now (a B2C home-services product, name under NDA): no surprises on the bill. Prices are published upfront and computed from clear parameters. Extra work happens only after the customer approves it in their account. Not "we did it and billed you", but "we offered, you confirmed".
KPIs are about systems, not heroics
I was named MTBank's top employee by annual KPI. The main lesson I took from it: a metric is the sum of many small actions, not one heroic push. Results hold when the right actions become habits rather than efforts.
Products work the same way. A metric on its own means nothing. What matters is which actions move it, and building the product so those actions are easy — for the customer, the specialist and the operator.
Finance is a language
My degree is in finance: Belarus State Economic University, Finance and Banking. In engineering it pays off every time I need to describe how money moves through a product.
Charge now, or place a hold and capture later. Refunds. Payment disputes. A commission model where the company collects the payment and pays out the specialist's share. Discounts that come out of the platform's share, not the specialist's. To an engineer without a finance background, that's a pile of edge cases. To me, it's an ordinary model that needs to be carefully moved into the database.
What I brought into the product
In short:
- customers should never be the last to learn about a problem — statuses and notifications beat pretty screens;
- the price should be clear before the order, not after;
- operators are users too, and a clumsy back office costs money every single day;
- money isn't a form field; it's a process with rules, and those rules should live in one place.
Instead of a conclusion
I don't see banking as "lost years" before engineering. Those were the years I looked at products from the customer's side of the counter. Now I build them, and I try to leave that side of the counter with fewer reasons to complain.