01
6+ years
Across software, business analysis, technical consulting, enterprise delivery and product management.
AI Product Manager · Technical Product Manager · AI TPM
I build AI products where
being wrong is expensive.
I’m Subham Ojha — an AI Product Manager and technical product builder working across enterprise AI, agentic systems, BFSI, ecommerce, automation and decision-support products.
I care less about whether an AI can produce an impressive answer and more about whether the system can explain, support and survive that answer when money, operations or customers are involved.
02
AI + enterprise systems
Experience spanning GenAI, BFSI, AML, RegTech, automation and compliance-sensitive workflows.
03
Technical surface area
Python, SQL, REST APIs, webhooks, JSON, data mapping, workflow architecture and AI-assisted development.
04
Builder, not spectator
Public products across banking intelligence, revenue reconciliation, AI simulation and urban systems.
AI product identity
AI gets interesting after the demo works.
Most AI demos answer one question: can the model do it?
Production product work begins with harder questions.
How often is it wrong? What evidence supports the answer? What happens when retrieval fails? Which decisions need human review? What belongs in an LLM and what should remain deterministic? What does failure cost?
That is where I like operating.
My background combines Product Management with enough technical depth to move between the user problem, system architecture, APIs, data, workflows, prototype, failure modes and delivery decisions without treating engineering as a black box.
You can call that an AI Product Manager, a Technical Product Manager, or an AI TPM.
The title matters less than the operating model: understand the expensive problem, design the system, make the trade-offs visible, and ship something testable.
AI Product Manager
AI Technical Product Manager
Agentic AI
Enterprise AI
RAG
AI Agents
BFSI / RegTech
Automation
Product Architecture
how I think about AI products
Start with the failure, not the model.
01
What expensive problem exists?
AI is not the strategy. I first want to know what failure, delay, leakage, decision or workflow is expensive enough to deserve intervention.
02
What evidence exists?
If the system makes a claim, I want to know where it came from. Provenance matters more as the consequence of the decision increases.
03
Where does AI actually belong?
Some problems need an agent. Some need retrieval. Some need deterministic rules. Sometimes the right product decision is not to use an LLM at all.
04
How does it fail?
A successful happy-path demo is weak evidence. I care about contradictions, unsupported assumptions, missing context, edge cases and silent failures.
05
What should a human control?
Autonomy is useful only when the cost of being wrong and the path to correction are understood. Human review is a product decision, not an embarrassment.
06
What changes because this exists?
The final question is business impact: faster investigation, less leakage, better prioritisation, reduced manual effort or a decision that becomes materially easier.
selected AI product work
Working systems, not AI adjectives.
BFSI · AI agents · failure intelligence
ScreenPath
Banking Failure Intelligence
What if banks could notice expensive failure patterns while customers were already describing them?
Customers report scams, unauthorized transactions, failed mandates, outages, blocked accounts and broken workflows across support tickets, app reviews, complaint portals, Reddit, X and other channels.
The individual complaint is useful. The pattern across complaints is where it becomes product intelligence.
I built ScreenPath to explore how those scattered signals could become structured investigation evidence.
The product models failures as contradictions: an expected system state, what broke, and the state customers actually reported.
The AI layer is designed to assist investigation rather than create unquestioned conclusions. The public deployment intentionally keeps the agent disabled while exposing the investigation workflow.
AI should compress investigation, not manufacture certainty.
AI Agents
BFSI
Responsible AI
Signal Intelligence
Human Review
ecommerce · reconciliation · decision support
RecoverRev
Marketplace Revenue Recovery
A dashboard can tell you how much money arrived. I wanted to know what should have arrived but didn't.
Ecommerce marketplace operations are fragmented across order reports, settlement files, returns, deductions, fees and platform-specific policies.
I designed RecoverRev around a simple principle: a discrepancy without evidence is noise.
A discrepancy connected to the original order, settlement event, applicable rule and supporting rows becomes actionable recovery work.
The product supports Amazon India, Flipkart, Myntra and Meesho and turns raw marketplace data into:
reconciliation → evidence → recovery opportunity → action queue → recovery tracking → ROI visibility
On a synthetic test dataset of approximately 9,000 marketplace records, the engine surfaced 116 evidence-backed recovery cases representing approximately ₹94,725 in supported revenue exposure.
The core financial reconciliation is deterministic and traceable. That is intentional.
When determinism is cheaper than uncertainty, use determinism.
Marketplace Operations
Reconciliation
Evidence Systems
Decision Support
Automation
simulation · digital twin · AI-assisted development
Sector V Continuity Command
Urban Operations Simulation
Most dashboards explain what happened. I wanted to explore what an interface for reasoning about what could happen might look like.
Starting with Kolkata's Sector V, I built a browser-based 3D urban operations prototype using Three.js, Blender and geospatial road data.
The system renders roads, zones, landmarks and traffic layers while creating a foundation for scenarios involving congestion, monsoon disruption, infrastructure pressure and response decisions.
AI coding tools compressed the implementation cycle dramatically.
But generating code was not the difficult product problem.
The difficult questions were: Which data should be trusted? What should the simulation represent? What level of realism actually helps? Which interactions inform decisions rather than simply looking impressive?
The initial working prototype was built in approximately 7–8 hours.
AI is collapsing the distance between product hypothesis and testable software.
Digital Twin
Three.js
Blender
Geospatial Data
Simulation
additional technical work
I use AI to expand what one product operator can test.
01
MiroFish
Self-hosted an AI simulation environment for exploring multi-agent behaviour, scenarios and possible future outcomes.
02
OpenClaw on Oracle Cloud
Deployed and explored a self-hosted AI system end-to-end, increasing my understanding of the infrastructure behind agentic products rather than treating the model API as the entire architecture.
03
Multi-channel AI automation
Built n8n-based workflows supporting multi-user onboarding, content generation, human review, approval and multi-platform publishing.
AI PM + AI TPM
Product judgment with technical proximity.
Some product managers operate primarily through discovery, prioritisation and stakeholder alignment.
Some Technical Product Managers operate closer to architecture, APIs, platforms, data and engineering.
My work sits between the two.
I can frame the business problem, write the requirements, reason about workflows and user experience, and then move closer to the technical implementation through APIs, SQL, Python, data structures, integrations, system constraints and prototypes.
That technical proximity has become significantly more valuable in AI products because many product decisions are now inseparable from model behaviour, retrieval, latency, data quality, cost, guardrails and failure modes.
before the AI portfolio
Enterprise systems taught me what demos don't.
My path into AI Product Management did not begin with prompt engineering.
It came through years across software engineering, business analysis, technical consulting and product delivery.
I have worked with enterprise systems involving BFSI, AML, RegTech and GenAI; written PRDs and functional specifications; coordinated API integrations; mapped data; managed UAT; triaged defects; supported releases; and translated between engineering, business, implementation and compliance stakeholders.
That background changes how I see AI.
A model response is not a product.
A product has users, permissions, dependencies, exceptions, economics, data quality problems, failure states, audit requirements and consequences.
AI has to survive contact with all of them.
how I work
From ambiguity to something falsifiable.
01
Understand the system
Users, incentives, data, dependencies, existing workflow and operating constraints.
02
Find the expensive failure
Where does money, time, trust, conversion, reliability or operational capacity leak?
03
Choose the right intelligence
LLM, retrieval, agent, deterministic engine, automation or no AI at all.
04
Build the smallest credible system
Enough product to test the real hypothesis, not enough polish to hide from the market.
05
Attack the failure modes
Edge cases, unsupported outputs, bad data, contradictions, broken workflows and false confidence.
06
Measure what changed
Reliability, time saved, recovery identified, usage, conversion, cost or another business outcome.
technical surface area
Enough depth to ask better product questions.
AI Product
AI agents · Agentic workflows · LLM systems · RAG concepts · prompt architecture · human review · guardrails · evaluation strategy · enterprise AI
Data & Engineering
Python · SQL · REST APIs · JSON · webhooks · data mapping · validation · workflow automation · n8n
Product Delivery
Product discovery · PRDs · functional specifications · acceptance criteria · UAT · defect triage · releases · stakeholder management
Domains
BFSI · FinTech · AML · RegTech · enterprise SaaS · ecommerce operations · automation · decision intelligence
Simulation & Prototyping
Three.js · Blender · geospatial systems · digital twins · rapid AI-assisted prototyping
Current technical depth
Advanced study in Agentic AI and RAG Engineering through IITM Pravartak, with continued public building and experimentation.
building in public
A résumé claims. A working product can be interrogated.
Not every prototype I build deserves to become a startup.
That is not the point.
I build publicly because working software creates a harder form of proof than another paragraph saying I understand Product Management or AI.
You can inspect the workflow. Question the architecture. Find a broken assumption. Look at the source code. Challenge whether the product should exist.
That feedback loop is valuable.
And as AI-assisted development reduces the cost of prototyping, I think Technical Product Managers should become increasingly capable of testing their own product hypotheses before asking an engineering organisation to make a large commitment.
currently
What I want to work on next.
I’m interested in Senior Product Manager, AI Product Manager and Technical Product Manager roles where AI is part of the product architecture, not a decorative feature added to the roadmap.
Especially interested in:
Enterprise AI
Agentic AI
AI Agents
RAG
BFSI / FinTech
AI Infrastructure
Decision Intelligence
Automation
Simulation
Based in Kolkata, India. Open to remote opportunities and relocation.
AI Product Manager FAQ
About Subham Ojha's AI Product Management work.
Who is Subham Ojha?
Subham Ojha is an AI Product Manager and Technical Product Manager based in Kolkata, India. His work spans enterprise AI, AI agents, BFSI, AML, RegTech, automation, ecommerce systems and technical product development.
What kind of AI products has Subham Ojha built?
Public projects include ScreenPath, a banking-failure intelligence product; RecoverRev, an ecommerce marketplace reconciliation and recovery platform; and Sector V Continuity Command, a browser-based 3D urban operations simulation.
Is Subham Ojha an AI Product Manager or Technical Product Manager?
Both descriptions fit the work. His background combines product discovery and delivery with APIs, data, Python, SQL, integrations, workflow architecture and AI-assisted product development. That places the work at the intersection of AI Product Management and Technical Product Management.
Does Subham Ojha build AI products himself?
Yes. Alongside traditional product-management work, he uses AI coding systems, Python, SQL, APIs, automation tools and web technologies to build and deploy working prototypes and technical product experiments.
What AI areas is Subham currently focused on?
Current areas include agentic AI, AI agents, Retrieval-Augmented Generation, responsible enterprise AI, evaluation, automation, decision-support systems and AI-native product development.
What roles is Subham Ojha open to?
He is interested in AI Product Manager, Senior Product Manager and Technical Product Manager opportunities involving technically complex AI products, enterprise systems, agents, RAG, FinTech, automation or decision intelligence.
work with me
If the problem is technically messy, economically meaningful and still poorly understood, I'll probably want to talk about it.
AI Product Management · Technical Product Management · Enterprise AI · Agentic Systems · Product Architecture