Maintaining Team & Product Alignment Through Hyper Growth

Nigel Yeo at UXDX APAC. Video: https://youtu.be/1WSviBduisk

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.

Xendit's origin story

[00:00:00] Nigel: Thanks for having me.

[00:00:02] Rory: Thanks for coming. Can you give everyone a very quick introduction to yourself and Xendit, so that we can get some context before we start talking about the hyper growth?

[00:00:13] Nigel: Sure. Hi, I'm Nigel. I'm currently the chief of staff to the head of product at Xendit. I've been in the company for about four years, and we've been operating for about six years in Southeast Asia. I'll speak less about myself; I find it less interesting than the story of the company.

[00:00:30] Nigel: Xendit is a payments provider. There are many terms that can be used for this: it can be payment services provider, but the most common term is payment gateway. There are certain technical differences between some of these, but for simplicity's sake we can just keep it to that. The story of Xendit and how it started was with our CEO, Moses. Moses is of Malaysian Chinese ethnicity, but he grew up in Australia; I think he's a citizen there, if I'm not wrong. Then he did his master's at Berkeley. His family has always been involved in doing business, so he has been bitten by the business bug, I think, since he was a kid, and he always knew that the one thing he wanted to do as an adult was to start and run a business.

[00:01:18] Nigel: When he went to Berkeley to do his master's, of course that's where Silicon Valley is, and he met his co-founders, Bo, our technical co-founder, and our principal architect, Juan. They are American Chinese and American Mexican respectively. They gelled, they applied to Y Combinator together, they got in, went through the Y Combinator program and got seed funding from YC. Then they decided that they wanted to launch whatever product or business they built in Indonesia, because of the massive opportunity that is in that country. They did that in 2015, and they released their first product in early 2016.

[00:02:04] Nigel: Since then we have done multiple things. We've grown our total payments volume from just a couple of thousands, hundreds of thousands, to 2022, even in the midst of the pandemic, when I think it was about hundreds of billions of USD per year. We now have, I think, close to a thousand employees across six to seven territories. We're currently mainly operating in Indonesia and the Philippines, but the company is looking at expanding to the rest of Southeast Asia. The way that the company has evolved in general is that we focus on making payments simple, seamless and reliable for customers, and now, on top of payments, we're looking at building digital infrastructure for Southeast Asia.

[00:02:59] Nigel: Just to close this background off, the interesting bit about the company is that when the founders first started, they actually launched something like a Venmo for Indonesia, a peer-to-peer B2C payment app. They found that in Indonesia, because of the financial infrastructure that was available, it was not even reliable enough for them to perform those peer-to-peer transactions. So they thought to themselves, instead of working with what we have, why don't we try to build financial infrastructure that can be used to power these types of B2C merchants in the future? And that's what they did. That's how we've come to where we are today.

[00:03:41] Rory: Excellent. You make it sound so easy: why don't we just build an underlying financial infrastructure? I'm sure it only took a few days.

From a living room to a thousand people

[00:03:53] Rory: That was great, the background to the company. You launched in 2015, and in seven years, as you said, you're up to a couple of hundred billion in transacted volume. Can you give an indication of the hyper growth from a people perspective? I'm assuming it started with the three co-founders, and then over time it just grew from there. Can you give me a rough timeline: when you joined, what was the size, and how has it grown from there?

[00:04:24] Nigel: Gotcha. I can even start from before I joined, because of course I've heard enough stories about it. Of the three co-founders, one of them was not able to come to Indonesia, so two co-founders came to Indonesia. It was just the two of them at first. They found their local co-founder, Tessa, who is also one of the co-founders of Xendit, and they started off with any engineers that they could find. That included engineers who had applied to them because they had heard of them by some means, and some of these engineers were even still studying at the time: really enterprising students from schools such as the Bandung Institute of Technology. They were happy to come down and interview with these three co-founders in a house that looked nothing like an office, and realized, oh, this is an interesting opportunity. So they would join even at that stage.

