Maintaining Team & Product Alignment Through Hyper Growth


Maintaining Team & Product Alignment Through Hyper Growth

Product Direction

In this candid conversation, Nigel will talk through the journey of Xendit as it achieved the Unicorn status within the region. By walking you through the evolution of Xendit's product roadmap, he will share how to ensure team alignment through hyper growth and touch on:

  • Establishing tangible product roadmaps: from setting up goals, defining metrics and creating a product focused culture from the start;
  • Ensuring that the roadmap scales; and
  • How to iteratively adapt and define the roadmap when you face moments of uncertainty

Learn how the team at Xendit created a company culture that ensures a steady forward momentum as both the team and the product scale within the region.

Nigel Yeo

Nigel Yeo, Global Product Manager,Xendit

So I'm Nigel. Hi. I'm currently the chief of staff to the head of product at Zendit. I've been in the company for about four years. 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. So Zendit is a payments provider. There are many terms that can be used for this. So that can be payment services provider. 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 Zendit and how it started was with our CEO, Moses. Moses is a Malaysian-Chinese ethnicity, but he grew up in Australia. I think he's a citizen there. I'm not wrong. And then he did his master's in Berkeley. And his family has always been involved in doing business. So he has been bitten with 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.

So when he went to Berkeley to do his master's, of course, that's where Silicon Valley is. 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. They went through the Y Combinator program, got seed funding from YC. There and then they decided that they wanted to launch whatever product, whatever business they built in Indonesia. Because of the massive opportunity that is in that country. And so they did that in 2015. They released their first product in early 2016. And since then, we have done multiple things.

So we've grown our total payments volume from just a couple of thousands, 100 of thousands, to 2022. Even in the midst of the pandemic, I think it was about hundreds of billions of USD per year. And we now have about, I think, close to 1,000 employees across six to seven territories.

So we're currently mainly operating in Indonesia and 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 we are looking at, on top of payments, building digital infrastructure for Southeast Asia. So just to close this background of the interesting bit about the company is that when the founders first started, they actually launched something like a Venmo for Indonesia. So like a peer-to-peer B2C payment app. And 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. And so they thought to themselves, hey, instead of working with what we have, why not let's 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. So that's how we've come to where we are today.

So 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. Sorry. Yeah, no, go ahead, Roy. So that was great. Just kind of the background to the company. So kind of launched 2015. So in seven years, as you said, you're up to a couple of $100 billion in transacted volume. Can you give an indication of the hypergrowth from a person perspective? So it started with, I'm assuming, the three co-founders. And then over time, it just grew from there. So can you give me maybe a rough timeline when you joined? What was the kind of size? And then how has it grown from there?

Gotcha. I can even start from before I joined, because I've got enough stories about these. So of course, the two co-founders, one of them was not able to come to Indonesia. 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 part of the co-founders of Zendit. And they started off with any engineers that they could find. So that would include even 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. And they were happy to come down and interview with these four, three co-founders in a house that looked nothing like an office and realized that, oh, this is an interesting opportunity. And so they would join even at that stage.

So before I came in, and this is about 2016 to 2017, all the earliest engineers as well as the co-founders were pretty much working maybe about 10 people in the living room of a house that I think was rented by the co-founders. And so when I joined, that was about 50 people or so. It was simply the same formula and 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 have a living room as well as a basement for the majority of the employees to work.

