 All right, good evening. So today, I'm going to be talking about transitioning from engineering management to product management, something that I've done over the last 12 years of my career, but professionally have done over the last three. So a little bit about myself. I studied hardware design. Really loved the lab classes, loved programming chips, from assembly to very long. And that's what kind of kept me going in the electrical engineering path. When I went to industry, though, within the first month, I shit you not, I just did not see myself working as a hardware designer for very long. No offense to any hardware designers out there. All my roommates were computer science majors. And they were all working at startups. And they would tell me about changes that they would make on their product, whatever they were working on. And the next week, 10,000, 100,000, a million people were using that. And it just sounded so exciting. So I just kind of fell in love in terms of the process and that iteration. And again, that goes back to my love for building. And that's kind of what got me into electrical engineering. So one of my roommates was working at Google and was trying to start a company and the online education space prepped me. And I was pretty gung-ho about it. I was like, let me help as much as I can. And so I started learning web development, something that I had never done in any of my studies. I dabbled a little bit, but never really built a full-fledged product. Learned my SQL, Apache, PHP at the time. So this is back in 2005. And we ended up bootstrapping a company and running that for two years. And then we raised it a big Series A. So I learned a ton. And I was always the lead tech on that team, as well as the engineering manager. But while I didn't really know that it was going on, I was actually transitioning to product at the time, like understanding what we need to build and why. So that's sort of my first foray into product management. We ended up selling that company in 2010. And in 2011, I started another company in the financial reward space. Again, a similar story started off as a tech CTO co-founder. But then, at that point, I already realized I was transitioning to product very quickly. But I still used my technical skills to my advantage. When we got acquired by LinkedIn, I was posed with a very hard question, be an engineering manager or be a product manager. I actually took a little bit of time to decide. This was three years ago. And I ended up talking to mentors and figuring out, like, what's my passion or what I wanted to do with my career. And decided that product management was my route. So after two startups, nine years in between those two startups, about four and a half each, moved over officially to product management. Well, other than site projects, I've been rid of single lighter code at work. So it's a little different. I'm also a mentor at 500 startups, giving advice to entrepreneurs. So today's agenda, we're going to go over a few things. Not going to talk about product management as a whole. There's a lot of great content on product school and other things about it. But today, I'm just going to go about shifting your mindset, going from engineering to product management, as well as my top three tips that I really learned over the last three years, especially working at a big company as a product manager, and then transitioning tips. So things that I saw within my own two companies, as well as at LinkedIn, in terms of transitioning over to product management from an engineering role. And then some paths to product. Things that I've seen over the last, actually, more than three years, maybe like the last eight years. And then Q&A. So everybody's seen this diagram. It's a classic diagram. Again, not going to go over this, but I just kind of want to give you a visual of like we're starting over in tech, at least that's where I was, and we shifted over to everything. And that's essentially what product management does. We just do everything reasonably well, not great. Maybe somebody has their forte and some things. Maybe UX, maybe engineering, maybe business, but as a product manager, you're going to have to be well versed and be okay with not being the smartest person in the room for all of these things. Product management is not about making decisions. As much as sometimes people think, you're not deciding between A&B or ABCD. It is really about taking those inputs. And so this is just a clip of the matrix when everybody's going to choose the red pill to go down the rabbit hole. So this is how I see product management. Sorry, this is kind of like going back to what I used to study. It really is just about taking a bunch of signals and synthesizing that and working with little groups and then rolling that up into other bigger groups. So marketing, data science, user research, engineering, design, product execs, your CEO. There's just so many factors that you have to say. And there's just no way, little right way of doing it. And so every company's going to do it their own way and you're going to find your own sort of way of developing. But it really is just about synthesizing those signals. And that's a really good way of me thinking about it because sometimes people go over index on one thing. And I think that's dangerous, right? You over index on design, you over index on engineering, over index on business, you're not going to get the best product over index on users as well. As much as we love to talk to users, sometimes if you over index there, you're not going to be building the right product. So I think this is just kind of the way I kind of picture it and how I tell my advisors or the people that I advise. So when I started off in product development, I always just cared about what I was building and how. I was learning technologies. I was thinking about the new technologies we're going to use and what can make it faster, what's extensible, what speeds up development, sort of the development process. Now there are engineers that I talk to that care about the why. And that's actually great. Actually most engineers that I work with care about why they're building. So I'm not saying that engineers don't care about it. What I'm saying is that product management, it's really more about the what and why you're building this. And so you're over indexing on that part of the world. That's the answer that you're supposed to come up with to help your engineers and your designers figure out what's going on. So again, it's just this whole shifting of mindset of how you think about problems. So this is a little dose of reality. It really hit me hard when I got to LinkedIn because again, 10 years at a startup, very different world. But you're going to have to like to do things that normally most people wouldn't like. Meetings, do you like talking to users? Do you like taking notes? Do you like diving into metrics? Actually I really do like diving into metrics. Do you like setting up and setting up meetings and taking notes and writing product specs or product briefs, however you like to call them? Having discussions. And not just dictating, but having thoughtful discussions where you're trying to convince or trying to get people in the direction where you're going. Some people find those frustrating. Some people thrive all those things. But those are all things that product managers have to do. One thing that I wanted to highlight is, do you like a good enough product or a perfect product? Something that I learned about myself over the last 12 years from like my first company to my second and even now is that I always cared about how I built things as an engineer, but not to the point where I'm going to spend too much time thinking too much about it. Like good enough was it's working, let's go ship it out, see how it's going. Because most likely we're going to have to change it. So spending too much time building it and building it and then refactoring it again. Those are the types of things that I found myself like not wanting to do. And I realized that the engineers that I was working with, the ones that I hired or the ones that I'm working with right now, like that's their passion. Their passion is building great, like fundamental great engineering product. That's just, I mean, that's just not how I was built. And again, that's just the mindset that I think most of the great product managers I've met have because at the end of the day, you're building for the user, you're building your product, you're not building the engineering part. Unless you're like an API startup, I get it. Speed is, if you're going to build a product that is mostly just here towards engineering, but most products that we're talking about here are consumer based products or SaaS products. So this is a little bit of a translation, maybe a little too rudimentary, but wanted to just kind of map, like at least my thinking before and now how my thinking is now. So before I would write code, now I do specs. We had code commits and we discussed how we would do things. Now I have Google Docs, like I live on Google Docs. I love creating a Google Doc, like a one pager, two pager, and just start adding people onto that from marketing to data science to get their input. Just have that conversation asynchronously on that doc. So it's kind of like my way of doing review board for those who are familiar with that or GitHub. As an engineer, you're talking to your immediate team, but as a product manager, you're talking to your immediate team plus users, plus marketing, plus legal. There's a lot of things that's under your responsibility where sometimes for some engineers would not want to talk to legal. They're just like, well, or marketing, but you're gonna have to do that. So there's no escaping that. So again, just fair warning. Again, this is all about the transition between engineering and product. Just trying to highlight a lot of the big parts and big hurdles. Again, how you think about this, and I touched on this earlier. How does this system scale? Does this system scale well? Actually, product managers generally won't care about that. I mean, they should if there's a option A and option B are drastically different. And obviously you talk to your engineer manager and you figure out, hey, how can we make the best decision going forward? You don't wanna put yourself in a whole two months later or a month later. But you really care about how does this product scale. And then you care about the metrics, not about how well the system is performing. Again, these are just easy translations. Just kind of want to set the table on how a product manager thinks and how an engineer manager or engineer thinks. So starting with my top three tips. Telling a story. This is actually something that I didn't really learn until I got to LinkedIn. As a founder, that's what you're supposed to be doing all the time. And so that's fine, I understood that. But at LinkedIn, even the smallest of things have to have a reason. And you're gonna have to start collecting those reasons and proving them. And the way you prove them, sort of like your arsenal and your arsenal of facts is from the direction of where your company's going, like from product exec or from your team organization direction to user research to data. So you really have to have those reasons. Again, engineers care where they're going with the product. And you're supposed to supply that answer. So, but not just in an answer where we're doing this because of this. We're doing this, and then here are the reasons why these are the user stories. These are the verbatims from customers. This is the product strategy. This is the data. So it really is just about taking all those signals and then crafting a story, getting people excited about what your project is about. And once you could get that, I mean, you know, you could start getting more engineers. You can get more resources and then, you know, you can start delivering a better product and more of their time and their commitment. So that's a team buy and then exec support. So that actually is something that is very familiar to me in terms of raising money. So in the first company and in the second company we raised a total of three rounds. And, you know, it's really odd, you know, when somebody asked me, so what's the transition from being a founder to being a product manager? I'm like, not that much. You know, you go pitch execs with sort of your vision, your story based on data, based on user research, based on the company goals, based on where you are with your product, and they give you resources. So it's just like a VC where you pitch them your story and exactly why you're doing it and then they'll give you money which gets you resources. So when we need, you know, five more engineers and a data scientist and another designer on our team, like there really needs to be a reason for that. And it really starts with, you know, you as a product manager are selling not just your team but your boss. And then your boss can communicate that and hopefully you get a present in front of execs to get your case across or maybe he'll do it for you. But either way, I think this is one of the most important things that I learned that, you know, that my first six months at LinkedIn, I was really just executing and really just saying, wow, these are like really obvious things. Like we should be doing this. And I would convince people at small groups. But again, and this actually goes to my, actually my third point, which is communication. But another point is be nice, be understanding, be a diplomat. Again, it's not about making decisions, it's about getting the whole team involved. And you want to have everybody in sync. Everybody sort of helping you make the decision so you guys are moving as a group. Again, engineering, design, data science, marketing, sales, they all have their own perspectives. They all have their own frameworks of thinking. Your framework of thinking is combining all of these things and making the best decision or at least directing the conversation to get to that decision. They're going to be making the best decision they have from their own framework of thinking. So also understanding that is super important. Again, the two startups, we didn't have this type of resources. So again, if you're applying to big startups or big companies with these types of resources, it's just super helpful to think about like that other person on the table. Because they see you as somebody who can decide. And so just reaching over and just kind of making sure that they're heard is the most important thing for your relationship. Because sometimes you're going to need them and sometimes they're going to need you and it's just great to have a great relationship with them. Because of timelines, maybe there's disagreements. And also at a big company like LinkedIn, there's cross team collaboration. So I work on the messaging team and there is some product that we need to have happen in the fee team for instance or on the notification team. Like as long as we have a good relationship with them and we've done something for them, they've done something for us, like the next time it comes to that, like they will help you there. Like if you're kind of like too narrow focused on your own team and when they ask you for a favor, you don't oblige. Like it's going to come back and bite you again because you have to be as diplomatic as possible. And not actually us to every request, but within reason. And again, different motivations for the different teams. So going back to this topic, communication. Again, something that I did not learn at my startups. So small, everybody sort of knows what's going on already but at a big company or even a medium-sized company, communication is absolutely key. And I'm sure you've heard of this, but like my first six months, almost to the first year, I really didn't do this for a while. I didn't know the CC game and like adding people, removing people to have a conversation, not making sure you're not going to ask a hard question in front of execs or in front of other people that could get them a little embarrassed or defensive. It really is a skill. And it is something that you guys may already have, but I just want to highlight as something that is super important to being a really good product manager is over communication. Not just in the email world, but a Slack channel. You could think of your product requirements, your docs as a good communication as well as just giving people updates. Because if you don't email people with what you're doing, especially in these big companies, they're not going to know what you're doing. And nobody's going to do it for you. And maybe your boss can do it for you, but chances are they're busy doing some other things. And they're not just managing you, they're managing like three other teams. So it's actually very important to get this right so that you not just get visibility, but it's also great for celebration. And if you do have a win, and that can hopefully go to another win and then get more resources and get your project into a better state. So some of my transition tips. So these are things that I've seen as well as that I would have liked to have seen from some of the startups that I've mentored and my own startups. I think that if you help your product managers now by just doing some simple things, could be, how many people are here are engineers? Wow, the majority. Most of this content is for both, for everybody, applicable for everybody. But if you are an engineer, I think there are just easy ones that you can start doing right now to start helping your product manager. And you could always identify as a product manager, you could always identify the engineers who are product focused. Because they're the ones who give out the suggestions. There's one who goes the extra mile to try to go for those stretch goals in terms of the product. And I definitely notice that I can see that. And all the engineers that I've ever hired and my companies were all generally product focused. I could trust them with a lot of the product decisions. You know, the small ones and even the some of the big ones. And it really is, like if they want to transition to product management, I would be in favor of it. Some people don't. Obviously you guys are here because you want to. But I think just knowing the metrics, knowing the product and going above and beyond is like super important. So that's one thing you can do like right now and start just giving those hints. The next thing you could do is having a conversation with either your engineer manager or with your CEO if you're at a small company. Now this is hard, because if one of, like I'm just thinking of my own start, if one of the engineers wants to transition product, I'm like, well, we only have like six. Like I can't lose one. But I think if you're not in a rush, I think that transition actually could be really beneficial for both parties. And the reason I'm saying this, and I say this as for smaller startups and even like medium sized startups, because when you're in a small startup, you want people who are product focused. You want everybody thinking either of growth or the users. And if you have an engineering lead or engineer who wants to take that mantle, you know, who is typically for the founder because most of the time we're not hiring product managers, it's a really good opportunity to grow into that. So again, this transition may take a year or two as the team grows, and then they need a product manager, you're the perfect fit. Again, it could be something of a transition time, but it's definitely worth thinking about, because again, in both my companies and even now, if I saw that, I can see that transition happening quite easily. But expect pushback, it's not gonna happen immediately. And if you start, I mean, if you do have timelines and you do want to switch over now, then you could have that conversation and if it doesn't go well, then you can find a new home. You can go to another startup, you can go to another big company, you can make that explicit. I actually would make it if you're working at a startup and startups again, would love to have PMs or actually engineers who can contribute that are partially working as a PM, maybe like 30% of the time. Again, people, I would love that. I had designers who were engineers and designers, absolutely great because as a startup, you're always looking for people who wear many hats. Another tip that I have here is for engineers who are working on backend products at big companies or even at small companies, the best type of experience that you can get is building front-end development. And I know that sometimes that could be seen as HTML and CSS, oh, that's not as technical as what I was working on. But again, product management is really about building a product, building something for the users, working with designers and the best way of doing that, like literally like you're hand-in-hand with a product manager is being a front-end developer either on the web or on mobile. So I would heavily suggest people switching over because you'll learn a ton about product development, about building products and you just start thinking about it more hours of your day. Because remember, you spend eight hours or 10 hours of your day at work and if you're not doing something to improve that, I mean, you're just gonna do it at night and that's great but if you could start just using the majority of your day thinking about products and building products like that and then also helping with product management once you're on those teams, I think you're gonna be setting yourself up for an easy transition within the team. So paths to product. So I've gone over my three tips in terms of what I've learned and I've gone over some three transition tips for engineers but these are the three paths that I've seen from easiest to hardest in terms of product management. So the easiest ones I've seen is and the ones that I've seen most often are product managers from startups. I'm not gonna say that startups are desperate but there is just a ton of startups out there and again, like I said, if you can both give value as an engineer and as a product manager, I think that's actually even better. So going to those types of companies, series seed maybe is a lot tougher. You're probably gonna have to commit to being an engineer for at least one to two years. Series A, B and C, most likely a year, maybe less if you make it explicit. But again, you can start working on product immediately and startups really want to have people with domain knowledge of their product. So if you're there working as an engineer, especially if they don't have any product managers like most series seed and series A don't have product managers. So it's a really good opportunity, one to get to know the product but to get to know the people, your team, the execs out there and just really build a relationship. The only con is that early seed stage, like I said, may want to have engineers instead. So again, it's all about your transition time and you want to have a two-year transition, you want a year transition, you just want to apply. I'd have to say that applying, and I've done interviews for the last three years at LinkedIn, applying directly from an engineering position, like a straight-up engineering position to a product manager, like it's really tough. It's really tough. And again, this is why product school exists because it's just so hard, it's like a chicken or egg problem. How do you get into product management if you don't have any product manager experience? How do you get product manager experience if you can't get a job as a product manager? So it's extremely tough. And that's why I think that the transition, if you find an early-stage startup, you make it explicit, you don't make it explicit, is one of the easier transitions I've seen out there. A big company transition. Also doable, I've seen this. You could start working on product, you could do all those things that I said before. You can talk to your engineering manager, and at LinkedIn, you need an executive sponsor. So that makes it slightly difficult, slightly more difficult. And you're competing against a lot of experienced candidates because all of the experienced candidates want to go work at big companies because of the perks and the upward mobility and the fact that you can learn from a ton of different product managers and products that you can work on. So that's why I say it's a little bit less more competitive, even though there's, well, I don't know if there's more big companies, there's probably more smaller companies. I just think that there's just a ton more applicants and applicants with a lot of experience. So I don't do the first set of filtering of the resumes. I assume that they're filtering out some of them because I've only seen people with experience in product management when I interview them. So just a fair warning. But it is possible. This is something new. I have never heard of this before until like a year ago. It's a rotational product manager program. These are awesome. You don't need experience. You don't need to be a new grad. And obviously a great place to learn in those two companies. The only issue is when I tried to do my research, these are the only two I found. Maybe you guys could do better than I could. So I could assume that they're highly competitive as well. Again, just from the sheer number of applicants and the number of companies out there. But I just thought this was exciting because to me, product managers should come from every type of background. Obviously this is for engineers, but I don't think it matters where you come from in terms of your experience. So excited about these programs. I listed them as third because I think that nobody here is still in school. So this next one is not gonna be applicable. But there are a ton of APM programs. So if you're still in school, you probably have a leg up because there's just a boatload of APM programs and LinkedIn has one. And there's just, when I searched, there was just too many. So these are just a name a few and Kleiner Perkins actually has a product fellow that they just place you in one of their portfolio companies. Still highly competitive, but just from the sheer number. Again, my only guesstimation here is that they're easier to get into. But if you're not a new grad, you're out of luck here. MBAs, I do see my fair share. Some companies like, love MBAs. Some of them don't. I think at LinkedIn, we do like it. We don't keep it as a requirement. But I've seen a lot of MBAs at LinkedIn. And I think the advantage here is that you almost start afresh. It's almost like going to school again. Because then there's all these APM programs or MBA product internships. So then you get like a new chance to apply. But even from competitive programs and all the programs I've seen, it's not a guarantee. So this is expensive. This is time consuming. I don't suggest this unless you really want, I mean it will kind of head your bets because you'll most likely get the job somewhere. But going into product, it's kind of a bet. Again, why it's listed fifth here. Just because of the cost, time as well as not guarantee. I think you'd have just as good of a chance if not better going to a startup. Way better, sorry. And then the last one is building a company. This is by far the hardest one. But I think it's the best learning experience out there. I can't stress it enough. Anybody I've interviewed who has started a company at LinkedIn, it's almost, when I talk to them, it's just the way they think the experience they've had because they just basically had to live and breathe this for one to three years. And those have been more experienced even if I've interviewed somebody with five years' experience as a product manager at different companies. So you're just really getting a load of information. The harder part is that it's really hard to get funding. And these are very tough incubators to get into, although YC is not an incubator. And it's risky. So let's just say you don't get funding and you want to go do this on your own. Again, it's kind of like getting an MBA. You're gonna have to spend a little bit of your savings, maybe a year's worth of your savings and try to take that risk. Again, it's a great learning experience, but it's also a huge risk. And it's not a guarantee if your product doesn't go past a side project. So I've seen side projects a ton. They're working full time and they have these side projects. Yes, you get to learn a lot, but I don't know. Just it's not as in depth because you're not spending eight to 10 hours of your day. You're spending one to two hours of your day. So you really need to get past a side project and work on it full time. Really devote a lot of time. So I really think that this is a good way of learning, but again, it is the hardest and I think the riskiest. So I've done this and I've done this because the first time I started a company, I was 22 years old and I was paying rent of $450 in a room and Mountain View. And then the second time I was just, I was fortunate to be able to do it because I already had that experience and I had some money saved up. So I think that's sort of my path and my, or at least the past and some of the kind of advice that I have in terms of past product transition tips as well as my own tips from being a product manager at a big company. Some things to sort of follow and read. Ken Norton and Julie Zhao, amazing content. They are, Ken Norton is not a product manager now, but used to be at Google. Julie is a product manager or VP product, I think at Facebook, I think she's a VP. But her tweets, it's just awesome. Other PMs that turned into VC because apparently that is a thing. Our Josh Ellman, Hunter Walk and Chris Dixon, again great, there's just a ton. These are just my top five. And then some reading here, which I'm sure you guys have all heard, but these are some of the great books about building product. And then that first one is about cracking and then obviously the product school book, which I unfortunately didn't put on here, but very good as well. So yeah, just read up as much as you can and I would say just start building and going out there. So how many people here work at startups or small companies? Awesome, how many people work at big companies? All right, how many people are not engineers? Okay, awesome. So I think that's about it. I'm happy to answer any question. I'm just trying to be as helpful as possible and give you any of my advice from my experience. Yeah, that's a great question. So when I said you're not supposed to make any decisions, I meant that you're not supposed to make any decisions for other people or other stakeholders. You're supposed to take in all those inputs and typically, or not typically, but sometimes there are disagreements and that's where you're supposed to help guide the discussion and hopefully get everybody on the same page so that you don't have to make that hard call. I've only had to make some hard calls where two teams or two groups or two, whatever, are completely disagreeing and we just have to make a call. I'm going to actually through that right now and it's tough and actually I'm not the decider here. So it's between me and another team and it's tough because I think we both have our perspective, we both have sort of all our inputs saying one thing and they have all their inputs saying another and at some point somebody else is going to have to make that decision. So those happen so rarely, actually, our VPs actually want us to show them more. Like they're saying we can't all be working this harmoniously together. There should be more disagreements because he wants to make more decisions or at least hear out what some of the things are happening. So that's where we just do something called the clean escalation where two members of generally of the product team will write up a doc together about the pros and cons of making a decision or building a product or whatever. And then that way that everything's written out. You sort of have your arguments, their arguments and sort of everything's laid out and then the executive or the VP will kind of read that and sometimes they'll have a meeting and then they'll kind of make a call. Those are like the decision and that's at a really high level, at a really macro level, at a micro level within your own team that could also happen. Like marketing could say one thing and then design or engineering wants to do another thing for whatever reason. So you're sort of doing that same thing but like the buck stops at you to make sort of those kind of, not decisions but get sort of consensus between the two teams and really dig into like why people are saying of what they're saying. And really it's just, it's really, it really goes back to the motivations. Like you have to understand like what people are trying to do. And again, maybe something, advice that I could take on my own is like trying to get those clean escalation documents written within my own team. Just so that like the marketing and engineering could like write it together. Maybe something I could try. Yeah. And the software engineer. Can you say that one more time? From the software engineer, right? So did you see anyone in the software company that didn't know how to go to earth and like it's not allowed for them? And who's still an engineer? Yeah, a different type of thing. Yeah, yeah, I've seen that before. I mean, if you're thinking of hardware, I've seen that at obviously hardware startups. So I made that transition, but my transition went to software after my hardware. Actually, now that I think about it a lot, there are a lot of EE, my EE fellows when we graduated that are now product managers. Actually two of them are on at LinkedIn. Like they graduated a year above me or year below me. And I think it does happen. So I guess your question is like, how do you make those transitions one and two without having to learn a new skill? I would say go to a smaller startup that is within your field. And there is gonna be something like a product manager role. And so that's probably the best transition. I think a lot of what we do has, I wouldn't say little. I would say a lot of what we do is interpersonal and sort of helping flow the decision making process. There is a lot of domain experience that is necessary. And so in those cases actually, I failed to put this up, it's like working on side projects. So if you are working at a hardware company and you make it into a PM organ, your passion is in software, consumer products. Build a side project. So you go in, and I've seen this before from people I interviewed, they'll come in from Cisco or other hardware companies. And then they'll say, we worked on these two side projects, me and these other two people. And this is what we did. And just put it on your resume. This is what we did. This is what we launched. We put it on the App Store. I will download the app. I'm looking at the resume, I'm downloading the app. So hopefully it works, because there's been a lot of times where I download the app and it's not working. I can't log in. And so I'll ask them, hey, what happened here? I watched your little video and I wanna understand more of how you were thinking about this product. And it really just starts the conversation. And I would say a lot of the resumes that we have, even with experience, still have those side projects. Again, I failed to put that on here. Sorry, my mistake. But again, that's a great way of making yourself stand out. And it's not hard, it's free. You just have to build something. Yeah, sorry. So the question was, how would an engineer from a hardware background that works at a hardware company get a job at a consumer facing a company as a PM? And you can make that transition to product management maybe fairly easy in a hardware company. But having then side projects that you can put in the app store or launch as a website is actually really, really helpful. Because really what I do in terms of interviewing is try to understand what you were building, why, what problem you were trying to solve, like how are you gonna make money? How are you gonna get users? So all those product questions that would come along with if you were just to work at like, let's just say Yelp or something. Like I would ask those same questions, but in this case, I could just ask. And the best thing is that you probably know every single answer to those questions. So it makes that conversation really easily. Yeah. My question is, do those resumes actually get, I was assuming that they get pretty tired because they don't work in a very good way. They're like, I understand it's not that because they don't look at work people. But in bigger companies, do those resumes actually make it seem like Cisco example? Yeah, so I have not seen, like and I wanna just emphasize this again. I have just repeat the question. So he said, does the resumes filter through to interviewers for people who have hardware, who work at hardware companies that don't have that experience and do those resumes come to me? I would say no. And the reason is that I've only interviewed people with at least two to three years of experience. And the people who have no experience are usually just like fresh grads. And again, this is that chicken or egg problem. Like how do you get a job in PM if you can't get a job if you don't have experience? So again, product school is great, but I don't think it's enough. You're gonna have to help yourself transition into a product role within your own company even at the hardware. And I'm sure they have product managers that do very similar jobs and think about similar problems. And again, what I was mentioning in the previous question was that once you are in that product management role, at a hardware company, work on side projects. Cause those are free. You can start building a product and then launching it, build a couple of products. Maybe you'll get some traction. Maybe you won't, but you just put those in your resume, put them at as high as possible because those are actually like really, really fruitful discussions that we can have that help me understand how you think about building a product. And I understand it takes some time and it takes some, maybe money if you're not a good designer or maybe you can design it yourself. But again, those are ways that you can help stand out. Yeah. Yeah. I think it's an add-on. I definitely don't think it's a critical piece. And the reason why I think it's an add-on is that as part of the MBA, you're not actually really learning how to build product. You're really learning about decision-making and you're learning how to think more broadly, which is part of that Venn diagram, right? It's the business part. It's understanding and then touching a little bit, but you're really just talking about one part of it. So I think it's an add-on. I think it's actually very useful for engineers because if you have an engineering background and you go to get an MBA, it does help round out like those two parts of those diagrams, right? Again, getting those side projects and then building a product, it will help you with the UX and the UI. But I don't think it's prerequisite, but I think it's a nice add-on. It's expensive and time-consuming, though. Yes. So the question was about domain knowledge and product manager's having that domain knowledge and how easy is it to transition from one company to another company, right? So I think that question is, it's just dependent on the company. I think there are some companies that want product managers that can do anything because it's really just the way you think, the way you think about problems, the way you break down problems, the way you work with other teams. So if you think about like Google or Facebook or LinkedIn, like they want people who they can put in messaging, they want people who they can put in some sort of like B2B part of LinkedIn. So I don't think it's a requirement to have domain knowledge. I think for smaller startups, it would be really good to have that domain knowledge because there's nowhere else to put you. They would prefer that. And then in some cases, these big companies would like to have domain knowledge if they want to hire a very senior or director-level product manager. But generally, like when I talked to other product managers like at LinkedIn, like the reason why we're here is that we can go from one product to another product and we're doing our rotation. And you'll see that at Facebook, you'll see that at Google. It's just learning about a different ecosystem, like ad space. Like I don't know that much about the ad space. I'm sure I can learn, but I just don't right now. I know how to build engaging consumer products. I don't know that much about SaaS products. I mean, I know enough, but I don't know, I've never done it. I don't really have that ingrained in me. So it'd be really hard for me to be a director of product or like a senior product manager at a SaaS company or an ads company. So again, that's where the domain knowledge when you go to startups plays in big. Yes. So the question was how do you know, how do you learn about business and legal? You know, when you don't really get taught that. I think you don't, you never know about legal. You have to hire a lawyer. And that's why they make a lot of money. They are very expensive at startups and at big companies as well. I think it's just understanding when you need to talk to legal. And we have open office hours with our legal department. And generally from small things, I wouldn't go to them. But if I have any sort of hint that I need to talk to legal, I'll sign up for the office hours and we'll talk. And then I'll understand more and more about what requires a legal component. It's really just pattern matching and understanding. And the business component, I think the way I learned it when you specifically asked about my background, just by, you know, quitting my job and doing startups. I think, you know, you start understanding like, you know, building the product isn't the like, building the code or writing the code is not the most important thing. It's about building the product and that is for users to use and then to pay for. So then you start really thinking about the business. So it's really just about experience. And in terms of some of the examples that I've given, if you could help your product manager, if you're an engineer that works with a product manager, think about these things. And like write up a one page doc. Don't write up long like, you know, essays on like what you should do next. Like we always talk about one pager because product managers generally are lazy. And we just want like a one pager that like kind of explains like our view of the world. And if you could help start doing that and then help and then obviously have a conversation, you can start learning as much as you can from the product manager you work with. Hi, email. So the question was in terms of communicating and overcommuting, what sort of tools do I use? Email, unfortunately, is still number one. Slack is great if I need a question answered, but really it's just about communicating to large groups of people, putting the distribution list out and just say, hey listen, our team ramped this. These are the results. These are what we're working on next. And you know, here are some links to some of our docs. Then following up that with like two weeks later or a month later with an update. Like people love updates and you know, you learn this from starting a company, your VCs want updates. They would like monthly updates. So it's again, it's very mirror to my experience as an entrepreneur, but you know, I learned that the hard way because I thought that this would be done for me and I would only have to worry about my own team. So it's really about communicating with your own team and outside your team. Yes. So the question is, do people that have graduated two years, one or two years ago still qualify? That's a good question. I don't know the answer. It may be dependent per company. I know at LinkedIn you have to still be a student. Oh right, how does an resume look for an APM? Really all of, I and I, it's APM season right now at LinkedIn and I've done like six in the last two weeks. Every single one of them had a side project or started an organization or was pro, I mean it's kind of like just getting into college, right? Like you can't just show like your classes and your grade point average. Sometimes if it's really, really good, but most of the times they want to see like your interest in building a product. Hopefully, and this is again something else that I've seen too, you already have a product management internship somewhere because all of the ones that I've reviewed over the last two weeks have a product PM roll internship for like three to four months. Yes here. The question was when you talk about side projects and you're building a product, does it mean that you have to code it or can you hire somebody else? I will ask who built this and I've interviewed people and they'll say I had my friend help me with this or I paid somebody to do this. I don't think it matters because as a product manager you're not building it but as long as you can answer those questions about why you're building this, what decisions you made and you know exactly how everything was done and you're really driving every product decision and company decision. I think you're totally fine. Yes. One of the slides about the Facebook. Yes. So I think I'm an example of that actually but I've been operating to you based on my domain experience actually. For the rotational program? I'm sorry? For the rotational program? No, just the product management. Okay, awesome. The first round and all that so that's only because of the domain experience. Right. What do I expect when I meet the second panel which is basically the product management itself that don't have any product management experience but somehow it will be all for the industry? Right. What do I expect as part of the interview or even get a job, how easy it is for each and every? Yeah, so there is a lot of content out there. One of the best pieces of content is actually from product school. It was the Uber, it was the guy from Uber who said cracking the inner product management interview with the guy from Uber. I don't know how old it was but I think it's actually the most viewed product school video. That's a great from soup to nuts again. I can't answer that question in a minute but there are some resources out there. Just at the high level is that we wanna know how you think. We wanna understand how you communicate and also how you have this habit, be a conversation. And how you think is really about taking all those signals and then coming up with the right thing, or not the right thing to do but what you think the right thing to do is. Yes. Is there any engineering mindset in the throwaway of the department? Sorry. Is there any engineering mindset that you throw away when you're being a product manager? Yeah, I mentioned one of them which is learning that perfect doesn't matter. And it actually applies to both engineering and design because designers love to craft their product which is fine. And engineers love to craft their product. I like to craft my story but at the end of the day like it's really about building. So I think that's the biggest thing that I would say that is that you would need to drop from building. The other thing which I had to learn my first six months going from engineering manager slash CTO and making generally like I said I worked on product decisions but I was still so involved in the decision-making on the engineering part like letting that go. Cause again, you know, you don't need to worry about the engineering part as much. Like yes, of course if they'll say well this thing takes 10 months and this one will take one week or whatever, for example, you wanna understand why but trying to stay away from well how about you do it this way or I built it this way why don't you go ahead and design the system that way. Like that's when you start going into their territory. And again, it's really about having that good relationship with your partners. Yes, you. So the question is transitioning over to another team within the same company but is a different sort of different domain. Okay. So I would say the best way of doing it and this happens to me quite a bit at LinkedIn is I would get other people from other departments to set up a coffee and I think you should just do the same but not just the product managers within that team or around those teams. The marketers or the sales or whoever. What other teams that that product manager or that product group has to work with to start having try to understand more of like why they're making decisions or how they're making decisions and get your name out there. Cause then not only will you learn but they'll also get to know you better and then that can also help with the transition.