Active experiments

Where I test AI product ideas
before the market does

Not a showcase of finished work. A working document of what I'm building, what I'm learning, and what I believe about AI products — updated as I go.

1
Live AI product
in production
2
Frameworks built
from real programs
10+
GenAI features
shipped at enterprise scale
0
Compliance incidents
across all AI deployments
Live Experiments
What I'm currently building
Side projects where I'm the PM and the user — the fastest way to learn what actually works in AI products.
Live in production
JobSignals — AI Labor Market Intelligence
Job seekers had raw data and no signal. I built an AI data product that extracts structured hiring intelligence — skill demand trends, company hiring velocity, salary signals — from unstructured job posting text. The central PM insight: prompt engineering is acceptance criteria. The precision required to get consistent AI output is identical to the discipline of writing good feature specs.
The PM problem I solved
What skills are actually in demand — not what job boards say, but what hiring managers write
The AI design decision
Structured extraction over generative summaries — precision beats creativity when users need to act on data
What I learned
Prompt engineering is product work, not engineering work — owns the same tradeoffs as a feature spec
Key product decisions
Why structured extraction, not generative summaries?
Users need to compare across job postings. Free-form AI summaries are unstructured and non-comparable. Structured output (skill: required/preferred, salary: min/max, remote: yes/no) is queryable, filterable, and trustworthy. The "smarter" AI output would have been less useful.
How did you define "accuracy" for the extraction model?
I defined 12 extraction fields and wrote acceptance criteria for each — same process as writing a PRD. If I couldn't write a test case for it, I didn't extract it. This constraint forced better product scope than technical ambition would have allowed.
What's the hardest unsolved problem right now?
Recency. Job postings go stale but don't always get taken down. The product needs a "hiring velocity" signal that distinguishes actively hiring vs. passive pipeline building — the data is noisy and the model gets confused by it.
Full case study →
Exploring
AI Adoption Gap Tracker
A lightweight tool to measure the gap between "AI feature shipped" and "AI feature actually used." Most adoption dashboards count logins, not value delivery. I want to measure meaningful usage — the moment a user acts on AI output vs. ignores it.
The PM question I'm trying to answerHow do you distinguish between a user who trusts the AI and one who opens the feature and closes it?
Exploring
Regulatory Radar — India AI Policy Monitor
India's AI regulatory landscape is moving fast — RBI sandbox, DPDP Act, SEBI fintech framework. I'm building a personal tracker that surfaces policy changes with product implications, not just legal summaries.
Why this matters for PM workRegulated AI products need PMs who understand regulatory risk, not just technical risk. This is my way of staying ahead of compliance constraints before clients discover them.
Backlog
Agent Handoff Spec
As agentic AI becomes real product infrastructure, the hardest PM problem is defining when an agent should hand off to a human — and what state it passes along. I'm working on a spec template for this transition point.
The design problemHuman-to-AI handoff is well-documented. AI-to-human handoff — when the agent knows it's failing — is almost entirely undesigned.
Backlog
Insurance Claims AI Triage Model
Sapiens context: most insurance claims routing is rule-based and brittle. I'm prototyping a lightweight AI triage layer that routes claims to the right adjuster type — not by policy category but by claim complexity signature.
The key risk to solveWrong routing in insurance is worse than no routing — it adds delay and creates compliance trail issues. Downside risk must be designed in before upside potential.
Frameworks Built
How I make AI product decisions
These aren't theoretical models. Each one came out of a real program where I needed a framework and none existed.
Framework 01 · AI Prioritization
Risk-Adjusted GenAI Feature Sequencing
Standard value/effort matrices miss the critical third dimension for regulated environments: the asymmetric cost of being wrong. This framework adds four questions to every AI feature prioritization decision — upside if right, downside if wrong, data readiness, and measurability. Developed at Deloitte Digital on a $10M HCSC contact center transformation program.
What's the upside if right? What's the downside if wrong? Is training data ready? Can we measure the outcome?
Origin: Deloitte Digital · HCSC GenAI program · 2022–2024
Case study →
Framework 02 · Metrics
Mechanism vs. Consequence Metric Test
Before committing to a north star metric, ask: does this metric expose the failure mode, or does it only measure the downstream consequence of the failure? The test: what would need to be true for this metric to look good while the underlying product is still broken? If you can answer that question easily, you have the wrong metric. Developed at Signzy when switching from "average KYC processing time" to "first-attempt success rate."
What does this metric exclude? Is it a mechanism or consequence? Optimizable while broken?
Origin: Signzy · KYC product · 2024
Blog post →
Framework 03 · AI UX
Design for the Skeptic, Not the Enthusiast
AI feature adoption is determined by your most skeptical user, not your most enthusiastic one. Designing for the enthusiast (who trusts AI by default) produces clean, fast AI output with no friction. Designing for the skeptic means adding confidence scores, easy overrides, and keeping humans in control. The skeptic's version has consistently 20–30% better adoption because trust precedes use. Override data also feeds model improvement — the friction is a product asset.
Show confidence score One-click override Agent stays in control Log all overrides
Origin: Deloitte Digital · HCSC agent UX · 2023
Blog post →
Framework 04 · Backlog
4-Factor AI Backlog Prioritization
At Sapiens, with 200+ items in the backlog and competing stakeholder groups, I needed a scoring method that was transparent, defensible, and fast. Four factors: strategic alignment (0–3), customer pain intensity (0–3), delivery confidence (0–3), and compliance risk (0–3, inverted). Transparent scoring lets stakeholders understand why their item moved — reducing negotiation friction by making the criteria explicit.
Strategic alignment Pain intensity Delivery confidence Compliance risk (inverted)
Origin: Sapiens International · CoreSuite backlog · 2024–present
Case study →
AI Product Checklist
What I check before shipping any AI feature

