How to Achieve Alignment across Diverse Teams and Cultures

Phúc Nguyễn Khánh at UXDX APAC. Video: https://youtu.be/Wt-ZZTiDkao

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

About me and about Live Payments

[00:00:01] Hi, my name is Phúc. I work as senior product owner for online solutions at Live Payments, which I will introduce you to a bit later. For today, the topic today will be how to achieve alignment across diverse teams, and I'll come with some tips and tricks. So let's start with some information about my company, Live Payments, so you will see about the diversity in my company's culture.

[00:00:39] About Live Payments. Live Payments was established in 2006 in Australia. Live Payments provides payment solutions for SMEs and the taxi industry. Just for your record, all the opinions and thoughts expressed in this material are solely mine and do not necessarily reflect the opinions and the beliefs of my company.

[00:01:06] Some statistics about Live Payments. Live Payments have a national presence and an operation of 16 years. We process 1 million transactions per month and processing 1.5 billion transactions per annum. We are operating over 10,000 payment devices like EPOS machines in the Australian market. We also do some lending and we originated up to 200 million[?] for SME business.

[00:01:50] About our company's global presence. We are an Australian national presence, operating in Sydney, Melbourne, Adelaide and Perth. We also have a couple of offices in Clark in the Philippines, where we have the customer service team, the CLD[?], finance and application team. We also have an office in Ho Chi Minh City, Vietnam, where our IT development team is based. For me, I am a senior PO for online solutions and I work 100 percent remotely in Hanoi, Vietnam, two thousand kilometers from Ho Chi Minh City.

Why remote work across countries is challenging

[00:02:39] Next session. You know that remote working with diverse countries sounds very challenging. Why? Because we have a different context, we have a different culture, we have different market practices, and even the definition of success is different. That leads to the very big question: how to make a good cooperation? Then here are some tips and tricks for you, to quickly adapt to a new company.

[00:03:18] Tip number one: know your partner's culture. Let's start with some things that you should never miss. Number one, the time zone. Number two is the holidays, I mean the public holidays in each country. And number three is what to do and not to do within a country, like some religions have some taboo or something you need to learn, to avoid those things.

[00:03:50] That is what to know, and then what is to do? Yes, let's set up your calendar with all the time zones and holidays accordingly. I will show you how.

Trick one: time zones, and trick two: holidays

[00:04:01] Trick number one, time zone. Add time zones to your Microsoft Outlook calendar. It helps if everyone uses that tool, and then try to book recurring meetings in advance so you can avoid the unavailability of your partner. For me, I have the time zones of Hanoi, Sydney and Manila, so I know that, oh, I should never book a meeting at 9am Vietnam time, because it's lunchtime in Sydney, so everyone is tired at this time. That is a good example.

[00:04:48] For non-recurring meetings, and with so much difference in time zones, you can do the same, but there are some tools just in case you don't use Microsoft Office. Like you can google "time zone meeting planner". You can see that to my right hand, the red one is not the good one, right? So the green one and the yellow one is some time that fits everyone. So those two are very helpful.

[00:05:18] Let's go to trick number two, holidays. So just simply add your holidays for your own country, related to your work, into your Microsoft calendar. You go to the calendar settings and simply add the country, and you see in my example, oh, I can see that, hey, this is the holiday in Australia and this is the holiday in Vietnam, for example. So maybe people are not in the office, they're at home celebrating with their family, so do not have a meeting on those days.

[00:06:02] And the other thing is, you should remember to learn and share the meaning of a holiday with your colleagues. So, I learned about your culture, so that's a good start for the relationship building.

Tip two: align the way of working

[00:06:19] Let's go to tip number two: align the way of working. Aligning the way of working, this is a very big topic, because every country, every company has a different way of working.

[00:06:34] Number one, company vision and target customer. Why the importance of company vision? You should know the market share that your company focuses on, and is it SME customers or retail customers or some priority segment of customers. So this is very important because everyone should share the same vision and set the same view on the market share and targeted customers, so that leads to the same understanding. Otherwise everyone thinks in very different ways, and the way you make a decision on any solution is very different.

[00:07:16] Number two is your role and responsibility within the company. So this means who does what in your organization, right? This is very simple and seems not a big deal, right? However, in the world, adoption is very high and increasing nowadays, the company structure and role responsibility becomes loose and varied. For some other cases I see that for a very complex structure it's very hard to remember who does what. So think very normally like, who does what, who should I talk to when I need, so, why I need that person's decision or advice on a solution.

