My Product Story - Jamja Phuc Long

Back in 2019 of a real product case I helped solve but never had the chance to write about 😂

Hello to my beloved readers,

As you might be well-aware, I am still unemployed 😂. Even though I have been quite enjoyed the time I have, this is a good chance I should write about my product portfolio. I made a plan to do this weeks ago but still got lost among the stars, until I read this article from my friend

Thao Vo

, and felt like a wake-up call is needed.

Mình đã có thể làm tốt hơn khi nộp xin việc 4 năm trước.

I have had > 8 years of building products, and of course got a lot of tales to tell. Being a fantasy writer myself, sometimes I feel like my life is a fiction book waiting to be opened. But the product experience is something real, and I want to tell it as-is. After all, we are living in a strange time where our technology has transformed our life faster then any other era in the history, and yet we often take it for granted and get lost in consuming it rather than building it.

The story is in English for 02 reasons: one, most product portfolio is written in English, so you can share to the world i guess (blame the system). Two, a friend gave me a text when he saw my personal notes 1 year ago. Maybe I should give my readers a chance to read my internal voice as-is (I often think with this voice - in English). For a bilingual person, sometimes you might feel like you have a different personality when you switch the language (so blame me on this one 😂).

Enough said, this is an experiment. You can throw it to Google Translate if you must, but I somehow believe my readers can digest this one. But beware, this is a really long read (perhaps the longest) for a short but memorable product I have helped built.

---

Hello,

The following is a story of the past on one of the actual cases I have solved. It is a challenge to present it in the manner of actual events happening, so you got to be in the view of the product owner who solve this case. What I love about this job is experience like this, where you put in your hat as a detective and come up with a solution to a problem and fix it.

Believe it or not, this skill (problem solving) isn't too highly rated, because people often forget the problems you make disappear than the one that still stays. Sometimes, a good product strategy can help you go a long way, and a bad one will make you lose eventually despite all the great problems you solve. And strategy isn't what you can control yourself as a product owner.

But cast that aside for later, as today I present to you a story I want to tell in many interviews, but often not enough context and time to do it justice. I will tell it in an unconventional way, not a beautiful snapshot of framework where a solution was crafted as if it comes from a product text book, but in the actual order of events that led me and the team to do what we do. This can't be achieved in a normal interview, since no one has the patience to read such a long but real journey, but rather a snapshot of quick points racing to the happy ending.

“Quick” Introduction:

In 2019, I have had a 03 month experience in a start-up at Jamja at one of the most pivotal times of its life. When I came, the company was at its peak, with > 100 employees, VC backed, >1000 brands via foods and drinks across 05 provinces, with offices in both Hanoi and Ho Chi Minh.

I have had a blast during my first 2 month probations. I was welcomed by the whole teams, felt like the entire office was a family, motivated daily by the hyper growth, was challenged with many interesting and meaningful problems (one of which is the case I wrote below). I was highly valued and promoted to become the future key leaders of the company. Within those 2 months, I felt like I lived there for years.

