00:06:58 · Lenny Rachitsky, Dmitry Zlokazov
[00:06:58] S1: Wow. Okay. Cool. So let's get into the... What you've learned about building an amazing product team and also hiring an amazing product team. So first of all, you call your product managers product owners. And when we were chatting through initially, I was like, oh, I see. It's just like a big scrum business, and they just have all these product owners who... You know, many times on this podcast, people have talked about us not actually a product manager, but that's not at all how you work. So in this context, product owner is an actual owner. Talk about just the kind of the story behind why you call the... Your product managers product owners. [00:07:28] S0: Yeah. It's not a scrum term for us. It's just our take on emphasizing how ownership is important, really. So product owners are central to company and its growth. They are end to end responsible for the product, for this part of the business, and for their customers to be happy. And for that, they do really everything. They run the teams. They define which roadmap we need to build to improve certain business metrics. And they also contribute to high level company strategy. But then most importantly, they execute on it relentlessly. And they are ultimate responsible for for the product to be shipped and achieve results. [00:08:23] S1: There's always this term of mini CO. PM is a mini CO, and it feels like in your context, that's actually what you try to do with your product team is they're essentially mini COs. They have a lot of power. Like, think engineers, designers report to them. Is that right?
00:08:23 · Lenny Rachitsky, Dmitry Zlokazov
[00:08:23] S1: There's always this term of mini CO. PM is a mini CO, and it feels like in your context, that's actually what you try to do with your product team is they're essentially mini COs. They have a lot of power. Like, think engineers, designers report to them. Is that right? [00:08:35] S0: Yeah. Correct. Well, I I prefer to say local CO. CO. Okay. [00:08:39] S1: Let's talk about that. Yeah. Yeah. [00:08:41] S0: Yeah. But that's true. So the way we operate, we have these fully cross functional teams, meaning they are staffed with all necessary functions, engineers, data analysts, designers, operation managers, and so on. And we also operate in metrics. So everyone has a line manager and a functional manager. So product owner is always the line manager for everyone on the team, meaning product owner defines what they need to do. But then functional managers, they define how these things need to be built and essentially with the right level of quality and so on. [00:09:28] S1: I love this because it's so fun just to learn about such different ways of operating. Another fact that I saw is that there's two types of product owners. There's kind of like a UX product owner, then there's a different... Like, a technical product owner.
00:09:40 · Dmitry Zlokazov
[00:09:40] S0: We actually have three. Three. And the third type becomes increasingly more important. So the first type is UX product owners. Then there are technical product owners, and then there are data science product owners. So UX product owners are the ones who who work on consumer facing part of the product. Usually, they they have a great taste for things, and they understand what constitutes UX that will work and which things will not work. So they also have this expertise in the industry. Then tech product owners, they are the ones who delve deepest into details. Usually, those are former engineers who grew into making decisions and driving business. And the data science product owners are usually former data scientists who decided to grow into management positions. But they're still very hands on. And you know what? There are a lot... There are way more things that are common to each of these three specializations. So what we see sometimes is people just shifting them. Because I would say that, you know, what defines the specialization is probably five, 10, 15%, while 85 to 90% is common to each one of them. And those things are... So first of all, being a great problem solver and have a great linear thinking, but also, you know, have a creative approach towards nonlinear problems. Then building this context for customer and building empathy towards customer and translating it into the team. Then going down to details very, very deep. Because in our domain, there are no obvious things. And you need to get to the root cause of the problem really, really deep to to to understand, okay, what will work and what will not work. And that means that you also need to be quite technical. Even if you're UXPOR, you still need to often go as deep as sitting, you know, with engineers and reading code. And then I would also emphasize importance of business acumen, because we tend to measure and quantify product performance a lot. And you need to understand, okay, what things will we build that will drive eventually that business metric and that target?
00:12:41 · Lenny Rachitsky
[00:12:41] S1: So I love this idea of the product owners having to go really deep. I think a lot of people hearing this, they think they can go deep, go deep, really understand the the details of what they're working on. I'm curious if there's an example that's illustrative of just what you actually mean here. For example,
00:12:57 · Dmitry Zlokazov
[00:12:57] S0: to provide the best possible product in every country of presence, we need to have necessary licenses. In Europe, it means that we need to launch local branches of our European bank. For example, a branch for France, a branch for Germany, or a branch for Italy. To launch a branch, you need to fully comply with all necessary regulation. You need to you need to report necessary data on customers to various regulators and authorities. You need to register with local payment systems. And each of these things, they have a lot of projects nested within. We have a very lean team, just a few people, who need to scope everything and do it at the scale of, like, of 50 countries. Right? So the way we do it is we go very deep on example of each of these projects. For example, we launched a branch in Ireland. We launched a branch in Netherlands. Then we reverse engineered what was the the best process to do it. And then we went back up on top level, and we said, okay. But what's the what's the ideal framework of doing it at scale? And then we formalized it into a process, really like an algorithmic process with steps and quality gates and SMEs and, like, which... What people do we need to hire and how how soon do we need to start doing that before we want to launch a new country. And then so it's not only going deep, but also being flexible, you know? And, like, doing this switch between zooming in very deep and then raising on the on the level of of helicopter view, and then understanding, okay. So this seems very, very complex in details. But then when you zoom out, like, how can we simplify it and build a robust process around it, which is scalable? And that's something that we have to do a lot.
00:15:05 · Lenny Rachitsky
[00:15:05] S1: As you're talking and we go through this chat, I'm keeping kind of track of what I think is most contributing to your alumni product owners, product managers becoming so successful. So a couple things so far that I think are probably contributing to this is one is just having a lot of ownership over what they're building, which leads to building skills to start companies and become leaders at other companies. So these product owners that you have are just, like, own a lot and are essentially GMs of the... Of whatever product they're working on. And then there's this depth and complexity where you have to really get good at understanding a problem really deeply. I imagine many of these people go on to work on something like that later somewhere else because they've spent all this time, or they just get really good at dealing with complex, many layered problems. So Yeah. Is there anything else just kinda along those lines as I say that that you think is important?