[00:08:13] Yeah, it takes a lot of time when you first come to a company, and you should know and you should never forget, because when you output your product or system, go to market, everyone will use your solution, right? For example, you are an IT developer, you make a solution and then some staff in the operation team will use that. So without knowing that, there's some advice from the operation team, there might be some defect in your solution that you are not aware of.

[00:08:50] The third one is the success metric. Success metric. After you know the company vision, you know who does what in your company, and the next thing you should know is understanding the stakeholders' expectations. So the CEO might think about the market share, the CFO might think about the income and costs, or someone like a COO cares about how to operate successfully and effectively. So each stakeholder has a different expectation, and this varies from company to company. So you have to know those things when you create some new solution.

[00:09:35] The next one is about finalization of the project. Why am I not talking about delivery? Because, one of the reasons why is because everyone is talking about delivering the project, how to do that in the PMP or just so many methodologies. But I see in practice the finalization of the project, like to review it: why did we succeed, why did we delay sometimes, and what is the key learning and how to share with other project teams. Usually at the end of the project everyone is tired and it's given less attention. So the learning of those projects is very helpful for the company to grow better. So finalization of the project, or even the closing of the previous ones[?], you can learn a lot from that, like learning the expectation of each stakeholder[?] for example.

[00:10:38] Yeah, success metric, meaning the KPI, okay, and other important metrics. So it depends, right? For a startup maybe, at the very beginning you cannot expect a big revenue or big income, so maybe the market share is the biggest target. So to know and to achieve this, it is very important to know what to do.

Listen, respect and share differences

[00:11:13] Like, the way of working, meaning for me, is number one, to listen, respect and share differences. You cannot know anyone from a different culture or country, therefore from a different country, in one day, right? Because simply that is not the environment you live in. So number one, try to listen to any differences that your colleagues share, and respect the differences, and even after that we can share, hey, this is my thinking, why this is market-wise successful in my market, and let's talk about how to together close the differences and reach agreement.

[00:12:07] To do that, number one, you should have some rules. You should have some rules. Lightweight working, meaning that you have some basic ground rules first. Don't create complicated rules, my advice is to not create complicated rules. So for example, a very simple rule like no meeting during lunch time or a holiday, of course, right? The second one is try to keep the meetings short, and maximum 60 minutes. Technically 30 minutes makes everyone rush, and it's a very good meeting, 30 minutes, I feel it's a very good meeting.

[00:12:55] And the last one is, for agile working we have a retrospective session. So anything you together agree on in those sessions, I call it a group agreed rule, or any other agreement following the retrospective session, my advice is to follow it.

Trick three: the organization chart, and roles in product management

[00:13:22] So let's go to trick number three: organization chart. This is an illustration of my extended screen, where I take a screenshot of the very big structure. For your information, this is of course not my current company structure, so this is just a picture. But this will show you how convenient it is. For example you can work on one computer and for the extended screen you can just put it in the background, so it will not take you time to find that photo in your documents. So that is my trick and I feel it's very useful, to remember everyone, and even someone you seldom talk to.

[00:14:19] Next, okay. As adoption is increasing, company structure and role responsibility become unique. For this I mean, from my experience I see that each company has a very unique role and responsibility. Even if we call it the same title, like product owner, but the definition of product owner in each company is a little bit different from the other. The following case is my current company, and it is a hundred percent different from my previous place, even though we both adopted the agile approach, even though we both adopted the same framework[?]. Just for your information, I'm working for Live Payments now, and my previous positions were in three other companies[?], within my 15 years earlier, so I see so many differences.

[00:15:31] Okay, so this is the introduction, the suggestions for product management. At the top you can have the product director, PD, then the product manager, then the product owner. So the product director would be in charge of business objectives. That means all the activities that facilitate alignment, priority and goals. So some highlights are overarching goals, high level priority and initiative roadmap.

[00:16:08] The second role is product manager. Product manager, PM, is not project manager, just for your information. Product manager will be in charge of product strategy, and he or she will provide a clear plan for Live Payments, my company, to reach each goal. Product manager will be the owner of product vision and mission, personas. Of course personas should be based on your target customer, not the personas of the whole world, the whole market. And also the product metrics, like for example the success metric, and the product roadmap.

[00:16:59] The third role is product owner. The product owner is someone focused on delivery. There is a meaning to drive and support in delivering values to customers. You can ask me, this is product management, so why is it not delivering the product to your customer, right? Yeah, that should be a very good question, because now in the new modern world what we want to do is not selling what we have, we're selling what is meaningful to the customer. So what is the most meaningful to the customer, we call it the value, right?

