My story
My first resume took me a week when friends filled a template in a couple of hours: I studied what each section was for, reviewed drafts with industry seniors, and iterated until I could own every word of it. When my friends later asked me to review theirs, I didn't rewrite them, I asked questions, and their own answers made them better, the instinct I still work from.
I work backwards from the outcome, through every perspective that gets us there.
In 2023, I started building my own AI products, not the next product job. From the outside, it may look like a leap, but it’s not. In 2016, building DBS’s chatbot, I was amazed at the possibilities of AI. While that was happening, friends kept asking me for resume help. By 2020, that became my idea: a resume buddy that wouldn’t write your resume, it would ask the questions that make it yours.
At Gojek in 2019, I joined as lead PM to build a social app for Mapan, the unit serving women resellers in tier-2 and tier-3 Indonesia who earn a living selling to their neighbours, and that mission is why I came. I initially rolled out the full social app, feed, connections, and ranking. Through a reorg I became head of product, including the commerce business model. Hired and nurtured a new team, and reshaped how product, design, research, and engineering worked together. Sales tripled in eighteen months and experimented with new business models, staying on through Mapan’s spin-off from Gojek.
At DBS in Singapore I found my footing in product. Back in 2014, when few wallets existed, I took up PayLah!, built its referral engine into production myself, every edge case, money flow, and unclaimed reward. Team grew to twelve and I led its new pay-to-merchant platform. That engine and merchants platform helped PayLah reach 350,000 users by 2016.
By 2016 I was building with NLP, the heart of today's AI, before most banks were. That’s the chatbot I mentioned a moment ago. As the SME on one of the region’s first conversational-banking chatbots, I led product architecture end to end, so a customer typing “Recent transactions” or shorthand like “Shopping txs” both landed correctly, then showing the user’s authorised customer data securely, inside a consumer messaging app never built to hold anything sensitive.
Building my own products, the decision from the top of this story, was a bet on AI: building was becoming almost free, and anyone can ship now. That makes the two things I spent fifteen years on the two that matter most: deciding what is worth building, and building it right. That is what I do for founders and teams, and what I build into my own products: tools that ask the right questions, so you sharpen your own thinking rather than have it done for you.
My first resume took me a week, when friends filled a template in a couple of hours. I studied what each section was for, reviewed drafts with industry seniors, and iterated until I could own every word of it. It was an expression of who I am. When friends later asked me to review theirs, I didn't rewrite them, I asked questions, and their own answers made the resumes better. That instinct, helping people sharpen their own thinking rather than doing it for them, stayed with me. The idea to build it into a tool came much later.
I work backwards from the outcome, through every perspective that gets us there.
In 2023, I started building my own AI products, not the next product job. From the outside, it may look like a leap, but it's not. In 2016, building DBS's chatbot, I was amazed at the possibilities of AI (back then, NLP). By 2020, I turned that into an idea of my own: a resume buddy that wouldn't write your resume, it would ask the questions that make it yours.
I started as an engineer at Kony, now part of Temenos, building Citibank's mobile app for Russia. The business team wanted instant in-app language switching from day one, but the platform couldn't do it. Rather than pass that back, I worked out a hack by understanding how the platform actually worked, because switching without closing the app was the experience users deserved. That mix, thinking from the user's side and driving to the outcome, has been who I am ever since.
DBS in Singapore is where I found my footing in product, given room to move from developer to tech lead to subject-matter expert across PayLah, Lifestyle, and the bank's chatbot, each step pulling me closer to product. PayLah! arrived at the bank vendor-built, and I took it over with one other developer; back in 2014, when few wallets existed, I built its $5-promotion referral engine into production myself, the edge cases, the money flow, the unclaimed rewards. That engine helped PayLah reach 350,000 users. I built out its merchant-payments side too, grew the team to twelve with another lead, and ran a hackathon at NTU Singapore.
That earned more trust at DBS. I handed PayLah to a co-lead and moved to the Lifestyle app as its SME, a new product built around instant point redemption, brand new in Singapore then. Working across ten teams, I shaped a five-million-dollar estimate, pitched it to the managing director, and de-risked the MVP launch in nine months. DBS has since merged PayLah and Lifestyle into one app, I worked on both from their first versions.
In 2016 and 2017, I was building with NLP, the heart of today's AI, before most banks were. That's the chatbot I mentioned a moment ago. As the SME on the bank’s conversational-banking chatbot, one of the first in the region, I architected it end to end with the business, sourcing real customer phrasing from our support history so "Recent transactions" or shorthand like "Shopping txs" both landed correctly. We took it to production inside a bank, clearing the security, compliance, and risk bar when none of that was charted.
At Citi, hired as AVP in FinTech, I owned authorisation and privacy on an API and partnership programme bringing banking into partner sites across EMEA, designing the product architecture so the strict EMEA rules lived inside one global product without burdening other markets.
As a senior PM at Ant Financial, on the Paytm joint venture, I paired with two PayTM PMs to reuse Ant's platform to ship faster, and we cut churn by a third by fixing what actually made people leave.
At Gojek in 2019, I was brought in as lead PM to build a social app for Mapan, the business unit serving women resellers in tier-2 and tier-3 Indonesia, who earn a living selling to their neighbours. That mission is why I joined. I initially rolled out the full social app, feed, connections, and ranking. Through a reorg, I took over as head of product, including the commerce business model. Hired and nurtured a new product team, and reshaped how product, design, research, and engineering worked together. Tripled sales in eighteen months and experimented with new business models, staying on through Mapan's spin-off from Gojek.
Building my own products, the decision from the top of this story, was a bet on AI: building was becoming almost free, and anyone can ship now. That makes the two things I spent fifteen years on the two that matter most: deciding what is worth building, and building it right. That is what I do for founders and teams, and what I build into my own products: tools that ask the right questions, so you sharpen your own thinking rather than have it done for you.
One thread ran through all of it: teaching. A hackathon at NTU on the PayLah merchant APIs, mentoring early-career PMs, AI workshops from Keka HR in 2024 to GrabChai with The Product Folks in 2026 (the photo at the top of this page is from that stage), and a small game that trains product judgment. The resume instinct from my first paragraph, just grown up.
Ant Financial, Senior PM, Paytm JV
Ant Financial is Alipay's parent company. The joint venture brought Ant's platform to Paytm in India.
The problem
On the Paytm joint venture, churn was visible and the Paytm PM had already done the analysis: refunds were hurting retention. The catch: refund processing wasn’t yet one of the pieces of Ant’s platform ported into Paytm, and building it properly would take real engineering time, time that had to compete with everything else already on the roadmap while churn kept costing customers in the meantime.
How do you help another PM turn a stack of refund tickets into a case strong enough to reorder a roadmap, when the data underneath says more than the tickets do?
My part
- Paired with him and went deeper than the tickets, into a real impact assessment: what refunds were costing in users and money.
- Helped him build the prioritisation case, and coached the articulation. Articulation comes from confidence in your own analysis.
- The call that mattered: the same pattern everywhere on the JV: we were porting a platform Ant had already built into Paytm, so PMs shipped by reusing it instead of building new.
The result
We cut user churn by a third by redesigning the refunds experience. Platform adoption increased too.
Mapan, Gojek, Indonesia, 2019-2023
Gojek is Indonesia's super-app: rides, payments, everything. Mapan is the unit I led, group savings (arisan) and commerce for women resellers.
The opportunity
Mapan already had a real business: Indonesian women saving in groups to buy together (arisan), led by group leaders. The constraint was scale: growth depended on 1,000+ sales team on the ground, and the know-how that made a great leader sat bottled up inside that offline team. The hypothesis in our CPO's product spec: a social network could move that knowledge peer to peer, experienced leaders sharing what works with new and average ones.
How would you get the best leaders' know-how flowing to the newest ones, through an app, for women who are new to smartphones?
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.
- Later, building commerce, ran an OpinionX problem stack-ranking to test whether social still mattered to them at all: the #1 thing that came back was wanting to be seen as productive by her peers, family and neighbours.
- Designed the social features around that finding: recognition, sharing her achievements outside the app, and a little competition, so the job of being seen as productive actually got done.
- 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, reactions doubled, followers started their own groups, and sales lifted 45% in the treatment group of a controlled experiment.
- 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.
The problem
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 was the opening to rebuild it end to end.
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.
- Decided from evidence: cluster analysis revealed the segments behind the 80/20, top leaders viewing a product up to 15 times more than average, plus the leaders' own problem stack-ranking.
- The call that mattered: ran the commerce like a product portfolio, launching seasonal plays like Arisan Lebaran, and building discoverability into the product feed so leaders could find what's trending and share it straight to their members.
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 failed, and the learning fed a later product that worked.
My own products, 2023 to now
2016
Building DBS’s chatbot, I was amazed at the possibilities of AI (back then, NLP).
2020
I built a working prototype for a resume buddy on Google Dialogflow: AI that would not write your resume, it would ask the questions that make it yours. Mapan’s reorg made me Head of Product. Couldn’t finish it.
2023
At Mapan, my manager reviewing one of my documents asked a question, “Is this causation or correlation?”, and it took me deeper into the topic than I went on my own. It became LiteThink, my first version of an AI partner, but for PMs.
That evolved into SuperProductManager, now live as a web app and Chrome extension.
That first version has matured, through many iterations, into what’s live at superproductmanager.ai today.
The problem
SuperProductManager already worked for people, as a web app and a Chrome extension. When I saw MCP as an opportunity for distribution, I converted my existing APIs into MCP tools. Claude and Cursor failed to use SuperProductManager accurately. A human PM finds their way on a web app interface, based on the gap that they want to address. An agent doesn't know what gap to address on its own. It only knows what you explicitly tell it.
How would you redesign tools a human already navigates on instinct, so an agent can drive the same workflow end to end?
What I did
This is what the industry now calls Agent Experience, AX: designing for how an agent navigates your product.
- 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 work it out on their own; 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 testing reasoning settings and temperature one at a time to see what actually moved quality.
- The call that mattered: every change is an experiment first, compared against the baseline, not a direct switch.
- I test most changes this way; one public write-up covered 100+ test runs comparing models before a switch.
The result
The migration shipped with quality holding steady. The same habit set the bar inside SuperProductManager, blind-graded internally.
SPM’s decision-forcing questions:
- Beat a frontier model's about 6 times in 10
- 67% cleared the aha bar, the kind of question that makes you stop and rethink
The $5M capability map, DBS, 2015-2016
A rewards and lifestyle app for DBS Singapore, shaped from what the bank's Hong Kong team had already built.
The problem
DBS Hong Kong already had instant rewards redemption. Singapore wanted the same. The catch: Singapore couldn’t see how Hong Kong’s systems worked underneath, and needed different mechanics anyway: instant point redemption, points landing as you spend, offsetting card spend without waiting for the bill. All brand new in Singapore then. Someone had to carry the whole picture across markets.
How do you take what another market built, when you can’t see how it works underneath, and land it as your own, not a copy?
My part
- Led the capability-mapping workshop with the Hong Kong team, learning from their technical product people how each piece actually worked, then judging what would survive the crossing and what would not.
- Redesigned it fresh for Singapore: different rewards mechanics, Singapore-only designs from the local design team, Hong Kong as inspiration rather than template.
- Working across ten teams, shaped the estimate, about $5 million, and pitched it to the managing director.
- The call that mattered: mapping capabilities, not features, so Singapore committed to an approach it could build, not a copy it would fight.
The result
The MVP launched, de-risked, in nine months.
Team growth, DBS to Gojek
Two teams built from scratch, in two different functions: engineering at DBS, product at Gojek’s Mapan.
The opportunity
A COVID-era reorg made me Head of Product at Mapan. The product function was just me. Building a team that could actually run activation, engagement, and the new business-model experiments meant hiring from scratch.
My part
- Hired five people into distinct roles: activation, two for engagement, business-model experiments, and a product analyst on platform features.
- The call that mattered: matched each hire’s expertise to what the role actually needed. Engagement got a senior for the growth-loop work; business-model experiments got a generalist with a design background, since that role needed range more than depth.
The result
- 3× sales, mainly from the engagement PMs, with activation contributing
- Business-model experiments fed a different outcome: a new product line
- 99.99% confidence social-to-commerce proof: mine, built alongside an engagement PM
- Later expanded to Head of Product & Design, ten people total
The opportunity
When I joined PayLah, it was just me. Everyone was excited about long-term Digibank. I saw the opportunity in the wallets ecosystem instead.
My part
- Grew the engineering team from two to twelve, becoming tech lead, while shipping the referral engine and the pay-to-merchant platform, including the NETS, AXS, and BusOnlineTicket integrations.
The result
That team shipped and maintained the systems that reached 350,000 users and ran stably for years without breaking.
Claude Certified Architect
Anthropic’s 301-level certification, one tier above the introductory courses, for people already building with Claude.
The exam is 120 minutes, closed-book, 60 questions, each a project scenario with four plausible answers, not a fact to recall.
- Agentic architecture and orchestration, 27%
- Claude Code configuration and workflows, 20%
- Prompt engineering and structured output, 20%
- Tool design and MCP integration, 18%
- Context management and reliability, 15%
I did not prepare for it the way that phrase usually means. Agent architecture, MCP, and context reliability are not exam topics I studied for, they are what SuperProductManager and Product Thinking Space are built on, two years of it. The only real preparation was a day or two understanding the exam’s format, not its content.
Passed alongside Advanced MCP, part of seven Anthropic certifications in total. The announcement post
