I'm Chiranjeevi Gunturi.

The problem

PayLah was about to launch for the first time, and a viral loop hadn’t been scoped into that first release. The business landed on a $5/$5 referral idea close to launch.

How would you create a user referral feature that moves real money across so many downstream systems, and still works for someone who hasn’t even downloaded PayLah yet?

My part

• Mapped the full user journey for both sender and receiver, down to the SMS each one got.
• The call that mattered: designed the system to need minimal changes from the downstream teams.
• Rallied several teams to build their parts and ship in days.

The result

The referral system drove PayLah’s growth, to 350,000 users, over months of word-of-mouth. The design held for years, and the part I’m proudest of: it stayed stable, it didn’t break.

The opportunity

The money was already in the wallet. People were topping up PayLah and paying friends without ever logging into mobile banking, and that behaviour was spreading. Paying a real business was the natural next step for that same money, and in 2015, there weren’t many references to build from.

How would you let users pay merchants across both web and mobile apps, without ever compromising security?

My part

• Approached it as a platform product for merchants: onboarding, a test sandbox, APIs, messaging standards, and a web SDK so any merchant could integrate, at any size.
• Met with merchants directly, walked their teams through the APIs and sandbox, and cleared issues hands-on. Most went smoothly because the architecture was standard.
• The call that mattered: one secure payment flow no matter where the user started, web or mobile app, with the result returned to them by callback or server-to-server pull.

The result

The MVP went live with the first merchants (NETS, AXS, BusOnlineTicket), then scaled to many more over the next few months, including Qoo10, Singapore’s largest online marketplace. PayLah users could now pay businesses from the single wallet they were already using with friends, which made it the go-to app for payments.

The opportunity

Mapan already had a real business: Indonesian women saving in groups to buy together (arisan). But it was a transaction, not a community. These women were deeply social in real life, so the opening was to build that social fabric into the app itself, and turn belonging into growth. When we asked them, the #1 thing a productive group leader wanted was to be seen that way by her peers, ahead of any feature.

How would you build real belonging for women who are new to smartphones, so the social layer actually drives the business, not just the app?

My part

• Built the Mapan social app from scratch: a ranked news feed, communities, and a follow graph, grounded in weak-ties theory and the way these group leaders already mentor each other.
• Designed the social features around what actually motivates them: recognition, a little competition, and relevant information, drawn from ranking their real problems, not guessing.
• The call that mattered: treated the social layer as a UGC growth loop, not a feed, so a leader’s own posts became activation for the next leaders, then proved it with controlled experiments on which social actions drove more commerce.

The result

The proof held up:

• When a leader’s arisan auto-posted to her network, reactions per post doubled and her followers started their own groups from the same products, lifting sales 45% in the test group.
• Leaders who engaged with a post went on to create over 70% more arisan groups.
• The social-to-commerce link was proven to 99.99% confidence.

Belonging, it turned out, was the growth engine.

The opportunity

The social app gave leaders a reason to show up; commerce was how they earned. But the commerce engine underneath was hard to scale, and it leaned on 1,000+ salespeople on the ground. Then COVID hit, and everything offline had to move online, fast, to keep the business alive. That pressure was also the opening: rebuild the commerce engine so a leader could run her whole business from her phone.

How would you move a thousand-person, on-the-ground sales operation online, and still grow, when your users are running businesses from a single phone?

My part

• Rebuilt the commerce engine from the backend up: order management and the catalog, plus catalog-sharing so a leader could send products straight to her members instead of bouncing between the app and WhatsApp.
• Used real evidence to decide what to build: an 80/20 analysis showing top leaders behave differently, viewing a product up to 15 times more than an average leader, and problem stack-ranking from the leaders themselves.
• The call that mattered: ran the commerce like a product portfolio, launching seasonal plays like Arisan Lebaran end to end, curating the products, the go-to-market, and a preorder feature to read demand before committing stock.

The result

The platform absorbed the work a thousand salespeople used to do, and then grew it: sales roughly tripled in eighteen months. Not every bet won, a bundling experiment didn’t, but the learning fed a later product that did.

The problem

SuperProductManager already worked for people, as a web app and a Chrome extension. When MCP arrived, I did the obvious thing and turned my existing APIs into MCP tools. Then I watched agents use them, and they stalled. A human finds their way between tools; an agent knows only what your last output told it.

How would you redesign tools a human already navigates on instinct, so an agent, which will not select its way out the way a human does, can drive the same workflow end to end?

What I did

• Treated the agent as a new kind of integrator and rewrote the surface for it: the instructions, how the tools are packaged, and what each tool says back.
• The call that mattered: every tool’s output now carries the agent’s next step. Humans select their way out; agents need to be spoon-fed.
• Kept one backend underneath, so the web app, the extension, and the MCP server stay one product with three doors.

The result

SuperProductManager runs as a live MCP server working in Claude and Cursor: the same product judgment, delivered where the agents are doing the building.

The problem

In May 2026 I had to switch the model underneath Product Thinking Space. The switch itself is one config flag. But this product scores other people’s thinking, and scores can drift quietly. A product that grades judgment cannot itself run on vibes.

How do you swap the engine under a live scoring product, so a user who trusted yesterday’s score can trust today’s?

What I did

• Kept a baseline: test suites across three domains, built before I needed them, run on every meaningful change.
• Ran grading and blind grading of the new model against that baseline, plus ablations on reasoning settings and temperature to see what actually moved quality.
• The call that mattered: the flag flipped last. The switch shipped only once the evidence said quality held.

The result

The migration shipped with quality holding steady, and the habit stayed. I test most changes this way; one public write-up covered 100+ test runs comparing models before a switch.

The same habit set the bar inside SuperProductManager: blind-graded internally, its decision-forcing questions beat a frontier model's about 6 times in 10, and 67% cleared the aha bar, the kind of question that makes you stop and rethink.