[00:17:51] The product owner typically manages the product backlog, design experience, feature roadmap, release planning and agile delivery. So you can see this is the whole product management life cycle: product framing, create a vision, identify problems and define success, research, design, pilot, launch and measure. So this is a very classic product management life cycle.

[00:18:25] You will see to the left some of the detailed work for the product manager, on the right is some detailed work for the product owner. For example, product manager, when they do the product orientation, product roadmap like this one, they name goals, features, metrics, and do some SWOT analysis or some DVF analysis, which I will talk about in detail later. To the right, as you can see, the roadmap, for example this is an agile map, you can go up and down, do some enhancement or new feature.

[00:19:08] Yeah, everyone talking about sprint, and yes, it's part of the role to monitor the burndown chart, for example. My burndown chart looks very good, right? To the left, the PO manages all the releases, matching with the product roadmap. In terms of the timeline, anything prioritized within the backlog with less than three months goes to the product owner. Anything for maybe three, or maybe not typical, or six months, from six months to half a year, a priority for six months and longer will be the role of the product manager.

[00:19:55] The other question I am often asked by my colleagues is how the PO and PM work together. So the product director often has a scheduled sync-up with the PM and PO, but the PM and PO often work together back in the sprint and iteration. Some companies use iteration as one, consisting of two sprints, or some with a larger sprint. A sprint is typically two weeks. So the product manager should know what to do, and of course we focus on the goal. Hey, after the two weeks work, are the goals reached, or do we need to wait for six weeks, meaning three sprints for example? Product owner will be the one who makes sure the delivery will be on time and the outcome will reach the value that they desire.

Trick four: set up rules and agreements

[00:21:05] Okay, that's the general information. So let's go to trick number four, I hope you can apply this. So, set up rules and agreements. Before doing that, please, please keep in mind that disagreement naturally comes first, until your team reaches an agreement, and it often takes a lot of time to reach an agreement. Across all the companies I work for, disagreement naturally comes first, I see it all the time.

[00:21:45] So the trick is, instead of trying to protect your idea, the trick is to drive your team to share and agree on any principle and common rule first. Because if you are not on the same criteria, there is no talk, okay? Then the whole team use the principal rules to review the disagreement and all the alternatives together, okay?

[00:22:25] So, do not, instead of trying to defend your idea or your solution, or try to find the weakness of others' options only. And do not allow one specialist to ignore the wisdom of the team, by, for example, the CMO said like this, for example the CEO wants it, or the chief something officer wants something, okay. Just to bring up, okay, what is the principle, what is the common rule? We should set up those things, otherwise it's very, very hard to reach an agreement.

[00:23:10] I now want to ask you a question for thinking. Number one, have you ever heard questions like, within your team, some may say, why would we do this? Or some might say, why is it so urgent, or why is it so high priority, I don't think so, I think the other thing is a higher priority. The other may say, why not another workaround, this solution is very hard to achieve, something like that. And the others say, hey, can we make it on time? Some say, oh, I think I can develop it, but the others say, maybe you can do it but the testing is longer.

[00:24:00] So, a lot of disagreements from each person's view. So there should be some condition. For example, maybe a dev will say, hey, it's easy, I can make it, by Friday the work will be finished. But the tester might say, hey, if you finish after Friday I cannot finish the testing, we need it on Thursday only[?], that's the maximum time I can afford, for example. So number one is to not protect your idea only, but to set the principles and the common rules.

Defining backlog priority: criteria and points

[00:24:42] You will ask me how, okay. So, to make rules and agreements work, I mean to make rules and agreements easily applied, to save discussion time, here are some suggestions how to do this.

[00:25:08] In my product owner life I see that defining the priority is something that has a lot of arguments, so today I will bring this to the discussion: defining backlog priority. So number one, you should agree on the set of criteria and priority based on the impact or output. If the backlog is about legal and non-compliance, it should be number one, right? The company should not be fined for some non-compliant things.

[00:25:48] Number two is business continuity. So for example, if you don't do this the whole business stops. For example someone's contract expires[?], you need to replace this with a new one, and the new solution will take over[?]. Those backlogs should be number two priority.

[00:26:09] Number three, yes, we're living in the modern world where the customer is at the center of all the plans, so customer satisfaction should be number three, very high level. The other thing is about technical enhancement and stability. For example, without some upgrade some of your customers might not be able to use the service anymore. For example you have some minimum requirement from Google or Apple, so you need to update it, otherwise your app will not be posted on the app store, for example. So that is something you should be mindful of. Or sometimes you see that there's some outage with your system stability, so you should not let it happen for so long.

[00:27:03] Number five, this is the goal plan, or something to consider. Whenever we satisfy the customer, we can never leave out the company business plan. That's very important.

