Abhijit Dey: How to Become an AI Product Manager in Fintech

Abhijit Dey - on becoming a Fintech PM

Abhijit Dey - on becoming a Fintech PM

I interviewed Abhijit Dey, fintech product leader and co-author of Building AI-Powered Financial Products.

Building an AI-powered financial product requires more than adding an LLM or an AI agent to an existing workflow. Product managers have to determine whether the problem needs AI in the first place, how to evaluate probabilistic outputs, and whether the solution can deliver measurable business value.

Abhijit believes these decisions require a different approach to product management, particularly in a regulated industry like banking.

We discussed how a product manager’s role changes when building AI products, using an AI-powered financial advisor as our running example. We also explored when to use traditional software instead of AI, how to design AI evaluations, why compliance needs to be involved from the beginning, and which technical skills product managers need to develop.

Use the links below to jump directly to the topics that interest you.

How AI changes the role of a fintech product manager

Manu: A traditional fintech product manager needs strong domain knowledge in areas such as lending or payments, along with product discovery skills and experience delivering financial products.

But when the products themselves are AI-powered, how does the product manager’s role change?

Abhijit: Over time, product management has developed into several specialized functions, including API product management, technical product management, and content product management.

But AI product management is different.

In traditional banking products, a product manager might focus on understanding the business and translating requirements into product features without needing deep technical knowledge.

For example, you’ll see product managers working on credit cards, lending, or payments. They need to understand the business and translate business requirements into product requirements.

But in AI, it’s different.

You need to understand AI itself.

I’ve seen people move from project management into product management relatively quickly. Someone might have spent six months delivering a credit-card feature for a mobile app, developed their product-management skills, and transitioned into a product role.

I’m not saying that negatively. It’s an observation, and it’s good that people can make that transition.

But AI product management requires something different.

You need to spend time understanding AI because AI is fundamentally about probabilistic theories.

If you’re genuinely an AI product manager, your ideation and your ability to think through a problem should include an understanding of probabilistic systems.

That’s why I believe AI product management is a specialized discipline.

Manu: Let’s say I’m a traditional customer-facing product manager at a bank, mainly working on feature delivery.

What skills should I start acquiring to move into AI product management?

Abhijit: First, you need to understand whether you really need AI.

That’s the most important thing.

In any type of product management, whether it’s AI, API, or something else, you begin by identifying a problem.

Then you map a solution to that problem, build it, and validate whether it works.

That’s the basic chronology of product management.

In AI, the first step is the same. You identify the problem.

But before you start building the solution, you need to validate whether the problem actually requires AI.

I think this is something that’s been missed over the last year or so.

I’ve seen many startups and fintechs approach organizations and say, “We know you have this problem, and we have an AI solution for it.”

That’s good. People are investing their time and trying to innovate.

But AI is not a magic wand that you can use for every problem.

And it’s a very costly magic wand.

AI has always existed, but with all the excitement around generative AI and agentic AI, the economics of experimentation have changed.

Earlier, you could run many experiments in an innovation environment, knowing that only a small percentage would succeed.

But now you also have token costs, model costs, and other operating expenses to consider.

AI costs are also affected by geography and changes in the broader technology environment.

So before you build anything, be absolutely certain that you need AI to solve that problem.

Otherwise, you might end up creating something that remains at the proof-of-concept stage.

Everybody might say it’s a great idea, but nobody will put it into production.

That’s why I tell product managers to develop their own mental framework.

As a product manager, you should develop your own framework for evaluating whether a problem requires AI. When someone presents a problem, you should be able to assess whether AI is appropriate before taking the idea through your organization’s formal evaluation process.

Because even spending one or two weeks creating a proof of concept has a cost. Eventually, all of that contributes to your operating expenses.

How to decide whether a problem actually needs AI

Manu: Let’s make this more concrete.

Suppose a wealthtech company wants to build an AI-powered financial advisor.

In traditional product management, we’d start with customer discovery, interviews, and understanding the customer’s problems.

Does that process change when we’re building an AI product?

Abhijit: That’s a good example.

Let’s say a bank is building an AI-powered financial advisor.

What does a financial advisor do?