This is the checklist I run through before every AI feature goes to staging. Not theoretical — built from the real failures and near-misses I've seen across healthcare, fintech, and insurance. The goal is to catch the avoidable failures before they reach users.

1
Problem & Scope
4 checks
The job-to-be-done is specific and measurable — not "use AI to improve X" (vague brief = vague product)
We have defined what "wrong AI output" looks like and documented the failure mode
The failure mode's cost has been assessed: low (human reviews before action) vs. medium vs. high (live output, no review)
We can articulate why AI is the right tool here — not just because it's possible
2
Data Readiness
4 checks
Training data is available and domain-specific — not just generic model capability (healthcare AI needs healthcare data)
Data quality has been audited — volume, freshness, labeling accuracy, coverage gaps
Edge cases are documented: what inputs is the model likely to fail on, and what happens when it does?
Data governance is cleared: consent, PII handling, cross-border transfer rules (especially for regulated industries)
3
UX & Adoption
5 checks
UX is designed for the skeptic, not the enthusiast — assumes users will distrust AI output until proven otherwise
There is a clear, easy override mechanism — users can correct or dismiss AI output in one step
Confidence or uncertainty is surfaced to users when the model is less confident than threshold
All overrides are logged — override patterns are the primary signal for model improvement
The feature has been tested with skeptical users — not just early adopters or internal teams
4
Metrics & Measurement
4 checks
North star metric measures mechanism, not downstream consequence (first-attempt success rate, not average processing time)
The metric test is passed: "What would need to be true for this metric to look good while the product is still broken?"
Leading indicators exist — we don't have to wait for the north star to move to know if we're on track
Success criteria are set before launch — not reverse-engineered from whatever number came out
5
Compliance & Risk
4 checks
Compliance team has reviewed the feature — not after launch, not as an afterthought
The regulatory framework that applies has been identified: HIPAA, GDPR, DPDP, RBI guidelines, SEBI, IRDAI
There is a rollback plan if the feature causes harm — not a "monitor and iterate" plan, a specific rollback trigger
The "0 compliance incidents" target is explicit and owned — not assumed to be someone else's problem
What I'm Watching
Trends I'm tracking for their PM implications
🏛️
India AI Regulatory Sandbox
RBI, SEBI, and IRDAI are all building fintech AI frameworks with different compliance requirements. Most teams are ignoring this until it's too late.
PM implication: compliance constraints should gate feature sequencing, not follow it
🤖
Agentic AI as Product Infrastructure
AI agents are moving from demos to real product infrastructure. The unsolved design problem: AI-to-human handoff when an agent fails or hits its limit.
PM implication: agent failure UX is the hardest unsolved PM problem in production AI right now
📉
LLM Inference Cost Curves
Token prices are dropping 10x per year. Features that are economically unviable today will be viable in 12 months. Sequencing decisions should account for this.
PM implication: "too expensive to build" is a temporary constraint — design the feature, defer the ship date
🔍
Retrieval-Augmented Generation in Enterprise
RAG is the real implementation pattern for regulated enterprise AI — not fine-tuning, not general models. But RAG quality is a data problem, not a model problem.
PM implication: the bottleneck for enterprise AI is document quality and retrieval accuracy, not model capability
💳
UPI & India Payments Stack Evolution
UPI 2.0, credit on UPI, ONDC integration, cross-border UPI. India's payments infrastructure is being rebuilt layer by layer with significant PM opportunity at each layer.
PM implication: Razorpay, Cashfree, and Juspay are building fundamentally different products than Stripe — the business model differences matter more than the features
📋
AI Adoption Measurement
Most "AI adoption" metrics count feature activations, not value delivery. The field is developing better instrumentation for measuring whether AI actually changed behavior.
PM implication: if you can't measure whether users act on AI output vs. ignore it, you can't improve adoption
Let's talk AI product
I'm looking for PM, TPM, and AI PM roles
in Fintech, Insurtech, and AI-first products
If you're building products where AI failure has real consequences — regulated industries, high-stakes decisions, complex integrations — I'd like to talk.
Get in touch View full portfolio