There are some fun stories because what Moses likes to say is that they've seen all the elements. They've experienced earthquakes before in Jakarta. They've had an incident where the entire basement, which is where all the engineers were housed and working, that basement was flooded. And so they had to move all of the computers and the rest of the important things outside of their basement. And I was lucky enough to have joined when they experienced the third element, which is fire, where Indonesia has this holiday period called Lebaran. It's to celebrate. It's a religious holiday. And at its extent, it can be even up to 10 working days of public holidays. And as a result of that, the caretaker that was supposed to be clearing out the dried leaves and things like that was, of course, on holiday, he was celebrating with his family. And the dried leaves that were being stockpiled in this shed next to the house somehow because of the heat and the dryness, maybe there was some spark somewhere, perhaps someone threw a single button, we're not sure, but that caught fire. And so when in Zendesk, we call incidents.

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. So when some of us were working during the holidays because the foreigners, we 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 we didn't see anything. And then 20 minutes later, the same person said, I still smell the smoke. And this time I said, yeah, I smell it too. And we went out and we saw that and we raised it in slack. And we said, hey, guys, there's a fire. And then people said, oh, what's happening to our services? And we said, no, like a real fire. We've got to sort this out. We've got to get the fire department down to come and down. And thankfully, there were people around the area who were experienced with these sorts of things and they knew what to do. And so no property damage, no human injuries or lives lost. Yeah, so that was about 2018 when I joined. Before the pandemic, and that is until about end of 2019, we did grow. And we grew, I think, to about 200 to 300 people.

And that was just before we had launched in the Philippines. It was when we were preparing to do so. But as with many other companies in the course of the pandemic, especially companies that are suited to capitalizing on the fact that everyone is going online, everyone is not being able to do physical purchases or go shopping or do all these sorts of things, we experienced a period of hypergrowth as well because so many merchants were trying to get online. And the existing merchants themselves, they were also seeing significant growth in their own businesses, especially those that, as I've said, were those that could capitalize on the pandemic. So in that two years where I was not able to fly around and meet people, go to Jakarta and meet the majority of my colleagues there, as well as to visit the Philippines where it was a new market that we were expanding into, we grew even further. And that was where we added, I think, the bulk of our hit count today to about close to 1,000 people.

Excellent. So if I summarize, you joined in 2017? 2018. 2018 with 50 people. And then by 2019, at the start of the pandemic, you were up to about 200? Yeah. So like 4x-ing the size of the organization in a year or two years. So yeah, that's kind of a then again from 2020 to 2022, another 5x. So I think that qualifies as hypergrowth.

I think so, yeah. Great, so can you give me a bit of an understanding of product management? Because what I'd like to dig into is how we're talking about the alignment. So that's really related to product management and how you keep those teams in line. So with that growth and those new people who don't have the context, they don't have the experience. So let's start with product management, and then we'll see how it's evolved over the years.

Sure. So the product management function when I joined, I think there was about less than 10 teams total. I started off as a PM right from the bat. And now the function has at least 40 teams. Depending on how you define a product management team. Yeah, so 40 to 50 teams I would say. So we now have four major product groups. That's the payments, the merchant experience, the fintech, and the internal services teams. Each of these teams are headed by a product lead. And because the products, even the existing product teams themselves have grown, therefore PMs now, there are strong business cases for PMs, product managers to also have associate PMs.

Yeah, so that is the way that the product organization or product function has grown over the years.

Great, and was that just an organic, OK, we're starting a new product line, so we'll just put in somebody and it just kind of, as that structure just organically grew out, or was there a big shuffle over time?

No, yeah. So our company, our founders, and our founders have from the start, they take the position and the philosophy that we build what customers want. This comes very much from people like Al Graham, from YC, which is of course where they got funding. And to be honest, it's not uncommon. Jeff Bezos with Amazon talks about being customer obsessed all the time.

So how 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, as well as new merchants want from us, and the pains that they are experiencing with payments and other financial services or related services, the pains that they raise to us, and the solutions that we think we can help them with. So it wasn't like the founders and the head of product. My boss had a grand plan in 2018 to say, OK, by three years time, by four years time, we see that 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 perhaps due to the increasing sizes of the teams, there were certain inefficiencies, not because of underperformance of people, but just because of the way that the teams had grown without any intentional organization.

So the structure that is today, the one I described a couple of minutes ago, comes from an intentional thinking and structuring of the product teams by the head of product at Zendid.

Great. So yeah, it's a great example of you can't really plan some of these things. You just have to wait until it happens, and then you go, OK, now we have a problem and address it. So 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. So what challenges did you face during that growth period, particularly around alignment and making sure that everybody was still focused in where Zendid needed to get to?

