# Semmal Palanisamy > Technical Product Manager, AI. Engineer turned PM who ships AI products people trust: GenAI analytics in production for a 3,400-location supply chain, a RAG compliance agent with human review, +22% MRR in two quarters, 15+ products shipped. Bengaluru · Remote (India). Contact: semmal5002@gmail.com. Every claim below links to a case study with the problem, decisions, trade-offs and outcome. Spec work is labelled as such and claims no results. ## Use this profile - Check fit for a specific role: open https://semmal.one/, choose "Hiring?" in the navigation and paste a job link, upload the JD (PDF, DOCX, TXT) or paste its text; the work list re-orders around the role and a shareable brief is produced. - Ask about the work: "Ask" in the navigation answers from the case studies and names its sources. - Lab: the Stranger Test (https://semmal.one/#lab) checks whether a first-time visitor understands any product's headline or pitch. - Tailored links: https://semmal.one/?role=&for=&m=. (competency ids: ship, evals, rag, trust, discovery, strategy, metrics, business, platform, leadership, zero). - Book an intro call: https://calendar.app.google/NMAqk6MvHuGziTRe7 - LinkedIn: https://www.linkedin.com/in/semmal-p · GitHub: https://github.com/semmal-dev - Everything in one file (profile plus every case study in full): https://semmal.one/llms-full.txt. Each case study is also plain Markdown at https://semmal.one/work/.md, linked below. ## At a glance - Role: Technical Product Manager, AI - Experience: 7+ years building software, 5+ in senior software engineer / technical PM roles - Open to: Senior AI PM & Technical PM roles; Bengaluru, or fully remote - Best fit for: 0→1 AI / LLM products; AI quality, evals & trust; Platform & integration bets; Growth & monetization features - Edge: I can build what I spec: prototypes, architecture reviews and eval harnesses, so decisions move at the speed of evidence. ## Case studies - [PRD-001: GenAI analytics for a 3,400-location supply chain](https://semmal.one/work/prd-001.md) (Shipped, Sep 2025 — present). Shipped a GenAI analytics layer that turns shipment, inventory and fulfillment data into natural-language insights, with a quality bar and validation checks. Outcome: Days → hours operations reporting time; Trusted summaries used without manual re-verification. - [PRD-002: Compliance Copilot: grounded AI with a human in the loop](https://semmal.one/work/prd-002.md) (Shipped, Oct 2024 — Sep 2025). Architected a RAG agent that extracts and classifies regulatory clauses, handles routine cases autonomously and escalates the risky ones to people. Outcome: ↓ manual compliance-document review time; +50% engineering throughput (AI-assisted docs, standardized PRDs); −30% technical debt, with NPS up (“Stability First” roadmap). - [PRD-003: Native Zoom integration: +22% MRR in two quarters](https://semmal.one/work/prd-003.md) (Shipped, 2021 — 2024). Owned a native Zoom integration from zero to one, product and engineering. Outcome: +22% MRR within two quarters. - [PRD-004: Omnify Payments & Credits: a new revenue stream](https://semmal.one/work/prd-004.md) (Shipped, 2021 — 2024). Architected native checkout on Stripe Connect and a wallet-based refund system with fraud-pattern detection. Outcome: New high-margin transaction-fee revenue stream; +18% ARPU / upsell conversion. - [PRD-005: Enterprise SSO & RBAC: +30% enterprise adoption](https://semmal.one/work/prd-005.md) (Shipped, 2021 — 2024). Built multi-tenant SSO with granular role-based access control. Outcome: +30% enterprise-segment adoption (US & APAC). - [PRD-006: Activation: −40% onboarding drop-off](https://semmal.one/work/prd-006.md) (Shipped, 2021 — 2024). Used Mixpanel cohort analysis to find the friction, redesigned onboarding, unified support tooling and automated first-response triage. Outcome: −40% activation drop-off; ↑ Day-1 retention; −60% client onboarding time. - [PRD-007: 15+ products, end to end](https://semmal.one/work/prd-007.md) (Shipped, May 2019 — Jan 2021). Ran discovery, architecture, build and launch for 15+ products; built an inventory-synchronization engine with rules-based demand logic. Outcome: 15+ products shipped end to end; −40% manual operational overhead (retail clients). - [SPEC-01: Spec: eval-first launch plan for an AI support-triage agent](https://semmal.one/work/spec-01.md) (Spec work (not shipped, no results claimed), Spec · 2026). A launch plan where the eval set, rubric and gates are defined before the prompt is written. Outcome: Spec no shipped metrics: this is a plan, not a result. ## Competencies, with evidence - Shipped LLM / GenAI products: GenAI analytics layer in production for a 3,400-location supply chain (PRD-001); RAG compliance agent for US K-12 institutions (PRD-002) - Evals & AI output quality: Defined the accuracy, freshness and traceability bar for AI outputs, plus validation checks (PRD-001); Grounded retrieval kept compliance answers traceable and auditable (PRD-002); Spec: eval-first launch plan for an AI triage agent (SPEC-01) - RAG, agents & tool use: Architected a RAG agent with agentic, function-calling workflows (PRD-002); API-driven LLM parsing pipeline for clause extraction and classification (PRD-002) - Trust, safety & human-in-the-loop: Escalated ambiguous and high-risk cases to human reviewers (PRD-002); Validation checks so stakeholders trust AI summaries without re-checking numbers (PRD-001) - Discovery & problem framing: Translated ops and finance leadership needs into scoped deliverables and success metrics (PRD-001); Cohort analysis to locate onboarding friction (PRD-006) - Roadmap, prioritization & PRDs: RICE prioritization with direct stakeholder input (PRD-001); Data-backed PRDs with strict edge cases: +50% engineering throughput (PRD-002); "Stability First" roadmap: −30% technical debt, higher NPS (PRD-002) - Metrics, analytics & experimentation: −40% activation drop-off and better Day-1 retention via Mixpanel cohorts (PRD-006); A/B testing and SQL in day-to-day decisions (PRD-006) - Business impact & monetization: +22% MRR within two quarters from a 0→1 Zoom integration (PRD-003); New transaction-fee revenue stream and +18% ARPU/upsell (PRD-004); +30% enterprise adoption across US & APAC (PRD-005) - Platform & technical depth: FastAPI microservices integrated with a Laravel core via REST (PRD-001); Stripe Connect payments infrastructure and wallet refunds (PRD-004); Multi-tenant SSO with granular RBAC (PRD-005) - Cross-functional leadership: Worked directly with client ops and finance leadership (PRD-001); Aligned engineering, compliance reviewers and the client (PRD-002) - 0→1 ownership in ambiguity: Owned the native Zoom integration from zero to one (PRD-003); 15+ products end to end as sole engineer and product lead (PRD-007) ## Judgment: when he chose not to use AI - Rules, not a model: Inventory for small retailers. Rules-based demand logic instead of a forecasting model. Owners needed something reliable and explainable they could run themselves. (PRD-007) - Checks around the model: Supply-chain reporting. The AI drafts the insights; validation checks guard accuracy, freshness and traceability, so stakeholders use the summaries without re-checking the numbers. (PRD-001) - A human, not autonomy: Compliance reviews for schools. The agent handles routine clauses; ambiguous and high-risk ones go to a reviewer. Automate the volume, not the liability. (PRD-002) # Case studies in full ## PRD-001: GenAI analytics for a 3,400-location supply chain - Status: Shipped - Organization: CanPrev (health & wellness supply chain, acquired by Apotex, Feb 2025) · via Trigent - Period: Sep 2025 — present - Role: Technical PM + architect. Owned the shipment platform as engineer and product owner. - Web page: https://semmal.one/#case-canprev ### Summary - Problem: Ops and finance ran on spreadsheet reporting that took days. - What was done: Shipped a GenAI analytics layer that turns shipment, inventory and fulfillment data into natural-language insights, with a quality bar and validation checks. - Outcome: Reporting went from days to hours, and stakeholders trust the numbers without re-checking them. ### Outcomes - Days → hours operations reporting time - Trusted summaries used without manual re-verification ### Context CanPrev runs a health and wellness supply chain serving about 3,400 locations in Canada. Operations and finance stakeholders depended on manual, spreadsheet-based reports built from shipment, inventory and fulfillment data. ### The problem Answers arrived days late and every number needed a manual check, so decisions lagged the operation they were meant to steer. An AI summary nobody trusted would only move the re-checking somewhere else. ### Decisions and trade-offs 1. Define the quality bar before the model: accuracy, freshness, and traceability to source data. - Why: For finance and ops, a fluent but unverifiable summary is worse than a slow spreadsheet. - Trade-off accepted: More upfront work on data plumbing and checks before anything looked impressive in a demo. 2. Build validation checks into the pipeline instead of relying on the model’s output. - Why: Stakeholders should be able to trust a summary without re-verifying the underlying numbers. - Trade-off accepted: Narrower scope at launch; only questions the data could answer with confidence. 3. Prioritize with RICE and direct input from ops and finance leadership. - Why: Logistics and reporting requirements compete; scoring made the trade-offs explicit and shared. - Trade-off accepted: Some requested reports explicitly deferred. ### What shipped - GenAI analytics layer: natural-language insights over shipment, inventory and fulfillment data - FastAPI microservices for shipment-event processing, integrated with the core Laravel platform via REST - Specs and roadmap that engineering built from ### AI quality and guardrails - Output quality bar: accuracy, freshness, traceability of source data - Validation checks on AI-generated summaries before they reach stakeholders ### Product and engineering split - Product: - Problem framing with ops & finance leadership - RICE prioritization and success metrics - Specs and roadmap - AI output quality bar - Engineering: - Architecture of the analytics layer - FastAPI shipment-event microservices - REST integration with the Laravel core - Validation checks ### What he would do next Add offline evals on a golden set of real ops questions, so every prompt or data change is tested against the same bar before release. Competencies: Shipped LLM / GenAI products; Evals & AI output quality; Roadmap, prioritization & PRDs; Platform & technical depth; Cross-functional leadership; Discovery & problem framing Summarized from his résumé and professional experience. ## PRD-002: Compliance Copilot: grounded AI with a human in the loop - Status: Shipped - Organization: Public School Works (K-12 EdTech compliance) · via Trigent - Period: Oct 2024 — Sep 2025 - Role: Architected the agent and its workflows; set PRD standards for the engineering team. - Web page: https://semmal.one/#case-copilot ### Summary - Problem: US K-12 institutions reviewed regulatory documents by hand, and every decision had to stay traceable and auditable. - What was done: Architected a RAG agent that extracts and classifies regulatory clauses, handles routine cases autonomously and escalates the risky ones to people. - Outcome: Less manual review time, auditable outputs, +50% engineering throughput and −30% technical debt. ### Outcomes - ↓ manual compliance-document review time - +50% engineering throughput (AI-assisted docs, standardized PRDs) - −30% technical debt, with NPS up (“Stability First” roadmap) ### Context Public School Works serves US K-12 institutions with compliance workflows. Regulations change often and vary by state, and reviewers answer for every decision. ### The problem Reviewing institutional documents clause by clause was slow and manual. A black-box AI answer would not survive an audit, and hard-coding each regulatory change into the platform would not scale. ### Decisions and trade-offs 1. Ground every output in the source document through retrieval. - Why: Reviewers must be able to see where an answer came from; traceability is a product requirement, not a nice-to-have. - Trade-off accepted: Answers limited to what the documents support; no free-form generation. 2. Autonomous for routine clauses, human escalation for ambiguous or high-risk ones. - Why: Automate the volume without automating the liability. - Trade-off accepted: Some cases still need a reviewer; the design optimizes review effort rather than removing it. 3. Keep regulatory rules in modular configuration, outside the core platform. - Why: US regulations change ad hoc; the core should not be redeployed for each change. - Trade-off accepted: More design work up front on the configuration model. 4. Standardize data-backed PRDs with strict edge-case definitions. - Why: Mid-sprint rework came from ambiguous specs. - Trade-off accepted: More writing before building; paid back in +50% throughput. ### What shipped - RAG compliance agent with an API-driven LLM parsing pipeline that extracts and classifies regulatory clauses - Agentic, function-calling workflows for routine classification - Human-in-the-loop escalation to compliance reviewers - Modular regulatory configuration - “Stability First” roadmap, including a cross-functional workflow performance audit ### AI quality and guardrails - Retrieval grounded in the source document so outputs are traceable and auditable - Escalation rules for ambiguous and high-risk cases ### Product and engineering split - Product: - Human-in-the-loop policy: what is automated vs escalated - PRD standards and edge-case definitions - “Stability First” roadmap and performance audit - Engineering: - RAG architecture and LLM parsing pipeline - Function-calling workflows - Modular configuration model ### What he would do next Measure review time per document and escalation precision explicitly, and publish them as the agent’s launch and regression gates. Competencies: RAG, agents & tool use; Trust, safety & human-in-the-loop; Evals & AI output quality; Shipped LLM / GenAI products; Roadmap, prioritization & PRDs; Cross-functional leadership Summarized from his résumé and professional experience. ## PRD-003: Native Zoom integration: +22% MRR in two quarters - Status: Shipped - Organization: Omnify (B2B SaaS for service businesses) - Period: 2021 — 2024 - Role: Owned 0→1 product and engineering end to end. - Web page: https://semmal.one/#case-zoom ### Summary - Problem: Post-pandemic, customers needed to run services online, and the platform couldn’t host them natively. - What was done: Owned a native Zoom integration from zero to one, product and engineering. - Outcome: +22% MRR within two quarters. ### Outcomes - +22% MRR within two quarters ### Context Omnify serves businesses that sell classes, appointments and services. The pandemic moved much of that demand online almost overnight. ### The problem Merchants were stitching Omnify to video tools by hand, which meant friction for them and value leaking out of the platform. ### Decisions and trade-offs 1. Build a native integration rather than point merchants to a workaround. - Why: The demand was immediate and core to how merchants now sold. - Trade-off accepted: Engineering capacity pulled from other roadmap items for the quarter. 2. Own product and engineering end to end. - Why: Speed mattered; one owner removed hand-off delay while demand peaked. - Trade-off accepted: Concentrated knowledge; documented the integration for the team afterwards. ### What shipped - Native Zoom integration inside the Omnify platform ### Product and engineering split - Product: - Spotting and sizing the post-pandemic demand - Scope and launch - Engineering: - Integration architecture and build ### What he would do next Instrument per-cohort retention for merchants using the integration, to separate new revenue from pulled-forward revenue. Competencies: Business impact & monetization; 0→1 ownership in ambiguity; Platform & technical depth Summarized from his résumé and professional experience. ## PRD-004: Omnify Payments & Credits: a new revenue stream - Status: Shipped - Organization: Omnify - Period: 2021 — 2024 - Role: Architected payments and the refund system; owned the product decisions. - Web page: https://semmal.one/#case-payments ### Summary - Problem: Merchants processed payments externally, so Omnify earned nothing on transactions, and refunds cost merchants cash. - What was done: Architected native checkout on Stripe Connect and a wallet-based refund system with fraud-pattern detection. - Outcome: A new high-margin transaction-fee revenue stream and +18% ARPU/upsell conversion. ### Outcomes - New high-margin transaction-fee revenue stream - +18% ARPU / upsell conversion ### Context Global merchants on Omnify used external payment processors, and refunds meant money leaving the business. ### The problem Revenue the platform enabled was being captured elsewhere, and churn-driven refunds hurt merchants’ cash flow and lifetime value. ### Decisions and trade-offs 1. Move merchants to native checkout on Stripe Connect. - Why: Owning checkout creates a transaction-fee revenue stream and a smoother buyer experience. - Trade-off accepted: Migration effort for merchants; payments compliance and reliability become Omnify’s responsibility. 2. Refund to a wallet (Omnify Credits), with automated fraud-pattern detection. - Why: Keeps value inside the platform and protects merchant LTV. - Trade-off accepted: More product surface to explain; fraud rules need ongoing tuning. ### What shipped - Omnify Payments on Stripe Connect (native checkout) - Omnify Credits: wallet-based refunds - Automated fraud-pattern detection ### Product and engineering split - Product: - Revenue model and merchant migration - Refund policy design - Engineering: - Stripe Connect architecture - Wallet ledger - Fraud-pattern logic ### What he would do next Track take rate and refund-to-credit redemption as first-class metrics alongside ARPU. Competencies: Business impact & monetization; Platform & technical depth; Trust, safety & human-in-the-loop Summarized from his résumé and professional experience. ## PRD-005: Enterprise SSO & RBAC: +30% enterprise adoption - Status: Shipped - Organization: Omnify - Period: 2021 — 2024 - Role: Engineered the architecture; owned the enterprise requirements. - Web page: https://semmal.one/#case-sso ### Summary - Problem: Enterprise buyers in the US and APAC needed SSO and granular permissions before they could adopt. - What was done: Built multi-tenant SSO with granular role-based access control. - Outcome: +30% adoption growth in the enterprise segment. ### Outcomes - +30% enterprise-segment adoption (US & APAC) ### Context Omnify’s enterprise pipeline across US and APAC markets was gated on identity and access requirements. ### The problem Without SSO and fine-grained roles, security reviews stalled deals and larger teams couldn’t roll the product out safely. ### Decisions and trade-offs 1. Multi-tenant SSO architecture with granular RBAC, rather than per-customer customizations. - Why: One model scales across enterprise customers and regions. - Trade-off accepted: Larger initial build than a one-off integration for the first customer. ### What shipped - Multi-tenant SSO - Granular role-based access control ### Product and engineering split - Product: - Enterprise requirements - Rollout - Engineering: - Multi-tenant identity architecture - RBAC model ### What he would do next Add admin-side audit logs and usage analytics, the next items enterprise buyers typically ask for. Competencies: Platform & technical depth; Business impact & monetization; Trust, safety & human-in-the-loop Summarized from his résumé and professional experience. ## PRD-006: Activation: −40% onboarding drop-off - Status: Shipped - Organization: Omnify - Period: 2021 — 2024 - Role: Owned the analysis and the onboarding redesign. - Web page: https://semmal.one/#case-activation ### Summary - Problem: New users dropped off during first-time onboarding, and client onboarding was slow. - What was done: Used Mixpanel cohort analysis to find the friction, redesigned onboarding, unified support tooling and automated first-response triage. - Outcome: −40% activation drop-off, better Day-1 retention, −60% client onboarding time. ### Outcomes - −40% activation drop-off - ↑ Day-1 retention - −60% client onboarding time ### Context Growth depended on new merchants reaching value fast, and on support keeping up with new clients. ### The problem The first-time flow lost users before activation, and fragmented support tooling slowed every new client’s onboarding. ### Decisions and trade-offs 1. Let cohort data pick the fix: find the step where users drop, then redesign that step. - Why: Opinions about onboarding are cheap; the funnel shows where users actually leave. - Trade-off accepted: Slower to start than shipping an intuitive redesign. 2. Unify support tooling and automate first-response triage. - Why: Most client-onboarding delay was waiting, not work. - Trade-off accepted: Support team retraining on one tool. ### What shipped - Redesigned first-time user onboarding - Unified customer-support tooling - Automated first-response triage ### Product and engineering split - Product: - Cohort analysis and problem framing - Onboarding redesign - Engineering: - Instrumentation - Triage automation ### What he would do next Today I would make first-response triage an LLM agent with an eval gate. That is the spec case study below. Competencies: Metrics, analytics & experimentation; Discovery & problem framing; Business impact & monetization Summarized from his résumé and professional experience. ## PRD-007: 15+ products, end to end - Status: Shipped - Organization: Independent (retail & service businesses) - Period: May 2019 — Jan 2021 - Role: Sole engineer and product decision-maker. - Web page: https://semmal.one/#case-freelance ### Summary - Problem: Small retail and service businesses needed digital products without a product team. - What was done: Ran discovery, architecture, build and launch for 15+ products; built an inventory-synchronization engine with rules-based demand logic. - Outcome: 15+ products launched; −40% manual operational overhead for retail clients. ### Outcomes - 15+ products shipped end to end - −40% manual operational overhead (retail clients) ### Context Clients were owners, not product teams, so every product started from a conversation about their business. ### The problem Retail clients spent hours keeping inventory in sync by hand. ### Decisions and trade-offs 1. Rules-based demand logic rather than a complex forecasting model. - Why: Small businesses needed something reliable and explainable they could run themselves. - Trade-off accepted: Less sophisticated predictions, in exchange for trust and maintainability. ### What shipped - 15+ digital products - Inventory-synchronization engine with rules-based demand logic ### Product and engineering split - Product: - Discovery with business owners - Scope and launch - Engineering: - Architecture and full-stack build Competencies: 0→1 ownership in ambiguity; Discovery & problem framing; Platform & technical depth Summarized from his résumé and professional experience. ## SPEC-01: Spec: eval-first launch plan for an AI support-triage agent - Status: Spec work (not shipped, no results claimed) - Organization: Spec work, not shipped. Extends the first-response triage I automated at Omnify. - Period: Spec · 2026 - Role: Written as the PM owning the agent’s launch. - Web page: https://semmal.one/#case-spec-evals ### Summary - Problem: Rule-based triage misroutes long-tail tickets; an LLM agent could do better, but only if quality is measurable before launch. - The plan: A launch plan where the eval set, rubric and gates are defined before the prompt is written. - Why it is here: Illustrative: shows how I would define “good”, prove it offline, and protect it online. ### Outcomes - Spec no shipped metrics: this is a plan, not a result ### Context Assume a B2B SaaS support queue where first-response triage is already automated with rules (as I built at Omnify). The team wants an LLM agent to classify intent, pick a route and draft a first reply. ### The problem Without an agreed definition of a good triage, every prompt change is a vibe check, and one confident misroute on a billing or security ticket costs more than the automation saves. ### Decisions and trade-offs 1. Write the eval set before the prompt: 300 real, anonymized tickets labelled by support leads with the correct route and severity. - Why: The golden set is the spec. It turns “better triage” into a number the team agrees on. - Trade-off accepted: Two weeks of labelling before any model work. 2. Score with a rubric: route correct, severity correct, policy-safe reply. LLM-as-judge only after it agrees with human graders on a calibration sample. - Why: Judges drift; calibration keeps automated scoring honest. - Trade-off accepted: Ongoing cost of periodic human re-grading. 3. Risk-tiered autonomy: billing, security and legal intents always go to a human. - Why: The cost of a mistake differs by intent; automation should follow the risk, not the volume. - Trade-off accepted: Lower automation rate than the maximum possible. ### What the plan contains - Offline gate: route accuracy and severity recall on the golden set must beat the rules baseline; zero policy violations on the red-team subset - Shadow mode for two weeks: agent predicts, humans act, disagreements reviewed daily - Online metrics: misroute rate, time to first response, reopen rate, agent-assist acceptance - Rollback trigger: misroute rate above baseline for two consecutive days ### AI quality and guardrails - Golden set + rubric + calibrated LLM judge - Red-team subset for policy and safety - Every release re-runs the full eval; regressions block the launch ### Product and engineering split - Product: - Definition of good (rubric) - Risk tiers and launch gates - Online metric tree - Engineering: - Eval harness design - Shadow-mode logging - Judge calibration ### Next step Happy to walk through this live, or adapt it to your product’s agent. Competencies: Evals & AI output quality; Trust, safety & human-in-the-loop; RAG, agents & tool use; Metrics, analytics & experimentation; Roadmap, prioritization & PRDs Spec work: a plan written to show how he approaches evals and launch gates. No results are claimed. ## Optional - [Résumé](https://semmal.one/resume.html) - [Structured profile (JSON)](https://semmal.one/profile.json)