The last month, is when the company received the sad news of being withdrawn for cash funding by investors. I still remember it was May 31st, 2019, the end of my 2-month probation, the CEO made a speech to say he won't be able to pay everyone for next month. Everyone has to decide if they wanted to go to war with Jamja, means working 9-6-9, and late payments, or else let's say goodbyes now. Some of us call it Thanos day (it's the year of Avenger Endgame), as we have to step to our left or right for our decision to leave or stay. We closed our eyes, made our call, and saw each other. There were around 30- 40 of us left, me included (just like Thanos, more than half were gone).

I got this book as a present from the CEO for being the few leaders who decide to stay during war time

I have spent another 01 month in war time with Jamja with many stories (but I will keep them to myself for now). It was a roller coaster of experience that no HR or outsiders will ever understand. I was thankful for such an experience and it became one of a very memorable chapter in my work life as a product manager.

Context and Background

Jamja was a popular app among teens back in the days when milk tea become the hot trends for every office workers and students in Vietnam (around 2015-2019). Believe it or not, the world back then was different, people were willing to go outsite and pick up their drinks for a cheaper price, and that's the unique selling points for Jamja.

Một chiến dịch của Jamja

The advantages of Jamja back then was about pricing. Jamja CEO, Mr V, opened (& closed) 2 restaurants himself, and realized that there were always downtime where shop owners were willing to cut down prices to ship out unsold inventories. With an app, he can become a distribution channel to connect these inventories out to people who were willing to come pick them up at cheaper prices.

That idea worked, with >1500 partners willing to cut a better deal to customers ranging from foods, drinks, services.

In 2019, Jamja successfully partnered with Phuc Long, a well-known F&B franchise, to receive 1000 discount codes to be used for all branches across Vietnam. This was a special deal for 2 reasons:

1. It took great effort to connect with Phuc Long and convince them to partner with a new brand like Jamja

2. Phuc Long never issue discount codes before, and 1000 was a new business rule that the product has never faced

Despite being famous for being popular among teens for all the hot milk tea deal, the new Phuc Long were expected to become the oil to the flame. However, 2 weeks since the launch, no sale were made, and all the team members do not know why? And that's also the week I came in.

The Problem

No one knew what the problem was. There was the CTO among 10 others: dev, Lead UI UX, designers,.. discussing heatedly at all the theories possible.

Writing the problem statement is an art to be master by every product person. I will write more about this topic.

At this point, the problem you need to know is:

Something was wrong because users at Jamja do not book any Phuc Long codes despite that this is the most famous brand and the marketing team have been heavily focused on promoting this for the past month.

Initial Approach and Analysis

The first and always important thing to do before building any new fixes is to understand the problem.

I screen through the app, and ask everybody for inputs. No one has a clear clue on what was going on.

From this, I decided to ask the CTO to let me do usability testing on it with actual users.

Usability testing might be something familiar now in banking, and some fin-tech companies, but back in 2019, it's still quite new.

I happened to self-learn how to do it. Honestly, I learnt it from reading off a really good book that explains everything in great details. This book is a testament for how you can learnt from someone's knowledge across the world and apply it well. Later on, I realize I have a knack for it. Turning book's framework into reality's actual case study is one of my secret weapons in product.

I mentioned my story of self-learning this and my ability to apply this into Coc Coc Product (a story on this later), and it impressed the hiring board for Jamja. I immediately got hired.

According to the book, it took like 7 day to set up a UT properly. I asked the CTO for 03 days to set-up. He said something I still remembered:

"You have one afternoon. We do it tomorrow morning! This is a startup"

Challenge like this is what kept me alive in this profession, and I felt like I need to pull a rabbit out of the hat for this one. Here is what I did:

- Tell HR to recruit for me 03 users from Jamja team. Best to find one familiar with the flow, one barely use it, one used it often but never learnt this flow (get the diverse personas)

- Write some documentation & questions on the case to be asked for the Usability Testing, review the flow again myself

- Find ways to record the experience. One key aspect I learnt from the book that many people might have missed, is this:

Make sure you have a transparent way to capture user direct opinions. After all, you do the work to represent the user's experience towards the team's product.

Any report without live recording, anecdotal reference would result in translating and installing your personal bias into the supposedly objective validation results

Next morning, off we went, to the site to order some milk tea, and you can read what happens in details here.

Main recap:

- No one can book it without some help from the Jamja customer support

- They all have the worst experience in ordering a deal (9/10 - 10 is the worst)

- We see many things wrong with our own eyes, and now it's hard to choose what problems to fix.

Without jumping into the many details of what went wrong, here is a new problem statement:

Users at Jamja needs a way to get their discount code during check-out because they cannot find their discount code while checking in at Phuc Long.

Here are some abstract list of reasons why they cannot find the code and the root cause after analysis:

Tricky product flow:

No one can find the code because we hid it too well

Jamja customer journey in a nut shell

JamJa Product Flow

- There's a hashed dot when user receive the code after booking => some users not even sure if this is a successful book

- When lining up for order (Phuc Long line is always long), user need to type in merchant code at the side to reveal their booking code (Phuc Long has a special merchant code in Jamja system) => User has no clue how to get this code.

Why the tricky flow?

Most product tricky flow usually comes from one root cause: failure to convey the business logic to user flow.

Remember Jamja has a limitation of 1000 codes. If they apply normal workflow, the first 1000 customers who ordered will be receiving those codes.

Yet the product designer did not want to do that. Here's why:

- Those who first order might not come to the sites to pick up. Jamja ended up wasting discount codes to those no-show customers.

- By making people key-in the merchant code (which they must ask on-site), he (designer) hoped that the codes went to the actual people who actually went there.

A simple learning lesson here for many product & ux people:

A lot of times, we try to fix a problem (limit codes to onsite users) by creating a new problem (make them work too hard to get those codes).

If you understand this root cause, then the problem statement now is this:

Users of Jamja need a way to receive Phuc Long discounted codes while checking out drinks because Jamja has a limitation of codes and only users who showed up onsite and looked for the code should receive them.

Solution Development

Understanding the core problems above was key, and it took more time to get there than I just told you above (like one day to reflect and think).

Once you get it, the solution is of course to target it.

How do you distribute codes to users whom we only make sure they get to the site?

The above is the key question. If you want to be in my shoes (product owner), maybe now is the time to pause your reading and get a piece of paper to draft your solution to the above question. Refer to the flow above if you must. Get your own answer and share with me in the comment (don't read the spoilers I'm about to tell you).

Good! Back to the story, I have had an answer of my own but as an experienced consultant, it's best to come up with multiple options (you should always do them, take advantages of divergent mindsets 👇)

Về nghệ thuật dẫn dắt trong cuộc họp

Here are those I draft (you can read my original analysis here):

1. Plan A : Get merchant to tell user a special code (ex: 007), user typed the code to get real code (which already purchased by JamJa) , the special code insert signifies transaction is complete in real time

- Cons: Phuc Long / big brand don’t want to cooperate in any educating effort for training staff remembering any special code (need to convince them)

- Pros: Minimum development work needed (only need to make the code simpler to remember)

2. Plan B: Give away the pre-purchased code to users for them to claim to merchants. If user don’t claim the code after a special time slot, the code will be expired and be given to other users. 

=> Basically, a code can be re-used for another user if we detect that the user did not show up properly

- Cons:

- How to confirm if a user has completed the purchase on system? 

- User show code and get their bubble tea and close the app while we don’t know whether they have redeemed their code

- Asking users to confirm their purchase is not easy

- They can lie about their purchase

- They can be annoyed

- Pros: 

- Can reuse the code purchased

- No need from merchant

- 3. Plan C: User receive a hashed code and a button “How to use code” . We will check for the app location on the mobile device and if they’re near the location of the store, we will show the code 

- Cons: 

- User may cheat by redeeming code before making real purchase by standing near the store and then still not pay 

- need development effort 

- check feasibility risk with tech to exactly locate users vs store location 

- Pros:

- No need for merchant coordination

- Complete control via app

- 4. Plan D: The Phúc Long deal can involve 2 parts :

1. Book in jamja app for a code 

2. take a selfie to unveil the code 

User receive a screen telling them they need to take a selfie with Phuc Long brand on site to verify they are there. The purpose of the selfie has following goals:

- The picture can be used to share later to create viral effect for marketing

- The deal has vitality factor and can serve as a marketing campaign 

- When user busy taking selfie as part of the deal, they don’t know our motive so we can believe their location better 

- Cons:

- It’s a bit brain-hack for users, they can still cheat

- Very operational heavy

- Development effort

- Pros:

- Have pretty user images to promote

I gave these 4 options to my CTO. Here is my questions for you:

- What do you think my prefer option is?

- What do you choose if you are the CTO or decision maker?

Think before you receive the spoiler answer below....

The CTO scratched his head and told me:

"You made the call, we will proceed!"

So I actually am now in-charge. And this is what i love after quitting my job as a consultant. What is the client's problem is now mine, and the one who passed the sentence is now me. I can no longer be fine with the way out of being a good consultant: just give client a good answer that works in theory and it's client problem to implement it.

And I choose..

Option 3 - for the following reasons:

1. Business vitality risks: I got the idea from Uber and Grab, they have the same technical problem: identify driver who was nearby a customer. If it worked for Uber, it should have worked for Jamja: identify a customer who was nearby a store location. Uber based their whole business on this technology, I just need to bring it to jamja situation. And surely the cost is not more than the profit (unlocking the Phuc Long deal)

2. Feasibility risks: the tech team was ok and said the technology under it isn't too hard to implement. It took just one sprint to fix it.

3. Usability risks: it will remove the constraint at check point to ask user to type in a store code, and can have a much better UX. It also doesn't require merchant to do anything. It attacks the main challenge of how to distribute codes to the right users without asking them to do anything extra.

Or simply put:

I choose to base the effort on some wheel that has been invented (don't re-invent the wheel), has the most simple approach to target: location.

The solution direction is set, now is time for executing the requirement for it.

Do you feel a bit tired yet at this point? If so, you can take a break here and read the next part later 😂.

I just want to tell the story in the process it happened, and it takes longer this way. But I want you to feel it, the journey to the solution, not just the solution itself.

Implementation: The one who passed the sentence must swing the sword

It's actually way harder than I initially thought.

It's not simply copying Uber model into Jamja

It's a challenge to put the wheel (location-based) into Jamja's cart and make it run like a vehicle.

It's reinventing the old UX to become something that completely new.

I do that in a few steps:

1. Help users understand what to do

For the booking flow, we still keep the hashed code (not revealing it). But we add some text to let users know they have successfully completed a booking, and tell them to come to the store to redeem the code by clicking redeem button

2. Check user location when users arrive at the store

The main idea is:

- User can trigger the location check by clicking the redeem button. Users will have to share their app locations and if they are within 200m to store location, we'll show the code.

- We shall not give user the code at the booking time. He might not be around the store during the time he ordered, and thus fail the location check.

However, there's another catch, which adds to the complexity: Time.

Let's say user booked for the milk tea slot on Wednesday that he will pick up the milk tea on Friday.

User of Jamja need to select a time slot to come pick up their drinks to receive the code

At any point from Wednesday to Friday (the time slot where he booked to show up and pick up his drinks), what will happen to the location check if he pressed the redeem button?

Would you allow user to get the codes if he decide to redeem the code earlier than the time he book (Friday) and somehow passed the location check (200m around the store location)?

If the answer is Yes, then if he lived nearby the store during the booking and got the code and never showed up at the store, Jamja would have lost the discount code to a fake booking.

It is not strong enough to assume when an user is nearby the store means the user will show up to get the drinks

If the answer is No, then it means even if user arrived at the store early, he must wait for the time slot to make an order.

Which inconvenience would you rather choose?

Our approach to this problem is this following assumption:

If an user show up within 30 minutes of his booking time nearby the store, he is considered there to redeem the code.

It meets 3 conditions:

- He trigger the location checking by pressing the redeem button

- He is 200m around the store

- He triggered around 30 minutes of the booking time made.

We'll release the code if it matches the above.

And the final requirement is even lengthier with some complexity below:

- Success screen during early booking time (from booking until 12 hours before checkout) to tell user what to do

- Countdown clock (12 hours before checkout time slot) to tell user the exact time to see the code

- Code reveal (within 30 minutes around the time slot): to show user the discount code

- Expired screen (after 30 around the time slot): to protect the code and re-use it for later.

I came up with an entire new concept of location and time checking, and pop up UX for each case. I must explain it to the engineer team and testing team while executing them.

Results and Impact

It was nerve-wrenching, as I saw my strange logic being tested with reality. As I wrote what I explained to you above, I was certain that I have made a feature unlike anything similar in the market. This is an unique wheel that I came up with, my first big case and I have only one shot to earn the trust of this team. All eyes of Jamja are on this feature.

There were few sale members whom already arrive at Phuc Long in both Ho Chi Minh and Hanoi. We don't have a way to reach our customers, everything must be intuitive through the app.

When the first chat of the day from a sale member told us that she saw few people use Jamja at Phuc Long in HoChiMinh successfully, i felt what Oppenheimer must have felt after his atomic trial run succeeded (well, he probably had a better feel, but i felt good).

When the first chat of the day from a sale member told us that she saw few people use Jamja at Phuc Long in HoChiMinh successfully, i felt what Oppenheimer must have felt after his atomic trial run succeeded (well, he probably had a better feel, but i felt good).

Then the dashboard continue to rise, users continue to claim the ticket code. It took like 9 days to spend all the 1000 Phuc Long tickets. It worked.

Our CTO was happy enough to mention my location-based service could be used to solve a bigger problem at Jamja: tracking users who actually went for payment and reconcile them with merchant system (a bit sad we never got to do this).

I was then invited to interview new BA for the company. During one of the interviews, our CTO even used location-based service as an example of the kind of innovative mindset Jamja is looking for.

It was a quick-win feature to help get Jamja out of a jam. But thanks to a meticulous approach to zoom-in on the problem, I was able to come up with a creative tech solutions that is original and relatively low-effort to save the day. This kind of feeling help move me forward to stick to this profession despite many other pains I endure during my product career.

Reflect and lesson learnt:

1. Most complicate UX came from business constraints that make users pay for their customer journey

I saw this everywhere I work. So my advice to young PO is to withhold all the early judgement like this is stupid design, etc,.. but instead chasing the why a product was built that way. Asking that from the one who built them. Then figure out what trouble users are facing. And work from there to develop ideas to fix them with your team. The solution should be the trade off from what users need vs the maximum effort that we can afford for that feature.

2. Stealing some ideas from one area to apply to another area is not straightforward as you think

I fail to explain the intricacy of this case to many people who did not join me on the build. On the outside, it's always look easy and simple that's how you do it, but in reality there are myriads of challenges in the details.

We all know it's challenging for Xuanzang (Duong Tang) in his journey to the West, but only by reading the details you understand each one of his 81 incidents was original and unique in its own way.

A lot of people can also make judgement that the PO is overthinking and make it too complex, or did not think clearly enough. But at the end of the day, PO is the one who has to make a decision and be responsible. All the angles of the issue is captured by the POs and sometimes it's hard to explain all these angles to outsider like above management.

3. Having stakeholder trust is crucial

I cannot make the call without the trust from my CTO and also the validation from my team members. The UT test was a way for me to win those trust, and as you can see i try to present them as objectively as I could, which bought everyone attention and understanding on the same page, to the point that they don't doubt me of a solution that I have never done before.

4. Trust yourself, despite other people bias

I don't have tech background, there's almost nothing I can do to change that. But I still can provide solution using logic, things I observe in in life, and bring it into the tech world.

And you see in this case, I can create new concept of time and location that works for Jamja. And yet still, many people have very low opinion of PMs who don't know tech too well.

Just ignore those bias, and focus on the problem. From the understanding of it, you will drive solutions that solve what users actually need, and it's your values you bring to the table

Conclusion

Some people question why I kept bringing a quick-win feature I built during a company that I have in short stay (3 months - because they then can't pay salary), and still feel proud of it. But out of many features I built, this is one of the first few experiences that brought to me the feeling of saving the day, plus the belief in myself that I can come up with good UX solution at concept level using what I learnt from textbook and user research.

Once you solve a case like this, you have the unwavering trust in yourself to solve other difficult problems, which is what our job - product management is all about:

Solving problems for users and corporates, not creating a problem for the world to solve.

Now if you made it here, congratulations!!!!! My writing must not suck that bad 😂. Please tell me what you think in the comment section.

Please have a rest as you deserve it. Let me know if you want me to continue this type of story in the comment 👇

Bài viết thuộc thử thách Viết Đều và Hay của Writing On The Net Alumni. #wotn #vietdeuvahay