Yeah, the first example is something that you've hit the nail on the head, right Rory? Whenever you add new products and teams to an organization, the number of communication touchpoints increases exponentially. It's not like, OK, we bring in one new APM, we bring in one new senior PM. Therefore, it's a linear expansion of the number of communication touchpoints. That actually increases drastically, right? Because they are just not, firstly within product, there are so many people that they can interact with or not interact with, and then also with other functions, right? This is also exacerbated because it's not only product that grows. I would say for Zendid, definitely it is not only product that grows or that has grown. But I would hazard a guess that even for other companies where perhaps they may be less operationally heavy because payments and money is something that is rather operationally heavy. But even for other teams, 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, right? These have also grown along with us. And therefore, the exponential increase in communication touch points that I mentioned earlier, now it's even more exponential because there are all of these other people added in these other functions as well. So some challenges that we experienced, number one, within product itself, as the function grows large, the teams feel disconnected with their own team as well as other teams. And this is even worse because this all happened in the context of COVID, right? And so we were all talking to each other on the screen, much like how I'm doing with you now, Rory.

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 they're not properly identifying dependencies in other teams that they will need in order to help them to release their products or to build their products. We also face two-way challenges with other functions from a communications perspective. So sales is a great example. Product and sales generally can't live without one another. Sometimes they can. I think like B2C apps, 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, for example.

But for B2B products, that's not the case. So why I say two-way challenges is because we were not satisfying the needs of sales in the best way that we could have, because there were so many new products. There were also new salespeople brought in, also new product people brought in, new people talking to new people or not knowing which senior people they could go through to get the information that they need. And vice versa as well, product people potentially expecting certain types of information that you can get from sales about customers so that it can help them be an input into their prioritization frameworks. Being able to hold each other accountable. Sales has said, hey, we were bringing in this customer and they can promise this amount of volumes and 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.

Yeah, so these were some of the challenges that we experienced as a result of this hypergrowth in the number of products and a number of teams as well.

So I guess my obvious next question is how did you address those challenges? How did you solve that? Because that is difficult with the exponential growth. It's always difficult because you have to kind of, you're dealing with two problems. One, it's the lack of knowledge. But also two, it's like how you manage or constrain that exponential growth.

Yeah, for sure. So there are two parts to your question, Wary. The first is how do we address the challenges I mentioned? And the second is how do we perhaps contain that growth. I'll deal with the second first because it's easier. One, the main approach that we're taking towards that is taking a step back and taking stock of the company as a whole, the processes, the operating systems that we have within the company, and slowing down on our expansions in terms of the team sizes. I think one of the major topics that is being raised in the tech space, the tech industry in the last maybe six months are all of the rather scary news about giant corporations like Netflix, Shopify, so on and so forth. Just announcing, yep, we are reducing 10% of our headcount, snapping their fingers and just doing that in the course of a month. And I understand the reasons for what they're doing, especially because the leaders of those companies have investors, have boards, and if they're public, they have shareholders to account to in these times as well.

At Zendid, 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. But what we're doing is we're saying, OK, we've capitalized on the pandemic to achieve a period of hypergrowth, and we've done that by one of the methods is by bringing on people to perform tasks, to do things, to lead things where we believe that those people are necessary in order to support that hypergroup.

So as you've said, Rory, now it's about constraining and managing that, relooking at the potential job openings that we have and saying, hey, do we really need someone to take care of this, or can this be achieved by some other means? And that means in question, can it be something that is designed to help us to scale even further in the long term without needing to hire one, two, five, or 10 additional employees? So that's the first thing we're doing.

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 the hiring or the placing of product leads, senior product employees, that oversee their own domain of expertise, their own product group or product domain.

Why this helps is because as compared to what happened before that, where the head of product was pretty much looking over each and every one of these domains themselves with the help of senior PMs that run the individual teams. Now there are product leads that their main role is to number one, of course, manage the PMs in those domains, but also to take care and look at the domain as a whole performance, whether it's functioning properly, what can be improved, what are the pain points within that group as well as with the other teams in the company, and how those can be improved. And then each of those leads sorting that out within their own teams. And if there's anything that they need to bridge with other teams, they can be the ones who are helping to raise that. So that's the first way in which that has helped with alignment.