[00:05:25] Nigel: Before I came in, around 2016 to 2017, all the earliest engineers as well as the co-founders, maybe about 10 people, were pretty much working in the living room of a house that I think was rented by the co-founders. When I joined, there were about 50 people or so. It was simply the same formula replicated to include more people, so it was just a bigger house. Housing is not as expensive in Indonesia as it is in, for example, Singapore, where I currently live, so you are able to rent a pretty large house that can allow your employees to sleep, and also has a living room as well as a basement for the majority of the employees to work in.

[00:06:12] Nigel: There are some fun stories, because what Moses likes to say is that they've seen all the elements. They've experienced earthquakes in Jakarta. They've had an incident where the entire basement, which is where all the engineers were housed and working, was flooded, so they had to move all of the computers and the rest of the important things out of the basement. And I was lucky enough to have joined when they experienced the third element, which is fire.

[00:06:41] Nigel: Indonesia has this holiday period called Lebaran. It's a religious holiday, and at its extent it can be up to 10 working days of public holidays. As a result of that, the caretaker who was supposed to be clearing out the dried leaves and things like that was of course on holiday, celebrating with his family. The dried leaves that were being piled in a shed next to the house somehow, because of the heat and the dryness, maybe there was some spark somewhere, perhaps someone threw a cigarette butt, we're not sure, caught fire.

[00:07:24] Nigel: For those of you who are not familiar, if there's a technical incident that's causing some disruption to our services for our customers, we call that a fire. Some of us were working during the holidays, because the foreigners don't take those holidays; we continue to work. Someone said, "Hey, we smell smoke," and I said, "Oh, it's probably nothing," because we walked around the house and didn't see anything. Then 20 minutes later the same person said, "I still smell the smoke," and this time I said, "Yeah, I smell it too." We went out and we saw it, and we raised it in Slack and said, "Hey guys, there's a fire." People said, "Oh, what's happening to our services?", and we said, "No, a real fire. This time we've got to get the fire department down." Thankfully there were people around the area who had experienced these sorts of things, and they knew what to do. So there was no property damage, no human injuries or lives lost.

[00:08:18] Nigel: That was about 2018, when I joined. Before the pandemic, until about the end of 2019, we did grow, I think up to about 200 to 300 people. That was just before we had launched in the Philippines; we were preparing to do so. But as with many other companies in the course of the pandemic, especially companies that were suited to capitalizing on the fact that everyone was going online and not able to do physical purchases or go shopping, we experienced a period of hyper growth as well, because so many merchants were trying to get online. And the existing merchants themselves were also seeing significant growth in their own businesses, especially those that could capitalize on the pandemic. So in those two years, when I was not able to fly around and meet people, go to Jakarta and meet the majority of my colleagues there, or visit the Philippines, which was a new market we were expanding into, we grew even further. That was where we added, I think, the bulk of our headcount, to close to a thousand people today.

[00:09:39] Rory: Excellent. To summarize, you joined in 2017 or 2018 with 50 people, and then by 2019, at the start of the pandemic, you were up to about 200.

[00:09:50] Nigel: Yeah.

[00:09:52] Rory: So four-x-ing the size of the organization in a year or two, and then again from 2020 to 2022 another 5x. I think that qualifies as hyper growth.

[00:10:09] Nigel: I think so, yeah.

How product management grew

[00:10:11] Rory: Great. Can you give me a bit of an understanding of product management? What I'd like to dig into is the alignment, and that's really related to product management and how you keep those teams aligned, with that growth and those new people who don't have the context or the experience. Let's start with product management, and then we'll see how it's evolved over the years.

