 Good morning, and good afternoon, everyone. My name is Tan Hwang, and I want to thank you for taking the time to listen to my webinar about my experiences working in Hong Kong as a product manager. First, I want to thank Anas from Product School for setting this up, and also for Mariano, Tukar Pazzani, for the interest in being a good friend. One quick heads up. This is a webinar very light on slides and very light on text. This is mostly going to be stories in quotes about my experiences in Hong Kong. So you're more than welcome to just listen in like a podcast, but with the benefit of checking out some of my photos that I talk of Hong Kong. Speaking of which, I do want to put out this disclaimer, but don't worry, this is literally going to be the most words you'll see on a slide today. So I'll give everyone a moment to read this. Okay, now on to the stories. Let's start when I first arrived in Hong Kong. So I arrived in Hong Kong in the early 2000s, on a three month project of a consulting firm that later turned into a two years of employment. For those first two years, life was as sweet as a single and living in the life of an expat in a city that was completely utterly caters for expats. Because Hong Kong was and still is mostly English, uses English as a primary means of business documentation and discussions, then everything in everyone had to adjust their lives to us, by the English speaking world. To say that us expats was in our own nice and not a little bubble slash every tower would be a huge understatement. But what I would notice was that as a local being smart and highly trained wasn't as valued as someone that could communicate well in English or want to naturally speak English. Let's just say that skill helps deals with the quote unquote foreign experts. By the way, I emphasize foreign because that's what we were, foreigners in someone else's country. Because of that, I noticed there were two types of meetings with us foreigners. Both of these have experienced just as equally badly. One where an hour meeting would be 55 minutes in Cantonese and five minutes in English, confirming the agreements and summarizing my conclusions. The problem with that is the rule, the lowest common denominator wins. That is, you get what is the most basic and good enough option. What you lose out on is the nuances of what happened in between. Who disagreed on what? What compromises were made and what alternatives were discussed? And finally, what we could have done to push the envelope. So the other type of meeting would be 60 minutes of broken English, trying to get to understand each other and to try to get an agreement, but also trying to summarize the conclusions. I mean, there's one advantage of that and that is inclusion. Sure, I've been in meetings where only English is used and the native English-speaking people feel included, but none of the foreign, none of the non-native speakers feel included because they can't express themselves as easy as if it was in their native tongue. I mean, for all of you bilinguals out there, when you're arguing with your spouse, which language do you default to? Actually, don't answer that. I don't wanna start with what free-roofing the family is. So, of those two types of meetings, which works better, you asked? The short answer is neither. So what now? And this is going to be a hard period to swallow for some of you. When in room, do what roommates do? Learn the language or don't be offended that they don't always use English. What are the flip side? Yes, you feel shit that you don't know what's going on. You feel excluded, you feel bullied. But understanding there's always more than one side to the story. First, understand that it's very difficult and challenging people that are in the world. And I don't exclude myself from that list that fundamentally, people are good people. So, remind your colleagues and your clients and your shareholders that we're all on the same page. But remember, you are the guest of a country. Be a good guest. And they will do their best to be a good host. If you do this, actually, let me rephrase, when I did this, I was more open to a wide world of experiences that I would have never have known. Now, just work when you're building the next great product, but also as a human being, being the best version of yourself. Yeah, yes, I know. I've just said that everyone is on the same page and everyone ultimately wants to be good yada yada. But let's get to two examples of bureaucracy at its finest. First one, while I was working on one of the government departments on a really cool product. So anyway, I joined this product right around the design phase. And yes, by design phase, I mean the design phase of a waterfall plan. Let's just say government ran, quote unquote, projects, strongly suggest that they'd be run as a Prince II project plan. Please give me some right with me, those old enough to understand or unfortunate enough to experience trying to run a project using Prince II. So guess what? I remember the first meeting we had to discuss the design details. And the lead government designer came in with a huge binder. And by binder, I mean think war and peace scale. So naturally asked, what's the SC board? His reply was, this is the RFP request for proposal. Okay, that's nice. Why don't you bring the RFP? Who had any sense of sarcasm? He goes, this is what we discussed in the day. It must match the designs your company provided in the RFP because that's our contract. I almost fell off my chair. I mean, to be fair, he did say we could change it and that it only needed to send me this change request that only needs two rounds of reviews sign off from my partners, sign off from their managers and update the cost for the budget approval. That's all. Let's just say we spent more than a year and a half on that and eventually we backed out of that. I was very bummed out. So what was the product that they didn't see that that didn't see the light of day? Let's just say it would have been at the time five years ahead of the rest of the world. Think Google Maps. Interestingly, about 10 years later, one of my more foreign-friendly contacts did ping me to say they finally went live. So you're gonna see, I went and checked out the link that they sent. But the first sign, something was not quite right was when I saw a cascading drop down to select the starting point and then another cascading drop down to select your destination. So after clicking go, if you didn't think that was bad enough, you didn't actually get a single answer right away. You got taken to a page where this is huge table where you run one finger vertically for your starting point, another finger horizontally for your destination. And where the two fingers meet up is, yep, you guessed it, your best mode of transportation to get from to a single place. Yep, I'm not sure I wanna remember to sync him. So the other example I wanted to give was when I was in one of the organizations that started to move to digital ways of thinking, but still had an analog way of thinking. Part of that was the new more agile and digital people were brought in to change the culture. But what you don't want to do is just replace everyone. You want to bring everyone on a journey so it's more balanced and organic. So in this example, we've been doing four-week sprints for the last six months where at the end of the sprint, we're doing releases to production, albeit to a very limited number of entire users, but still it's production, which was a huge paradigm shift from the one-year waterfall releases that we're currently doing. So as the product manager, everything is your problem. So when the release team said that we couldn't release the app unless they first completely regression tested by the testing COE, and that would take two months. Obviously, my nightmares of Prince II came back to mind. But after snapping out of it and getting off my high horse, I made a deal. Sure, let's do two months of regression, but give us, give agile a chance and at the end of your regression test, if you didn't find anything, please don't ask us again. Deal? Deal. So two months went past where I'm doing everything I can do not to know how the testing was going. And finally, at the end, I got a testing report. I read the testing report and guess how many defects? That was additional that the two months have found. They found one extra medium defect. That's it. One. Let's just say that team could gladly turn their attention to other teams and products that weren't doing agile. So trying not to gloat about the point that I'm trying to make is that we knew quote unquote, agile would work, but those not quite digital folks did not. I mean, you can only tell them, but the major, I mean, you can only tell them so much. So you need to lean in, bring them along with you, bring them along with you in the journey because if they do, they become your biggest advocate and they will make your life and everyone else's life easier. So moving on. The product school founded in 2015 and coincidentally, so did my product school, Ling. 2015 was when my company decided to go digital, but later never I'd say. And what an amazing journey it has been. Starting with a handful of product managers cooped up in an unused side door meeting room in South Bank in London, very far away from the financial hub and office headquarters in Canary Wharf. We, and soon as everyone else in that room affectionately courted the digital closet. Yes, you heard that right. I was pretty much living in London and because that's where the rest of the product managers were because I was the only one from Hong Kong. Yes, the only one. And did I mention that Hong Kong office has about 30,000 employees? But also, I was the only one that happened to be looking at mobile apps. I mean, get this, the company didn't think mobile apps were that important back then to the point where they effectively let me define and drive the product roadmap. Although there were the fun times, but that didn't mean it was smooth sailing either. So just to take a step back before I started doing product management, I was the lead engineer responsible for the mobile app. Going all the way back to the first mobile app for this company and we're talking iPhone 3GS here. And for those in case you didn't know, the first iPhone available outside the US was the iPhone 3GS. The iPhone one was only available in the US. So naturally the first mobile app was just a web view pointing to mobile optimized web pages. I'm not even talking about mobile responsive web pages. I'm talking about mobile optimized pages. So after serving as purpose, we moved on to a client site HTML implementation using jQuery because, well, there wasn't exactly that many native developers in Asia at the time. And again, it was great and we were able to launch it to 28 countries in two years. And so when it came to look at the next generation of the mobile app, that was when I moved over to product and was made to fix all my past mistakes. The unfortunate part was, whilst I was working on a new agile ways of working for this new digital team, which was made mostly of existing developers that helped me plus whatever new hire required rex we could beg, borrow or steal was this other new and huge industrial web engineering team that decided they need to launch a new web product, but also evergreen the existing APIs and the mobile app plan. Normally that would make sense, but they decided they didn't need any requirements. Yes, not any new requirements, any requirements because they can just rebuild the existing app. And by the way, that app has been live for three years but with the same look and feel, but instead using Dojo instead of jQuery and that it would only take them one year because their waterfall plans said so. If it's written down, it must be true, they said. So meanwhile, my plan to rewrite the mobile app with new designs and updated requirements was seen as a risky thing from a delivery inclined perspective. Yes, they rather take twice as long be just as shitty of an experience as it had been for the last three years. But lucky, or I like to think good thing for modern product development was that within one month we were able to show in production the new improved login experience which by the way was twice as fast to log on. Actually it was so good, I remember demoing this to the board of directors. And very quarterly, one of the C-levels started to rant on about how impressive the demos are in front of the board but then very pretty, whenever I get to the customer's hands it's much slower. I literally couldn't interrupt fast enough. I had to remind him, I just logged on using my own personal accounts and that it was more than welcome to use his own account and check out the speed of the app for himself. Naturally he declined. I would have mic chopped there and then if A, I had a mic in hand, or B, they even understood what that meant and that I didn't accidentally just drop the mic on the floor. Needless to say, my own mobile app launched soon after when it went from a one-star app to a 4.7-star app. But this webinar is called trials and tribulations. So there's at least a few more happy, less than happy, happy endings. Let's start with being, having to be very fixed skinned. I remember one night at the office, I was alone 11 p.m. which wasn't that unusual but most of the team members had already left. So this was just myself and my boss who was sitting about five rows behind me. And back then you had to call building management to turn the lights. So it was pretty dark except for the light coming from my monitor. Anyway, I started hearing someone braiding my boss about something. So I decided I better mind my own business. About five continuous minutes of this braiding. I realized the braider was my boss's boss and the subject of the braiding was actually me, not my boss. If I could sink into my desk and fade away into the dark any further, I would have. After hearing five minutes or what felt like 30 minutes operating on me about not pulling my own weight and not working hard enough and no, it wasn't lost on me. It was getting close to 11 p.m. at the time. I was finally done and he started to walk out of the office. But before doing that, yeah, you guessed it, he walked right by me. And he was even nice enough to stop and say, thank you for working late. It felt like a bad dream, except of course it wasn't. Speaking of working late at night, just as I joined the company and I changed the working policy, I started to phrase it. They started to phrase out five and a half working days. It's very normal back then that everyone worked five and a half days. I'm not talking about retail or food and beverage industries. I'm talking about banks, office workers, governments, everyone. Everyone had to work five and a half days. It was always very interesting how different companies, especially large multinational companies, would find a way to implement that. For the company I worked for, they just naturally expected you to work longer hours in the remaining five days. And this mindset was backed up by how we had to do our time sheets. Before the change, you were expected to enter seven hours a day, excluding the one hour for lunch. But then after the change, yep, you guessed it, they expect us to enter at least 7.9 hours a day, at 7.5, 7.9. And if you're thinking 7.9 hours a day for five days a week, it's not bad, right, it's not. Except it's a cap. You typically work 10 to 12 hours a day. Put it this way, people would have afternoon snack at 5 p.m. so that they can go working on until 9 or 10 or 11 p.m. I mean, even restaurants near the office had afternoon tea specials until 6 p.m., I kid you not. So if that's the norm, does it mean sustainable or even effective? Well, in a way, if you're in a production line, then I can see it working with some loss of productivity due to dimension returns. But if you're trying to do product, I never find it sustainable for more than a few months. And only then if you're trying to hit a launch date. But for some scenarios, it's very hard to argue with the results. You just need to be self-aware where your product is at in the lifecycle and also evaluate how much do you really want this. This is where I give my shout-out to those working in startups trying to do the first launch. All up, Hong Kong. Well, I was in Hong Kong for more than 20 years and I wouldn't change any of it. I met my lifelong friends there. I met my lifelong lessons there. I met my wife there. My kids were also born there. Remember, you are the sum of all your experiences, the good, the bad. But as any good product manager will tell you, you launch, you learn, you iterate. If you ever get a chance to live or work in Hong Kong, I would highly recommend it. I would be more than happy to give you some tips too. However, it will be different for everyone as everyone is unique, but the approach I recommend for everyone is just to embrace it. Learn from me, learn from others. Remember, as a product manager, you always have a choice. I chose to evolve and be better. Thank you for joining. Bye.