The second way that I can raise is we are building processes that mesh the product team together with other functions as well. By that, I don't mean, oh, we're not going to put one salesperson into each product team. What I mean is instead of product working as just a isolated function, OK, we are product. We are going to work on things. We're going to try to build products that our customers want and we're going to do this ourselves. And when we need other functions, we'll put them in and we'll give them information, vice versa, and then we will launch our products in this way. But we are now looking at processes, including a better roadmap that will involve these important stakeholders from the get go. So instead of, historically, Zendit product has been quite autonomous. And the PMs are really given full autonomy, well, full to the extent of, of course, certain senior leaders have the ability to veto or to ask for certain things to be prioritized like any other organization.

Rather than that, one of the things that Moses always says is that I hire people who are smarter than myself so that they can take care of problems that I either don't want to or find difficult to solve. And that's his belief towards PMs as well. So it is only in the very rare exception where a PM who has decided to build three things in one quarter will be overruled by their superior or even by our CEO. But that also means that there is a little bit of friction where other functions who might need that team for their merchant who has a pain point that can be solved by some feature or some new product. There is friction because the PMs are used to having this autonomy, right? So we're looking at changing that a bit where the analogy I like to use is we've been operating as sort of two magnets where the poles are the opposite poles, right? Where when you push two of these magnets together, they can come together for a time because you're forcing them to, right? So in a certain project, okay, we've got this big customer product and sales and solutions, we'll bring them together and we'll work on this thing. And then after that, the magnets automatically separate because of that's how the polarity works, right? What we ideally want to do, what we'd like to do and what we're working on is for the teams to be like magnets that can attract, right? And once they attract and they can move forward in the same direction without always wanting to come apart.

So why I raised the roadmap is because this is an example of a process where instead of it being a purely product led approach, it's still primarily product led, but instead of it's being, okay, PMs will come up the roadmap and then they will go to sales or other functions and say, hey, what do you think of this roadmap, right? It's going to be collaborative. And right now it is collaborative, right? There's a process whereby PMs will speak to not only sales but other stakeholders across the organization, those that are the most important to their particular product team and they will understand what is all the feedback from merchants that these various other functions have spoken to over the previous period, because the PMs themselves are not, they can't clone themselves a hundred times, right? So they do speak to lots of customers regularly, but they may be missing out on information that comes from sales, come from customer success, so on and so forth. And with the benefit of all of the information, they will now craft the roadmap, right? For their team in conjunction with these people. And it's a discussion process. And 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 that process and understanding why we chose to do so. Yeah. So what we're focusing on now is how do we make this process something that is more scalable and more seamless?

And what techniques are you using to try gather that insight from either sales or marketing or all these other places? What do you have a forum? Do you have a particular software? What techniques are you using to try gather that information?

Yeah. So as much as possible, we see documentation as a key tool in doing so, right? Documentation first about each individual product teams, so that other functions can know and read about them. And then the tool that we're using to drive this collaboration is, I'm not referring to like a specific software, like Asana, Jira, Coda or anything like that. It really is coming up with a good operating system, which is a process, right? And that process will be, okay, at this point in time, we're going to involve XYZX stakeholders, right? And they will be brought in to give their input, to give the information that they need. And 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 or, but you know, to be honest, even before the pandemic, I knew that lots of people prefer to just work on things on reading comments and docs and things like that, async. And they go through that process of giving each other the information that you need. And then if a meeting is necessary, it will be called, right? But only if it is necessary in order to fresh out certain things that cannot be decided over discussion on a doc. And if they can reach resolution and finalize their roadmap, that's great. If there is a bottleneck and it requires some senior leader to some management to come in and make that decision only at that point in time would be involved in otherwise it's good to go.

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

Thanks, Rory. Thanks everyone who is watching and on the call.