Everyone, for joining the the session. I'm really excited to share some insights around how we build a data driven organization.As an analytics leader, I I get asked to to give a lot of presentations around what it means to be data driven using a lot of buzzwords like AI, machine learning, and things like that. And it always really frustrates me, because I feel like we use these words without really actually understanding and internalizing what they really mean within an organization. So today's talk will be going into the specifics of what it actually takes to build an organization that's truly powered by insights, and I'll try to share some of my expertise. Just to give you guys a bit of context, I started my career about ten years ago in data analytics. Around the time that I I started my career, there wasn't really a data science path.

I studied math, economics, and psychology unsure of what I really wanted to do with a combination of those degrees. And I thought I would do something like behavioral economics and then fell into product, analytics, which I find, quite similar these days. I started as an individual contributor and then moved to a program manager role and then a people manager role at LinkedIn before I moved to Wise. I think the reason why a lot of what I shared today might be relevant to some of you is because around the time that I I joined Wise, I was actually tasked with the responsibility of trying to scale the team. When I joined, we had an analytics guild. So it was a function that existed. The the data capabilities existed, but they didn't really have an analytics function. They all the analysts reported into product managers.

And around the time that I was hired, the company realized it that was not really a sustainable model, and we actually needed to take a step back and really think through how we set up a thriving analytics and data organization within Wyze. So over the last four years, what I've done is to scale the team, from I think around the time I joined, it was 40 people. Now we've got 220. And underneath my org specifically, I had seven initially, and now we've got about 42 people. So I've done a lot of hiring and also thinking through how to structure the team to make sure that we are getting the right impact from from the work that the analysts are doing. So a lot of what I will share today actually comes from, comes from those insights. When I initially joined, I would as I mentioned, I was given the task of of scaling the team with an undefined budget.

That doesn't obviously mean that you can spend as much as you would like, but there was a commitment from the company to to invest into the analytics function. And if you ever find yourself in that position, it's really easy to just go ahead and hire a bunch of people. Especially in early on in your career, you might take pride in the fact that you've got a very large team. And I was really conscious of not doing that. I wanted to have a really clear mission statement for why every single person that I've hired into my org actually existed and and what problem they were solving. So I essentially came up with these, like, pillars and principles for myself that I really wanted to answer. The first one was, what is the vision and the mission for the team that I'm trying to build? Why do these, like, groups of people actually exist?

What are they here to accomplish? And what brings them together? What is the main problem that they're trying to solve? And I wanted to make sure that if anybody asked me that question within the organization or outside the organization that I could have a really clear answer. The second one is once you decide what is your vision and and mission for your team, you need to come up with an operational an, an operational model and a or an organization framework. So, essentially, all these people that you're hiring to solve a problem, actually, how do you wanna set them up within the organization so that they are best positioned to be able to achieve the mission that you've laid out for them? There are different approaches that the companies take. You could have a centralized model. You can have an embedded model. You can have a hybrid. At Wyze, we really believed in the value of contextualizing our work. So we went with the embedded model.

And what that meant is for every product manager and engineer that was working on a specific aspect of the product, there was an analytics person in the room that was working alongside them. And that makes them that makes the work that they produce so much more contextualized, and they can go really deep into the domain that they're executing in. The third bit is, again, once you have a clear vision and mission and a a healthy and and high functioning operating model. You need to really think through the types of people that you wanna bring into your organization that actually want to operate in this way and who have skin in the game and who show a lot of passion for the types of problems that you wanna solve. It's really easy to hire a lot of people who excel in, various degrees of technical skills. I on the side of thinking that if those skills to a certain extent are actually quite teachable.

