12 years engineering data platforms → now shipping product.
I decide which pipeline to build, what to optimize, and who it serves.
Most PMs learn systems through diagrams. I learned product thinking through systems.
After 12 years designing enterprise data platforms (Azure, Spark, large-scale ETL), I kept noticing the same pattern: the hardest problems weren't technical — they were decision problems disguised as engineering tickets. Which data should we trust? What metric actually reflects user value? When does ML add complexity without adding lift?
I stopped waiting for a PM to answer those questions and started answering them myself.
Four shipped systems. Every one runs at zero inference cost, and every one records what I chose not to build.
|
Problem — Compliance officers cross-reference dense CBUAE and VARA texts by hand. A tool that invents a citation is worse than no tool at all. Key decision — Fail-closed. Server-side composite confidence scoring rejects weak context before generation, and every citation is verified afterwards against the source. The model is never asked how confident it is. Why it matters — In regulated AI, an explicit refusal is a feature. The system says "I don't know" instead of guessing. |
Problem — A credit model that can't explain a rejection is unusable in a regulated market. And removing protected attributes is not fairness. Key decision — Dropped demographic variables, then measured what leaked anyway. Proxy detection via η² effect size caught employment tenure standing in for age. SHAP output is translated into a plain-language adverse action notice. Why it matters — 4/5ths-rule fairness auditing and CBUAE grounding across 14 provisions. Fairness is measured, not assumed. |
|
Problem — Recommenders optimize for clicks, so a 40%-margin product and a 10%-margin product get identical treatment at the same behavioral score. Key decision — Don't touch the behavioral model. Layer margin on top: Why it matters — Measurable revenue lift with zero movement in hit rate or precision, on 2.7M real events. Business optimization without a UX trade. |
Problem — Rules flag payment anomalies they can't interpret. Is a capture at 95% of authorization an error, or a partial capture? Is a settlement 14 days late stuck, or international? Key decision — Deterministic rules catch known errors; the LLM sees only the ambiguous remainder. Advisory only — the system classifies and routes, never edits a record. Deleting a "duplicate" that is two real purchases has financial consequences. Why it matters — Analysts stop reviewing noise. Roughly 90% of records never reach the model, which is why it runs at zero cost. |
→ All seven case studies, with the trade-offs written up
| Dimension | What I Ask | Why It Matters |
|---|---|---|
| 🔀 Trade-off Analysis | "Does this need ML, or will a heuristic with 80% accuracy ship 10x faster?" | Prevents over-engineering |
| 📊 Metric Design | "Are we measuring what moves the business, or what's easy to measure?" | Aligns teams on outcomes, not outputs |
| 🗺️ Stakeholder Mapping | "Who disagrees with this decision, and what data would change their mind?" | Reduces alignment debt early |
| ⚖️ Cost vs. Value | "What's the cost of being wrong here vs. the cost of waiting to be right?" | Forces prioritization clarity |
I approach every system with four questions:
1. WHO is the user, and what decision are they trying to make?
2. WHAT metric proves this system is working — for the user AND the business?
3. WHERE is the cheapest point to validate the hypothesis before building?
4. WHEN does "good enough" ship faster than "perfect"?
Concrete examples from my work:
- 📐 KPI design — Built a 6-metric evaluation framework (Hit Rate, Precision, NDCG, MRR, Margin Yield, Position-Weighted Yield), because a single metric always hides a trade-off
- ⚡ Prioritization — Chose TF-IDF over transformer embeddings. Lower accuracy ceiling, but 10x faster iteration and fully explainable to non-technical stakeholders
- 🤝 Stakeholder alignment — Wrote the data contract as a cross-team specification, not an engineering artifact. Product owns the what, engineering owns the how
- 🛑 Knowing when to stop — Co-founded an energy venture replacing diesel generators with battery packs. The user research came back negative and we killed it. That taught me more than anything that worked
| From Engineering ⚙️ | Applied to Product 🧩 |
|---|---|
| Architected large-scale data platforms | Understands system constraints and build costs intuitively |
| Managed cost vs. performance trade-offs | Can size investments and kill low-ROI features early |
| Built evaluation frameworks from scratch | Knows how to define success metrics that don't mislead |
| Worked across data teams, infra, and consumers | Natural cross-functional operator |
| Debugged production pipelines at scale | Thinks in failure modes, not just happy paths |
🏗️ Building decision-grade case studies that demonstrate product thinking through systems
🔬 Working at the intersection of data platform strategy and regulated AI
👀 Open to Technical Product Manager and Data Product Manager roles