Developer to Product Manager — Always a Builder at Heart
I started as an engineer because I liked the idea of building something. My stint at SAP, working in the UX engineering team, taught me to put the user’s experience above all — and that’s how I started asking: who are we building for, and what problem are we actually solving for them? Knowing that felt like the key to building better products.
Today, building platform products at ThoughtSpot, I ask the same question — and I’ve added another: what would customers lose if I didn’t build this? Together, they’ve shaped the products I’ve built here, and made our platform enterprise-ready.
That love for building from scratch, and for learning where the world is heading, is why I’m building this portfolio too — a product of its own, built with my engineering team of “Claude” agents.

Experience
AUG 2024 — PRESENT
ThoughtSpot
Senior Product Manager
Co-own platform product at ThoughtSpot, shipping enterprise-ready features like Collections — a content governance system — and notification whitelabeling, together unlocking $19M in ACV. Also invested deeply in identity - building IAM features like MFA, SCIM and RBAC - hardening AuthN/AuthZ across the platform.
JUN 2016 — MAR 2023
SAP Labs India
Senior Software Developer
Spent seven years building enterprise SAPUI5 Fiori Elements and SAPUI5 Suite Controls used across 1000+ ERP applications. Rebuilt SAPUI5 Gantt Chart control’s architecture to cut load times from 102 seconds to 10, and filed two US patents on Efficient test automation and PDF printing of large HTML screens.
Education
2023 – 2024
Indian School of Business
PGP · Information Management
Dean's List · top 10% of cohort · National Semi-Finalist, Flipkart Wired 7.0
2012 – 2016
Government Engineering College, Thrissur
B.Tech · Computer Science & Engineering
Certificate of Excellence, University of Calicut · top 5% of cohort
Skills
Product
Technical
Tools
I’d love to work together if you value
01
Solving the real problem
I dig past the request to find what the customer's problem actually is — the job to be done — and solve for that. That includes understanding what's lost if we don't build it at all, not just what's gained if we do.
02
Saying no with data
I use lightweight frameworks to kill good ideas in favor of great ones, and I'd rather ship one thing well than three things adequately.
03
Staying close to the build
I stay hands-on with the how, not just the what — it keeps my product judgment honest instead of theoretical.