Hello, everyone. Uh Thank you so much for joining this session. So you're here uh to talk about uh scaling product organization. So I'm here to give you a few tips from uh personal experience at the different companies I had the opportunity to work with.And as I said, um feel free to uh use the chat if you have any questions or comments. Um First, uh before we get started, I wanted to give you a brief intro. I'm currently chief product officer at a company called Miracle. Uh Miracle is uh a, a leading company in uh marketplace Solutions. It's a s company and I spent the past 15 years in product management. Um throughout my career, I had the opportunity to work for a, a very diverse set of companies. Uh But most importantly, I was very lucky to work for um fast paced uh fast growing companies where the product organizations has to be thought in a way that it can really scale and can really go with uh with the growth of the company. So this is what I'm I want to, to share with you today. Um So just a few items. So that you can uh follow along here. It's really about scaling your product organization. So hopefully, we will try start to define a bit what that mean uh where to start if you are looking into uh doing.

So, uh I want to give you some tips around how we can embark your team into the, into the this uh adventure and then maybe uh a few more thought at the end. So first, when we talk about uh scaling a product organizations, really, what does it mean? Uh if you think about scaling on organizations, how would you define that to your team, to your organization? So I try to put together one slide that maybe, you know, highlight some of the few keywords. But really what it means when we talk about scaling an organization is really how you will be able to equip your team with the structure, but also the tools so that your team can grow and adapt to the rapid growth of your own company. And this is very important because you want your team to be ready to be going through obviously some of the challenging times, but also the exciting times that goes with growth. And so what are the objectives for us when you think about changing your organization's orga or restructuring your product organizations is really about three main objectives. One, what is very important as a product organization is to remain agile when it's a team of, you know, 1 to 3 product managers. It's easy to remain agile. You can talk to the person next to you or resume very quickly.

But when your organization grows and becomes 10 people, 40 people, maybe 100 people. How do you keep yourself agile? How do you keep yourself um innovative? And that's very important to set yourself as an objective, that no matter the size of your organization, you want to keep agility at the heart of everything you do. Obviously, as you grow, you will also want to find efficiency in the way you drive your organization. And last but not least, w what is very important because if you go back to the definition of what a product manager could be, product manager is really this mini co of their product. So you want them to feel empowered to drive the vision, to drive the strategy and to make the decision. So, empowerment should be also an objective as you think about your new organization and as you design it. So maybe the, the reason why you're all here today is really where to start, right? So, OK, uh thanks Isabel for all this. I knew this, but now I really want to know where to start and I'm sure that if you think about this, you say, oh, well, there are so many models out there on, you know, in books and in blogs and, and whichever resources you can find out there on product management.

But where do you start? And what do you, what do you use? Right. Uh, should I, uh, organize my team, like Amazon or Spotify or something else? Well, my answer to you is maybe stop if you're here is because somehow you're working in a product team and if you are working in a product team, you know, that we never jump to a conclusion, we never jump to the solution right away. What you want to do is really treat your organization as a product. So what does it mean to treat your organization as a product? If you were to launch a new product from the start? Hopefully, you will not start right away to uh jump at the conclusion, you will start to go through a certain process that we all know of and that um really relies most of the time on a drive framework. So what you wanna make sure is uh thinking about how you design your organization. You need to have a number of prerequisite for these two works. You wanna make sure that you have a clear strategy in place, you wanna make sure you have clear governance. What does it mean governance here? It's a, it's an ugly word just to say that you wanna make sure your teams know their role and responsibility into the team. So uh does the PM know exactly what their role and the scope of their role is?

What's their responsibility and the same way it will really help you to think about your future organization as you have a clear strategy, a clear governance, but also clear processes. How do you decide to work as a team? It's very important to define that upfront and all of that will really help you to design your structure. And so going back to treating your organization as a product, what does it mean? It's really going through those different steps that you know very well. Uh when you design a new product, you start by doing research and discovery. So that's where I want you guys to start to listen. So what is the problem we are trying to solve? Why do we need to reorganize uh the team? Why? Why is it required? So here, the similarity to a product development, you have many ways to do that. You could do one on one interviews of members of the team to better understand what the problem uh that the current organization is facing. You could have quantitative surveys, you can have workshop organized.