[00:27:19] Number six is about the data enhancement. This is my advice to everyone, because now it's very easy to copy a product or a feature of some solution. But you can never copy the knowledge, someone can never copy your knowledge of your own customer. So the trick is you need to do the data enhancement, to have more data on your customer. What is the most value to your customer segment, right? Your company targets this segment, the other company targets another segment, so someone trying to copy you might not work with their different segments.

[00:28:19] So, how to know your customer, that should be based on data. Data can be got through the customer review or some collection with the data tracking tools like Google Analytics, data analytics. So there are so many tools in the world now helping you to do the data enhancement. So there should be some categories like this and some priority order. So when you align the backlog you say, hi, I do 30 for business continuity, 40 for customer satisfaction, so then it's much easier to align on the priority of the backlog.

[00:29:08] So the next thing, to follow easily, that is the basic criteria, and now I can lead you to the next advanced variation. So after having that, maybe for example six, seven, five, ten, whatever criteria, you should go back and align with your company product vision. For example, business continuity: if you cannot sell a product because your supplier or something, the contract will expire, and you should let go some customers, so you will see that maybe your company vision is to focus on something else and does not wish to continue that business, right? So that is the level of the company or product vision, so you should lower the priority of the business continuity and maybe put the customer satisfaction up, I mean at the higher priority.

[00:30:26] Number two is set a point to each criteria category. For example customer satisfaction, but not all the backlog is at the same level, right? Some based on a score rate of 100 for example, some backlog might be 80 percent impact and the other maybe 20 percent of the customers. So you can set some points to those categories, so later you sort everything by point only. For legal, maybe you set it 200 to 300, so that's to make sure that it will always be on top, for example.

[00:31:11] Number three, allow data to drive your decision. Data driving is now industry world practice, right? You can use some free tools like Google Analytics to track how your customer uses your mobile application for example. So you can see the drop rate. Hi, so this amount of customers log in, and this may be dropped to 80 percent of the people who do the first feature, and they drop to 50 percent of the people, of the customers, who make the successful transaction. So what happened with that 30 percent? You make some analysis and see, hey, this would be the big priority on this stage, for example.

DVF: viability, desirability, feasibility

[00:32:09] Yep, another high level analysis is DVF analysis, to make a decision. I must advise you this because it's simple and it balances everything. DVF. We have viability, that is the business requirement, to make sure that the backlog we have brings the company growth. Desirability, so you can translate it as what is the need of the customer. But we also have this one, which is the feasibility: so what is the solution, and do you have enough resources to do it[?]?

[00:32:57] You can see to the right there should be a sweet spot of the three circles. So viability is business, desirability represents the customer's need, and feasibility will represent the technology, the operation and resources, meaning the project team for example. Try to balance.

[00:33:25] Another example of the use of this model is, viability, okay. The legal, company or business CFO might set some target for viability. Somehow you find that it's not viable, so, in this area. But somehow you find that desirability, the customer wants it, maybe it's a very popular feature in the market. So you see it's not feasible and want to make it close to this, so maybe the next thing is to purchase some new solution, for example.

[00:34:15] When your team knows, hi, when we decide the next solution we should consider, hey, does it satisfy the business, does that bring some value to the customer, and yes, is it possible for us to do it? So it's a little bit more easy to reach the agreement on this sweet spot.

Summary

[00:34:42] Thumbs up. Let's go to the summary on how to achieve alignment across diversity and culture. Throughout my presentation I have some notes here. Number one, you try to book some recurring meetings before the iteration, your iteration of the sprint, starts, so everyone will not have duplicate meetings.

[00:35:10] Number two is to review the sprint work and success metric on a very regular basis, and it should be in a separate meeting: the review sprint, and the success metric. Review two weeks' work; the success metric should be reviewed in another meeting, like, hey, after we're doing this for months, did we reach our goal?

[00:35:41] Number three is to practice more, constantly listen to your teammates' issues[?] and make adjustments during the retrospective session. Like what I have mentioned, the very last day of the sprint or last day of the project, people are feeling tired and normally feeling reluctant to do retrospective, so you cannot learn from each other and cannot do the enhancement or work well with the team. So this is very important, to do it constantly.

[00:36:22] The last one, now the focus for you is a regular sharing session. This is an important item in sprint planning. So typically a project team often does the research and the development, maybe then go to production, that is typical, but let the team remember to do the sharing. So number one is, you cannot learn from each other, right? Number two is, the team's progress[?] is very slow. So a sharing session maybe once a sprint should be in the recommendation. Thank you for your time.