 Welcome to this week's Product School webinar. Thanks for joining us today. Just in case you didn't know, Product School teaches product management, coding, data analytics, digital marketing, and blockchain courses online and at our 15 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, live streams, and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Hey everyone, I am Kusbucha. I'm a product manager with Amazon. I work in the Alexa team within Amazon. So I work with the Echo Family Devices. And today's topic that we are discussing is global product development. And why? You need to think about a global product even when your mandate is to launch a product that's to be used by local customers. And so, here is the reason why. Globalization is nearer than you think. The world with the internet is a much smaller place than you would expect it to be or than it used to be. I live in Canada and if I'm talking about Canadian customers, Canadian customers are diverse. Like 46% of the Toronto population is foreign-born. And technology needs to be an enabler, not a constraint. In fact, I would like to believe that expanding to a new country needs to be a business decision and not a technical decision. And therefore, product has to assume that whatever products we are building would eventually move to new geographies. That's how you have to think about product development. Whether it's a software, whether it's a hardware, or it's a process that you're designing, it has to be scalable across boundaries. Here is a map that shows where do all the people that spend time on the internet will live. Not surprisingly, the largest number is in China, followed by India, and followed by US, followed by Japan, and Brazil. So the next time you're designing a product, it could very well be reaching any of these, say, top five geographies. Then do you have all of them in mind? Make note that the countries themselves are pretty diverse. There is way more to global product development than just translations. In fact, customers may vary even within geography, like I said earlier, even Toronto has 46% foreign-born population, and they're not all from the same country. You deal with customers that have different requirements. One, of course, is the ability to interact with your website in their own language, but there are other constraints. For example, if you're a supplier, you would want to get paid in your own currency, and that can come into play. If you're a seller, say, on Amazon, then you would want to sell to customers outside of your geography, maybe to Japan if you're based in China, maybe to all geographies that speak French. That includes France, but it also includes Canada and large parts of Africa. A seller in China may very well want to sell to customers in Japan and in Europe, and so when you're designing a product, even if you have a Chinese seller in mind, you have to make sure that it adheres to its needs to sell outside of just China. There are three key components to globalization, internationalization, localization, and translation. Internationalization is the simple set of making a product.com to .co.uk to .de. That's internationalization and all the things that come with it, which is making sure your text fits in the space, making sure your design is aligned, making sure that you have factored in the language and styles and the culture in your account. Second part is localization. Localization is more than just the design, it is images, graphics, inherent cultural assumption, norms. For example, in the UK, taxes are usually included in the prices. In India, when you're talking about delivery, you have something called cash on delivery, which is basically you pay after the product reaches your house. Those are things that are very, very specific to the regions and very, very specific to the target market, which you do not think about when you're designing a product for North America, for example, and of course, translation, which is what everybody thinks of when they think global product development. But globalization or a globalized product is a way of thinking, and this thinking needs to be integrated at every stage of product development. It needs to be there when you're defining the product requirement. It needs to be there when you're evaluating the approach and it needs to be there in your launch plan and your success criteria. Defining the product starts at the requirement phase and it starts with data gathering. Data is of course the king. So start with data about customers in global location. Do not be blinded by assumptions. For example, data is the most common one. Five to seven. What is it? Is it May 2nd, 2007? Or is it February 7th, 2005? Or February 5th, 2007? Dollar can be US dollars, Canadian dollar, Australian dollar, and it could be with a common or a dot separator. So when you see a dollar sign, you cannot make the assumption one way or the other, and when you're designing it, it needs to accommodate, say, a future need of USD to incorporate CAD and eventually AOD. Do not stereotype customers of a geography. Appreciate the diversity. Canada I keep coming back to is enough for an example. But US is pretty diverse, not just in terms of the climates between East Coast and West Coast or the lingo between Boston and California, but also in terms of the customer needs the customer choices and preferences which can vary between geography. You cannot assume all US customers are the same, nor can you assume all Chinese customers are the same or all Indian customers are the same. Therefore, good assumptions are flexible. Customer data will eventually determine the nature of the product. For example, you can assume that, okay, if you are in India, you're assuming that mostly poor connectivity and the internet is half the time down, well, not so much if you're living in New Delhi or Mumbai, for example, and you have excellent connectivity with high speed deal and customers have unlimited internet just like in the US. So if you've designed a product that doesn't adhere to the needs of these customers, you haven't quite won these customers ever. Needs and constraints would vary around the world and therefore your assumptions need to incorporate the flexibility or the ability to change as you go around different places. Defining a pattern is the key because you can never design a product that's meeting the needs of all customers in every geography, in every part of the world. So it's important to identify the key ones. It's a standard 80-20 rule. You have to say, okay, 80% of the times customers face this problem, so let's solve for the bigger ones and then as we go along, we'll refine for the smaller ones. It is also important to identify differences in cultural and language requirements. Language is something that everybody gets. That's the easy one. But the cultural nuances or cultural norms or even just a matter of habit is something people take longer to adhere to. Therefore, going back to my bullet one, start with data. Excuse me. If you're assuming that customers are not going to use credit card, well, does the data say so? If you're assuming that customers always go for cash on delivery in India, well, do you have data that shows so? Or there are more and more customers that are now using debit cards or online wallets like ATM. Optimizing a global customer's requirements requires creating personal. So when you're talking about customers from the east coast of the U.S., well, there's a customer from the west coast of the U.S., you have to ensure that you have the right personas of your target customer segment. This would help you get into their shoes, like literally get into their shoes and understand what is it that is going through their minds, what is it that would delight them the most and does your product get it to that aspect or not? Get stakeholders in various parts of the world to help you. This is not something that you can do as a lone warrior. There is no way one person can understand all the different personas and all the different parts of the world like they had lived in them. So you need local help. You need somebody to be able to point out why Boston is different from New York. Apart from stereotypes, there are local nuances which only a local can help you and therefore you need allies. You need stakeholders, research agencies and customer outreach programs that would help you gather requirements and data firsthand from the local user, whether it's east coast, west coast or somebody in Germany. But then the other catch is that if each one of them goes on their own journey and has their own customer discovery, then you don't know what to make of all the data that you would have gathered. So it's important that you use a template so that while the data comes from different parts of the world, you're able to use them together. You're able to use them in a very modular systemic fashion. And so everybody uses a standard template, has a standard way of collecting data and is looking for similar nuances of data. Local customer experience considerations have to drive the product design. And your mandate may be local, but unless you have factored in expansion in the future, unless you are aware of all the different factors that your customers might present, you would fail to incorporate this ability to scale and expand early on, which basically means a lot of throwaway work at future stages of the product development. A lot of not so ideal decision making and product decisions that are not perfect. So you need a framework. You need to design the user experience and capture and use the framework to capture the experience across geography. You also need comparable success criteria for launch. It is important to know that if my customer satisfaction has to be four on five, it has to be four on five for Germany launch and it has to be four on five for US launch and for Canada launch. Or you could say that, okay, if JP is, for example, a difficult language to translate, I am okay with the Japanese customers having less customer satisfaction compared to my US customers because 80% of my customers are in the US. Translation and localization is an important part. And the earlier you start on the process, the better it is. A lot of many products and a lot of many projects have not seen the light of day because they couldn't complete translations on time. It is far more complicated and nuanced than Google Translate makes it feel. Our customer service and support is also very local. What an Indian customer is expecting when a customer service picks up their call versus what a customer is expecting when a customer service picks up their call in the US could be very different. The level of detail a customer may ask the support team in Germany, for example, can be very different from those in your cave and you have to be prepared for all of those kinds of customers. Even within the same geography like US or Canada, you have a diverse group of customers that have different expectations. And it is important to know that say, for example, in the mid US or Southern States, there can be geographies where transport takes longer and therefore you would not be able to accept their returns in 24 hours. It doesn't help because they can't get you the stuff in 24 hours. So you have to give them longer lead time for them to be able to get it to you. And so on. There are some interesting stuff. Isle of Man, Jersey, in Guernsey is an island off the coast of UK, but it's quite not in UK. So it uses GBP and GGP. It actually has two currencies and they use both. If you're selling to somebody there and you're thinking you're servicing UK, then you're in for a shock because there's a second currency out there. Legal and safety is another aspect that can vary a lot between geography. Not just in the rules, but also and more importantly in the implementation. Even when the rules are standard across air travel, the implementation varies from airport to airport as you probably already know. Payments and taxation is usually different across different geography. And if your product design hasn't incorporated the different kinds of payment instruments, the different kind of payment channels and taxation that you might be up for, then expanding in future geographies is going to be a challenge. Fulfillment transport and logistics also varies by geographies. The time it takes to transport, the options for transport you may have. FedEx may be a great option in some geographies, but not in the others. Maybe a local courier is a better option for you. Maybe the local post office is the best option in some places where there is no UPS, FedEx, DHL, or any of the other global transporters. And so you have to factor this in very early on that if you have hard-coded your logistics operator, then that can be a challenge in terms of design and architecture later on. You cannot make a global product without the tech team also thinking forward. I mean, I can talk about high-level examples, but just handling a non-ASCII character correctly is important. Are you Unicode, UTF-8 compliant? It's priority because there's no way you can translate later on. It would become a humongous task in the absence of these basic practices. If you're using specific information for coding, do not make it hard-coded. Use internationalization APIs for formatting and you have tons of those. There are external resources and you would use them off and on. Publicization, fulfillment, local transport, we can't hard-code them. They have to be separated from localizable content. So, strengths and external resources are different aspects. Another rule and a lesson learned with much, much, much problems faced is avoiding string concatenation. When you concatenate two strings, it's basically not something you can scale, translate, or look like. String 11 plus variable plus strings tool is equal to impossible translation. Allow for text expansion. This is the most easily missed. You would think you would readjust later on, but actually some languages take way more space for the same idea I expressed than some others. I just given a comparison between English and Spanish and as you can see, if your website's wireframe did not factor in the Spanish words, then you have a problem. Icons, images, multimedia, are very culture and local sensitive. Dates, numbers, currencies, these are stuff that everybody gets right. And yet they are sometimes hard-coded, which means that they're not easy to change. They can also be misinterpreted if you are selling into geographies or dealing into geographies. For example, USD and CAD are both dollars. But the Canadian dollar and the US dollar are different. And if you code something in US dollars, then you have to mention it is US dollars. And you have to mention the equivalent of Canadian dollar when a Canadian customer asks the same thing. So how do you decide what you would do, what you would not do, what's other easy ones, and what are not the easy ones? I've tried to put this whole set of features that you may have to do trade-offs for into four buckets. Based on cultural considerations and technical considerations. Technical considerations could be easy to implement technically or difficult. And cultural considerations are how local or universal it is. So if I were to look at bucket four, we are talking about say power outlets, plug type, warranty type. These are really tough technical considerations. They have to be thought about at the onset because you cannot change them much later in the life cycle. However, in terms of cultural aspect, they're universal. Like most customers don't care what the plug type really is as long as it fits into their socket. That's about all that they care about. Similarly, if I go to bucket three, it is high on local considerations, but low on technical. Social media requirements are a very important example in this pocket. Because social media is very, very region-specific and very culturally sensitive. But in terms of the technical aspect or the technical implementation, it is low effort. Sure, you need the feed and you need the database to pull the requirements from. But at the end of the day, it is not a complex technical problem. It is not something that cannot be added on later, changed later. However, making sure that the promotion that you send out or the social media presence that you have does not offend anybody and delights everybody and gets the right message is tricky. Bucket two is the easy one. Say you have a feature like we do at Amazon, customers who bought X also bought Y. Simple, easy, everybody gets it. Every geography has it. And technically, once you've implemented, it is the same logic. Customers in a region bought X, they also bought Y with it. Simple. And so once you have got the logic in, you're good, easy to scale. The bucket one is the toughest one. Things like local payment options or delivery options. So cash on delivery is something that nobody in America has ever heard of. But you go to India and that's quite the most preferred option, which is basically saying that they will pay the vendor cash when the vendor arrives at the doorstep for their stuff or anything they ordered online. Unheard of in the US, but in India and Japan, that's a thing. That's an important thing. The implementation of which is super complex. Imagine having to deal with cash through your delivery boy. It is going to be a nightmare, making sure the accounting is correct, making sure the customer pays correctly, making sure it is tracked all the way back when the customer made the payment. And you have already shipped the product. Then there are delivery options. In fact, there are places in Scotland that you can't even reach by road. There are no roads. There is no road that goes there. You can maybe use drones to get there, but clearly your FedEx and the DHL and the UPSs do not yet deploy drones. So those options are ruled out. Do you want to leave those customers out? Maybe you have a rich king sitting there. You don't know. What is ton of stuff from your website? Would you want to miss out? But then you have to think this one through. And so when you're deciding on your requirements, you have to also acknowledge where in the bucket it fits. Because that would determine how much resources and which teams you would engage with to deliver those. Something high on social media and local content does not probably require as much tech resources as something that's high on technical content. And finally, your delivery plan and prioritization by geography. You have to define the product success criteria by geography. You have to take a call on whether the customers in Germany are going to receive a similar customer satisfaction level, customer accuracy level, if there is an accuracy involved in your product. What is a customer in the US? Or are you OK with the German customers getting less accurate results? Or maybe it's vice versa. Actually, the US customers care much less about accuracy than do the German customers. Again, then the feature aspect. Do all countries need all the features? Or some countries need additional features, like delivery options or payment options can vary between geography. Some countries may need additional features, such as showing the taxation, showing the local stats, and you have to show those differences in detail. Some others couldn't care less. They care about the total payment that's required. The next question and the most important question is do you need to have a full-featured launch in every geography or in phases? This is only, of course, if you are looking to launch globally. Maybe you do it in phases. Maybe you do a big bang approach and launch in every geography at the same time. Can you even launch in all countries with the solution? Maybe not. Maybe you do not have the resources. Maybe you only stick to US to start with or Canada to start with. And then if the product works, if you have enough traction, then you go to other geographies. In either case, you have to plan for it beforehand. What is going to be your approach if you were to go beyond one geography? What resources do you need to launch globally? Translation, sure, everybody gets it. But maybe you need editorial. Maybe you need legal. Maybe you need designers that will make sure that all aspects of your product are designed for a global customer. And how to ensure that you keep all your global stakeholders updated with all the changes that your product is going through. You launch a product in the US. It goes to Canada. Now it has a French version. And you have to ensure that maybe the French users in US also get a French version. So are you keeping them at par or not? It's important. And finally, what is your QA and user acceptance test plan? You have to test for all locales and events. Or do you do them one at a time? Or is it one QA? Or each geography will have its own QA. Keeping all of these questions in mind is important and critical when you are aware that you're going to launch in more than one geography. But even when you are not going to launch in more than geography, it is important to be mindful of the requirements because customers are diverse even in a single geography. That's all from my side. If you have any questions, feel free to reach out to me at chat.kushboo at gmail.com.