What is really hard to to establish if it doesn't exist is a passion and curiosity for customer challenges. And especially when you are operating in a product organization, it's really important that the people that you're bringing into the organization actually really care about the challenges that they are helping solve for the customers and also for the business. And then the last bit is, again, this links to the people but the values. And I don't mean just the cultural values of the company, but the values that these people bring to the table, which you can actually assess really easily, through a very detailed interview process. You can understand things around their curiosity, their learning mindset, their grit, and and a lot of other attributes that actually indicate are are much better indicators of somebody's success as an analyst within the the setup that we've created. So across these four, pillars that I've identified as things that I I really wanted to to write down and clarify, The biggest one that was or let's say the hardest one to try to tackle was really around the vision.

So, ultimately, there were two questions that I really needed to answer for myself. The first one was, what is the biggest problem that we're trying to solve as a business? And then what are the decisions that we should be able to make that we cannot make today? And I let the answer to those questions define the priorities in terms of where I staffed the teams, and and the seniority and the different skill set those that those people brought onto the table. And, ultimately, what I realized as I was trying to scale the org at Wise was that when we talk about the idea of being a data driven organization, we really don't actually talk about something or a framework that is really external, something that you can take from outside and implement into your business.

What we really actually talk about is this cultural shift and understanding within the organization that prioritizes insights in problem solving and in decision making. And, again, that really actually comes down to not really having an analytics strategy, but more so a problem solving prioritization strategy across the organization that then becomes the the starting point for the analytics work to take place. Throughout my time at Wise and also previously, this dynamic of problems and solutions that seem so common sense and simple when you talk about it, actually has become really front and center for me. And I realized that as logical as we think we are, even in the most brilliant organizations, we kind of miss the point of this dynamic. And what I mean by that is when we take a step back and and look at the ongoing work that's happening across our organizations, sometimes we can't clearly pinpoint the problem that we're trying to solve or justify why the solutions that we've created are the right solutions for the problems that we've identified.

And I'm a huge believer of the fact that analytics, regardless of the technical skills that they that they bring on to the table and the different hats that they wear within the organization. Somebody with an analytics background, somebody who is your data person within the organization can play an incredibly critical role in in assessing the dynamics between problems and solutions. And so what that really means is, you know, having a function that helps you get really clear on what problem you're solving, so why that problem is happening, who is affected by that problem, help you develop the right solutions by understanding what has worked previously or what works in the industry, or trying to get that input and insight from the customers in a quantitative and qualitative way, help you build and create the solutions, and also help you look back and measure the impact that you have delivered through the future or through the solution that you've created.

And this last bit is really important, and I'll come back to this throughout the presentation. But this idea that, again, we are perfectly logical and we can find the the perfect solutions to all the problem all the most important problems out there is is actually, pretty arrogant thing to think about. It what really matters in organizations that I think really thrive is this idea of iterative learning, being able to look at the things that you've launched and understand where your hypotheses have fallen short, where you were right, where you were wrong, and being able to learn from the the gaps in your judgment and make better decisions in the long run.

And, again, when we talk about data driven organizations, to me, it's an organization that has really understood that dynamic and really operationalizes that dynamic. I'll give you guys a couple of examples of how flawed some of our thinking can be, and how easy it is to to fall into certain traps. So for those of you who have used Wise, Wise obviously started as an international remittance company, but for, an extent for the last, five to seven years, we have expanded our offerings to include an international bank account. That means that you can actually do a variety of things with Wise beyond just sending money overseas, and we wanna incentivize that behavior. We wanna build products and features that make it easier for customers to to use these additional features that we've created and and be able to navigate them really easily. And couple of years ago, we realized that our adoption of our cards, our Wise cards were really low.

And the the solution that the the product team came up with was or one of the teams came up with was, okay. We will look at all of our customers that are using us frequently to send money, and we will send them a bunch of free cards. And the idea is that if we send them a bunch of free cards, then they will actually end up using this feature, which you can see already, hopefully, the the the flaw in the the deduction that they were doing. It was really easy to spot the problem and then jump to a solution without actually having a lot of in-depth understanding of what was causing the problem. And this is something that happens in organizations so many times. I'd like to think that we have a very smart product team at Wyze, but it's really easy to to fall into these traps.