[00:10:37] Nigel: Sure. When I joined, the product management function had fewer than 10 teams in total. I started off as a PM right from the bed [?], and now the function has at least 40 teams, depending on how you define a product management team, so 40 to 50 teams, I would say. We now have four major product groups: payments, the merchant experience, fintech, and the internal services teams. Each of these is headed by a product lead. And because even the existing product teams themselves have grown, there are now strong business cases for PMs and senior PMs [?] to also have associate PMs. So that is the way that the product organization, or product function, has grown over the years.

[00:11:32] Rory: Great. And was that just organic, "okay, we're starting a new product line, so we'll just put somebody in," and that structure just organically grew out? Or was there a big shuffle over time?

[00:11:44] Nigel: From the start, our founders took the position and the philosophy that we build what customers want. This comes very much from people like Paul Graham from YC, which of course is really good grounding. To be honest, it's not uncommon; Jeff Bezos at Amazon talks about being customer obsessed all the time. So the way our products have evolved, the way that we've added products and the way that we've formed teams under these products, has been very much driven by what both our existing merchants and new merchants want from us, the pains that they are experiencing with payments and other financial or related services, the pains that they raise to us, and the solutions that we think we can help them with.

[00:12:42] Nigel: It wasn't as if the founders and the head of product, my boss, had a grand plan in 2018 to say, okay, in three or four years' time we're going to have these different product groups, with product teams under each of them and potentially sub-teams under each of them as well. That was definitely not the case. There were a couple of reshuffles in the course of the four years that I've been at the company. Those reshuffles were mainly when we felt that, due to the increasing sizes of the teams, there were certain inefficiencies, not because of underperformance of people, but just because of the way the teams had grown without any intentional organization. So the structure that I described a couple of minutes ago comes from intentional thinking and structuring of the product teams by the head of product at Xendit.

Alignment challenges of hyper growth

[00:13:42] Rory: Great. That's a great example of how you can't really plan some of these things. You just have to wait until it happens, and then you go, okay, now we have a problem, and address it. Can you give me some examples of the challenges? I can foresee that you've got all of these new people coming in without context. What challenges did you face during that growth period, particularly around alignment and making sure that everybody was still focused on where Xendit needed to get to?

[00:14:11] Nigel: The first example is something where you've hit the nail on the head. Whenever you add new products and teams to an organization, the number of communication touch points increases exponentially. It's not like, okay, we bring in one new APM, we bring in one new senior PM, and therefore it's a linear expansion of the number of communication touch points. It actually increases drastically, because, firstly, within product there are so many people that they can interact with or not interact with, and then there are also other functions.

[00:14:46] Nigel: This is also exacerbated because it's not only product that grows. For Xendit, it is definitely not only product that has grown. But I would hazard that even for other companies, where perhaps they may be less operationally heavy, because payments and money is something that is rather operationally heavy, it doesn't make sense to me that the product function would grow without other functions also growing at least at the same rate, if not more. So sales, partnerships, operations, customer success, all of these functions have also grown. Oh, and of course, how can I forget engineering? These have also grown along with us, and therefore the exponential increase in communication touch points I mentioned earlier is now even more exponential, because of all these other people added in other functions as well.

[00:15:42] Nigel: Some challenges that we experienced: number one, within product itself, as the function grows large, the teams feel disconnected from their own team as well as other teams. This was made even worse because it all happened in the context of COVID, so we were all talking to each other on the screen, much like I'm doing with you now. Isolation aside, teams also find it hard to learn what other teams are doing and who they should reach out to for anything that they might need. This might result in someone going to the wrong person for a request, or not properly identifying dependencies in other teams that they will need in order to build or release their products.

[00:16:30] Nigel: We also faced two-way communication challenges with other functions. Sales is a great example. Product and sales generally can't live without one another. Sometimes they can: for B2Cs, for example, if you've got a good enough interface or a good enough marketing team, you don't need a salesperson to convince me to sign up for WhatsApp. But for B2B products, that's not the case.

