Christopher Parola - Comment construire une équipe produit efficace (FR)

Hello everyone. Hello, hello, hello. A big thank you to all the organizers of the Floconference for inviting me today. I'm delighted, it's been, well I think like many people, a long time since I've seen so many people in one room, and so I'm very happy, a little emotional, well, a mix of feelings. I'm very, very, very happy to be able to talk to you today about a subject that is very close to my heart, under this somewhat catchy title, one might say, how to build an effective product team adapted to your challenges. So we're going to talk about product, we're going to talk about things that apply to all teams, and things that apply only to the product team. I am aware that it's 11:50, that you will be hungry during the presentation. So there will be moments of great sport where you will raise your hands because I will ask questions and I am counting on you, if you don't it will become very, very, very complicated for me. Still have energy, alright? Great, thanks. So, I can't get my slides to advance. It worked, there we go. So, I'm Christopher Parola, I'm Chief Product Officer at Usign. You might know Usign, it's an electronic signature solution. I'll talk a little bit about the Usign example, not so much to sell you the wonders we do in electronic signature, even if we do some good ones, but mostly to explain the growth of the organization and what we are trying to implement. I was Chief Product Officer at Meilleurs Agents. I put the figures next to it, these are the sizes of the product teams. So, first number when I join the company and last number, either when I'm still at YouSign or when I leave. So at Meilleurs Agents it went from 1 to 40, at YouSign it went from 4 to 25. I'm not telling you this for glory, but just to give you an idea of the team sizes I'm talking about in what I'm going to tell you right after. If you want to keep in touch afterwards, you can find me on Twitter, on LinkedIn, on a small website, don't hesitate, I'll be happy to chat with you. So building a product team, well, it's easy, everyone wants to do product. So I've put a short extract here, it's an extract from the barometer of the Product Conference, you might know this conference, where we ask product managers and people who work in product, I'll say product people quite regularly. Because we have a lot of jobs, we'll see that right after, we ask them where they want to work in France. And they answer Blablacar, Alan, Doctorlib, Backmarket and so on. Do you know, does everyone know these companies? Does everyone know someone who works in product in one of these companies? Great. Me too, and when I talk to them, it's quite fascinating to realize to what extent the product manager at Alan has a job that has absolutely nothing to do with the product manager at Doctorlib, nothing to do with Backmarket, nothing to do with Blablacar. In fact, they all do totally different jobs, and that's quite fascinating. And it's quite fascinating, especially when we look at more common professions. So here I've put a picture of a butcher shop, it'll make the organizers laugh, I bothered them by telling them I want vegetarian meals during lunch. But my grandparents on both sides of my family were butchers and pork butchers, I like to think of them from time to time when I think about what we do too, because in fact when you put yourself in their shoes. If we project ourselves a little bit onto this type of profession, the career path, the career, you are a butcher in a butcher's shop or in another butcher's shop, there are small variations but it still largely resembles each other. And in fact, it's a bit of a characteristic of a huge number of physical professions in which, ultimately, we don't ask ourselves too many questions, today I'm an agile coach, tomorrow do I have to define myself as a Lean coach, do I have to talk about Kanban, do I have to talk about Scrum, do I now have new skills, I'm a product manager, in fact I'm no longer a PO, oh no, in fact, it's still changing. It's super fascinating, I find the industry we're in, that's what makes it beautiful, but also what makes things very complex. And so the message I want to share with you with this little introduction is to tell you that each organization will probably have its own definition of product functions and that's perfectly normal. And so I'm not going to tell you about a framework or anything like that, I'm rather going to try to think with you about the questions you need to ask yourself to find the right organization according to the challenge we have. Does that suit you? Good, we can't change it anymore. So, let's get to the heart of the matter. The first thing we're going to look at together is what team you need to meet your challenge. That was in my title, and in fact, we're going to start by defining the challenge you're facing. Because it has absolutely nothing to do with the types of organizations and company sizes. I'll tell you about mine at YouSign, maybe it will speak to you, maybe some of you will recognize yourselves. So at YouSign, we built a mission statement. I'm going to show you a lot of slides with a sentence, you who know the corporate world, I'll let you imagine the number of hours we spent to churn out these few words on a piece of paper. So what we do, there will be slides in English too. First, because we are an international company, we are in Germany, Italy, Poland, in addition to being in France, but also because it sounds much better in English than in French in our fields, you will see. So what do we do? We help European SMEs execute agreements in a fast and secure way, where we help SMEs and VSEs to contract in a fast and secure manner. That's what we do at YouSign. That's what we do at YouSign. And the problem, problem or opportunity, you'll tell me, is that we're not alone. So we are in a market where there are more than 100 electronic signature players in Europe, because there are also Americans who come to Europe and it is a market that is also highly regulated. So in fact, there are bodies in absolutely all countries that are control bodies. So we have an annual certification like banking organizations to prove that the electronic signature we deliver has the right concepts or at least meets the right criteria. Of course, I'll spare you all the standards, but it's just to give you a little bit of an idea of the market we're in today when we talk about these companies. And so, we produced a vision, we said to beat the competition, what we're going to do is give a platform that is secure, that does contract management, not just signature, which means we're going to try to have more value propositions and not just one unique value proposition and to give the best user experience. And ultimately, our only differentiation in a regulated market where everyone has the same level of signature, where everyone offers the same service, will be the user experience. That's the challenge we set ourselves. When I was at Meilleurs Agents, we were also more or less outsiders because ultimately the characteristics of the companies are similar. I arrive at YouSign, there are about forty of us, a fundraising has just been done, there are 100 players, there is an American giant that I will not name so as not to give him more publicity but you know him and everyone confuses us with him also because we all have the same names, we do electronic signature, we all call ourselves sign something like that. At least it's universal, signa. There is a specificity in Spain. But, therefore, we try to differentiate ourselves through user experience. So a very big market, a market with a lot of people and so the first thing we say to ourselves is that we're going to have high velocity in our teams and so we absolutely need to organize them. In the best possible way, we think. So we have the squads, I'm not going to teach you what that is, multidisciplinary, self-organized teams. We like to represent them that way. Because in the squad, there are representatives from many different teams. In fact, when you ask someone from a squad which team they are in, you'll see a product manager, there's always a pause, should they say they're in the product team or should they say they're in their squad? And so that's also a characteristic that makes squads work well when we do that. So we created squads and in these squads, we have several, we have all the skills to be able to deliver a product from A to Z. And I'll come back to the product jobs later, but basically, we'll find product managers. Classic, product designer, engineering manager, developers. Potentially quality assistance or not, it will depend on the types of teams and product marketing management PMM which I noted as part-time. Have you already worked with product marketing managers? Not yet. Well, we'll talk about it right after, great. And so these squads, the idea is to be able to organize them around a common theme and for them to have all the skills to deliver the functionalities they perform. Behind these teams, we actually have, they're not clones, it's not just one squad is one squad, they are different typologies of squads. So normally, there might be some vocabulary here that you will also find in what you know. We have three types of squads at YouSign, we also had them at Meilleurs Agents. We have a type of squad, and I'll go from right to left, the platform teams which are teams that actually have a level of focus on a technological or technical project, rather long-term. For example, at YouSign, we have a signature engine. That's where all the, it's the heart of the machine, if the signature engine doesn't work anymore, there's no more service for our users. That's what we call a platform team here. It's not a team that has regular change issues, it's not a team, it's rather a team that will have projects over 6 to 9 months because a new standard has been released, you have to adapt to it, it's very well documented and in fact you have to do the work to deliver it. That doesn't mean it won't do iterative and incremental things, but it does mean that there's no need for a force, for example, of product design or product management highly focused on launching new products. It's more about delivery that needs to be done there. We have another type of team called feature teams, which are teams that are rather focused on a functional scope as their name indicates, and we have a third type of team called impact teams. So that's a name and I pay tribute to Nicolas Baron who is not with me, who was CTO at Meilleurs Agents and we followed each other to YouSign so he is CTO at YouSign. We continue to work together and we created this term in 2017 to also try to say that there were typologies of teams that could be organized not on a functional perimeter, not on a technological perimeter, but rather on a perimeter of quantified objectives to achieve. What that concretely means is that we take a team, I'll give you this example that we have today. We have an application at YouSign where we sell licenses, the entry license is 9 € per month. And today, to sell a license at 9 euros per month, we have a salesperson who calls the customer, gives them a demo, explains a lot of things, etc. Our product is to upload a PDF and put a signature on it, so it's not Rocket Science, it doesn't require crazy training. That's what we do at YouSign. Suffice to say that when we sell a 9 € plan but it took three or four days of work for a salesperson, the economic equation is not great. And so, from that perspective, we want to do what's called self-serve, let the user buy our product themselves. We have a team that we told, your role is that 15% of transactions now be self-serve, figure it out and tell us what needs to be done. That's what we call an impact team. It will be able to work on all functional perimeters, it will be able to call upon other teams for help, platform teams, feature teams, but it has all the skills to decide on its plan to achieve this objective. So that's always in a quest for team autonomy. Rather than having an executive committee that will tell the team, we want to do self-service, we've thought of everything, this is what we're going to do, we prefer to tell the team that is in contact with customers and users, organize yourself, you have all the skills to do it, recommend a plan to us and then we will validate or invalidate it at the executive committee level. So we're changing the paradigm a bit here. So, well, we also have another way of organizing teams. So we have the unit, the squad, these squads are organized in three different ways, platform, sorry, component, feature, impact team. And then, we're also going to structure them into domains. So we're going to try to still cut out squad themes at some point. And what that will give is actually coherent domains in which we will be able to have unique leadership and for example, we haven't reinvented the wheel. At YouSign, we sell an application and an API, we have a domain called API. So, these are the people who work more on the enrichment of our API. But what's interesting is that they use exactly the same services as the people who build the platform. But what's interesting is that they use exactly the same services as the people who build the platform and therefore they are the component team. I'm going to show you a super simple diagram because it can seem complicated. So the joke we've been making since 2017 is that people tell me, "You have to put impact teams everywhere," I see a lot of white papers coming out about impact teams, I was at people's places who set them up and who asked me to come to their plenary to explain why we should set up even more of them when they weren't working for them, the impact teams. So I just wanted to share that with you, obviously, not all teams should be organized on this model. It will depend on the maturity of your company, it will also depend on what they have to achieve. And so to show you the next diagram, this is the engineering and product organization at YouSign. So what you have here, we won't go into too much detail about the team names, etc. Basically, what you find at the bottom, you really have to see what we find at the bottom of the slide, it's the foundation, it's what we call the transverse teams. We will find infrastructure teams, data teams, quality teams, product marketing teams. In fact, these are all the people who are not full-time in a squad, but who come to bring expertise at some point to a squad. Just above, we have what we call the platform team, which are our teams that are where we find here only component teams. These are teams that actually work on a technological component and that they provide to the entire company. So for example, the team we call Engine, we called it that because it's really the heart, it's the engine of YouSign, they provide services to other teams, the other teams consume it, the day Engine no longer works, there's no more YouSign. Globally, that's the level of pressure on this team. And then we have other types of teams where we'll find four domains. We have a domain we call integration, that's where we find everything related to APIs, connectors to third-party software, a domain we call the core in which we'll find everything related to the YouSign application. And we also wanted to diversify. So we acquired companies to integrate them into YouSign and expand what we were doing. So before we only did signature, now we also do document preparation and document archiving. And so, we bought companies that we put into YouSign, but that we ultimately put in a slightly separate pot from the rest of the teams. And all the way to the right, we find a domain we call scale, in which we'll find all the teams that contribute to growth. Rather via internal software or processes. And so this is an organizational model that is quite simple ultimately. So I deliberately don't name frameworks for agile at scale or that kind of thing, but you will find, I think, elements in what I show you there, but basically, we kept it very simple, we have eight squads. Transverse teams, platform teams, three types of squads and that's it, it works like that. And so I put it there, I'm not going to re-detail it but what's interesting is that it's a model that also worked at Meilleurs Agents. In fact, it's exactly the same model. We identified what was the heart of the system. At Meilleurs Agents, it was the data platform, if it didn't work, there was no more service rendered, we put it at the bottom saying these are our platform teams and on top of that, we plugged in teams that then came to consume these services. All good so far? Okay. So, we're in an ultra-competitive environment, we've defined the types of teams and organization we needed. Now, I suggest we get to the heart of the matter, what skills do we need in a product team to work in this type of context. So we're going to start with the jobs. The jobs in a product team are varied, about one comes out per year. So there are trends that come, go, come back, it's super interesting. We have product managers, then we'll talk about product owners and product managers for a minute, if you're interested in fueling this debate together, it's always fun. We have product designers, product designer, that's the old term, you know for a very long time, there were job descriptions that said UX/UI. Well, these are product designers, they do both, they will do user research and also design. If you want to make them really angry, tell them that we have pretty colors thanks to them on this type of slide. We have product analysts, these are the ones who will help the product team access data. They are not data engineers, they are not the ones who build the company's BI, but rather they are the ones who will do complex analyses. You have to start doing cohort analysis on cross-acquisition funnels. Wow, not easy for a product manager alone to go and find that data. So they will come and bring this layer to the teams above. Then, well, quality assistance, we tend to know these teams. Product Ops, new job, they could have called it product coach. In the majority of companies, Product Ops, the idea is to say that the product team must learn skills to do its discovery and delivery well. And so, we're going to bring people into the organization to teach them how to do user research, how to do interviews, how to dig into a data lake, and so on. And so, it becomes full-fledged teams in many organizations. Payfit, for example, to name them because they were on the first slide, has one of the largest product ops teams in France. And product marketing managers, that's kind of the missing link. Of product commercialization. That is to say, without these people in the teams, today what we often find in organizations is a product team that makes software, a marketing and sales team that will make it available to the market, and often the knowledge that the product teams will acquire in the field by interviewing users is a little bit lost at this stage. So in fact, we know what users want, we know their needs, we even managed to formulate it in the user's own words, but we're not going to use it at all to make it available to the user. And so product marketing teams will be very focused upstream on whether there is a market for my product and downstream, when the product is available, on whether I have the right distribution and adoption channels for my product. Are the terms clear to everyone? Top. If someone doesn't agree, you can raise your hand and say I protest, I don't agree. So, what's important for me is to share this with you: when you create a product team, you've seen all these jobs, more than half of them are super recent and date back less than 5 years, plus they evolve enormously. So I put a superb photo of the Big Bang. For me, when you are at the head of a product team, defining the expected skills in that product team is really the birth of the team. It's not about recruiting, it's not about making them work together on a product vision and so on, it's about defining what you expect from them. Because in fact, when you join a product organization today, that's the example I gave you at the very beginning, you have no idea what job you're going to do when you arrive, none. And so, defining these skills and making them available to everyone, allows all stakeholders of this team to say, 'OK, when I join YouSign or Payfit or Blablacar, that's what will be expected of me.' So how do we define these skills? Before getting into it, I never talked about product owner. Do you have a preference? Who is for product owner in the squad? Product manager? Both? for me, when you are at the head of a product team, defining the expected skills in that product team is really the birth of the team. It's not recruitment, it's not making them work together on a product vision and so on. It's defining what you expect from them. Because in fact, when you join a product organization today, it's the example I gave you at the very beginning, you have no idea of the job you're going to do when you arrive. None. And so defining these skills and making them available to everyone, it allows all stakeholders of this team to say, 'Okay, when I join Yousign or Payfit or Blablacar, this is what will be expected of me.' So how do we define these skills? Before getting into that, I've never talked about Product Owner. Do you have a preference for Product Owner in the squads? Product Manager? Both? Top. I thank you for that. I'm just making this digression because I find it interesting, it's a big debate. And I'll give you a few phrases that I hear regularly. And well, I'm sorry, I'm not going to close this ontological debate and besides, I risk attracting the wrath of a lot of people who know where I live. So I'm not going to share that. But what I find interesting is that we continue to try to define Product Owner, Product Manager. Often we define them by a dichotomy, saying Product Owner is a role, a role in a Scrum team, Product Manager is the job, extremely annoying for all Product Owners, I find, but we hear this phrase enormously in organizations today. Another phrase we might hear is 'Product Owner is for delivery, Product Manager is for discovery.' Just this morning, I was reading the white paper of a consulting company that works on product management topics and had written that in its white paper. And I found this model interesting, a bit easy, a bit risky too, because when you do that, it broadly means that you've returned to a V-cycle without really saying it. You have the thinkers, they're going to give you a nice report and good luck delivering it. And so it's quite interesting, but it's an attempt at clarification. I also dabbled in that a few years ago, so I include myself in the people who say that. And I'm sharing this definition with you because I find it quite beautiful and it ultimately goes a bit beyond the debate. It's Melissa Perri. You probably know Melissa Perri. She wrote an incredible book called "Escaping the Build Trap." which is a book that tells a story, you have names of characters, and it's quite funny because you can change the names of the characters with any of your colleagues and I'm sure it's a real-life situation. She managed to universalize the difficulties we have in business. And she says this, she says the goal for a Product Manager is simply this: reduce risk by focusing on learning. And I like this sentence because I find that it encompasses all the themes we have in these professions: the theme of risk. In fact, ultimately, the Product Manager or Product Owner in many organizations doesn't have the final decision-making power. They are not the CEO of their product, as we sometimes hear. It's someone who has to reduce risk, and my personal conviction is that to reduce risk, they must know how to both think about their product and put it in the hands of users, and thus go all the way to delivery. There you go, it's worth what it's worth, but I hope it adds a little water to the mill of the subject. So that's why I'm only talking about Product Manager, but it's without any judgment, it encompasses both jobs for me, and that's what I expect when I talk about a Product Manager in my teams. So, we're going to build a career path. So we have a lot of product team skills. Well, first we're going to do one thing: we're going to build levels. To tell the person when you join us, you're fresh out of school, welcome, you are level 1. Then when you are super developed in all your skills, you will be level 5. So far, quite simple. A system of levels on the types of organizations I've managed, so up to 40, 50 product people. Honestly, five levels is quite enough. Because sometimes we want to go into an enormous amount of detail, to have level A, B, C, D, E, F and then sometimes we have a career path that takes 15, 20 levels. Well, it's a bit complex, and then you have to use it every day. So, good luck explaining to someone why they're level 18 and not 19. It's not easy with these organizations. And at Yousign, a particularity we've introduced is a sub-level system. So in fact, what we tell the collaborator is: welcome to the product team. Here are the skills we expect. You have five levels. And the sub-levels are quite simple. In fact, when you want to be level 3 of our career path, you must master at least 50% of the skills of level 3. When you master them, you are 3.1. If you master 75% of the skills, you are 3.2. 100% of the skills, you are 3.3. And then you can go for level 4. What is, well, it will seem basic to you, but it's really important because it also allows us to declare something, which is that in many organizations, we reach the next level of a career path and then we have to prove ourselves at that level. So for example, we tell you, 'Well, you're level 4, welcome to the organization.' I expect you to prove that you have the skills of a level 4. What we've chosen to do is rather say, 'You are level 3.3.' You're going to spend some time at that level. Once you completely master it, you're going to look at level 4, which is in front of you. You're going to look at the skills you need to develop, develop them, and when you have them, you will pass to level 4.1. So it's a way to use the career path. Well, it's quite generalist, as a career path. So what you need to remember here is not necessarily to get carried away with the number of levels and to have a regular progression, a regular progression. The other question we're going to ask ourselves, which is perhaps more interesting than that of levels, is whether you need generalists or specialists in your teams. And I'm going to stop there for a second. Well, generalist, illustration, the orchestra man. He does a bit of everything, he knows how to do everything. Specialist, perhaps the music lovers will have recognized Glenn Gould on his piano who is recording the Goldberg Variations, which are very beautiful. True, true, true specialist, but specialist so specialized that he only plays one composer. So ultra, ultra specialized. And I'm telling you about this also because today, the career paths we find in the world of product rather encourage specialization. So when I talk about specialists, I'm going to stop there for a second. Look at job offers for Product Managers (you can do this after the talk), you will often have something prefixed or suffixed. You are not just a Product Manager, you are a Product Manager API, Product Manager Acquisition, Product Manager Growth, Product Manager Scale, etc. In fact, we have a certain tendency in companies to tell ourselves, I need a Product Manager for my team who works more on the API component, so I'm going to take someone who has done API for 10 years, put them there and it will go well. So it's someone who has developed very in-depth skills in their domain, but not necessarily on all aspects of Product Management. Where a generalist will rather have a skill set, so a set of skills that will be more about all the actions of the product manager, what a good product manager should know how to do, not necessarily having worked for years on a particular topic, but what is interesting is that this type of profile, you can easily reposition it in your teams. And so I'm bringing you the answer for me: in the construction phase of a company and in a very moving market, you have to prioritize generalists. Why am I telling you this? Because I've seen it many times. You recruit, so you set up your squad, it's called API. So we say we work on the API component. And you recruit a specialized API Product Manager. You've just made a decision, perhaps without realizing it, a fundamental one, which is to say that for the next five years ahead of you, there will always be more priority work than on all other topics, on the API. That's what we've just defined, because in fact we've just told ourselves, there's a part of my flow that will be dedicated to the API forever. And that's a decision we often make somewhat unconsciously. Because we say to ourselves, 'Okay, I have a component, I want to push it very far, I want to work a lot on it.' And we don't necessarily realize that by taking this decision, we have committed ourselves to a path in which we have just decided the priority for the organization of this subject compared to others. Because I don't know if you've ever experienced it, but go see this API Product Manager. And then all the developers specialized in APIs who love doing that and so on. And tell them, 'So now, for the next six months, we have an acquisition problem. So we're all going to take you and make you work on acquisition.' Has this type of thing to do ever happened to you? Did it work? I see some nodding yes and no in the room. Well, if it worked for some, send me a message right after because I want to learn how we do it. What I've often seen is people raising shields, people saying, 'Never in my life. I came to do APIs, it's my skill, it's my specialty.' I don't want to work on the rest, and sometimes I don't even have the generalist skills to look at the next topic. And so there's a paradigm here that's really important for me and I wanted to share it with you today. In phases where your market is really moving, and in fact, when we think about it, often agility was a response to that. It was a response to obviously mastering its delivery, predictability, etc., but also to being on domains where, ultimately, we weren't sure what we were going to build and we wanted to see small pieces of it, make them available to users, learn, and iterate on them. And so when you freeze your organization and define it, it can be very complicated if you go for specialist models. So that's a feedback I learned the hard way myself because I had teams where obviously I took specialists and it didn't work out. So I'm not going to tell you the skills of a generalist, what it is. We're going to talk about a framework that is super simple, which is called the Core Framework. It has the good taste to apply to all product professions, so all the career paths I do in my teams. use the Core Framework. Whether it's Product Marketing Manager, Core Framework. QA Analyst, Core Framework. Product Analyst, Core Framework. Core Framework, it's quite simple. It's an acronym, obviously, for Communication, Organization, Research, Execution. I'm going to take the Product Manager job, we're going to caricature a bit. We're going to say Execution Delivery, Research Discovery. We often talk about these two terms. And Organization Communication, it's often what we put in the kind of slightly soft skills. slash PMO skills. I know how to lead a cross-functional team, I know how to move a subject forward. So in fact, all our career paths are defined in this way. They have these four categories and in these four categories, then we detail competencies, so there are several lines, which allow us to say, 'Well, you are a Product Manager at level 1.' Here's what we'll expect from you regarding organizational skills. You're fresh out of school, we might not expect you to pilot a project that is directly validated at the executive committee level. However, we can expect you to pilot decision-making in your team. And so, that's your organizational skill that we expect from you. So this framework is quite powerful for generalists. So there you go, I'm sharing it with you, it might be another facet for you to imagine it. And it applies to 100% of professions. So once again, that's the beauty of this framework. It's that in all product teams, you have a common framework for the teams, which can also create some coherence in a team that on a daily basis may not always work together, but rather work with their squads. No questions so far? Are you following me? Is there still energy? I put a parenthesis on Discovery because I talked about it, there are lots of frameworks, there's a great book called Discovery Discipline by Rémy Guyot which came out recently and is in the top sales. What I wanted to share with you was the Discovery framework that we created with Laura, who was Head of Product at Meilleurs Agents, and which we continue to implement at Yousign. And in fact, this framework, behind this framework, we always have a toolbox. So we do training for newcomers, we give them lots of tools, the Lean Canvas, the Business Model Canvas, problem interviews, user interviews, etc. These are really tools. What's important for me is the process today. Our process is a four-step process. We consider that there are four types of risks. When you are a Product Manager, remember Melissa Perri's definition: your job is to reduce risks. Well, we consider that a product team's job is to reduce these four levels of risk. First level, user risk: do I have users who really have my problem? Are there users who really have my problem? You'll tell me it's logical, but there are so many products where we go directly to the solution and we don't even think about the user problem that in the end no one uses it. Google Glass, for example. The product risk, is the value proposition and my functionalities the right ones to meet this need, and are they better than existing alternatives? The channel risk, will I be able to distribute my product? Because similarly, there are so many beautiful startups that have made great products that didn't take off because they didn't know how to put it in the hands of users. And the profitability risk, the idea is to say, we're going to put a squad on a topic, for example, I'm saying anything, for six months. Uh, well, if I go back to my analogy with the butcher shop, uh, when you put a squad, let's say 10 people for 6 months on a project, in your opinion, how much does it cost for the organization? We're talking about the fully loaded salaries of the people. How much does it cost for the organization? We're talking about the fully loaded salaries of the people. We're talking about the fully loaded salaries of the people. More than 100,000 euros? Okay. More than 200,000 euros? More than 300,000 euros? 400,000 euros? I'm going to turn this into an auction, I love doing that. More than half a million? Yeah, well, those who raised their hand are in the right today. We have completely lost that in our digital projects, but in fact, when you invest 10 people, fully loaded salaries, average salary at 50k, you are at half a million euros for half a year. And so that's super interesting because suddenly this cost, this cost, well, we can say, 'We are a company, we already have the salaries that are paid, we have already hired these people.' But in fact, it's also an opportunity cost. You have chosen to invest half a million in one subject rather than another. And so we try, from the beginning of the projects, to think about this risk on profitability. So, I'm sharing this with you, it's a framework that's worth what it's worth, but it also explains to you. Typically, that in the user risk and the product risk, we are very much in the world of Product Management, Product Design. Whereas in the channel risk, profitability risk, we are very much in the world of Product Marketing. Will I be able to distribute my product? So that's why we're starting to really see the emergence of these jobs in product teams, because if we consider that the product team's role is to minimize all these risks, you need skills to minimize them. Well, it was a small digression, but an interesting one. So, another question, which completely falls outside the world of product management, but is management a grail? That is, when I follow my career path, is level 5 being caliph in place of the caliph and becoming the CPO of the company? Because the only way to evolve in an organization is to do management. Obviously, the answer, I won't dwell on it, but it's a big, big no. We need several paths in a career path. What we considered is that we could start choosing a different path from level 3. So up to level 2, you are a Product Manager, you don't manage anyone. From level 3, you can say, 'I want to become an individual contributor.' And therefore go towards expertise, in the end we will talk about jobs in English of the type Principal Product Manager, or do I want to go rather towards management and therefore start to manage a team and then pilot increasingly large teams and increasingly large functional domains. So there you go, I won't dwell on it. I won't dwell on that, I hope you are all convinced. Interesting fact, we have a salary grid that is completely open. So people know where they are and know the salaries, and the salaries are identical between manager and individual contributor. That way we've gone to the end of the logic, because we can't tell people, 'It's exactly the same, it's great, take both paths.' Well, if you take the bottom one, on the other hand, in the end, you'll have the pool, the one below, you'll eat pasta. And another interesting point about building a career path is its on-off side. Sometimes we write competencies, I'll give you this example, 'Knows how to facilitate co-creation workshops.' Yes, no. It's super complicated. You're with your collaborator and you say to yourself, 'Wow, does he really know how to facilitate this co-creation workshop?' It's very on-off, very binary. So, everyone here speaks Japanese and obviously recognized the letter Shu Ha Ri. So, everyone here speaks Japanese and obviously recognized the letter Shu Ha Ri. I see some nodding their heads, some are writing it in their notebooks. Well, I don't speak it at all obviously, but the philosophy is interesting. It's a philosophy that comes from Japanese martial arts, which comes from dojo, and the idea is to tell oneself, Shu Ha Ri, it means that at some point, before completely mastering a skill, it's not on-off, there are three levels. There's a level where you are an apprentice, a beginner, you learn to master the gesture. And so there you have to repeat it regularly. Then you master it with a master, preferably. Then you master it, and then we consider that you are. master, so you master the skill. And then there's an ultimate level where you transcend the skill. And it's quite interesting, it's the level we translated in French. And then there's an ultimate level where you transcend the skill. And it's quite interesting, it's the level we translated in French. It doesn't take on the whole philosophy of the term, but it's 'professor'. So in fact, in our teams, when we have our career path, we have all the competencies listed on the Core Framework, and for each of the competencies according to the level, we tell you, 'Well, you're level 1.' We expect you to be a beginner on a lot of topics. There you are level 2, we expect you to have maybe become autonomous on some of these practices, and then when you reach level 4 or 5 of expertise, there we expect you to be able to teach newcomers in the organization. And so that makes something quite interesting. Because the progression is not just linear and binary, but much more progressive. What is also interesting from a management point of view is that you know at some point who is a professor on which skill. What is also interesting from a management point of view is that you know at some point who is a professor on which skill. And so it can also help you transmit knowledge and skill in your team, because you can ask someone to come and teach another person. So that's the Shu Ha Ri concept that we've put in place in our career paths. I specify, I haven't put a photo of the career path, but it's public. All Yousign career paths are public, so you type 'career path Yousign' and you'll find all the files we use for these career paths with all the associated competencies and Shu Ha Ri. Some may like The Office series, you'll recognize Dwight. The idea is to say how are we going to use the career path regularly, because it's great, we built it, we did Shu Ha Ri, we have the Core Framework, we're convinced of all that, great. How do we use it regularly? What we do is that every six months, we ask each collaborator to self-evaluate on the career path to tell us where they are. Each manager evaluates the collaborator by seeking a little feedback around them. And then we're going to spend an hour discussing the points where we don't agree. Disagreeing can be positive or negative, because we obviously have biases or there are collaborators who underestimate themselves on certain skills and we see them better. And so, quite simple annual evaluation interview, but the advantage of having this career path grid is that it's not just, 'What are your objectives or your aspirations for the next six months or the coming year?' And so, quite simple annual evaluation interview, but the advantage of having this career path grid is that it's not just, 'What are your objectives or your aspirations for the next six months or the coming year?' but it's really something where we have self-evaluated, evaluated, and we can project ourselves on growth prospects, which can also tell the collaborator, 'Well, if you acquire these skills at such a level, you will be able to move from one level to another,' which will mechanically increase your remuneration, among other things. It changes the nature of discussions about raises quite a bit too. It's not, 'I did a good job, raise me.' It's more, 'Okay, I've acquired the right skills, I think I now deserve level X,' and we discuss that subject. So we do it regularly. Your career path is neither a masterpiece nor an ephemeral work. I've given you the source, the painting is for sale if you like it. The idea is also to tell yourself that your career path must be able to evolve. So it shouldn't evolve every day, because you project your whole team onto it and you tell your team, 'Well, now all the skills have changed, it's no longer the Core Framework, it's something else,' etc. It's terrible. Worse, you do that at the very beginning of December, just before the end-of-year interview, you add a good dozen competencies to tell them, 'Look, you have all that to master, good luck on the way.' So you have to be very careful with the momentum of career path evolution, but it's not a masterpiece that is finished, you have to be able to make it evolve. So I have an example, when I started at Meilleurs Agents, we were a platform, it's not a platform, sorry, we were more of an advertising agency for real estate agencies. There was an audience of individuals who came to the platform, and we sold to real estate agencies the fact of being exposed on the platform. And then we said to ourselves, in fact, our platform is a real platform like Uber, like Blablacar, etc. We should connect individuals with the right real estate agents for their project. And that completely changed the dynamic of thinking because we started thinking about critical mass. Is it that in Lyon, we have enough individuals to interest the agencies and vice versa? And so that completely changed our philosophy on these projects. And suddenly, we added a whole part of competencies on understanding the mechanics of a platform. So we made it evolve on that occasion. So my message here is when you create your career path to create your product team, don't make it evolve too often, so you still need the first iteration to be not too bad, but don't hesitate to make it evolve according to the evolution of the needs you have in your organization. Okay. form. And then we thought, in fact, our platform is a real platform like Uber, like BlaBlaCar, etc. We should connect individuals with the right real estate agents for their projects. And that completely changed the dynamic of thinking, as we started to think in terms of critical mass. Do we have enough individuals in Lyon to interest agencies, and vice versa? So that completely changed our philosophy on these works, and as a result, we added a whole part of skills on understanding the mechanics of a platform. So we evolved it on that occasion. So my message here is that when you create your career path to create your product team, don't evolve it too often, so it's okay if the first iteration isn't too bad, but don't hesitate to evolve it based on the evolution of your organization's needs.

Transcript (Translated)