I spent two years at Paytm. Started in marketing. Moved to product after six months. By the end, I owned the full user lifecycle across 350M+ users. This is a note about two specific problems I worked on during that time and what I actually learned from them.
The retention problem nobody was naming
Paytm had a new user problem. People were signing up. They'd make one transaction, maybe poke around the app, and then disappear. The numbers showed it clearly: drop-off was steep in the first week.
I wanted to know why. The dashboards told me the "what" but not the "why." So I talked to users. Qualitative research, mostly conversations, to understand what was happening between download and churn.
The pattern was consistent. Users felt unsure about the interface. They didn't trust the app yet. They needed a reason to come back a second and third time. But here's the data point that changed my approach: users who completed 2 transactions almost always stuck around. Two. Not five, not ten. Two transactions was the inflection point for retention.
I've since seen this pattern at other companies. At ShopX, the retailer activation threshold was 2-3 orders. The number is always lower than your instinct says it should be. If I had designed the Paytm program for a 5-transaction threshold, the streak would have been too long and drop-off would have killed it.
So the problem reframed itself. I didn't need to make people love the app on day one. I needed to get them past two transactions before they forgot about it.
Building the habit loop
I designed a daily-streak gamification program. The idea was simple. Give new users a small incentive to come back each day and complete an action. Open the app, do a UPI payment, recharge a phone number. Each action earned cashback or reward points.
The rewards were segmented by user behavior. Near-churn users got direct cashback because they needed the strongest nudge. Active users got reward points. Somewhat active users got scratch cards with brand vouchers or discount codes. The logic was that you shouldn't spend the same money on someone who's already engaged versus someone who's about to leave.
I tested two game formats. The daily streak and a spin-the-wheel.
The daily streak worked. Users came back. Transaction frequency went up. 5% DAU growth on the gamification cohort and 20% transaction volume lift on tested cohorts.
The spin-the-wheel did not work. Not version one. Not version two. Not versions three, four, or five.
Why the spin-the-wheel failure matters more than the streak success
This is the part I think about the most. I ran five versions of spin-the-wheel. Different reward amounts, different triggers, different visual treatments. None of them moved the metrics. And I kept going.
Why? Partly because the format felt engaging. People liked spinning the wheel. They smiled. It felt fun. But fun and retention are not the same thing. The daily streak created a behavior pattern. Come back tomorrow to keep your streak alive. Spin-the-wheel was a one-time dopamine hit with no continuity. Users spun, got a coupon, and had no reason to return the next day.
I should have killed it after the second version. The signal was clear by then. But I kept thinking a different reward structure would fix it. It wouldn't have. The problem was the mechanic, not the prize.
The lesson: "feels promising" is not evidence. Three extra versions of spin-the-wheel burned time and budget on conviction instead of signal. Now when I run experiments, I set a kill threshold before the first variant launches. If two variants miss, the format is dead. Move the budget to what's working.
The homepage: when the real problem is organizational
The second project taught me something completely different. Sometimes the thing that looks like a product problem is actually an org problem. And no amount of A/B testing will fix it.
Paytm's homepage was shared real estate. Multiple teams used it to promote their own initiatives. Payments had banners. Lending had widgets. Commerce had deals. Marketing ran rotating promotions. Everyone had their own experiments live at the same time.
The result was chaos. The page was visually cluttered. Users scrolled past most of it. My team was responsible for overall homepage visitors and transaction numbers. But we had no authority over what appeared on the page.
I did something uncomfortable. I put together a proposal to leadership and asked for full control. Not shared control. Full control. The proposal had two parts: scroll-depth data showing the current page wasn't working (most users never reached the bottom third), and a forecast with specific numbers. Give us the page. Hold us to these results.
Leadership approved it. That was the hardest part.
What we actually changed
The redesign wasn't dramatic. We reorganized, not rebuilt.
Revenue levers went to the most visible spots, based on scroll-depth data. The top half of the page got a daily content refresh. New offers, new deals, new creative every day. "What's new today" as a simple motivation to open and scroll. The bottom half stayed consistent. Same layout, same categories. Stability below, freshness above.
We streamlined all communications so the page delivered one theme per day instead of five competing messages. And we pushed hard on referral placements.
40% click-through rate lift on tested cohorts.
The trade-offs behind both projects
Cashback budget vs. habit formation. For gamification, the question was always how much cashback is too much. Spend more and the metrics look great but unit economics break. Spend less and the incentive isn't strong enough. I segmented the budget by cohort risk. But I always wondered if I was buying behavior instead of building it. Honestly, it was both. The ratio shifted as users internalized the routine.
Daily homepage refresh vs. operational cost. Refreshing the top fold every day required daily content planning, asset design, and offer coordination. A weekly refresh would have been cheaper to run. I chose daily because the return-visit data supported it, but the ops burden was real and ongoing.
Speed vs. organizational buy-in on the homepage. I could have made smaller changes without asking for full authority. Less political risk. But incremental changes hadn't worked. Everyone was already running incremental experiments. The page wasn't improving because the fundamental issue was ownership, not design.
Fairness across teams. Taking the homepage away from other teams made them unhappy. Their banners disappeared or moved below the fold. That tension never fully went away. The results justified the decision. The politics didn't disappear because of the results.
What I'd do differently now
The area where AI would change my approach the most is experiment velocity. I spent hours every week pulling data, formatting experiment results, and building the case for what to do next. An LLM connected to the experiment dashboard could generate the first draft of that analysis in minutes. Not the decision. The analysis. Flag underperforming variants, surface anomalies, compare cohort responses. I'd still make the call, but I'd get to it faster.
The daily homepage refresh was also labor-intensive. New copy, new creative, new offer framing every single day. Current AI tools could generate and test multiple content variants daily, removing the production bottleneck.
For gamification, I used three broad cohorts for reward targeting. With a behavioral clustering model, you could personalize the reward type and timing per user based on their specific transaction pattern. Not "is she about to churn" but "what incentive has historically worked for users who behave like her." I was doing manual segmentation. The logic was sound. The granularity was limited.
None of this replaces the core judgment. Knowing that 2 transactions was the threshold came from looking at the data and asking the right question. AI wouldn't have asked that question. But once you know the question, AI accelerates everything after it.
This is one of several notes about my product work. The ShopX note covers building a marketplace channel from zero and the messaging mistake that almost killed adoption. The Shippr note covers making invisible operations problems visible through data.