So, obviously, what has happened is just because we sent the cards to our active customers, they didn't end up adopting these because they didn't have a use case for it. And we weren't clear on the problem that we were solving for them because we hadn't really understood why this problem exists in the first place. So this is a very, very simple example of how it's so easy for us to kind of lose the right dynamic between the problems and the solute problems that we're trying to solve and the solutions that we're trying to create, and how a very simple insight, around your customer needs, your customer segments, and even just blockers to adoption can play a huge role in you coming up with the right solutions that will get you the outcomes that you desire.

So when this happens at Wise, we now have a muscle to be able to go back and and really iterate on where we have gone wrong. Right? So when we launch a feature or when we, launch a new product and it doesn't perform the way that we would like it to perform, we can understand whether the issue is in the problem that we've identified or in the solution that we've created. So we can ask ourselves, did we detect the wrong issue? Did we misjudge its prevalence or its importance? Or we identified the right problem to solve, but the solution that we've created was not the right solution because we unders misunderstood what was causing the problem, we solved it poorly, or we underestimated its complexity. So there could be a lot of different reasons why something that you're trying to achieve as a business can fall flat. And, again, this is a really good example of where data people that you have in your organization can play an incredibly pivotal role in helping helping you get to better outcomes.

So all of this hopefully sounds great. We all aspire to have an organization that has this muscle and using data and insight in a very intentional and strategic way. But for this to happen, there are fundamental things that need to take place so that we can actually get to insights and this level of decision making as easily as possible. So the first one is and I'm I'm not going to go into the the to go into the details of these things, but I have to call out the importance of having a really clear data infrastructure. And that's things around data availability, reliability, but also consistency in the metrics and the definitions that we talk about. This was something, despite having forty, fifty people at Wise years ago, something that they did not they did not really have. And so coming into the organization, we would have these conversations around how we improve conversion rates, how we improve revenue, how we improve adoption of x y z.

And we didn't really have consistent and clear definitions on what any of these terms really meant. So that meant that across the organization, we couldn't really take holistic decisions or look at things holistically because we didn't have the right data and, metrics, infrastructure, and definitions. And this is if you are in a place where this foundational layer just does not exist, it is the number one thing to prioritize. And I know it takes a lot of time and effort, and it's not as exciting as actually getting to the insights. But getting this right as early on as possible will really help unblock some of the things that, I've talked about. The the second one is around data literacy. I know it's another buzzword that we talk about, but it's really this idea that the insight and the data that you're using in your problem solving and decision making should not be isolated to the analytics teams that you have in your company because the the strategic and analytical thinking that you want cannot scale just with the analytics org that you have.

You want product managers, engineers, researchers, designers, people in your finance teams, financial crime teams that can actually look at a dashboard, look at a dataset even if they obviously, they're not required to be able to pull their data. That's a plus if they can. But be able to look at a dashboard or look at a report and drive some basic insights without relying on the analytics team. And that's incredibly important because that helps you increase the leverage that you get from your team, but also frees up a lot of time from your analytics team to be able to do the type of work that we've talked about. And so what that really means is, there needs to be some principles around how the analysts are expected to operate within the organization, which are quite fundamental to like, the the principles that I share here are quite fundamental to the embedded model specifically, but this can be applied even in a centralized context by creating some domain specializations.

The idea that you are putting dedicated people behind a collection of problems or a theme of problems. And that's really, really important because then they can assess the the infrastructural issues, data consistency issues. They can assess the data literacy of the people in the problem space that they're operating in and hopefully play a key role in solving these things and also carve outside some time being to be able to do do the more advanced insights generations that, that's really critical to that problem solution dynamic that I've talked through.

And, ultimately, what that really means is for us at least, at least within a product organization, we really try to enable analysts to work with their teams across the the entire product life cycle. Let's say, not just the product life cycle, across the entire decision making cycle, from discovery of the problems to defining the problem, validating, implementing, launching, and measuring, they they wear a different hat across all of these stages, but they're part of all of these stages, which makes sure that they understand the area that they're operating in as deeply as possible, and they can have independent opinions on what to prioritize and how to prioritize.

