Why Paytm Won the Night Demonetisation Happened

November 8th, 2016. 8 PM. Prime Minister Narendra Modi walks onto live television in his trademark white kurta and delivers one of the most consequential announcements in post-liberalisation India. Starting at midnight, ₹500 and ₹1,000 notes will stop being legal tender. Overnight, 86 per cent of the country's cash becomes worthless paper.

Within minutes, panic erupts across the country. ATM queues stretch around entire blocks in Delhi, Mumbai, and Bengaluru. Shopkeepers refuse to accept the old notes even for the last thirty minutes they are still legal. Autos won't run. Chai stalls can't make change. Weddings scheduled for the next week halt mid-preparation. Small businesses freeze. An entire economy that ran on cash suddenly has nowhere to go.

And then, within 48 hours, one app's downloads exploded. Suddenly, you saw it everywhere. At paan shops in Ghaziabad. On vegetable carts in Mulund. At temple donation boxes in Bengaluru. At petrol pumps in tier-3 cities that had never seen digital payments before. That giant orange-and-blue QR code taped to every counter in India. Paytm. A company that had been building quietly for years was now on the front pages of every newspaper with a giant headline — Paytm karo.

Paytm did not win the demonetisation moment because of luck. Getting lucky on the biggest single night in Indian payments history was not an accident. It won because of how the company had been built from day one. And understanding that difference — the difference between a company built product-first and one built problem-first — is the most important starting lesson any founder can learn.

Two very different ways to start a company

There are basically two ways to start a business. Most founders pick one of them instinctively, without realising they are choosing. The two paths diverge sharply, and the choice shapes everything the business does for the next decade.

The first way is to have a cool product idea and then go looking for people who might want it. A founder watches a demo of a new AI tool, gets excited, imagines an Indian version, builds a prototype, and then starts trying to figure out which customer segment might pay for it. The founder is in love with the thing they can build. The customer is an afterthought, to be discovered later.

The second way is to start with a problem real people already have and then build something — anything, in whatever form works — that solves it. A founder watches her mother argue with the vegetable seller over change for fifteen minutes every Saturday morning, sees the same scene play out at the petrol pump later that day, realises that the missing-change problem costs Indian households a cumulative billions of hours a year, and starts thinking about what could solve it. The founder is in love with the problem. The product is an instrument, not the destination.

These sound similar in a brochure. They lead to very different companies.

What Vijay Shekhar Sharma was actually building

When Vijay Shekhar Sharma started Paytm in 2010, he was not building a payments app. He was fixated on a specific Indian problem — why were small transactions in India so inefficient? The paan shop had no change. The auto-driver had no change. The kirana store had no change. Everyone argued about ₹5 or ₹10 every single transaction. Digital recharge for prepaid phones was the first wedge; topping up your mobile balance at midnight was a real pain if the local shop was closed. So Paytm started as a mobile recharge service. That was the tool. The problem was the friction of small-value cash payments in a country where cash was king.

Over the next six years, as the company grew, it kept returning to that same underlying problem in new forms. Bill payments. QR-code-based merchant payments. A digital wallet. Eventually, a full payments bank. At every pivot, the problem stayed the same — cash transactions in India are painful at the margins — while the product kept shifting to whatever solved that problem better. By November 2016, Paytm had already signed up hundreds of thousands of small merchants in tier-2 and tier-3 cities, had already trained its distribution to onboard a paan shop with a single QR code, and had already built the back-end infrastructure to handle a massive surge in transactions.

When demonetisation happened, Paytm did not have to build anything new. It just had to scale what it had been quietly building for six years. Every paan shop already had the sticker. Every merchant had already been on-boarded, even if they hadn't been using the system actively. When the cash vanished, the infrastructure to receive digital payments was already there — and that infrastructure had been built to solve an everyday problem, not to capitalise on an event nobody could have predicted.

Why this is the definition of luck favouring the prepared

There is a lovely old saying attributed to Louis Pasteur — chance favours only the prepared mind. Demonetisation was an extraordinary chance event. Nobody in 2010 could have predicted it. But the founders of Paytm had spent six years preparing for the general problem of cash friction in India. When the specific chance event that collapsed the cash economy happened, they were the only company in India ready to absorb the demand surge. That is not luck. That is preparation meeting opportunity.

Contrast this with product-first competitors during the same moment. Several digital wallets and payment startups existed in India in 2016. Most of them had been built around specific product bets — a particular interface, a particular niche, a particular technology. When demonetisation happened, they could not scale because their infrastructure had been built for a narrower audience. Their on-boarded merchant base was a fraction of Paytm's. Their technology could not handle the transaction volume. Their customer support was not ready for millions of first-time digital-payment users asking basic questions. The product-first approach had given them elegant solutions to specific problems; but when the general problem suddenly got ten times bigger overnight, elegant-but-narrow was a handicap.

