Pathao Points
This month, we launched Pathao Points – a unique rewards program that lets our customers earn points every time they use Pathao for rides or food deliveries. Along the way, these points unlock exclusive and exciting benefits for our members.
Following this launch, we have been asked:
What’s your reasoning for launching such a product (Pathao Points)? How does it work? What research went into it? How long did it take? Did we design for the long-term? What metrics do we look at?
These questions are not only relevant to Pathao points but also in any product development context – be it Pathao Points, Rides, Food – or any other tech product for this matter.
In this 3-part series, I plan to answer these questions using Pathao Points as an example but I hope the details will be useful for anyone working on developing technology products in Bangladesh and beyond.
Why build Pathao Points, at all?
As a homegrown startup, our community has been a big part of our journey.
We’ve always wanted to recognize and reward this community for choosing us. With this program, we’re excited to be taking a big step towards that.
Customer retention is a big focus area for us. We want to be the platform of choice for our users, consistently and are eager to work for it.
It is far more expensive to acquire a new user than to retain an existing one.
It only makes sense to put our efforts into building for the customers who are with us. Pathao Points is exactly that – a program to recognize and reward our users.
The points that our users earn give them access to a wide range of rewards and discounts that are designed to truly matter to them.
There are four membership levels: Bronze, Silver, Gold, Platinum, and users are enrolled automatically at no cost.
Once in the program, users will start earning one point for every ten taka spent on the Pathao platform. Once a user earns 200 points, they’ll advance from Bronze to Silver. At 1,000 points, users will be promoted to Gold tier. And at 7,000 points, users will be advanced to the highest tier, Platinum.
Since this project dealt with rewards and customer relationships, we thought trust and reliability were very important. The internal name for this project was ‘Sancus’ – named after the Greek god of trust and oaths.
Before diving in, I must emphasize our goal is to build things that work, not ship fast...although we do that well. Here’s how:
Fig: Explorations and refinements we’ve done before the MVP launch | Photo by Pathao
Fig: Explorations and refinements we’ve done before the MVP launch. Source
Upon release, we expected the first version of this product to go through many iterations based on feedback from the market.
To allow for fast turnarounds and push updates easily – building the frontend on the web, instead of native android/iOS made sense.
On one hand, frontend changes to Android/iOS platforms require full updates and are dependent on the user accepting the said update.
On the other hand, the web view approach loads the updated UI each time.
But there were concerns with a Web-View based approach.
We hadn’t used a web-view for any major part of the app experience before. Naturally, this was uncharted territory.
Would there be trade-offs in the experience? Would there be lag? Is there a possibility for it appearing inconsistent compared to the rest of the app? Would the frontend be able to handle the load?
We decided to experiment and created a POC (proof-of-concept). Our web frontend team built a few HTML/CSS pages. We hooked them up to the app then tested performance. The result was far better than we had hoped for.
It was not perfect, but it could be polished and iterated to create something amazing. There were a few usability issues, a few design considerations. A diamond in the rough, if you will.
After a few iterations, we were happy with the performance. No lag. No major usability issues. No bugs. We decided to go forward with the web-view solution.
Photo by Pathao
Earlier this year, we had spent time standardizing our design language and guidelines. We created our very own UI library, named Lego, with pluggable components that meet our needs.
This library is our source of truth. It acts as a boilerplate to start new projects. More importantly, Lego ensures consistency through our app, website and other touchpoints.
In a nutshell, Lego saves time while working on any UI and helps us build new user experiences at lightning speed.
Using patterns and learnings from building similar robust systems like our Payments service, from back in the day, our engineering team decided to go with a microservice-based architecture. On a high-level, there would be four main services.
There would need to be a few other microservices supporting this stuff but, by and large, these four would be the pillars on top of which we’d build this system.
Traditionally, measuring the impact of product releases has been an afterthought. This leaves no one better off. We now plan for it even before writing a line of code.
It’s difficult to reliably know how vital a feature or variable is unless we can deploy it in both - a control and treatment environment and measure the effects.
Sure, qualitative ways of interviewing users could be used – but there are issues. At the scale Pathao operates, FGDs and interviews are rarely representative. Especially for a product that runs on the entire platform. Thus, quantitative methods, A/B testing is our way to go.
Easier said than done, of course.
It requires development, setup, and know-how to run a proper experiment and A/B test. This is rare expertise to come by, without experience.
Most of the questions we have about Sancus (internal name) – the stuff we want to test and iterate on, have an A/B testing mechanism built-in.
That means we are able to have control-treatment groups, rollout specific features to cohort user groups and much more.
We then monitor the data for the two groups, analyze the data to derive insights, and take appropriate actions.
As Peter Drucker rightly said, “What gets measured gets managed”
We’ve found face-to-face communication to be essential. But we don’t want to bury builders with meetings. On the other hand, email and text messages are sometimes slow ways to coordinate. We needed to strike a balance.
a. Our Capstone Project Management Tracker – Maintained by the Product and Engineering leads, it gives a birds-eye view of our progress and priorities.
b. Standups and Face2Face Meetings – We had stand-ups, with the 6/7 core team members roughly twice a week. Usually on Mondays and Thursdays. This cadence allowed us to unblock issues and keep track of progress – while also spending minimum time on such meetings.
We’ve found face-to-face communication to be essential. But then, we don’t want to bury builders with meetings. On the other hand, email and text messages are sometimes slow ways to coordinate. We needed to strike a balance.
During retrospectives, we purposefully spend more time on the negatives. Nothing, NOTHING is off the table for discussion, but EVERYTHING must result in an action.
c. Document the things that matter: Early-on I started collecting meeting minutes for all the different meetings I was having with tech, marketplace, marketing, partnerships, and other teams. At the end of each meeting, I sent out a recap and the next steps to be taken. This discipline didn’t last throughout, but it was there long enough to get us off the ground.
The team
The team that makes it possible
It goes without saying, there are folks who’ve contributed but aren’t in the frame, to whom we’re grateful. Among them, I’d mention Jitu bhai for his contributions in the early stages of this product.
-
Was this helpful? I write about startups, products, and do interviews with folks building things, in Bangladesh. Check out https://ahmedfahad.com for more. If you know anybody that would find this useful, please share.
Read more insights:
