I build AI products that actually work for real people.

The Problem

Brokerage transaction compliance at scale is genuinely hard. Analysts were manually reviewing flagged transactions from a queue that never emptied — a system designed for a world where trade volume was ten times smaller. Every manual review was a delay, and delays in compliance mean regulatory exposure. The error rate on "Not-In-Good-Order" (NIGO) filings was quietly eating operational budget and creating audit risk.

My Approach

• Shadowed compliance analysts for two weeks to map the actual decision tree in their heads — not what the playbook said, but what they actually did.
• Identified that 70%+ of reviews followed a predictable pattern that a model could handle. The remaining 30% were genuinely ambiguous and needed human judgment.
• Designed a Human-in-the-Loop (HITL) architecture: ML handles the clear cases, flags the ambiguous ones with confidence scores, and routes them to the right analyst tier.
• Worked with ML engineers to select and tune anomaly detection models on historical transaction logs. Wrote the evaluation criteria — precision/recall thresholds — based on the business cost of false positives vs. false negatives.

Outcome

What I Learned

In regulated industries, trust is the product. You can have a 95% accurate model, but if compliance teams don't trust it, you have nothing. I spent as much time on change management and explainability design as I did on model requirements. The technical work was table stakes. The human work was where the project actually succeeded or failed.

What's Next

The roadmap now extends toward real-time predictive threat detection — moving from reactive flagging to proactive monitoring that surfaces risk before a trade settles. I'm also scoping automated remediation for the clearest NIGO patterns to further reduce analyst load.

The Problem

Insurance applications were bleeding users at the document submission step. Customers would photograph and upload documents, then wait — sometimes days — only to be told the image was unclear or the wrong document type. By that point, they'd moved on. The abandonment rate at this step was alarming, and it was entirely self-inflicted friction: a manual review process that could have been automated.

My Approach

• Ran abandonment funnel analysis segmented by document type. Found that ambiguous document categories (e.g., utility bills vs. bank statements) accounted for disproportionate rejection rates.
• Designed a real-time feedback loop: the moment a user captures a document, the system evaluates image quality, identifies the document type, and extracts key fields — all before submission.
• Worked with the ML team on OCR model selection, ultimately choosing a combination of a commercial OCR engine for structured documents and a custom classification model for document type detection.
• Built the product so that users see extraction results in real-time — "We found your address: 123 Main St. Correct?" — which also serves as an implicit data quality check.

Outcome

What I Learned

My mobile engineering background paid off here in a way I didn't expect. I understood exactly why on-device inference was both valuable and limiting — not as an abstract concept, but from having optimized Flutter rendering pipelines and dealt with device-tier performance variability. Being able to speak to that constraint directly with engineers saved weeks of back-and-forth.

What's Next

Extending the model to predictive policy renewal — using behavioral and claims data to surface personalized renewal prompts before customers start shopping alternatives.

The Problem

Commercial energy clients had access to mountains of smart meter data and no ability to act on it. The existing reporting tools showed consumption history but couldn't answer the questions facilities managers actually had: "Are we heading for a high-demand day next week? Should I pre-cool the building tonight to avoid peak pricing?" They were flying blind on a dataset that should have been telling them exactly what to do.

My Approach

• Ran interviews with 12 facilities managers. The core insight: they didn't want more data visualizations. They wanted fewer, better alerts and clear recommended actions.
• Scoped the AI solution around two core capabilities: demand forecasting (7-day horizon) and anomaly detection (unusual consumption patterns relative to historical baseline).
• Integrated hourly smart meter data with historical operational records and weather API feeds — the weather correlation was the key variable most competitors were missing.
• Designed the mobile dashboard around the concept of "one number that matters today" — a daily energy risk score — with drill-down available but never forced on the user.

Outcome

What I Learned

AI products in enterprise B2B contexts live or die on workflow integration. Our best features went unused when they required users to check a separate dashboard. The engagement lift came when we pushed the right alert to the right person at the right time — inside the workflow they already had, not asking them to build a new habit.

What's Next

Automating demand-response triggers — when the model detects an imminent peak stress event, the system automatically initiates pre-approved load-reduction protocols, with the facilities manager receiving a notification rather than a request for action.

The Problem

Field service operations at Cintas were running on yesterday's data. Route assignments were made the night before based on static schedules; inventory reorders were triggered by stock-out rather than prediction. Drivers were covering inefficient routes, and supply depots were constantly over- or under-stocked. The real cost wasn't visible on any one report — it was buried across fuel, overtime, and emergency restocking charges.

