Open to senior AI & data product roles

AI is only as good
as the data feeding it.
I build that layer.

Senior Product Manager, ex-Amazon, ex-o9 (T-Mobile). For nine years I've owned the data products that enterprise AI runs on — the trusted datasets that feed ML forecasting models, and the analytics that put AI in the hands of hundreds of users. The models get the headlines; the data layer is what makes them work.

What I do

I make enterprise AI reliable —
by owning the data layer underneath it.

Forecasting models, planning engines, and AI copilots all share one dependency: the data feeding them has to be trusted, complete, and production-grade. That's the layer I've owned for nine years — turning messy, fragmented enterprise data into the reliable products that AI systems actually run on.

9+
years in data & AI product management
100s
of users enabled with AI-powered analytics
AI
planning platform data layer, owned end to end
Top 0.1%
company-wide performance recognition
01 · FOUNDATION

Trusted dataThe single source of truth AI depends on

Models are only as reliable as their inputs. I built the trusted foundation underneath them.

  • Created a single source of truth for inventory by merging warehouse, ERP, and carrier/logistics data into one unified dataset used across the enterprise
  • Led a cloud migration to a modern Lakehouse, moving CRM, ERP, and supply-chain sources into an AI-ready foundation
  • Stood up an enterprise data-quality framework — monitors and alerts for stale, duplicate, and missing data, the guardrails ML models depend on
02 · ML DATA PRODUCTS

Feeding the modelsData products that power an AI planning platform

I owned the data layer for an enterprise adoption of o9, an AI-powered supply-chain planning platform.

  • Led a cross-functional team to deliver production-grade data products — item, location, supplier, and transactional datasets — as direct inputs to o9's ML models
  • Enabled AI-driven capabilities: ML demand forecasting, promo-lift prediction, multi-echelon inventory optimization, and purchase-order automation
  • Translated ML model data requirements into reliable, governed datasets the algorithms could trust
03 · AI IN USERS' HANDS

AdoptionPutting AI analytics in front of the business

A model nobody uses delivers nothing. I drove real adoption of AI at the user level.

  • Rolled out Databricks Genie (AI natural-language analytics) to hundreds of supply-chain and procurement users, letting them query data without writing SQL
  • Ran structured training and adoption tracking to turn a new AI capability into everyday usage
  • Reduced analyst dependency and accelerated time-to-insight across the organization

Pet projects

And on weekends, I build the AI myself.

Side projects, built for the joy of it — and to stay fluent in how modern AI systems actually get made. The most involved is an autonomous agent I built and pointed at my own job search.

Pet project · the most involved one · built & deployed solo

Job Tracker — a scheduled, agentic document pipeline

Next.js 16 · Hono · Cloudflare Workers + D1 · Claude (headless, MCP) · Python

Inbox paste a URL Nightly agent headless Claude · 10pm Reason + tailor JD → experience map Render docs .docx · deterministic Review + reasoning log deterministic plumbing & model judgment, deliberately separated

Every night, unattended — ingest → reason → generate → render → human review. The agent explains itself on every run.

The idea

Most "AI document" tools are a chat box and a prompt. I wanted to answer a harder question: can an LLM run unattended, on a schedule, and produce work you'd actually trust? I picked a problem I had real stakes in — my own job search — and built a system that, every night, turns a structured profile plus a job posting into tailored application documents, to a quality bar I define, while showing its reasoning so I stay in control. The job-search use case kept me honest about quality; the agent architecture is what transfers to any high-stakes, repeatable knowledge work.

Decisions I'm proud of

  • LLM as orchestrator, not a chatbot. A runbook drives a multi-step, tool-using agent loop — ingest, dedup, reason, generate, render, publish, report.
  • A hard line between plumbing and judgment. State transitions, rendering, auth, and uploads are deterministic code (zero AI); only the genuine judgment calls go to the model. Knowing which is which is half the design.
  • Human-in-the-loop, by construction. The agent writes a reasoning log every run — what it emphasized, stretched, and skipped — so review is an approval step, not blind trust.
  • Guardrails as a contract. Non-negotiable content rules plus a structured output schema keep every autonomous run on-spec — the start of a real eval loop.
🩺

Health Tracker

Next.js · Cloudflare · D1

A self-built, deployed full-stack health-tracking app on the same stack — proof I can ship and run a real app with a database, end to end.

● Deployed
🎲

Board game + balance simulator

Simulation · modeling

A board game I designed and am playtesting, with a simulation engine I built to model balance — playthrough simulation and win-rate analysis.

○ Write-up coming soon

Experience

Where I've worked

T-Mobile
Sr. Manager / Sr. PM — data products for o9 (AI planning) & the Databricks Genie rollout
2019 – 2026
Amazon
Sr. Program Manager — Amazon Business (B2B) analytics
2017 – 2019
Earlier · Education
Data & analytics roles · MBA, The Ohio State University — Supply Chain & Analytics
2011 – 2017

Full résumé available on request — vardhaman.patil88@gmail.com