Pandai Gadai

The claim was that app customers are more loyal and more valuable, so getting more customers onto the app grows the business. The data agreed: app users transact far more often. Every dashboard said we were right.

That is exactly the shape of a selection effect, so I tested it five ways instead of one: a within-customer pre-trend, a new-customers-only cohort who could not have been loyal beforehand, and a difference-in-differences on branch launches, which is a natural experiment the business had handed us for free.

All five came back null. Activity was already accelerating before people adopted the app. Customers who started on the app were worth less, not more. The app was riding the wave, not making it.

App users really are more valuable. The app is not why. That is who adopts.

The easy move was to keep the loyalty narrative, since it justified my own team's roadmap. I told the founder to stop funding it. An investment case built on a number that will not survive scrutiny is a liability, not a strategy.

Then I rebuilt the case on what the evidence did prove. The app is a convenience and optionality layer, and that is real and observed: customers move the annoying, low-value payments online, while redemption stays in the branch because they come in to collect their item. It is cheaper and safer than a bank transfer. It offers things a counter cannot.

That is a smaller claim, and a true one. I also specified the forward test that would actually size the value, because history could not: the past can only tell you what to stop believing.

If the app was not the engine, something else was. Almost all of the next year's growth comes from new branches ramping up, and a new branch is slow because a new frontliner is slow: the person behind the counter has to learn to appraise, price, and close.

So the highest-leverage product I could build was not for the customer at all. It was a platform that gets a frontliner to competence fast, with clear expectations, real feedback, and a path to fix performance, without depending on an overwhelmed human trainer. Make the ramp faster and every branch pays back sooner, and a region we have never staffed becomes runnable.

I re-weighted my own team's roadmap behind it, which pushed customer-app work I had championed below the line.

Poin Pandai, our rewards program, had a mass-expiry problem. The org read it as apathy, so the proposed fixes were motivational.

The customers were not apathetic. Points expired seven days after they were earned, and most customers did not verify the app until about twenty-five days in. They were losing their points before they ever opened the app. A rules-and-onboarding problem wearing the costume of an engagement problem.

I killed a belief while I was in there: the team thought customers were saving points to cover a redemption in full. Nobody ever had. It was arithmetically impossible. I also retracted two of my own findings from the same analysis, under my own challenge, and published the retractions inside the document rather than quietly correcting them.

And then I recommended no lever. The diagnosis did not establish that redemption drives lifetime value, and that was the program's whole objective. Shipping a fix would have been activity, not progress.

We had a Compliance and Trust team on the org chart. I dropped it, one version after designing it.

Compliance is not a product team. It has no discovery roadmap, and its backlog is written for it by the regulator and the auditors. You cannot run it like a product, so I moved to how regulated fintechs actually run: the rails embed into whichever first-line team owns the underlying system, a second-line risk function governs without holding a roadmap, and internal audit is the third line.

The part that changes behaviour is the gate. No initiative passes intake without its regulatory and risk implications written down, at the same status as its metrics. Compliance becomes a design input at planning time, not a review you fail after the build.