My Approach

• Spent three days riding along with field service reps to understand their actual workflow — not the documented process, the real one.
• Identified that route optimization alone wasn't enough; inventory sync timing was the critical dependency. You can't give someone an optimized route if the truck isn't stocked correctly.
• Designed an offline-first mobile app (Flutter) with AI-driven recommendations that worked without connectivity — critical in Cintas's operational environments — and synced intelligently when connectivity resumed.
• ML models processed GPS telemetry, historical route performance, inventory usage patterns, and customer service windows to generate daily routing recommendations with confidence scores.

Outcome

What I Learned

The best AI recommendation means nothing if the person in the field doesn't trust the app enough to follow it. Reliability earned trust. Trust drove adoption. Adoption made the cost savings real. The sequence mattered — and I've applied that lesson to every AI product since: earn trust first, optimize second.

What's Next

Computer vision integration for automated physical asset tracking — using camera feeds from service locations to detect uniform inventory levels and flag reorder needs without manual scanning.

The Problem

The Comerica contact center was absorbing thousands of calls per week for questions that had clear, definitive answers: What's my current balance? Why was this fee charged? When will this transfer clear? Each call cost real money and kept the line busy for complex inquiries that actually needed a human. The frustrating part: customers calling for simple answers had often already opened the mobile app — they just couldn't find what they needed fast enough.

My Approach

• Analyzed 6 months of call transcripts — categorized by intent, resolution time, and first-call resolution rate. Found that 4 intent categories accounted for 58% of total call volume.
• Built the product case around those 4 intents first. Resisted scope creep pressure to build a "comprehensive virtual assistant" — chose to do a few things well rather than everything poorly.
• Implemented RAG architecture: the assistant retrieves relevant account data and policy documentation before generating a response, dramatically reducing hallucination risk on account-specific queries.
• Designed guardrails for financial context: the assistant defers any ambiguous query to a human agent rather than generating a plausible but potentially wrong answer. In banking, a confident wrong answer is worse than an honest "let me connect you."

Outcome

What I Learned

Scope discipline in AI products is genuinely hard because the technology makes everything feel possible. The pressure to add "just one more intent" before launch was constant. Shipping four intents that worked reliably was the right call — and it gave us a track record of reliability to expand from, rather than a reputation for inconsistency to recover from.

What's Next

Expanding to proactive financial wellness recommendations — using transaction patterns to surface relevant insights before the customer has to ask. Moving from reactive resolution to anticipatory guidance.

1. Problem Statement

Mobile product teams get hundreds to thousands of app-store reviews a week and no realistic way to read them all. Regressions hide in the noise — a bad release can tank ratings for days before anyone notices the pattern, because "read every review" doesn't scale past a few dozen a day.

2. User Persona

Priya, Senior Mobile PM at a mid-size fintech. Owns a release every two weeks across iOS and Android. After each release she needs to know, within a day, whether something broke — not after support tickets pile up.

3. Market Research

Competitors: AppFollow, Appbot, Sensor Tower, Thematic. All are capable but built for enterprise ASO/CX teams — priced and configured for that buyer, not a single PM who wants a fast, disposable triage view after a release. That gap is the opportunity: a lightweight, self-serve tool with zero setup cost.

4. PRD — Key Requirements

• Ingest reviews (CSV: text, rating, version, date) or a live demo dataset
• Classify sentiment and surface it as a trend by app version
• Auto-tag common complaint themes (crashes, performance, billing, support, UX)
• Flag the specific negative reviews worth reading this week
• Runs with no paid API key and no setup — must work the moment it opens

5. MVP Scope (V1)

In scope: lexicon-based sentiment scoring, keyword-driven theme tagging, sentiment-by-version trend chart, top negative reviews table, CSV export.
Out of scope (V2): live app-store scraping, multi-language support, transformer/LLM-based theme classification.

6. Success Metrics (KPIs)

7. AI Architecture

Prompt: none in V1 — a keyword taxonomy dictionary drives theme tagging. Model: VADER-style lexicon sentiment scoring, chosen over a transformer model for zero cost, instant latency, and full explainability. Evaluation: precision/recall against a hand-labeled 200-review sample; V2 path is a fine-tuned or zero-shot LLM classifier benchmarked against this V1 baseline.

9. Lessons Learned

Explainability beat marginal accuracy here — a transparent lexicon model that a stakeholder can question is more useful than a slightly-more-accurate black box. And the theme taxonomy itself is a product decision, not an engineering detail: which buckets you choose shapes what the team pays attention to.

