I grew up in Rajkot taking things apart. Radios, toys, whatever I could get my hands on. Not to break them — to understand them. To see the mechanism behind the surface.
Amazon was where I learned what that instinct means at scale.
I joined as a software engineer in 2013, after BITS Pilani, part of a team that owned the core product data feed processor. The thing ingests product data — descriptions, images, prices, attributes — for the entire Amazon catalog. At the time, that was roughly 230 million products. Every single listing on the site, across every category, passes through this pipeline.
When a system is that large, "making a change" isn't a decision you make lightly. A bug at that level doesn't affect one customer. It affects everyone. The feedback loops are slow. The blast radius is enormous. You learn a particular kind of humility.
Listings 2.0
The first big project I owned was what we internally called Listings 2.0 — a redesign of the data model underlying how product attributes are stored and served.
The legacy system had accumulated years of shortcuts. Different categories used different schemas. The same attribute might be stored in three different places depending on when it was added. Querying it was expensive. Maintaining it was expensive. And the cost was real: $4.7 million annually in infrastructure overhead, when we finally did the analysis.
Listings 2.0 was a migration — the unglamorous kind of project that never shows up in a product review. No user-visible feature. No press release. Just: move the data, deprecate the old system, make the thing cheaper and more maintainable. The kind of work that makes every future project easier, that no one notices until it's done.
I learned something from that project I still carry: the highest-leverage engineering work is often the work that removes friction for future work. Not building the flashy thing — building the foundation that lets someone else build the flashy thing faster and more reliably.
Textbook Rentals
The project I'm proudest of from Amazon is Textbook Rentals.
Amazon had been selling textbooks. But students weren't buying — they were borrowing, sharing, photocopying. The economics of college textbooks are brutal: prices run $150, $200, $300, for a book you'll use for one semester. The whole model was broken.
Rentals was a bet that Amazon could disrupt it. Rent the textbook for the semester, return it, pay a fraction of the price. Simple idea. Complex to execute: tracking physical books across a return cycle, managing condition grading, pricing the rental vs. the sale, handling late returns.
I worked on the inventory and pricing side. The net value we calculated on that business — balancing rental revenue against the cannibalization of outright sales, against return logistics costs — came out to over $100 million in the first phase.
But more than the number, what I remember is the moment when the economics clicked into place. When we found the pricing model that was good for Amazon and good for students and sustainable. That three-way alignment — the business, the user, the unit economics — is what I went looking for in every product problem after that.
What I carried out
Amazon gave me two things that have compounded ever since.
The first is a deep intuition for systems. Large-scale systems don't behave like small-scale ones. They have emergent properties, failure modes, latency characteristics that only appear at scale. Understanding that — really understanding it, from having written the code and watched the dashboards at 2am — changes how you think about product decisions.
The second is a respect for the work that makes future work possible. Migrations. Refactors. Data model improvements. The unglamorous infrastructure that no one talks about but everyone depends on. Some of the most important product decisions I've made since weren't about features — they were about foundations.
I left Amazon in 2015 to pursue an MBA at IIM Ahmedabad. The question I was asking then was: I know how to build. Do I know how to decide what to build?