A financial advisor is someone you can approach with your financial problems. You expect that person to give you a solution.

Whether that solution is right or wrong is a separate question. But your expectation is that you’ll get some advice.

Now, before building an AI-powered advisor, you need to identify the kinds of problems customers are likely to bring to it.

Then you need to separate those problems into two categories.

Which are deterministic, and which are probabilistic?

Let me give you an example.

In India, because of UPI, the number of transactions appearing on bank statements has increased significantly.

People use UPI to pay even five rupees. As a result, customers have many more transactions to look through.

Now suppose I ask my financial advisor, “How many times did I travel with Uber last month?”

Or, “How much money did I spend on travel?”

This is a deterministic problem.

You might use natural language processing to understand the question and convert it into a SQL query.

But once you’ve done that, you don’t need AI to calculate the answer.

You know where the data is.

You run the query against the database, retrieve the information, and display the result.

The business logic is known, and the answer can be calculated.

Now consider a different question.

“How can I save 10% of my monthly expenses?”

Let’s say I spend ₹150,000 a month, and I want to bring that down by 10%.

That’s a different problem.

Nobody can guarantee that if you follow a particular set of recommendations, your spending will fall by exactly 10%.

You need to analyze spending patterns, understand behavior, and identify opportunities.

For example, the system might notice that I have subscriptions I’m not using.

Maybe I have duplicate subscriptions, or services that automatically renew every month.

We often subscribe to something and then forget about it.

The system could identify those subscriptions and suggest which ones I might consider cancelling.

That’s the kind of problem where probabilistic AI becomes useful.

You could also have more complex questions.

Suppose you’re standing in an Apple Store looking at an iPhone and want to know what the final price would be if you purchased it using a particular credit card.

The answer might depend on the card’s offers, discounts, and other conditions.

Or you might ask how to reduce your spending on an upcoming vacation.

These questions can involve several pieces of information and different possible recommendations.

So the first thing I would do is segregate the problem statements into deterministic and probabilistic ones.

If a problem is deterministic, try not to use generative AI unnecessarily.

You know where the data is, you know the business logic, and you know how to retrieve the answer.

Use AI when the problem requires additional intelligence or reasoning.

Manu: So identifying deterministic and probabilistic problems is the first step.

What comes next?

Abhijit: Next comes solution design.

Once you’ve identified that a problem requires probabilistic AI, you need to decide what kind of AI solution it needs.

Do you need a traditional machine-learning model?

Do you need an LLM?

Or do you actually need an AI agent?

Those are different things.

Let’s return to the financial-advisor example.

Suppose I ask, “How can I save 10% of my monthly expenses?”

The system might identify unused subscriptions, duplicate subscriptions, cashback offers I’m not using, or other spending patterns.

Now suppose I want to go one step further.

I want the advisor to cancel those duplicate subscriptions for me.

That’s where an agent comes in.

The agent is no longer just providing information or recommendations. It’s performing an action.

I’ve heard people say they want to build an AI agent to recommend the best credit card for a customer.

But do you really need an agent for that?

A credit-card recommendation might be based on matching a product with a customer’s profile and preferences.

You might be able to solve that using a relatively straightforward recommendation model.

You don’t necessarily need an agent.

An agent becomes useful when you have a complex task involving multiple steps and decisions at different stages.

You have a workflow with several nested decisions, and the system needs to take actions as it progresses.

That’s where I would consider using agentic AI.

Once you’ve decided on the appropriate solution, you design it, test it in a small proof-of-concept environment, and scale it gradually.

But there’s another important thing I believe product managers should introduce very early in this process.

An AI evaluation framework.

Why AI evaluations belong in the product lifecycle

Abhijit: I think one mistake organizations make is not having an AI evaluation framework.

Building an enterprise-wide evaluation framework is difficult. It’s an uphill task.

But you cannot ignore it.

As a product manager, I believe it’s your responsibility to have an evaluation framework ready, at least for your own product or area.

From the first day of development until production, you should be measuring every step and every change.

Otherwise, you’ll just keep building.

At some point, you might find that the model or LLM is driving your decisions rather than you evaluating what it’s producing.

That’s why I believe an evaluation framework should come into the product lifecycle at the second or third step.