So this is the part where you try to define what is the problem that you're trying to solve? Reorganizing for reorganizing doesn't make sense, right? So if you set your as an objective that there is a need, let's make sure to understand what is it that you're trying to solve for. And it could be a number of things here you have on the screen. A few example of those challenges, what they could be? Right? Is it a problem of ownership or autonomy? Is it a problem of how you prioritize? Is it a problem uh related to the size? Is it a problem related to the scope of your team or even the what we call duration? So how long the team have been working together? So there are a number of aspects that you can question yourself uh either through those one on one interviews, those workshop or even surveys to really try to identify what is the true problem or challenges you're trying to address. And once you have your long list of challenges, maybe this is the time where you start to prioritize them. And similarly to a product, when you want to prioritize, you need to define what is the KP I, the criteria for success that will help you to prioritize.

And here it will really help you to make sure that you only focus your attention to the biggest challenges that your organization is facing. And if this is the case, then you can start working on ideation and finding the right solution. So um if you have challenges around autonomy and ownership from the product team, how can you lower the center of gravity uh uh of decision making to the team so that they can feel more autonomous. If there are two, any dependencies between team, how can you drive more autonomy into your organization? So this is going to be very important for you to achieve to the right solution. If you have done your research, and if you decide that you only focus on those challenges, that are the most important one for you and your organization, obviously, as any product development process, you will go through an implementation phase, a launch phase and then eventually iterate.

So at this point in time, my recommendation as you understand is really before you jump into any conclusion, especially like me, if you were to start uh as a new chief product officer in an organization like I did last year and you were told, well, you need to rethink your organization.

So before coming with solutions, start listening, start understanding what are the problems that you are trying to solve? What are the challenges that you want to address and then set yourself clear objectives clear KP I that you can measure, measure the the results against.

But it is important as you go through this process of scaling your team is ready to embark your team into the process. Nobody likes change. Nobody. We know we all work in probably, you know, uh fast paced uh environment uh technology company where innovation is at the center.

So changes is there all the time. And as your company grows very fast, it could be that your organization actually change every 36 or 12 months, which is crazy if you think about it. But what is important is that as you go through this process, you need to make sure to explain to your team why changes is important. What is it that we are trying to achieve all together as a team? And how can they help you succeed into this change? And so keeping in mind that changes is hard for everyone, please make sure to explain the why of changes. People are always more inclined to adopt change if they understand why they do it and what will be the benefit for them. I'm going to walk you through the example that uh which we've been through just this year uh at my company. So like I explained, I joined the company last year and we had to rethink our organization. And what happens then is the organization was no more adapted to one, the type of customers and product that we were serving and two that it wasn't uh capable of scaling and absorbing the number of new hires that we had, we grow very fast. We were like, we are lucky to double the team size every uh six months to a year. So, meaning that the organization needed to be able to absorb uh this uh very uh fast growth of people.

And also the fact that our product was changing and that the the type of customers that we serve over the time was changing. So our answer to how to scale our organization was to adopt one simple concept that you probably know which is the squad concept. And we introduced that notion of squad for two main reasons. One, we wanted to make sure that we give more power or empowerment to our team, meaning decision making is really happening within the squad. What is a squad? The squad is a team of with one product manager, with developers, with designers, with Qas and those squad. As we hire new people, we will just assign those new hires to each of those squad and each squad uh then when they become too big can be sended and, and separated into creating new squad. And you can see on the screen that uh it's not just a squad, it's a core squad. It's really uh the teams that are working on the core product that we are developing at miracle. And it's very important for us to build this concept of squad within the organizations.

It's really um is about making sure that the team learns and become expert about the core product that they are working on, but also that they become so tightly knit and, and so uh close and with such a strong collaboration that they uh actually gain in velocity and inefficiency.