Ultimately, for us, again, what that means is in order to have an organization that can do all of these things, you ultimately want a generalist profile. And, again, depending on the the area of the business that you're trying to hire your analysts, they might vary in how much they are indexing on some of these skills versus others. But the idea is that you want a really healthy balance of technical skills with some of the business softer skills around communication, analytical thinking, collaboration, being able to influence decisions, being able to take an insight that somebody has produced from their piece of analysis and go to their stakeholders and actually help them make better decisions and being able to have, assertiveness to a certain extent verbally or written to be able to, push the decisions in the right direction.

So these are all things that we try to gleam in our interview process, but also things that we try to coach our analysts on once they come in because these are really the things that set them apart in in the, organization. And, ultimately, because they have the the skills that both the technical skills and the softer skills, as I mentioned, they can wear a lot of different hats, from more technical things like data ownership to helping build KPI trees, understanding where the the North Star metrics should be and, the the different levels.

Being able to do impact sizing, which is something that I am a huge believer of. So, essentially, looking at the hypothesis that we create and being able to estimate, the the potential value that we can expect from, from the delivery of, of x y z feature or x y z product and then helping with testing and iteration. I I wanna acknowledge that all these principles that I'm talking about are much easier to do when you are starting from scratch or when you have an organization that's not mature in some of their established ways, and these are much harder to to try to change if you are in an organization that's used to working in a very, very different way.

So, hopefully, some of the things that I'm sharing are useful guide points in terms of the types of things that you might want to aspire to have in your organization, but I'm also conscious that there's a huge amount of change management, and and breaking of data silos or even just silos across the different parts of the business and the product teams if you aren't already set up this way.

And that's, that's really worth acknowledging. Just for the the sake of time, I'll I'll try to move a bit quicker. So why why do we care about all of these things? Again, the the topic of the conversation is how do you build an effective data driven organization? Regardless of whether you are a product led company or not, you wanna be data driven to solve the right problems as as I've talked about in the last half an hour. But why do we care about solving the right problems? Because ultimately, all of our businesses exist as a service to a consumer or a business, and we wanna make sure that we deliver value to to the people that we're serving and make a difference through the work that our business is providing. And when you set up your organization in the way that I've just, tried to model out, you really build a strong muscle that's not really making decisions in an isolated group of senior leadership, but you've got people scattered through your organization that's really owning that analytical and critical thinking muscle across every aspect of your business.

They are challenging decisions. They're bringing the right data and insights to the table, and they're constantly asking, hopefully, the right questions and, and making sure that they are course helping course correct the the decisions that are happening across the business. And the amount of leverage that you can get from an organization that can not only pull a piece of analysis, but can use that analysis to create well thought out plans and suggestions for your product or business is invaluable. And that's to me the the biggest value that you can get from a data driven organization. I had some examples here that I'll, I'll skip over, but I'll I'll end here by, essentially trying to wrap up why I think all of these things are really important. Because if you get all of these pieces correct, then you can get to a place where on a very regular basis, you can look at the decisions that your company has made, whether they are product decisions or service decisions, and get to a place where you can learn where some of those decisions have not landed or where they could have been improved, or where, where you could have made different trade offs.

And being able to build a muscle that enables you to do that is a huge competitive advantage in any industry that you're a part of. So hopefully, this was a a useful summary of some of the things that we think about when when we really talk about data driven organizations And, also, some of the critical pieces to to really nail, so from my point of view, that's around the contextual that's around contextualizing the work that your analytics teams are doing and making sure that they understand what decisions that they are contributing to so that we can really ensure that, they take ownership of the of the problems that they're solving, and you aren't creating single point failures, by putting all the decisions on certain business leaders or product leaders.

You are actually building an organization that has that critical thinking. I'll stop sharing my