You design the solution, test it, evaluate the results, and scale gradually.

And before you move into production, you need to establish the commercial value.

What benefit is the product producing?

Can you translate that benefit into financial terms?

If you can’t, it might be a very good innovation project, but for the organization, its value could be zero or even negative.

You also have to consider that AI costs can change.

So identifying the commercial value before going live is extremely important.

Manu: I want to focus on the AI evaluation framework.

Even with our financial-advisor example, there could be many edge cases. The product manager needs to identify those cases and build test datasets to evaluate the AI system.

What skills do product managers need to develop to do this properly?

Abhijit: When we design AI evaluations, we often try to create a matrix.

But a matrix alone will not always work.

When you’re dealing with probabilistic AI, you have to observe how the model responds to the same or similar prompts.

Let me explain.

If I ask you your name, you’ll tell me your name.

If I ask you again, and then a third or fourth time, your answer should remain the same.

But your tone might change.

You might sound a little irritated or respond in a different way.

Generative AI can also respond differently to similar prompts.

The tone, format, and wording might change.

But the core answer should remain consistent.

That’s what your evaluation framework needs to identify.

You need to evaluate the core answer, not just the way it’s presented.

Let’s take our financial-advisor example again.

I ask the model, “How can I save 10% of my monthly expenses?”

The model analyzes my spending and says I’m spending too much on entertainment, including movies and restaurants.

It might identify that I’m spending a significant part of my monthly budget on entertainment and suggest reducing that expense.

It might also identify cashback offers available through my credit card that I’m not using.

Now I ask the same question again, but I phrase it slightly differently.

“How can I spend 10% less every month?”

The wording of the response might change.

The model might explain the recommendation differently or use a different tone.

That’s fine.

But the underlying numbers and facts should remain consistent.

Suppose the first response says I spent ₹15,000 on entertainment.

Then the second response, using the same underlying data, says I spent ₹12,000.

That’s a problem.

The model is giving inconsistent information.

Your evaluation framework needs to identify that.

It should check the percentages, amounts, categories, and other quantifiable details.

If the model refers to entertainment expenses, travel expenses, or cashback offers, you need to verify those details against the underlying data.

An evaluation framework cannot be just an abstract matrix.

It needs to identify the exact content and the quantifiable information in the response.

That’s how you start determining whether the model is behaving correctly.

Bringing compliance into AI product design

Manu: We’ve discussed how product managers can evaluate whether an AI-powered financial advisor gives accurate answers. But in banking, those answers also need to meet regulatory requirements.

In your book, you emphasize involving compliance early in AI product development. At what stage should product managers bring compliance into the process?

Abhijit: In a heavily regulated industry like banking, everything has to go through compliance.

You need to bring compliance into a pivotal role.

You cannot build things in silos.

Think about the difference between asking an LLM a question on your personal laptop and asking your bank for financial advice.

If you’re using an LLM personally and asking about your finances, that’s one thing.

But when a customer asks their bank about their spending, financial position, or other financial matters, the bank is accountable for the information and advice it provides.

So compliance needs to be in a central position from the beginning.

Let’s return to the financial advisor.

It sounds impressive if the system can tell you how to save 10% of your monthly expenses.

It sounds impressive if it can analyze your transactions and tell you that you’re spending too much at McDonald’s or KFC.

But is the bank in a position to make those statements?

How do you ensure that the information is correct?

How do you ensure that the recommendation stays within the limits of the applicable regulations?

These are questions compliance needs to be involved in answering.

You can’t bring compliance in only after you’ve built the product.

We’re seeing regulators across different geographies develop frameworks for responsible AI.

In India, for example, the RBI has been working on its AI framework and the seven guiding principles, or sutras.

Who translates those regulatory expectations into requirements for the business and the AI product?

You need compliance professionals who can interpret those guidelines and work with the product and technology teams.

One positive change I’ve noticed is that risk and compliance professionals are becoming more digitally aware.

Earlier, they were often focused primarily on their traditional risk and compliance responsibilities.

Now many are also trying to understand how digital business models and technology work.

That combination is important.

You need people who understand regulatory requirements and can translate them into the way an AI product is designed and operated.

