I came to product through systems engineering. Understanding how systems fail taught me how products succeed.

Tharun Kumar S
Hyderabad, India · GMT+5:30
I spent three years at Infosys writing automation scripts before I'd ever heard the phrase "product management." The work looked like plumbing: JavaScript and Python stitched between systems that weren't built to talk to each other. But the questions it left me with were product questions. What breaks first? Who notices when it does? I got good at tracing a small missed edge case back to the moment, months earlier, when nobody had asked who owned it.
At IIM Calcutta I headed the Internet Solutions Group: infrastructure for a 12-person team and 5,000+ campus users. The MBA gave me a vocabulary for tradeoffs; the ISG gave me the actual education. Migrating five legacy applications from AWS to Azure without downtime taught me less about cloud infrastructure than about incentives. Every outage we avoided came from someone caring enough to flag a risk before it became one, and nothing in a process document made that happen. I started paying closer attention to what makes people act, not just what we ask of them.
That instinct found its sharpest test at Simpl, on a consumer credit product. I sat through 100+ interviews across four delinquency cohorts expecting to hear about intent: people who knew what they'd signed up for and gambled anyway. Instead I kept hearing confusion. Comprehension failures masquerade as fraud: the credit-risk model was scoring a communication problem as a character problem, and nobody upstream could see the difference from a dashboard. That finding reshaped a go-to-market decision. It's the reason I default to reading behavior before I trust a metric.
It's the same pattern across everything I've worked on since: a marketplace whose registered users couldn't find a product that already existed for them, a BNPL model that treats a thin credit file as a red flag instead of a design choice, an LLM I refused to let touch the actual math because explaining money and computing it are different jobs with different failure modes. I'm less interested in whether a product works in theory than in where real people get stuck using it. I'm stubborn about the idea that most of what looks like a demand problem is actually a discovery, trust, or comprehension problem wearing a disguise.
I'm based in Hyderabad and open to PM, APM, and product-adjacent roles in fintech, payments, lending, and AI.