 Hello, Hope. Thanks for the school for having me. Today, I will talk to you about how I focus on improving processes when I start in a new company. Improving processes is something you can always do. But especially when you're onboarding, you have the chance to see everything with a fresh eye and you recognize things easily. I thought it was a good topic, as everyone has been in the onboarding period at least once in the past or will do it in the future. And this is a great chance to make an impact as soon as you start. So a quick overview on the agenda. Today, I'm going to introduce myself and my experience, why I think we should be focused on processes during the onboarding period, what are the areas to focus on, mainly the product, the initiatives, the people and processes, and then some practical example. Let's start. I'm Sara, Italian, graduated in business and economics. I started my career in Italy working for Uxnet Apporter, a fashion e-commerce platform, where I spent almost five years. Then I moved to London, joining the body shop, the beauty brand, and I started being a product manager. And it's one year now that I'm in Farfetch as senior product manager. For the ones not knowing Farfetch, Farfetch is an online fashion luxury platform and in particular, I look after an internal tooling, a CRM, and I feel like I'm quite lucky as my customers are internally and I get to know more about them on a daily basis personally. So why is onboarding important and why should you focus on this period when thinking about what are the processes to change or to improve? Onboarding is one of the most important periods of your career in the new company. You have one and only chance to make the best first impression on your colleagues, understand what they do, what's the company culture and the structure and what are the things they want to keep and improve or like any processes that they have currently in place. MPM roles are all unique and they all depends on the company itself. So some of them have focused more on the delivery, some others on the strategy. In a small startup, you need to wear a lot of hats. So helping with the design, the training, the analytics, while in bigger companies, you have many more resources and people really to help you with their projects. And starting with a new company, it's a very stressful period. Lots of things to learn, like names to remember, the acronyms that everyone is super used to use and you need to understand the challenges that you have and what the company like expects from you. But at the same time, you feel refreshed. You finally finish to send all the CV to tons of companies and do hours of interviews. In the first days, you get to know what resources you have, what's your product about, what are the ongoing initiatives and what's the strategy of the entire company. You get to use your product, you get to meet your customers and understand what their pains point are. And this is the time when you can settle yours and your stakeholders habits. And when you can understand without the process working, the one that you are missing and what your customers want to improve. When you start, you see everything with an external eye. You don't know why things work in that way, but you always put things to improve. While if you are in a company for a long time, you get to use to see things working in the same old way, you get to use of all the politics and bureaucracy in place and it's even easier if it's not your first job. You know already what was not working on what you didn't like in the previous company and you can make an impact and spot areas to improve in the first weeks. So I think it's all interconnected. And if you watch some other talk about onboarding, they all tell you about people, product and processes. And I personally agree. And this is why I put together these pretty complicated sentences by involving people. You can understand what processes are currently in place. This will lead you to start initiatives to enhance your product that in return will affect people back again. Of course, it all starts with people. One of the first thing you usually do when starting in a new company is meeting your Dev and Design team. You have lots of want once where you explain what's your background and what you've understood so far about the company and in return, you get their opinion about the product, the projects and the processes going on. Do they feel they don't have context when they start developing? Did they understand what is the value of all the projects when they're working on? Do they directly get customer feedbacks? If you have like the feeling that some of those things are not clear to them, try to improve them and be part of the team. Maybe you are doing some good training as part of your onboarding or you're watching some insight through research. Share it. Share the knowledge that you're building and don't take for granted that everyone knows everything. Sometimes, and usually like if you are in the tech department, the Dev team doesn't have access to all the research that the business has put in place. And having a common idea and share the knowledge is always a good practice. Of course, like you don't work in silos and you get the chance to meet others, stakeholders, mainly the business. And here you have a bunch of departments to consider depending on your product and the company size. Usually there is the sales team, the marketing team, legal operation, analytics, project managers, research, product marketing. And of course, you have like other product managers covering different areas of the business. You should like try to meet them as soon as possible like dealing the first 30 to 60 days and ask how they are currently involved in the project you're working on, what they need to, when they need to be involved, how to raise requests to their teams and what's their understanding of your product. Then focus on the processes. Having met a bunch of stakeholders, surely they raise to you some concerns. Things they think you should focus on, how they want to be involved. And in particular, you should now have a good understanding of how to ship a product. Who do you need to involve to decide what to do next? What's the ideation process? How to take requirements? What metrics to consider? The development process? How to update the stakeholders and how to deliver the initiative in general? And I don't know, maybe you can maybe test it or you have the SMEs that are ready to help you giving feedback along the way. You should try to understand if you usually release to all the customers or just a portion of them or perhaps a region or a market or anything similar. It's not really common, but sometimes you have the chance to have an end overdone by the former PM. Well, in that case, map out all the projects you need to work on, at what stage they are. What are your stakeholders per projects? What are the metrics they usually consider? How they update their stakeholders? And what are the impact and business dependency as you have and ask who's the most influential person to talk to in case of any need? See what has been promised already. What is, how is like the relationship with the business and why they think should be improved? Where did they fail and where did it succeed already? You should know kind of like the history of your product, understand what failed already and what are the ideas that didn't work and why. So you don't make the same mistakes. And then you have the product and the initiatives you're working on. So if you're lucky and it's a consumer product, you can start understanding what you will work for before actually starting in a new company. Maybe you'll be a PM for an app. So you can download it or your job is about a website. You can sign up or register and try the experience yourself. You should like search what people say about your product, read reviews, try to replicate the life cycle of a typical customer in general. Or for instance, you could also write to the customer service pretending that you are having like an issue with an order or a product or the website in general and see what's their approach. Or maybe you are going to work on an internal tooling or a system you don't have access to before entering the company. So in that case, as soon as you start, ask for all the type of user access. You want to have the admin and the user account. You want to keep track of your first impression being like an user. And this is like the first, the chance that you to see like what is the first impression of your product. Not kind of like the feelings you have. Maybe, I don't know, the blocking is too painful. You easily find all the areas and everything works perfectly. You should like put yourself in the customer shoes and remember what is your first impression. If you perhaps like have a training team that also cover your product, ask to be part of the next training. See how the team you explain your product and what's the usual life cycle of a customer like accessing your product is. What is their first impression and what do they do? What they do find like painful and what are the strengths of your product? Okay, let's be practical now. How can you make an impact and improve the processes straight away? I'm gonna start like with asynchronous work. Let's say that during the first meetings, you found that the business struggles to understand the timelines and deliverables you're working on and they don't have a good way to give you feedback on what you're building. Be an ambassador of asynchronous work. Surely like you use a messaging program or a messaging app, Slack, Teams or anything. You can create channels or conversation and regularly update the team on what the progress on your initiatives are. Cause like you can't pretend to always have everyone in a room and have the attention of everyone at all the times. Reduce the meeting as much as you can, be concise and write things down where everyone can see them. For instance, like they can understand why your project has been blocked or they can give you feedback straight away without having to wait for the next meeting and you don't have to schedule a meeting in the early morning and one in the late evening to be time zone friendly. If you work in a global company, like you will never have the right time to have everyone involved in the same room and you can't always wait for the next day to get an answer. Record videos. There are a bunch of tools to record a video and then with the progress of your project instead of finding the right time to have everyone in a room, maybe you need to give feedback on our design. You can write the comments on the design itself. Almost like all the tools designers use have a comment functionalities and you don't have to wait for the day after to give feedback in person. Are you working on presentation? Again, almost all the tools to create presentations have comments functionalities and you can also assign words to others. Asynchronous words to me is the best. So like use it as much as you can, be an ambassador of it and try to change the way everyone works by improving this process. Of course, like it's not something you can do all the times. I also think that being in the same room or Zoom meeting and share ideas is really powerful but try to free everyone's time as much as you can. And what's the best way to not lose focus and be sure that everyone understands what you're talking about? Well, with visual engagement. So you can create flows, use diagrams, build engaging presentations or whatever. I don't know if your initiative affecting a process that is currently in place, things will change massively. Use a whiteboard tool to show the new process, visually highlighting the main pain point and trying to focus on the conversation directly on those. Maybe you're a researcher, you can add videos to your presentation. Who's the customer you're interviewing? What are the main feedback? Don't write too much, but show as much as you can. Do you want to engage better with stakeholders? Build a timeline visually where everyone can understand what happens when and of course make it available to everyone so they can check it out whenever they can. Whenever they can. Maybe you're building a one-pager. Don't be too wordy. Include screenshots, process tables, anything that can help with the understanding of your initiative and don't take for granted that everyone knows all the acronyms you're used to. About this point, I also always try to understand who I have in front of me when I'm in a meeting. And I try to have like definitions or to give definitions. I give you an example. Let's say that you work for an e-commerce. You are in a meeting talking about products in general. It could be that like the audience means that the product that you are selling, so whatever product that you're selling in terms of like one pair of shoes, for example, or that pair of shoes in that precise size and color, or it could be that they mean the precise pair of shoes that has been sent to the customer. Depending on the conversation, this could lead to a lot of misunderstanding. Definition, I think that makes the difference. And if you help yourself with visual representation is always a good starting point to have everyone understanding what you're talking about. It can also happen that during the onboarding period, your dev team is concerned because they got too many direct requests from the business. And in this case, you have the opportunity to start with the right foot. So you can establish your role, establish ways to get in touch with you and with your team and try to protect your team's time. Understand why the business goes directly to your dev team is it because of new requests, because they change their mind or because they want to get updated. Explain them why you need to protect your developers time, why it's important they focus on the right things and how long does it take to get to a new feature, how to solve a bug or et cetera. Create ways to get new requests about an initiative you're working on and make them accountable of what they're requesting. Did they check with other teams before coming to you? Do they know what's the value of the request they're making? Do they know what you're working on and how much this thing will affect your timeline? Explain then how they could access to your board. You can use like Gira Trello or anything that you use to track your work, but make them self-sufficient to see what is the status of a project you're working on and don't be scared about creating new processes, but at the same time, like be responsible for them. If you have meetings where you raise requirements, you get everyone to understand what are the main pain points of your initiative, you share a timeline and always update all your customer regularly, then they will trust you. They will know where to go to see what the next steps are and not what the stage your initiative is. They could see the videos of the demo you recorded and finally they can also see like visually what's the impact of an initiative. Also establish KPIs and create dashboard to track them. Are you in maybe improving the average order value or the click-through rate by doing this and that? Well, ask your analytics team to create a dashboard, give access to everyone and make themselves sufficient. So they don't ask you all the times how many clicks you got in that banner or whatever metrics you're considering for that initiative. This leads me to my final point that is be self-sufficient. Try to remove all the possible bottlenecks and again, have all the teams able to self-serve and work asynchronously. An example with data, your analytics team needs access to some report that you just have in your tooling, give them access to it or create rules to send those reports automatically to the bright audience. Do you need data to see how it's going with one of your projects, create a dashboard, ask access for that precise table you need and learn how to use the data. So if someone is on holiday, you don't get stuck or you don't have to wait for the other teams to get to your request like prioritized. If your products integrate with other systems via API, ask to have them and check how long it takes to update them. You want to be able to troubleshoot any issue by yourself instead of relying on your team. And if your product has a UAT or a pre-prod environment where the development goes before eating production, ask access to it. Again, like as if you were any of the user, you want to be able to demo the product by yourself, see the progress by yourself and don't have always to ask your DAB team. So to recap, try to work asynchronously as much as you can, use visual engagement to explain things to your stakeholders, establish boundaries to protect your team's time and try to be self-sufficient and continuously reiterate the process you have in place. All those things can be done while you are in the onboarding period and also while you are in an established role. Change the ways of working and always improve and ask for feedback and see how to improve every day in your work. I hope you find it useful. Feel free to reach out over email or LinkedIn or write a comment down below and let me know if you think I missed anything. Thank you again for listening.