Why problem-first businesses are antifragile

There is a term from the writer Nassim Taleb — antifragile. Something antifragile does not just survive shocks; it gets stronger from them. Problem-first companies tend to be antifragile. When the market shifts, when a pandemic hits, when a regulation changes, when a competitor folds — the problem they were solving does not go away. Often the problem gets bigger. And the company that was already solving it gets a bigger canvas to paint on.

Paytm in 2016 is the textbook example. But you can see the same pattern elsewhere. Companies that were solving the problem of remote work when the pandemic hit in 2020 did not have to pivot — they had to scale. Zoom. Slack. Atlassian's tools. In India, you saw it with companies like Zerodha (the retail-investing surge during lockdown), Dream11 (the explosion of fantasy sports during cricketless days), and BigBasket (the necessity of grocery delivery when people could not step out). None of these companies suddenly discovered their problem in March 2020. They had been solving it for years. The pandemic simply changed the size of the canvas.

The difference in how problem-first founders talk

There is a subtle cultural tell that distinguishes product-first founders from problem-first ones. Listen to how they introduce their company. A product-first founder will say, "We are building an app that lets you..." A problem-first founder will say, "Have you noticed how annoying it is when...?" The first opens with the tool. The second opens with the pain. Three seconds in, you already know which kind of founder you are talking to.

Problem-first founders also tend to use their product differently when they talk about it. They say things like, "Right now we do X, but if customers want Y, we will build Y." They are comfortable imagining a future version of their company that looks nothing like the current one. Product-first founders, by contrast, tend to attach their identity to the specific product. "We are the app for Z" — and when Z stops being useful, they either cannot pivot, or they pivot so awkwardly that the whole organisation resists.

How to tell if you are building problem-first or product-first

Most founders believe they are building problem-first. Almost all of them are lying to themselves. There is a simple test that reveals the truth. Ask yourself this one question — if tomorrow, I discovered that the customers I am targeting actually care about a different problem, and the product I have spent the last six months building is not useful to them, what would I do?

A problem-first founder will answer, without much hesitation, "I would rebuild the product." A product-first founder will hedge — "Well, I think the product is still useful..." or "Let me find different customers for it..." The hedge is the tell. Product-first founders protect the product. Problem-first founders protect the customer. Only one of those two choices survives a decade.

This is hard. It is hard because once you have built something, killing it feels like killing a part of yourself. The lines of code are yours. The name is yours. The pitch deck has been shown to investors. The product feels real in a way the underlying problem doesn't. The customer's pain is invisible; the product is sitting on your screen. The natural human bias is to protect the visible thing at the expense of the invisible thing. Great founders invert this instinct. They treat the invisible thing (the customer problem) as the real thing, and the visible thing (the product) as a disposable instrument.

💡 Insight: Product-first founders build something and hope customers come. Problem-first founders find a crowd in pain and then build whatever quiets it. Only one of these survives decades.

That single sentence captures why, ten years from now, most of today's "hot startups" will be forgotten while a few quiet problem-first companies will be the new giants. The market rewards depth of problem more than novelty of product. Every year, some product-first company has a glorious launch, raises a big round, gets magazine cover stories, and then disappears quietly when the product stops being interesting. Every year, a few problem-first companies keep compounding, keep pivoting, keep serving the same problem in new forms, and eventually become household names.

What this means for a student thinking about starting

If you are in college dreaming about starting something, the single most useful exercise you can do is not to come up with an idea. It is to find a problem. Pick one. Something that frustrates you or the people around you so consistently that they have stopped noticing the frustration. The way small businesses struggle with GST compliance. The way college hostels run their mess operations so badly. The way small-town parents have no reliable source of information about the engineering entrance exam their children are preparing for.

Then — and this is the counter-intuitive step — do not immediately think about the product. Think about the problem for two or three months. Talk to twenty people who have it. Understand why previous attempts at solving it have failed. Figure out what makes this problem hard. Only when you genuinely understand the problem should you let yourself think about what form the solution should take. And when you build, build the smallest possible version of the solution, so you are free to change it as you learn more.

That is what problem-first looks like when chance finally shows up. It looks boring. It looks like years of quiet on-boarding of paan shops in Ghaziabad. It looks like a QR code that half the country ignored until the day they suddenly couldn't. It looks like the founder still wearing the same kurta she was wearing six years ago, walking into a crisis she did not predict but was somehow ready for. The problem you fall in love with in your 20s is the problem you will still be solving in your 40s. Pick well.

🎯 Closing Insight: Start with the pain, not the product. The product will have to change. The pain rarely does.