Product & Business

Most people in product have to take an engineer's word for what's feasible. Most engineers have to take a product manager's word for what's valuable. I've done both jobs, at the same company, in that order — first researching and pitching what should be built, then joining the engineering side and building it. That sequence changed how I work more than any single skill I've picked up. It taught me the thing that's hard to learn from one side alone: the cost of a requirement. When someone describes a feature in a meeting, I'm not hearing a wish, I'm hearing an estimate. I know which parts of that description are cheap and which parts quietly triple the timeline. And when I'm the one making the pitch, I write it knowing an engineer is going to have to live with what I wrote. My product work has run through market research, competitive analysis, technical feasibility assessment, and the stakeholder conversations that connect them. I've identified AI feature opportunities, pressure-tested them against what the engineering team could realistically deliver, and made the case to the people who decide. Several of those proposals were approved and built. The ones that weren't taught me more — usually that I'd found a real problem and proposed the wrong solution to it, or the right solution at the wrong time. Partnerships and the commercial side. I've led strategic partnerships across property and education — working with developers, property owners, and schools to match housing supply against student demand. The work looked commercial from the outside and analytical from the inside. Most of what determined whether a partnership was worth pursuing came down to reading the data honestly: where demand actually sat, not where we'd assumed it sat, and whether the two parties wanted things that could genuinely overlap. I've also run international exchange programs end to end, matching participants to host organisations across countries, cultures, and time zones. Aligning what a candidate wanted against what an organisation could offer, and being the person responsible when those two things didn't line up. It's unglamorous work and it's the closest thing I've done to pure stakeholder management. What connects it. Translation. Between business and engineering. Between what one party needs and what another can offer. Between what a client describes and what they actually mean. The hardest part of a technical project is almost never technical — it's the gap between the words in the brief and the thing that would actually solve the problem. Closing that gap is the work I'm best at and the work I want more of. I speak six languages — Tamil, English, Malayalam, Hindi, Arabic, German. That matters less as a party trick than as a habit. Being fluent in several languages means being permanently comfortable as the person in the room who has to adapt, and that turns out to be most of what client-facing work is. How I think about it. Chess is the honest metaphor. Limited information, an opponent running their own plan, and the discipline to think several moves out rather than react to the last thing that happened. Good product decisions and good chess share a failure mode: both go wrong when you optimise for the immediately visible gain and don't look at what it costs you three moves later.