[00:17:01] Nigel: Why I say two-way challenges is because we were not satisfying the needs of sales in the best way that we could have. There were so many new products, and there were also new salespeople brought in and new product people brought in: new people talking to new people, or not knowing which senior people they could go to to get the information they need, and vice versa. Product people were potentially expecting certain types of information from sales about customers that could be an input into their prioritization frameworks. And there was being able to hold each other accountable: sales saying, "Hey, we're bringing in this customer, they can promise this amount of volume and this business case," and product also being accountable for saying, "Hey, we're going to release this at a certain time with these features," and being able to meet those expectations. So these were some of the challenges that we experienced as a result of this hyper growth in the number of products and teams.

Slowing down and adding product leads

[00:18:04] Rory: My obvious next question is how you addressed those challenges and solved them. It is difficult with exponential growth, because you're dealing with two problems: one is the lack of knowledge, and two is how you manage or constrain that exponential growth.

[00:18:25] Nigel: For sure. There are two parts to your question, Rory. The first is how we address the challenges I mentioned. The second is how we perhaps contain that growth. I'll deal with the second first, because it's easier. The main approach that we're taking there is taking a step back and taking stock of the company as a whole, the processes and operating systems that we have within the company, and slowing down on our expansion in terms of team sizes.

[00:19:01] Nigel: I think one of the major topics being raised in the tech industry in the last maybe six months is all of the rather scary news about giant corporations like Netflix, Shopify and so on, just announcing, "Yep, we are reducing 10% of our headcount," snapping their fingers and just doing that in the course of a month. I understand the reasons for what they're doing, especially because the leaders of those companies have investors and boards, and if they're public they have shareholders to answer to, especially in these times. At Xendit we're not doing that, unless employees are underperforming, for which there's always a process and a justification for underperforming employees to be let go anyway, even outside of a potential recession or stressful economic circumstances.

[00:20:00] Nigel: What we're doing is saying: okay, we've capitalized on the pandemic to achieve a period of hyper growth, and one of the methods we used was bringing on people to perform tasks, to do things and to lead things, where we believed those people were necessary to support that hyper growth. So, as you've said, Rory, now it's about constraining and managing that: really looking at the potential job openings that we have and saying, "Hey, do we really need someone to take care of this, or can it be achieved by some other means?" And those other means could be something designed to help us scale even further in the long term, without needing to hire one, five or ten additional employees. That's the first thing we're doing.

[00:20:49] Nigel: The second is about the challenges I've mentioned, and it's not a solved problem. It's an ever-improving process that we are working on even today. But there are a couple of things that have helped. The first is not an intentional solution that was deployed to fix this alignment problem, but it has helped, and that is placing in product leads, senior product employees who oversee their own domain of expertise, their own product group or product domain.

[00:21:24] Nigel: Why this helps is that, compared to what happened before, where the head of product was pretty much looking over each and every one of these domains himself, with the help of senior PMs who ran the individual teams, now there are product leads. Their main role is, number one, of course to manage the PMs in those domains, but also to look at the performance of the domain as a whole: whether it's functioning properly, what can be improved, and what the pain points are within that group as well as with the other teams in the company, and how those can be improved. Each of those leads sorts that out within their own teams, and if there's anything that they need to bridge with other teams, they can be the ones helping to raise it. That's the first way in which it has helped with alignment.

A collaborative roadmap process

[00:22:18] Nigel: The second thing I can raise is that we are building processes that bring the product team together with other functions as well. By that I don't mean, "Oh, we're now going to put one salesperson into each product team." What I mean is that instead of product working as an isolated function, saying, "We are product, we are going to try to build products that our customers want, we're going to do this ourselves, and when we need other functions we'll pull them in and give them information, and vice versa, and then we will launch our products this way," we are now looking at processes, including a better roadmap process, that will involve these important stakeholders from the get-go.

