 Hello, everyone. My name is Vikram and I'm a product manager at Monzo. In this webinar, I'm going to give you a few pointers and suggestions that are going to set you up for success in your first 100 days on the job as a product manager. But before I get into that, I'd like to share a little bit about myself and my career journey and what has brought me to Monzo. So I graduated from Singapore Management University studying economics and joined DBS Bank. It's Southeast Asia's largest bank in various corporate banking and capital market roles. After six and a half years at DBS, I moved to Metta at a time when content review, trust and safety as an industry was just exploding. So Metta was hiring very rapidly. The organization kept changing because the needs of the organization were... It was so hard to understand what the future state would look like that we went to frequent reorgs and changes. And during that time, in that uncertainty, what I learned is that people come and go, organizations change. But what really sticks in an organization is a good product that solves a critical business problem. That is what attracted me to product management. And when the opportunity arose, I joined the product team building the platform in which a large outsource content review workforce was doing its work and make sure that content review was done in the best possible way. In the last year, I've joined Monzo. Monzo is a digital bank here in the UK, which is growing really fast and its mission is to make money work for everyone. At Monzo, I also work in the operations collective and this opportunity was incredibly... It was a great opportunity for me because it brought my domain knowledge of banking together with what I learned in product management at Metta all together. So let's move on to the topic for today, which is what you need to think about if you want to ace your first 100 days as a product manager. I'd like to talk about three sets of ideas with you. The first one being how to understand the product deeply, how to understand your ecosystem well. And next, how do you ship your first change? So to understand the product deeply, one of the things that I find very useful is to start with the end in mind. My reason for this is that it's really easy to get lost in lots of data and information overload. And you don't want to be rabbit-holing into the wrong direction. What you want to do is always keep yourself centered and know what is the breadth of things I need to know about before going into the depth of each one of those things. And four questions that I like to think about when I'm trying to understand any new feature or any product at large are what is the problem you're trying to solve? Who are your users? How does the product solve this problem for the users? And if the product or feature wasn't around, how are the users making do? Are they using an alternative product? Are they using an old version of that product? Are they using a spreadsheet or is the process entirely manual and clunky? Now, when you're understanding this, chances are that you're going to be triangulating between talking to people about the problem, reading the documentation and also seeing the data. I would also want to caveat here that in a fast-growing environment, very often documentation is not up to date. And a lot of this information resides in the minds of people as tribal knowledge. And putting this together is going to feel like building a jigsaw puzzle where every conversation and every document gives you one piece, but you're always uncovering the full picture slowly. The place which has a large number of clues is usually the data. And with regards to this, my third point is basically to learn how to use the data self-serve tools as early as you possibly can. You can always get help from your colleagues in fetching some data or dashboards, but the earlier you know how to use it, the more independent you become. And it's incredibly empowering to be able to do this by yourself in your own time and come back and ask the smarter, more detailed questions to the folks you're going to be speaking to. So in summary, start with the end in mind and go through the documents, talk to people, talk to the users, talk to fellow product managers, as well as the data, and triangulate what you see in the data with the documents as well as with the people to make sure you're really understanding the product deeply. The next thing I want to talk to you about is basically making sure that you're incredibly familiar with your new ecosystem, right? And the first thing that's going to come into this is your one-on-one. So right after you finish your company on boarding, you're probably going to be speaking to a slew of people one by one in many conversations. Now, if for anything like me, I have a terrible memory and I forget things pretty fast. What I like to do is constantly take notes and summarize. So before I go into a conversation, I like to think of myself, think about what is the one or two things that you want to take away from that conversation. I often ask this to my stakeholders in one-on-ones that if there's just one or two things you want me to remember in the next one or two months, please tell me what they are. Also would love to understand what are their priorities in the next two to three months. And the reason for this is because when you bring this back to yourself and you're summarizing and understanding things, even in the second and third month, going back to what the priorities of the people were, as they had shared it back then, is so useful in the long run. There are three sets of people you're largely going to be speaking with. The first set is going to be your team or your squad. This could be different things in different companies, and it's possible your company may not be organized that way. But the people I'm talking about are folks you're going to be working with very closely, like your software engineers, your data scientists, data engineers, designers, researchers, key folks in operations who help you deliver change or communicate to your users, folks with who you have to work with to do change governance. You're going to be working with them day in, day out. The second set, when I like to work with the first set of people, I like to understand how long they've been and what their specific developmental goals are or who they are as people. I think a little bit of that social touch is so important because you're forging a relationship that's going to help you over the next few months or even years, potentially. And it's just nice to know them as people. The second piece is basically the senior stakeholders, folks with whom you want to understand what are their priorities for the business, what are their priorities for the product, what are the most exciting things happening in their teams in the last one or two months or in the next few months that they're looking forward to. And it gives you really important clues about how the organization around you and the product around you is changing and what's important to them. The last one is your manager, who's going to be your most important ally in the company. What I like to do is as I like to take these notes, I have a shared document with my manager and I'd like to keep my manager updated with the conversations I'm having so that he or she can guide me into what I should be doing next. And if I'm going in the wrong direction, they can also pull me back out of it and help me reset my focus. The next thing I want to talk about is engaging with your team. And in different organizations, you could have different rituals. But most of the time, it's going to be a shade of a weekly planning, followed by a stand up or frequent meetings during which you update each other about what's happening. Even if your team is working remotely, actually, you could have virtual socials or physical socials. And then the most important over here is basically also having a team retrospective. Product management involves a lot of influence without authority. And sometimes people may not be happy with the way you're making decisions or you may not be happy with how decisions are being made. Or understanding their interactions within the team that are outside of your control and visibility between designers and engineers, between engineers and data scientists, and so on and so forth. You want to make sure that at a regular cadence, the team comes together and there is an opportunity for you to celebrate the wins, understand what is on people's minds, like understand what people are loving and what people are longing for within that team. And that's really useful when you're coming in new because it gives you very vital clues about the team dynamic and what are the places where you need to intervene or make changes or make things more positive and better. The last thing over here that I want to talk about is while you are working hard in understanding everyone, it's important for everyone you're working with to also understand you. Understand the values that are important to you. Understand how you like to receive feedback, how you like to learn stuff, and whether you like to come into meetings super prepared with a pre-read or do you like to jump into a call and understand and troubleshoot problems, whatever, what focus times work for you and what time chat work for you. I think these seem pretty small and simple, but making sure you have a structured way of sharing this with your team so it becomes permanently available to them is also really important because people are going to keep joining your team and people are not going to internalize it the first time, but if it is available for them to take a look at at a later time, that's really great as well. The last thing over here is like we spoke about, you know, your one-on-ones and then engaging with your broader team and then lastly a wider company. If you're a product manager, chances are this is not your first job. You've worked somewhere else before and you need to make you need to switch context and have a reset between your previous place of work and your new place of work. And understand, you know, the tools, the mailing lists, the groups, the calendar invites that you need to be a part of. Understanding the culture of the company and what the company stands for and start seeing that in the product and the people you speak to or ask them what it means to them and get aligned with that because it takes a while to get there. And of course, the most important one, which is goal setting or road mapping. As a product manager, you're likely going to be involved in it or probably even leading it for your team. And in the first 100 days, you'll definitely be in some stage of, you know, completing your goals or starting your goals or thinking about the next half. And understanding how that's done, where that's done, what all documents look like could be very useful for you when you're new to the job as well. The next thing I want to talk about is basically how do you ship your first change? So we spoke about understanding the problem and the product. We also spoke about understanding the people in the ecosystem. And then the last thing, the last idea I want to leave you with is being able to ship your first change. When you join a company as a new product manager, you join with so much of enthusiasm and so much of excitement to do a great job of what you want to do and you're very high on motivation and energy. And you might come in guns blazing, coming in really hot, wanting to make a big change as soon as you come in. I would strongly advise against that. But I would encourage you to make a small, meaningful change like a feature upgrade or something which is directionally moving the product in the right way early on within your first three months. You don't have to do the biggest change. You don't have to do the best change, but you have to do a change which is directionally aligned to where we want to take the product. And the cycle feature development is different in every company, but you want to deeply understand what it is in your company. How is it that problems are identified and opportunities scoped? Where can you write a proposal and share it with folks for feedback? How would you work with your designer to build out an MVP and ship it in the cheapest, most inexpensive way? Experiment it, share experiment results, interview your users, collect feedback from them anecdotally as well as by looking at data. And then how do you go through the change governance and approval process, communication and deployment process? Once you've completed this full cycle and that the very first time you're doing it, it's possible that this could be a little bit clunky. It's possible that your company may have very strict and tight rules and mature processes around each of these things. It's also possible that you don't have a mature process around each of these things and you might be helping build those out, right? But going through the cycle once sets you up for a lot of success. Specifically, within the larger ecosystem, it builds trust that you as a new product manager with a new team are able to ship things in a thoughtful, incredible manner. The second thing it does is that it builds momentum and morale within your squad. You will understand each other's working style and it's very encouraging to ship your very first feature. For you, it could build a lot of confidence in your reinforces your ability to be able to ship new products in your new organization. And you're also very aware of what it means to ship change, which means when you actually go into the next big thing you're about to do, you know exactly where the pitfalls are and how to go about doing it, right? So it sets you up for success for a long period of time. And that's exactly where you want to be at the end of your first 100 days. So in summary, I spoke to you about understanding the product deeply, getting super familiar with the people within your ecosystem and understanding how your ecosystem works. And then thirdly, make your first move by shipping your first change, right? These are the three things I think are useful to remember when you're joining your new job and wanting to achieve within the first 100 days. In closing, I would like to share that it's a hard job to start. It's a lot easier to grow into the job, but when you're starting as a new product manager, you're paddling very hard. And I like using the gif of the swan on the left because it's not just that the swan is flapping its wings and paddling really hard with its legs. And it also has an extra set of robotic arms to make sure that it's getting where it needs to go. And I think that's really important because in the very beginning you have to put in that extra time to get going really fast. That's how I feel until you reach the right, which is the graceful swan, which is going into uncharted waters and looks really smooth. But underneath, it's paddling really hard. And that kind of stays with you through the job, I feel. But when you're moving from the left to the right through the process, be kind to yourself. You could be dealing with a lot of your imposter syndrome and you could be dealing with not knowing enough about the job, but that's okay, right? And also do what you need to do to be resilient, like stay on top of it. If that means getting enough sleep, getting enough exercise, whatever that means for you, you want to make sure that you have the emotional energy and the physical energy to keep up with the new job. And lastly, always remember that you are hired for a reason. Your experience, your knowledge, your fresh perspective and your creativity are your assets. And every product manager brings a new spin to the products that they're developing and the themes that they're leading. And that's what makes it uniquely you. And you want to make sure that you value that and treasure that. So that's all I have for today, folks. Good luck with your job as a product manager. And if you'd like to stay in touch or if you'd like to know more about any of the things I have shared or my experiences so far, feel free to reach out to me on LinkedIn. Thank you very much and have a nice day.