Why? Because you, as you learn to work with your team and as you develop your own culture and your own ways of working, you become more efficient than if somebody else is telling you to. So what is interesting about the way we organize our own squad is that we really decided to make sure uh that we give each of this quad the ability to define their mission statement, their Ost Metris who does to all those or the way they work, we don't necessarily follow the crime or Kanban.

Each squad can define the ways they work, which gives them a lot of uh power into organizing themselves, but also to make sure that they reach the company objectives and the company vision. So that helps us really to um drive that core uh that core mission. But sometimes, and we want also to be to remain agile. We also need to create what we call project squad, what those projects squad are. It's really about the idea that if we had something that come up out of the blue and we know has a beginning a middle and an end, then we wanted to make sure that we have the flexibility to pick up some of the element from core squad and form a temporary project squad for a certain period of time.

And that is really helpful as an example when we have new regulation coming up and development is required. So we know there is a beginning a middle and an end. And then at the end of the project, everyone just goes back to the squad. And as I said, empowerment is also coming with um the ability to know clearly what you're working on. So each squad has what we call a squad charter. They have a clear mission statement. They uh know what the squad is about. They know obviously who is in the squad, but also who the stakeholders that they can work uh with very close they are. And so it's very important for us that they have those Northstar metrics well defined so that they know what they are contributing to in terms of success of the, of the company and how, what they do on a daily basis is actually contributing back to the company vision and the company's success.

So here, by providing all of those tools to our team. If you remember, scan your, your organization is about the structure, but also the tools then it really helped our squad to feel empowered to take ownership of their product, drive efficiency, but also drive result and, and innovation.

So what is important when you think about scaling your organization is um with, even with the best design, the truth is your team organizations and the team structure will probably change over time. It's not going to be uh static, it's not, it will probably be more dynamic than static. So what you want to remember here is something that is very important. The same way as you would develop a new product is the iteration. So my biggest piece of advice for you guys is really to think about your organization in an iterative way. Don't try necessary to go with a big bang try with a small change and then go over time and add incremental change to your organization so that they can scale. But also iterate after three months, after six months, what is working, what is not working? And the same way, what are still the challenge that you need to, to be facing and that you need to address as an example. This new organization that I showed you just earlier, we implemented it last September. And just last week, we had our first retrospective on that organization with my team. We talked about what went well, what didn't work so well? And what are the challenges that are remaining for us to be uh to address?

And what came out of these conversations is yes, there is more changes to come. So what you want your organization to do and help your team to understand is change is going to be the constant, you will continue to evolve. But it's OK because you have the tool and the structure in place to help you feel a part of an organization that knows where it's going, that has the same culture, the same vocabulary, the uh a framework where everyone can operate, but things will change. So it's changed within a frame if you like. And so maybe to conclude this, this talk today, uh I wanted to remind you some of the key things III I shared with you. So, like I said, start by listening. Don't jump to conclusion, make sure that you spend the time to understand what are the true problem and the true challenges you are trying to address, address as you want to scale your organization. And as you think about the the structure of your organization, make sure that you embark your team into the process, make sure that you give them visibility, make sure that you explain to them the why and the reason of the change. But also what are the criteria for success so that everyone can agree when this become a success? And ultimately make sure that you build something that will last. Meaning, make sure that you iterate you think regularly about how your organization evolved. Is it still the right sizing?

Is it still the right portfolio uh organization? Uh Do you still uh have the right set of tooling? Do you need more tools, all of this needs to be constantly um monitored and think about the same way as you would develop your own product you want to do to think about your organization, have a clear vision and a clear strategy that will help you to be successful with that.

I will uh conclude my uh presentation today by thanking everyone for being attentive and, and uh joining this talk. I'm really uh uh thankful for everyone to take the time and I hope to see uh if you have any questions before we conclude. Well, I don't I, I guess I, this is my time everyone. Thank you so much and have a great conference for everyone. Bye.