[00:23:04] Nigel: Historically at Xendit, product has been quite autonomous, and the PMs are really given full autonomy. Full to the extent that, of course, senior leaders have the ability to veto, or to ask for certain things to be prioritized, like in any other organization. But other than that, one of the things that Moses always says is, "I hire people who are smarter than myself, so that they can take care of problems that I either don't want to solve or find difficult to solve." That's his belief towards PMs as well. So it is only in very rare exceptions that a PM who has decided to build three things in one quarter will be overruled by their superior, or even by our CEO.

[00:23:48] Nigel: But that also means that there is a little bit of friction, where other functions might need that team for a merchant who has a pain point that can be solved by some feature or some new product, and there's friction because the PMs are used to having this autonomy. So we're looking at changing that a bit. The analogy I like to use is that we've been operating as two magnets with opposite poles facing, so that when you push the two magnets together, they can come together for a time because you're forcing them to. In a certain project, okay, we've got this big customer, so product and sales and solutions come together and work on this thing. And then after that, the magnets automatically separate, because that's how the polarity works. What we would ideally like to do, and what we're working on, is for the teams to be like magnets that attract. Once they attract, they can move forward in the same direction without always wanting to come apart.

[00:24:57] Nigel: Why I raise the roadmap is that it's an example of a process that, instead of being purely product-led, is still primarily product-led, but instead of PMs coming up with the roadmap and then going to sales or other functions and saying, "Hey, what do you think of this roadmap?", it's going to be collaborative. And right now it is collaborative. There's a process whereby PMs speak to not only sales but other stakeholders across the organization, those that are the most important to their particular product team, and they understand all the feedback from merchants that these various other functions have spoken to over the previous period. The PMs can't clone themselves a hundred times. They do speak to lots of customers regularly, but they may be missing out on information that comes from sales, from customer success and so on. With the benefit of all of that information, they now craft the roadmap for their team in conjunction with these people, and it's a discussion process.

[00:26:06] Nigel: Of course there are certain things that will have to be deprioritized, but with this process at least everybody is in the loop together. It's not a case where we have made a decision to deprioritize something from sales without them being involved in the process and understanding in depth why we chose to do so. What we're focusing on now is how we make this process more scalable and more seamless.

[00:26:32] Rory: And what techniques are you using to try to gather that insight from sales or marketing or all these other places? Do you have a forum? Do you have a particular piece of software? What techniques are you using to gather that information?

[00:26:47] Nigel: As much as possible, we see documentation as a key tool in doing so. First, documentation about each individual product and product team, so that other functions can know and read about them. And then the tool that we're using to drive this collaboration, and I'm not referring to specific software like Asana, Jira or Coda or anything like that, really is coming up with a good operating system, which is a process. That process says: at this point in time, we're going to involve XYZ stakeholders, and they will be brought in to give their input and the information that's needed.

[00:27:30] Nigel: As much as possible, we do all of this asynchronously, without needing meetings and calls, because we found that quite a lot of people are allergic to them. I don't know whether it's because of the pandemic, but to be honest, even before the pandemic I knew that lots of people prefer to just work on things by reading comments and docs and things like that, async. They go through that process of giving each other the information they need, and then if a meeting is necessary, it will be called, but only if it is necessary to thrash out certain things that cannot be decided in a discussion on a doc. If they can reach resolution and finalize their roadmap, that's great. If there is a bottleneck and it requires some senior leaders or management to come in and make the decision, only at that point in time would they be involved. Otherwise, it's good to go.

[00:28:28] Rory: Excellent. We've unfortunately run out of time, and I didn't get to ask a question that I wanted to ask, which also came in from the audience: what is a chief of staff to a head of product? Unfortunately we don't have time, but I might throw that question into the Slack, if you'd be able to answer it there, because I think other people would be interested in that answer as well. But thank you, Nigel, for sharing. That was a really interesting story, and I hope people got a lot of value out of it.

[00:28:57] Nigel: Thanks, Rory. Thanks, everyone who is watching.