 Hi everybody, my name is Anton. I'm extremely excited to be here and in this webinar I'll talk about what is it like to be a product manager and how to get a job. A really quick disclaimer is that the opinions expressed in this webinar are solely my own and do not express the views of my previous or my current employer. So once we get this out of the way let's talk about what we're going to learn. So first I wanted to focus on the product management 101 to basically walk you through what the product management is all about and the second part we'll speak of what the qualities of the successful product managers are and then if you are trying to get in we'll talk about it, we'll talk of how to get the job. So really quickly of who I am and how I became a product manager. I was born and raised in Ukraine and I moved to the U.S. in 2011. I landed my first job in 2014 and today I work as a director of product at Salesforce. I got into Salesforce through the acquisition. I was actually part of this company called MuleSoft. It's an integration platform company so we help companies to connect different applications together. So if you have a Salesforce in Workday we have an integration platform that makes it easy to make those connections so the applications could exchange data. So I joined that team when we were 300 plus people company and then now I work at Salesforce which is the 50,000 plus company. So now when you know who I am, let's speak about what the product management is. I'll walk you through of what I do, some of the basic principles and to get started I wanted to kick this off with there's this guy Ben Horowitz who basically said that product managers are CEOs of their own product. There was the memo from about 20 years ago when he made that statement and it is a really good quick analogy of what the product managers are. Except the PMs do not have direct reports so many of the product managers work that as an individual contributors and they basically work with the engineering teams and they do not have direct authority of managing people and instead it makes it a little bit harder for influencing and leading the teams to basically rally them into building amazing products. On the left hand side you see this three circles. This is basically if you google of what the product management is. It's basically product management lies on the intersection of the user experience technology and business. So as a PM you really want to deeply understand your users, who they are, what their pain points, what they want, what are the features they don't like. You also need to understand the tech so the core competency of your technology and what you're building and you need to map them up with the business needs and the business value that you're creating. So basically your knowledge is this three circles and your expertise, your experience, what you bring into the table is the understanding of those three mixing them together and distilling things into what we're going to speak about next, into vision, into strategy, into features, beardies, roadmaps and things of that nature. But first there's the market. As product managers we always excited getting into the problem solving right away. There's a lot of passion, there are a lot of creative ideas of how you might be thinking about improving the specific product and I see this mistake always being made during the interviews when we ask the question of hey, how would you improve your product X? People typically dive straight into the problem solving but the thing here is that as PMs we also need to understand the market. We need to understand the competitors in the space, what are the technology trends and basically distill all that knowledge into the business needs and the business value that you're creating. I typically like to suggest starting with reading analyst reviews. There's Forrester, there's Gartner, there's the best sources to read from on the different technologies. This is my to-go place. If there's a new company or there's a new space that I don't know much about this is an amazing place to start. So really start by understanding the market and then craft your vision. Here's a quote from Jeff Bezos who said that you can be stop-born on vision but you can be flexible on details and I do support that your vision is basically your north star. This is where you want to go. This is where the impact that you're making. This is the things that you want to change. This is how you are going to delight the customers to change the industry. That is a very, very big ambitious goal that you want to reach. And then from the vision you basically go into the strategy. This is where you distill all the different components and you start thinking of what are the core competency of my company, of my team and how can I create a value to my business. It is also very important to think about building versus buying or partnering with somebody. Building features is extremely expensive. You have your engineering teams that really can build any type of software but it takes time. So when you think about buying and partnering as a different outlets for realizing certain value, what you bring into the table, it's also an alternative path to get your features to market much faster. So this time to market is very, very important aspect to the strategy because guess what? If you're going to be building all the features yourself and house and you have a limited resources, there might be a competitor that decided to partner with somebody else and got those features much faster and gain all the market adoption before you actually completed your product. Working at Salesforce, I could give one of the examples. There's a Salesforce app exchange where any developer could basically build on top of the Salesforce APIs and alongside Salesforce build compelling experiences. So really think of where and how you can take the shortcuts where you can partner with somebody and drive value instead of building all the things in-house. And building, you're basically focusing on the core competencies that are very difficult to replicate and this is what you're really good at and this is what your team and your business is really, really good at. And vision strategy are basically the market division and the strategy are the first starting points that will basically be if you're getting a job as a PM, will be your 30-60-90, this year kind of onboarding plan. This is where you start, but it's also very important to inform your key stakeholders of what are all those different things that you're planning to do. It's very important to keep them informed. Your stakeholders start with your team, right? So you want to make sure that the team is on board, but there's also the product leadership. There's depending on the size of the company, there might be CEO that you work with directly or indirectly. There's your sales team, you're legal. There are different people that represents those teams and you want to make sure that they are informed of what you are planning on building because they eventually are going to be helping you get that product to market. So now, as a PM, I understand the market. I crafted my product vision. I crafted my strategy. I informed the key stakeholders. What's next? Well, it depends. It depends if you are building the new product. You might have heard terms like zero to one or you're evolving an existing product. If you're starting zero to one, well, obviously you need to start by funding the team, right? You need to hire the people. You need to start prototyping, engaging some design partners, so basically finding customers and users within those customers and bringing them in, understanding their pain points. And instead of building platforms, you actually think, how can I build a solution to meet needs of this specific customer? And then you bring more and more customers in and you're basically trying to think of how you would generalize certain features. But there's also a different type of product management where you basically joined as a PM and there's an existing product and your task is to improve that product. So that type of product management is a little bit different because you would already have a team. The team would kind of be in the execution mode. There's a strategy that might have been defined either by the engineering or previous product manager. So it really depends. But I wanted you to make sure that you kind of understand the different distinctions of building the product from the ground up versus evolving the existing product. But in the core of any execution strategy, you first need to connect with your customers. Understanding the customer's bigger pain points is extremely important. It's basically before you start thinking about the solutions, you really want to go and speak with the customers to make sure that you're understanding the technology space of a set of problems that your customers are dealing with is accurate. And basically, once you build those relationships, what happens is that you go and ideate with your team on the different solutions. You come up with early designs. And what's also very, very important is to build this design partnership with your customers, where once you hear all the different problems that these customers are dealing with is that you can come back to them and basically say like, hey, I think I have some of the solutions. Can I spend 30 minutes with you walking you through and getting your initial thoughts? That early prototyping validation is extremely important because it basically builds certainty, helping you and your team know that you're doing the right thing. And when you go and rally your team all the way to that amazing product, you are actually validated that with the customers and you know that you're building the right thing. And then the fun part begins. You bring your engineering team, your UX, your architects, you start building the PRDs. The PRD stands for Product Requirement Documents. They're basically one of the deliverables of the product managers. That's where you would document how a specific feature will work. But the PRDs itself, it's not a solution to, it's more of a tool that helps you communicate your ideas, the customer needs, the pain points, the use cases back to your teams that are actually going to be building that. I also find things like mock-ups, wide boarding sessions to be very, very helpful to help your teams to actually understand what they need to build. And finally, prototyping. Prototyping is extremely important. Prototype, before you build a product, there are a lot of amazing tools that exist out there. You can basically, as a PM without any single line of code, you can quickly compose a prototype that will help you communicate the ideas to your engineering teams, but also you can use that tool to bring to your customer and basically ask them what they think. Is that what they're looking for? Is that the solution that solves their problem or you might have misunderstood what are the things that they had in mind? So that prototyping early is a very, very important thing that helps your team then take that prototype and polish, improve it. The UX will bring amazing ideas of how the final product should look like. The engineering and the architects would actually put all the infrastructure together. So there's a lot of fun in doing all of this, but again, there are a lot of different tools. One of the tools is writing the product requirement documents, but do not limit yourself with those. There's a lot of amazing other tools that help communicate ideas. Then you go into the prioritization and estimation. You basically have a set of use cases, set of features that you want to build. You would share the PRDs with your engineering teams. Based on those PRDs, they will understand what would it take to build something like that. So then you basically go into this prioritization activity where you have a cost and the value. So the cost is basically what it takes to build a specific feature and the value would be what value you're creating to your customer, to your users. And then you start creatively thinking of like, hey, there might be this very, very amazing feature that brings a lot of value to my customer, but there's also so much work that needs to be done in order for us to chip something like that. So then you kind of go into trade-offs. There might be another feature that is medium value, but it's a very extremely simple to build. So then you start thinking of like, hey, how can I build a roadmap in a way that has a consistent feature delivery to my customers? And basically what happens is that after you went through that prioritization, you build a roadmap, then you take that roadmap and you go to your key stakeholders, you talk to the field, to your marketing teams, to your customers and basically tell them of what's coming. Internally, your field, your marketing, the legal will help you get this out of the door. The stakeholders will be informed so they know what's coming. And basically your customers or early design partners will know what to expect so they would not go and look into another product or start shopping for something else, building this solution in-house. They will know what to expect. Product roadmaps are different depending on the company. You might have companies that basically communicate those things quarterly. You might have product, you might have companies that do not communicate roadmaps at all. Again, it just depends on the nature of the company that you work with. But internally, the roadmaps are extremely important and they basically help align the team on what's coming and helping them rally towards that amazing customer experience that you're planning to deliver. And with all of that, there is basically the execution. This is your day-to-day. This is where you would use agile principles. You would go through, we personally go through two-weekly sprints. We would have daily stand-ups where we come and teammates will speak about what they have done yesterday, what they're planning to do today, and if there's something that is blocking them to realize a specific feature that they're working on. Typically for me, those things will become one of the most important things to figure out and help navigate them as we go throughout the future development. But there's quite a lot when it comes to the execution. These are my three favorite books that I typically recommend to people. The design thinking, this is basically all about the customer problems. And the lean startup and agile, this is on the customer solutions. So this is all about this early prototyping that I've talked about, how you operate, how you plan, how you work with the teams, how you build the small increments of value or MVPs, which are minimum viable products. Read those books. They're absolutely amazing. Highly recommend either for you as a new product management or as an existing PM who haven't read these books yet. And then through all the executions, through all the passion and the energy and love that you gave to these features, you ship them. You ship these features, you give them to customers, but it's also very, very important to measure success. There are things like key performance indicators, or also known as KPIs. Basically, this is a way for you to know that the feature that you have shipped is actually gaining the adoption. So you might be monitoring of how many users are using the feature or how this feature has improved the entire workflow. So for example, if you have a workflow within your product, and it takes maybe 10 minutes for users to navigate it, imagine you decided to change some parts of this experience, and now it takes five minutes for users to do this task. So it's very, very important to establish those things ahead of time. They actually would go into your product requirement documents, but it's also very important to build these things into your product so you can measure success and know that your feature is gaining the adoption that you are looking for. This is also the time when we do a lot of exciting activities that are called the GTM or go to market. We basically do the webinars, we do the blogs, we do the product demos, you will go to the events and speak about the features. So basically, this is where you are a marketer, a sales person, you want to talk to people about this amazing feature that your team has delivered. So this is an amazing activity. The scale of presenting the scale of talking to customers is one of the things that product managers do. This is a very exciting thing and also gives you a very good connection with those customers that basically expecting for other things to come in the future. And then you obviously celebrate, we like to celebrate the new features and their release and you then basically go on the repeat. So you would, again, depending on the company size, you might do these things quarterly where you would take your vision, you would take your strategy, you would think, has there something changed in the market? Is there a new competitor in the space? Is there a company that got acquired by the friend company? If there is anything that changes my strategy, some adjustments that I need to make? And also like if there is a specific feature that took more time to build or, you know, the scope got bigger as you work in with the customer, you also need to incorporate those inputs into the roadmap. So before you kind of go on the repeat, you actually have this quarterly checkpoints where you adjust your plan based on the market, based on the team, based on the customer's feedback, and you would go through that cycle again. So this was the product management 101. Now I wanted to go to second section, which is what is it like to be successful product management? And here, instead of reinventing the wheel, I wanted to quote Todd Jackson, who is the XVP of Dropbox, who basically said that the excellent PMs do three things. They articulate what the winning product looks like. They rally the team to build it, which is extremely hard, because again, in most of the cases of the product management, you are an IC, an individual contributor without the direct authority of managing your engineer and the UX teams. And then you iterate until you get this right. So those are the three things that basically summarize the qualities of an excellent PM. There's leadership. There's the people skills. There's quite a lot that goes in here, but I also wanted to touch on Todd's three things that represent a good PM with a few add-ons. The things that are very, very important to me, and I also have seen this throughout my career, is that different PMs come from different backgrounds. Some come from engineering, some come from support, some come from sales. And when you have a very technical PM, it's an absolutely amazing skill to have. You basically speak the same language with the engineers, and there is an engineer who is not available, but you really need to understand how a specific thing works. You can actually do it yourself. So knowing the superpowers actually helps you as a product manager to leverage those strengths and leverage them in your advantage. As a person who comes from sales, you might be very good with the customer engagements. So that might be your channel. That might be your strength that makes you a good at what you do. Again, different PMs have different qualities. There is quite a lot that goes into this job. So understanding your superpowers and using them in your advantage is definitely one of the keys that I would highly recommend to everybody. The other thing that I typically talk about, and I talk about this with my entire team, I tell it to the guys who I work with from UX, docs, engineering. Being a number one user is a very important mindset to me, because that basically helps you understand the product inside out. Some products that I worked in the past are extremely technical. You basically need to be an engineer who understands the technology inside out and understands the space. And I have seen some UX designers or some product managers that might not necessarily understand all the details. And it might be fine not to understand the semantics of how this product is being built. But what's very, very important for me is to look for all the teammates to be a number one user. This is basically where as a PM, I would go and test the new feature way before it gets shipped to the customers. I would like my documentation people and the UX designers to do exactly the same. So being number one user helps you one to actually have passion and love to what you're building, but also gives you this out of the box thinking into like, hey, I got this customer feedback of this different pain points. How can I think in the way that actually aligns with understanding the entire MTM journey and then tweak only the things that produce the biggest outcome? Choosing the right framework is also very, very important. And it's a good quality of a successful PMs that I have seen. There are a lot of different ideas, but structuring those insights and ideas in the way that is very easy to understand helps you to communicate the message and helps you to align the teams. Things like SWOT, 4Ps, 5Cs, there is a lot of different strategy frameworks. They're kind of your beginning of the journey when you work on the vision strategy and you basically trying to convey a different message to different stakeholders. But there's also this frameworks that help with the team alignment. There are frameworks like OKRs or V2MOMs. V2MOM is close to my heart. We use it at Salesforce. Basically stands for values, vision values, methods, objectives and measures. And basically what we do with this framework is that every single employee in the company writes a V2MOM and it starts with our CEO and it stills down to every single person. And what it helps us to do is to basically align and move to the same direction where as a product manager, I will write my V2MOM and my teams will basically write their V2MOMs and all of us will be driving this feature development, driving the sales, the marketing, all supporting the same thing. And those frameworks are very, very important for the team alignment. And typically I would say the company that is bigger than the company that is bigger than 20 people in size will benefit from this framework quite a lot. Now, if you are new to this, if you're new to product management, let's speak about how to get the job. Again, I mentioned this before. There are different routes. I've seen people coming from different fields. There are people that come from different backgrounds. They transition from engineering. I've seen some PMs that join from support team. There are those that join as insasit PMs from different companies doing different things. I personally didn't have a previous PM experience. I did have my own business that was not in tech and I did spend some time in consulting. So when I joined the tech company, I joined as insasit PM, which is again, yet another way to get started and put your foot in the door. The tips that I typically give people who come to me and basically say like, hey, we really like what you do. We would like to learn more. We would like to join. We want to be a PM. Where do you get started? Well, I think the biggest thing that I personally looking for is there's this passion and integrity and passion could be illustrated very quick by the proactiveness of the individual. And one of the things that I also wanted to point out is that Moss tech companies, they do have referral programs. So basically, as an employee who refers somebody to join the company, if that person gets hired, the employee gets a referral bonus. And it's really important to know that and use that in your advantage. But it's also very important to be mindful, right? So you basically going to be reaching out to people on LinkedIn and saying like, hey, I want to learn more of what you guys do. Could we spend maybe 10, 15 minutes on the call? It's very important to be mindful. So I would recommend reaching out with two, three sentences on the LinkedIn, not writing very long emails and basically be very cautious of everybody's time. People are busy. The other thing that I would say show the passion and show your integrity, do the homework, research the company, all this different things that I've talked about on how the good PMs, they first would go to understand the market, right? So like, don't go straight into the product and, you know, come up with the list of like, hey, here, 10 different improvements that I think we should do. Actually go take a step back, take the outside end view, understand the competitors, maybe take a look at the competitor and what they do in the space. All of that shows the hiring manager that you are doing the right thing, that you're asking the right questions, that you can connect the market trend with their business, with their set of problems. So doing your homework, doing the research, I also like to see the candidates who basically jump in, play around with the product that we hiring for and then they know it. So showing that passion is, it's one of the things that we're looking for and obviously be a good human, be honest, be transparent and show you best qualities you've got. And finally, find a mentor. There is a room to grow no matter what position you hold. Think of the people that you know that inspire you and reach out. I also would suggest be very mindful of their time. So find the projects where you can help them. Basically, if there's something that they are working on, where you can help them drive that thing forward, tell them that you can do it for them and ask for feedback and return. What this creates is this win-win relationship where your mentor will benefit from the work that you do, but in return you will get the feedback that you're looking for. This is the best kind of combination of a theoretical part, but you also do things in practice and you get this instant feedback from the people who inspire you and who you want to become. Finally, read this book before the interview. This is one of my favorite books and I think if you are trying to get a job in one of the big companies, this book describes really, really well how the product management in Facebook differs from the product management in Google or Microsoft. There are a lot of different techniques, frameworks, methodologies. There are also different sets of questions that you would typically have hiring managers ask you during the interview. This book summarizes most of them, so I do highly recommend reading that book if the product interviews is something new that you're going for. With that, thank you very much. Again, my name is Anton. Let's stay in touch. Below is the LinkedIn profile that you can find me by, and good luck on your journey. Thank you.