That’s why I gave compliance such an important role in the book.

Measuring business value and customer engagement

Manu: Let’s look at another challenge with an AI-powered financial advisor.

How do we ensure that the advisor prioritizes the customer’s interests instead of recommending products that generate more revenue for the bank?

That brings us into AI ethics. How should financial institutions think about this?

Abhijit: That’s a basic principle for any organization.

You want to build things that generate revenue, but you also need to ensure that customer satisfaction doesn’t decline.

If you ask me, an AI-powered financial advisor like the one we’re discussing is more of a good-to-have feature than a must-have feature.

You cannot automatically assume that building it will translate into direct revenue.

There’s no assurance of that.

What you’re really doing is creating another engagement point for the customer.

Let’s say a customer normally logs into their banking app two or three times a month.

They might check their balance, review transactions, or make a payment.

In India, people are also using UPI apps for many everyday payment activities, so they may not need to open their bank’s app as frequently.

But now suppose the bank has a financial advisor inside the app.

The customer can ask questions about their spending, savings, and other financial matters.

They might start using the banking app more frequently.

That increases digital engagement.

And banks want customers to be more digitally engaged because engaged customers may be more likely to maintain their relationship with the bank.

Not every increase in engagement can immediately be translated into revenue.

But over time, it can contribute to business value.

That’s how I would look at this use case.

You also have to ensure that the experience is actually useful.

If a customer asks how many Uber transactions they’ve made and your system doesn’t give them a satisfactory answer, why would they come back?

So you need to measure the quality of engagement.

Let’s say when you launch the advisor, customers ask an average of two questions.

Thirty days later, the average has increased to five.

That’s one indication that engagement is growing.

You should also measure NPS, customer responses, and feedback.

You need a feedback loop.

Those are some of the ways you can measure whether the feature is creating value.

And when you know a feature isn’t producing direct revenue, controlling its running cost becomes even more important.

For example, if a customer asks the same question repeatedly, do you really need to call the LLM every time?

You could use a semantic layer or the system’s own memory to retrieve an answer instead of repeatedly invoking the model.

That helps reduce costs.

So it’s a balance.

You need to improve engagement and customer satisfaction while making sure the economics of running the feature remain sensible.

Who owns AI evaluations, product outcomes, and technical decisions?

Manu: An AI product has both business metrics and AI evaluation metrics. How should responsibility for those metrics be divided between the product manager, AI engineers, business teams, and compliance?

Abhijit: There should be a division of responsibilities.

The AI evaluation framework should be designed by the AI product manager.

The implementation should be done by the AI engineers.

Revenue tracking and other product performance metrics should remain with the product manager.

Business teams also play an important role because they’re the ones meeting customers.

They understand the problems customers are facing and can help identify the problem statements.

Risk and compliance should be in a central position.

They need to have oversight and control across engineering, product, and business activities.

I would say the AI product manager should work as the core coordinator between all these stakeholders.

But the DNA, or the nucleus, of the AI product or feature should be owned by the product manager.

That includes responsibility for designing the evaluation framework.

Manu: How technical does an AI product manager need to be?

Do they need to understand the underlying models and write code, or is it enough to understand how the different components work together?

Abhijit: I wouldn’t say they need to be deeply technical in the sense of writing Python code.

That’s not necessarily required.

But they should have a clear understanding of the workflow.

They should understand the use cases for different components and know where each one fits.

For example, they should know when to use a semantic layer, when to use memory, when retrieval-augmented generation makes sense, and when other technologies are appropriate.

They should be familiar with these concepts.

They also need a clear understanding of AI evaluation frameworks.

That clarity is very important.

Manu: For a traditional fintech product manager who wants to transition into AI product management, would building a small AI product or prototype help them gain hands-on experience?

Especially if they don’t yet have experience delivering AI products in a real organization?

Abhijit: I don’t think that would be a problem.

If someone already has strong product-management skills and understands how the different AI components work, they can make that transition.

They need to understand where those components should be used and how the system should operate.

They also need to understand what is permissible within the relevant guidelines.

But they don’t necessarily need to know how to write the code themselves.

The important thing is understanding the product, the workflow, and the technology well enough to make the right decisions.