There's a gap opening in AI product management that nobody is talking about. On one side, you have technologists who understand transformer architectures and prompt engineering but have never operated the business processes they're automating. On the other, you have operators who understand the business deeply but view AI as a black box they need to "adopt." The best AI products won't be built by either group. They'll be built by operators who crossed the technical divide.
I know this because I lived the transition. I spent seven years as the person in the operations chair: managing €2B in receivables, reconciling cash flows across 10 countries, building the data infrastructure that supported €1.3B in fundraising. Then I moved into AI product management. The difference in how I design AI products compared to someone who came from pure tech or pure PM is not subtle. It's fundamental.
The Knowledge Gap That Kills AI Products
Most AI PMs working on financial automation have never reconciled a bank statement. They've never stared at a payment that doesn't match any invoice and had to figure out why. They've never explained to a CFO at 9pm why tomorrow's cash position is €3M lower than forecast.
This matters more than it should.
When you design an AI agent for cash application without operational experience, you focus on the obvious: match the payment amount to the invoice amount. 1:1 matching. That handles maybe 60% of cases. But the remaining 40%? That's where all the value is, and it's where pure technologists fail.
A client pays €47,250 against an invoice of €47,500. Is it a partial payment? A discount taken? A bank fee deduction? A currency rounding issue? The answer depends on the client's history, the payment terms, the country's banking norms, and whether your sales team offered an informal discount that nobody documented. An operator knows to check all of these. A technologist builds a threshold tolerance of ±1% and calls it done. One approach resolves 95% of exceptions. The other creates a permanent queue of unresolved items that grows every month.
Three Things Operators See That Technologists Miss
1. The workflow behind the workflow
Every process has an official version and an actual version. The official version lives in the process documentation. The actual version lives in the heads of the people doing the work.
When I managed collections across 10 countries, the official process was: send automated reminder at 30 days overdue, escalate to phone call at 60 days, send formal notice at 90 days. Simple. Clean. And almost completely wrong in practice. In Spain, the first 30 days were meaningless because most companies paid at 60-90 by cultural norm. In the UK, a phone call at day 45 was more effective than any automated reminder. In Germany, the formal notice needed to reference specific legal clauses or it was ignored.
If you design an AI collections agent based on the official process, you build a system that sends the wrong message, at the wrong time, through the wrong channel, in every country. Operators know the real workflow. That knowledge is the difference between an AI agent that actually reduces DSO and one that generates noise.
2. Where the data lies
Not "where the data is." Where it lies.
I discovered a €25M discrepancy between our forecast model and actual collections. The data was technically correct: every number in every cell was accurate. But the model was forecasting collections when it should have been forecasting cash-in. It was using a simple average of historical collection behaviours when the data clearly showed seasonal patterns. It was ignoring partial payments entirely.
The difference between collections and cash-in sounds academic. It's not. Collections means "the client agreed to pay." Cash-in means "the money arrived in our bank account." The gap between those two events can be days or weeks, and it varies by country, by client segment, and by time of year. A technologist looking at the data sees numbers. An operator sees the physical process behind each number and knows which transformations introduce distortion.
3. The political topology of change
Building an AI product inside an existing organisation is as much a political exercise as a technical one. Every automation project threatens someone's job, someone's expertise, or someone's empire.
When I introduced AI agents alongside an enterprise treasury platform, I framed them as complementary: the platform handles structured automation, the agents handle unstructured exceptions. This wasn't just product positioning; it was survival strategy. The team that owned the enterprise platform had budget, headcount, and executive sponsorship. Framing AI agents as a replacement would have triggered organisational antibodies that would have killed the initiative before it shipped.
Operators understand organisational physics. They know which stakeholders need to feel ownership, which metrics matter to which executive, and how to sequence a rollout so that early wins create momentum for broader deployment. This isn't in any PM curriculum. It's learned by navigating real organisations with real politics.
The Operator's Framework for AI Product Design
Based on my experience building AI products for treasury, here's the framework I use:
Step 1: Map the actual process. Not the documented one. The one that happens at 11pm when the quarter is closing and nobody's following the playbook. That's the process your AI needs to handle.
Step 2: Identify the judgment points. Where do humans currently apply contextual knowledge? These are your AI opportunities, not the mechanical steps.
Step 3: Design for the exception, not the rule. The rule is already automated by existing software. Your AI agent's value is entirely in how it handles what existing systems can't.
Step 4: Build confidence levels, not binary decisions. An AI agent that says "I'm 92% sure this is a partial payment for invoices #4521 and #4523, deducting the Q3 credit note" is useful. One that says "matched" or "unmatched" is not.
Step 5: Instrument everything. You need to know not just what the agent decided, but why. When it's wrong, you need to trace back to the specific reasoning step that failed. This is where operational experience tells you what the common failure modes will be before you ship.
Why This Gap Is a Career Opportunity
The supply of AI PMs who understand transformer architectures is growing rapidly. Every bootcamp, every online course, every "AI Product Management" certification is producing them by the thousands.
The supply of AI PMs who have actually operated the processes they're automating? That's tiny. Because that requires years of domain experience followed by a deliberate technical transition. You can't shortcut it.
In treasury alone, I estimate there are fewer than 50 people in Europe with deep operational experience in financial operations who also have genuine AI product design capability. Not AI awareness. Not "I use ChatGPT." The ability to design an agent architecture, define tool-calling workflows, specify confidence thresholds, and ship a product that handles real-world exceptions at scale.
If you're an operator considering the jump to AI PM, the window is now. The technology is mature enough to build real products. The market is hungry for domain-specific AI applications. And the moat you bring, operational depth, is the one thing that can't be replicated by taking a course.
The best AI products will be built by people who've operated the systems they're replacing. Not by technologists guessing at business problems, and not by operators afraid of the technology. The intersection is where the value is.
The question is: which side of the gap are you standing on, and are you willing to cross it?