1. Problem Statement

Every AI-adjacent PM job I've had generates a steady stream of "can we add AI to this?" requests. Without a repeatable framework, each one turns into a multi-meeting scoping cycle before anyone can say whether it's worth building — or what architecture even fits.

2. User Persona

Marcus, Product Owner at a regulated enterprise (bank or insurer). Triages a growing backlog of AI feature ideas from stakeholders and needs a consistent, defensible way to score and route them — not another ad-hoc conversation.

3. Market Research

Competitors: Productboard, Aha!, generic RICE/ICE calculators, and plain ChatGPT used ad hoc. None of them encode an AI-feature-specific intake framework — model type, data readiness, failure modes, audit trail — the way an experienced AI PM's mental checklist does. That checklist, digitized, is the product.

4. PRD — Key Requirements

• Structured intake form: business goal, target user, data availability, knowledge volatility, regulatory sensitivity, latency tolerance
• RICE scoring from reach/impact/confidence/effort inputs
• Deterministic architecture recommendation (rules-based / RAG / fine-tune) with stated reasoning
• Auto-generated risk & guardrail checklist scaled to regulatory sensitivity
• Downloadable one-pager brief; optional LLM "polish" pass on the prose only

5. MVP Scope (V1)

In scope: rule-based decision engine, RICE calculator, templated brief generation, optional bring-your-own-key LLM polish.
Out of scope (V2): multi-user approval workflows, Jira/Confluence integration, historical calibration against real outcomes.

6. Success Metrics (KPIs)

7. AI Architecture

Prompt: a structured template combining form inputs + framework rules, used only for the optional prose-polish step. Model: a deterministic, auditable rule/decision-tree as the core logic — not an LLM — because a regulated intake tool needs an inspectable answer to "why did it say this," plus an optional GPT-4o-mini-class call for tone only. Evaluation: the rule engine was checked against real scoping decisions from the Schwab HITL and Comerica RAG-vs-fine-tune case studies to confirm it reproduces the same call; LLM polish is checked for hallucination via template-constrained, no-new-facts output.

9. Lessons Learned

Forcing an implicit judgment call (RAG vs. fine-tuning) into an explicit scoring rubric was valuable independent of the tool — it made me articulate criteria I'd been applying by instinct. Deterministic logic beats an LLM whenever "why" has to be auditable.

1. Problem Statement

Field teams run reactive maintenance — fix it after it breaks — even when sensor data exists that could flag the problem early. The data isn't the gap; turning it into a plain "check this asset first" signal for a non-technical operator is.

2. User Persona

Dana, Field Operations Manager overseeing a fleet of industrial equipment. Wants one risk indicator per asset to plan this week's inspections — not a raw telemetry firehose she has to interpret herself.

3. Market Research

Competitors: IBM Maximo, GE Digital/Predix, Uptake, Augury, SparkCognition. These are heavy, expensive IIoT platforms that assume a dedicated integration team. The gap is a lightweight, explainable dashboard a mid-size ops team can stand up without one — the same "one number that matters" philosophy from the Xcel Energy case study.

4. PRD — Key Requirements

• Ingest per-asset time-series sensor data (temperature, vibration, runtime hours) via CSV or a built-in simulator
• Compute an anomaly score vs. historical baseline per asset
• Rank the fleet by risk tier (Low/Medium/High) so the highest-priority asset is obvious
• Drill-down chart per asset showing sensor trend with anomaly markers
• Exportable fleet risk report

5. MVP Scope (V1)

In scope: synthetic multi-asset data generator + CSV upload, Isolation Forest anomaly scoring, rule-based risk tiering, fleet ranking table, per-asset drill-down chart.
Out of scope (V2): live IoT/SCADA streaming integration, LSTM-based failure forecasting, automated work-order creation.

6. Success Metrics (KPIs)

7. AI Architecture

Prompt: none — this is a numerical time-series tool, not an LLM product; not every AI product needs one. Model: Isolation Forest over rolling sensor features, chosen over an LSTM forecaster for V1 because it needs far less historical data and is easier to explain to a field ops manager — mirroring the "earn trust with something explainable before justifying a deep model" sequencing from the Xcel engagement. Evaluation: precision/recall of flags against injected synthetic failure events, with a plan to backtest against real historical failure logs once available.

9. Lessons Learned

The hardest part of predictive maintenance products is data readiness, not modeling — which matches what I documented in the field at Cintas. Starting with an explainable statistical baseline earns the right to later argue for a more expensive model.