 And without further ado, go for Sean's side. Hi, I'm Sean. Just a bit of background. I started my career at Google in the associate product manager program. I was there for two years. After that, I decided to do my own startups. I set up that. We did that for about two and a half years before we got acquired by GoDaddy. So I was there for about two and a half years again. And then I decided to join a startup scene again. So I actually joined one out here in New York called Dresser. It's still a sort of a, can you hear? Did I move this up? Just speak louder. OK. So I joined the startup called Dresser. It's still in stealth right now. So I can't really talk too much about it, but we're doing fashion AI. So today, the topic is product management at big companies versus startups. Just a quick show of who's working as a product manager right now. OK, about 15. And big company product manager? And the rest are startup I'm assuming. OK. I wanted to talk about four differences today. I have two slides per difference. The first slide will conceptually explain what the difference is. And the second slide will give some examples to elaborate on the concept. We'll go through these. And then after that, we can have Q&A session. Just a bit of context before I jump into the first difference. As you know, the roles and responsibilities of a PM depends on many factors. The company size is one factor. But the market, the type of product, the size of your team, whether it's a product or service, the senior already of your position, all of that factors into it. So please remember that. Keep that in mind as I talk about these differences tonight because I'll be generalizing a bit. So the first difference, what I like to call the average flying altitude, 10,000 feet versus one foot. As a product manager, you're expected to fly at different altitudes. And when I say altitude, I'm talking about the granularity of perspective. So at a high altitude of 10,000 feet, you are operating with this strategic perspective. So especially if you're at a startup and especially if you're at a pre-product market fit stage startup, your day-to-day operation is largely strategic. You're thinking about how to find your fit within the market. You're thinking about the landscape, how the technologies will shape your landscape in the future, your strategy and goals for the upcoming years. If you're working for a large company, you also have to think about other teams' priorities, your company's priorities, all of that. So that's sort of strategic perspective that you have. And that's what I like to call flying high. At a lower altitude, you're sort of worrying about the intricate details of your product. So the implementation perspective is what you should have. And getting the user experience right, the UI right, and managing your backlog, fixing your box, and launching things, all of that is sort of the implementation perspective. So a couple of examples to illustrate my point. When I was at GoDaddy, I worked on this product called Search Engine Visibility. It was their SEO product. I'm sure you know GoDaddy. You've heard of it. We're very famous for Super Bowl ads that we ran a number of years ago. We're leaders in domain registration and hosting. Very few people know that we're trying to get into the website builder and digital marketing services as well. I was part of that organization. So the idea is that you buy the domain from GoDaddy, you buy hosting from GoDaddy, but then you would build out your website using GoDaddy technology. And then you also do digital marketing of your website using GoDaddy technology. So it makes sense. They're trying to provide the end to end solution for small medium business owners. And I was pretty excited when I joined this team. I was told that if you're the owner of the product, you get to set your own strategies and goals. So I was like, yeah, let's do it. But then I soon realized that it came with a certain number of constraints. There were already company level, strategic goals, OKRs. And then even within my department, the website building product was a much larger product. So it was already decided that when all the other smaller digital marketing products would be launched as part of the website building product, it wouldn't be an integration into it, which made sense. I was happy about it because as a product manager, I didn't have to really worry about acquiring users after we launched. I already had an on-ramp through this product. But regardless of whether I was happy or not about that plan, there was not much room for me to fly it on high altitude. There was no very little room for strategic thinking, if you know what I mean. Now in contrast, when I was doing my own startup, Canary Calendar, this was our third major pivot, by the way. It was an iPhone calendar app with smart scheduling functionality. And as you can imagine, we were in this constant phase of testing our hypothesis, trying to see what sticks in the market, trying to find our fit in the market. And we were actually dreaming of being able to fly at a lower altitude, if that makes sense. We were dreaming of being able to optimize on metrics instead of constantly thinking about strategic things, finding our market fit, all of that. So yeah, that's the contrast between the big and small companies. One small site, no caveat, is that when I was working for my own startup, I was also coding. I was working as a front end engineer as well. And as you can imagine, if you're an engineer, you're flying very low in terms of your implementation perspective, you're actually building out the product. So I was in a situation where I had to sort of switch back and forth between altitudes. So I was coding, flying very low in terms of altitudes. But then I had to sort of step back and think about where we're going, think about our strategy and fit and all of that. And what I realized rather quickly was that if you do that rapidly enough, you become so inefficient. Like no one, I like to think that I wasn't the only person who was incapable of doing this. But in order for you to sort of switch between these modes, it requires a lot of time for you to sort of adjust your perspective. So just one tip, if you ever find yourself in a position where you have to sort of switch modes like this, I would recommend that you don't do it so rapidly. So the second difference is scaffolding size. Fortress versus ladder. When you build a structure, you need scaffolding. If you have too little, it might be dangerous for you. It might not be efficient for you. If you have too much, then it just becomes a structure of its own. It could get in the way of you building the actual structure, right? So stating the very obvious, you need just the right amount. Generally speaking, at a smaller company, you don't have enough scaffolding. You don't have enough structure. As the company size grows, you tend to have some scaffolding here and there that you may not need. So when I joined Google for the first time, I was really excited, not because of the free food or the certain level of prestige that comes from it, but project management tools, methodologies, testing and release cycle, those were all established. Like the scaffolding was already complete. Clear role definition. They have very clear role definition. So if I had a question, if I had an issue, I knew exactly whom to go to. They had a very clear role definition for product managers, so I knew what I was doing and other people knew what my role was. In contrast, when I joined my current company, I was an investor, it's a small startup. When I first joined, they didn't have any product managers, so they didn't have any of that. They didn't have an agreed upon project management tools, methodologies, release cycle, testing cycle, there was all sort of ad hoc. So there was an opportunity for me to set something up, but I found myself in a situation where I had to wear many hats, which is fine, but then I was in this interesting position where I had to sort of justify my own existence. Now, to be fair, a product manager has to do that in annual organization, I believe, but it was a sort of an extreme case for me. I think it's partly because we had a lot of people joining from the fashion industry and they weren't really familiar with the way we go about building products and they didn't really understand what a product manager was for, but then I had to really carve out an area of sort of expertise and ownership and sort of tell people, this is wine here, this is what I'm supposed to be doing, let me help you do it. So that was a sort of an interesting learning that I took away. Caveat here, side note here, is that there's no one-size-fits-all scaffolding, kind of obvious again, but what I mean by that is when I implemented the agile practice within Dresser, I immediately went back to my experience at GoDaddy. We had a really efficiently running strum implementation at GoDaddy with my team. So I was like, okay, work perfectly with my GoDaddy team, I'll just bring that over to Dresser and we'll be fine. We did that for about a month or two and then I realized strum isn't really agile at all, like that's what I realized. It actually takes a lot of effort and time to implement that and practice that properly. So I realized strum was just wrong for us and that's what I mean by this, there's no one-size-fits-all. So I had to sort of develop a version of that that would meet the requirements of our team. We ended up implementing a hybrid model somewhere between strum and kanban, but it's working for us now. Now the third difference is coordination communication for the lack of better analogy here. I'm using first states versus weddings. If you guys can think of better analogy, please let me know after the talk. But what I mean by that is, hopefully you're going out on more first states than you're having weddings in your life, right? The frequency might be higher, but the level of coordination and communication required to set up first states is much lower than planning a wedding, right? So startup coordination and communication at startups is like setting up first states. You may need more frequent communication because you're usually flying at a higher altitude. You're having that sort of strategic perspective and that requires more frequent communication and coordination, but that also means that the information size can be small because it's very abstract. In contrast, at bigger companies, you might not be meeting as frequently, but because you're flying at a lower altitude with all the implementation perspective you have to have on it, all the intricacies of your product details, the information size is big. And a couple of examples. So when I was at Google, the meetings would usually be weekly. When we were leading up to launches, we would have more frequent sync ups for sure, but usually meetings were weekly. And when we would have these meetings, they were very low in abstraction. So the agenda was set prior to the meeting. I would send it out prior to the meeting. We would have the meeting. I would take notes during the meeting. There would be a clear set of action items by the end of the meeting. I would send it out to everyone. And we would all understand, remember and recall what we talked about in the meeting. It was easy. I should say it was easier. In contrast, when I was working for my own startup, we had daily coordination because remember we're flying at a high altitude, things are more abstract. An interesting thing here was that, I don't know if you've ever found yourself in these situations, but we would talk about an idea. We would talk about, you have a question? So I was at Google seven years ago and each team had their own versions of project management methods. My second team did have a version of Scrum, but I can't speak for the entire Google as a company right now. I don't know. My guess is yes. It has to be, but yeah, I can't really speak on behalf of them right now. It's been a while. Anyone from Google? No? Okay. But I would bet a lot of money that they are doing a form of Scrum, right? It has to be agile. So we would talk about an idea. We would talk about a hypothesis that we would test and we would really get excited about it. When you think of a cool new idea, at first you're really excited and then you think about it a bit more and then you're really disappointed. It's not gonna work out. So we would agree on an idea. We would get excited and then we would walk away. The meeting would end. And then we would reconvene after maybe, I don't know, 24 hours, 48 hours. And the interesting finding was that oftentimes these abstract ideas sort of branch out in different directions in different people's minds. By the time you reconvene after 24 to 48 hours, which is not a lot of time, you have completely different versions of these ideas and abstractions. So we realized that and we were like, okay, we can't operate like this obviously. And because we were talking about ideas that are so high in abstraction, it didn't really make sense for us to document everything to the extent where it would be crystal clear for everyone. So our answer was that, okay, we need to meet much more frequently. So that's sort of the difference. The caveat here is for big companies managing up is a huge part of coordination, I'm sure you know. And what I mean by that is, as a PM at bigger companies, carving out sort of areas of specialty and ownership for your team and sort of telling the rest of the company and your leadership about what you're doing, your sort of progress and achievement, that takes a lot of time and coordination. So we have to keep that in mind as well. So that's the difference. The last difference, team momentum now versus later. When I sort of think about team momentum at a startup, you know, agreeing on an idea or hypothesis that you wanna test might be a difficult process, but when you actually agree on something that you wanna test, the implementation phase can actually be really enjoyable, like it's fun. You're doing your tech startup because you like building things and when you actually get to build something, it's fun for you. So there's a lot of momentum. But then comes the launch time and you realize, you know, even if you build it, they won't necessarily come automatically, right? And then you sort of start to lose momentum because you have to sort of really think about how to get users, how to onboard users and everything. Compared to that, at bigger companies, you have a lot of sort of internal hoops that you have to go through when you try to implement anything, right? But then, you know, in many cases, because you already have a large base of pre-existing users, you have sort of on-ramps that you can leverage when you launch your features and products. So after launch, the momentum tends to be higher. Again, I'm generalizing here. So again, at GoDaddy, when I was working on SCD, we had this one feature. We decided that it was a good feature. So we prioritized it. We built it. We tested it. It was ready to go. But then it took us more than a year to launch that thing. It was completely ready to go, but it took us more than a year to launch because it was all the internal constraints that we had to sort of overcome. Technical integration constraints, legal accounting, we had to meet with them. There were a lot of sort of politics involved as well. I'm sure, as you can imagine, resourcing. Other team that we had to rely on for this launch, their priorities would change. Company priorities would change. We would get sort of deprioritized. So we had to wait a year. When we did finally launch this, it was great. The team felt good about it. Users were loving it. But the momentum already sort of, the momentum only picked up once we sort of launched. Until that point, it was a lot of sort of hassle that we had to sort of go through. As opposed to that, within Canary, I already sort of explained it. Once you sort of decide what you want to build, we had a lot of sort of excitement fondring the sort of implementation phase, but then it would all come crashing down when we launched because we realized we had to sort of go out and get users. We would repeat that. So yes, those are basically the four differences. And yeah, again, just keep in mind that, this is generalization. A lot of factors sort of go into the nature of PM work and company sizes when you're one of them. I hope you learned something from this. Should I take questions now? Yeah, yeah. So I guess, I probably wouldn't call GoDaddy startup anymore, especially since they have IPO'd, but they had something like 4,000 employees and they weren't an order of magnitude bigger than your startup, it sounds like. So as the company grows, unfortunately, I haven't been in a situation where company grew so rapidly, it had to sort of change its way of doing things from the release cycles and project management sort of methodologies and everything. But I would think that there has to be sort of an adaptation period and process in place. I'm not sure if I'm answering your question, but is there anything specific that you want me to speak to? I would constantly question how much scaffolding, just to use my own analogy here, I would constantly question how much scaffolding you have and whether that is too much or too little for your current situation, that's what I would do. If it seems like your CEO is just trying to operate at a pace where it doesn't make sense for the size that you have right now, maybe it means you just need a little bit more scaffolding to stabilize everything. If it's the other way around, maybe you need to sort of simplify things. But that's what I would try to concentrate on, yeah. To from what kind of personality trades or job satisfaction trades you have to have to be happy, be successful at the big company versus the startup, like who fits better in one versus the other? Which one do you think you fit better in? I'll answer the second question first. I change every two years as demonstrated by my pattern of going from Google startup, GoDaddy startup. So if you're forcing me to choose one, I can't. I think if you ever work for a startup, there is sort of inherent certain level of chaos and uncertainty that comes from it. If you're okay with it, like you're gonna have a lot of fun, right? On the other hand, big companies, they do provide stability, but unless you're one of the lucky few, 2% of the company, you may not be working on the most exciting projects at the company. And if you're okay with that, then the stability factor might work out for you. So I think those are, I'm sure there are many, many other differences, but I think stability versus like really sort of being excited about the level of impact you might have. I think those are sort of the pros and cons. Yeah, and was it, did I answer your question? Personality traits? Yeah. Yeah, I think risk averseness, I think really comes down to that. So have you ever worked for a startup? Yeah, for sure, all the time, all the time. Yeah, I mean, people don't really realize that. And in my case, I know I'm gonna get bored after a certain number of years at a big company. And then I also know that after a certain number of uncertainty at a startup, and not so high sort of paychecks, that I'm gonna sort of long for this ability and sort of bigger paychecks. So like I go back and forth, and I've seen that in my friends as well. There are extreme cases where some people can't just don't sort of manage to adapt to the big company lifestyle and then they just sort of quit. Not for the purpose of joining a startup because if they wanna work on startups, but just for the purpose of sort of not wanting to do that anymore. There are cases like that. But if I may add, I think if you're a starting PM, and this may not be part of your question, so pardon me if I'm just like speaking additionally here, but I think if you are a starting PM, there's a lot of benefits to starting your career at a bigger company because they have way better structure in helping you sort of grow as a PM to understand what you're supposed to be doing as a PM. If I actually joined my current startup dresser as like a sort of a new PM, I think I would be lost. Like there's like no one to handhold me, like I have to figure everything out. It's just so much chaos there. And certain level of sort of surety that comes from your leadership is affected by the number of years of experience, I believe. So working for a big company does provide you with the training. And that's what I would recommend anyway, yeah. Yes. Good question. Do you guys, have you seen the... What do they call it? The Valley of Despair or something of Despair, the graph? And it goes something like, you're super excited about your startup idea, but then you implement it, no one's sort of using it, so you just get depressed. And then slowly usage picks up and then if you are a successful startup, you keep growing. Exactly, right? So, and it's not like a one dip, you go through this, right? And that's what I mean when I say, you have to be okay with that level of uncertainty. Yeah, I think it actually might come down to your personality. I think there are some people who may not choose to sort of go through for the sake of keeping their stability. I'm not actually sure if that's something that you can sort of work on to improve upon and get better at, but some people are just more okay with uncertainty. They're sort of better at dealing with sort of emotional ups and downs. So I would really sort of ask introspectively, am I that person, can I handle that? If the answer is yes, I think startup is the answer for you, but have you ever worked at a startup? You'll go a lot of, I mean, like for me, even like throughout the week, on Monday I might be really happy, Tuesday I might be depressed, right? So you might get better at it, but I think you really have to sort of decide for yourself if your personality matches the lifestyle of the startup, sort of the emotional ups and downs that will accompany the lifestyle of startups. Oh, sorry, yeah. So I don't quite understand your momentum in your startup. So I never really worked in an industry where we don't have that at launch point. I don't quite understand why the momentum would start to go down to a big company that doesn't have a customer at launch. Yeah, no, I mean. I think you were both faced with similar challenges. Yeah, that's true. I mean, that's why I sort of said this is generalization. Probably doesn't work in every situation, but I was saying that the chances are that bigger company would have pre-existing customer base that they can tap into. So if you're launching a feature and if you're able to leverage that, the momentum would be easier for the momentum to pick up after launch when compared to the startup situation. Does that answer the question? Okay. I think part of the reason why we're already thinking operationally in advance before the launch and exactly how which particular in this case is gonna have a higher adoption rate. So yes, customers are there, like knowing how the momentum is going to pick up, that kind of thinking already goes in advance. But actually, I wanted to, based on that, I wanted to ask you a question. Do you think that startups or, do you see a trend where startups are starting to embrace the experience of a product manager from a big company and trying to attract that talent so that, as you said, chaos is there. So kind of defuse the chaos and build a little bit of structure. Do you see that kind of trend happening? I see that a little bit and I don't know if, I still haven't decided if it's a difference between San Francisco and New York or if it's the fact that I'm working for kind of a fashion company or fashion AI. So, but they wanted a product manager without understanding what a product manager would do exactly. So I thought that was very interesting. They wanted more structure, more sort of order and method to the way they were doing things. That's why they wanted product managers. But I felt like after I joined, I was like, I don't know if they actually know what I'm supposed to be doing. That's why I said I had to sort of carve out my own areas of sort of ownership and expertise. But I think I see the startup scene sort of picking up on the importance of having sort of good product managers to lead the sort of the strategic decisions of products. So I see more and more sort of roles popping up in that scene as maybe compared to a few years ago. But that's my sort of perspective. I don't know if that's actually happening. Yeah. Yeah, so we had a big meeting with all the engineering leads, myself, the design lead, and our CEO. And we're talking about what tools to use, what sort of cycle to use. Okay. So, sorry. Okay, I'll speak up. Yeah. Okay, the question was basically like how did I sort of implement the scrum process at Dresser, right? At my current company. And I was explaining that we had to sort of get all the leads together and decide on what tools to use, what the release cycle would be, what methodology to use. So as I told you, I initially tried to bring over the scrum process that I used at GoDaddy at a bigger company to Dresser. And it didn't work out because the number of hours required to make scrum process work efficiently is not insignificant. And at a start up where things are changing so rapidly and a lot of the time people are just like running around so busy, expecting people, especially the engineering leads, to dedicate three, four hours every sprint and really sort of tracking how we're building things was too much. So that's why we decided it's not working. So we decided, okay, so if not scrum, what can we do? We switched over to sort of Kanban process where it was sort of a rolling list of tasks that we had to complete. But then we would still have sort of sprints. Like every two weeks we would meet and sort of assess where we are and things like that. That's why there was a sort of a hybrid version. Yeah, for a few months. But they had their own, so we had one team that was working on sort of the technology side of it. The other team that was working on the infrastructure. So there was no real need to come up with a process that would involve both teams at the time. When I joined, we actually set it to need that process so that's why sort of implemented it, implemented the version of it. So the product design engineering teams understood because they actually come from product backgrounds, right? So I had no issue with my engineering teams, my design teams, but again, we had a lot of people joining us from the fashion industry. I had to sort of explain to them what I'm here, why I'm here for all of that. Yeah, yes. Is there any, from a product manager perspective, is there any thoughts or consideration that the legal or Reuters should have in mind when talking to their product managers in terms of not stifling or seeming condescending or not wanting to get the idea off the ground, but also helping us be more effective and efficient so that the product can launch effectively? And if that strategy would be different at a big company versus for an in-house lawyer at a big company or for a lawyer who also has clients who want to be startups? Yeah, yeah, so in a startup, hopefully you're not talking to the lawyers too much. Like hopefully you're taking the approach of, what do they say, don't ask for permission, ask for forgiveness later. I mean, at least that seems to you the mantra of Silicon Valley and how startups there operate. When it comes to big companies, the struggle can be real. Like you wanna launch something exciting and cool, but legal team might say no, right? So I think it's a compromise and I think it's case by case really. Luckily in my case, like they were more than willing to sort of help, they were sort of more than willing to understand what we're trying to do. So they really worked with us on that instead of just saying no, it's not gonna work. And I think that's very important. Just trying to get to the core of the value proposition. That way you might say no to a certain implementation of a solution, but you might have other ideas of getting there. Yeah, yeah, but I think I really appreciate it when a lawyer that I'm talking to and legal department that I'm talking to sort of understands the core of what we're trying to do. So even though when they, they might say no, that specific implementation is not gonna work for legal reasons, but how about this, right? I've been in situations. That's not at all, that's not. No, not at all, no. I mean, you know, if you get offended by that, I think you have to sort of change your attitude, I think, as a product manager. But I don't think that's overstepping at all. You're just simply providing an alternative way by which legal constraints will no longer be an issue for the product team, right? So I think that's totally fine. Appreciate it. Yeah. Switch jobs. You mentioned that there's a difference between a product company. How would you say there would be a difference with preparing for those job roles or interviews? Interviews. I mean, if you sort of research online and read these PM interview books, I think you will notice that some of the companies have very specific ways of testing your PM skills. So like, for example, Google will ask you technical questions, I believe. It was the case seven years ago. And there are specific sort of types of problem solving questions that certain companies will ask, right? So I would actually prepare specifically for that company. If it's like a well-known big company and you can actually research for that company. Startups not as structured, but a lot of these well-funded startups, they have people coming from these big companies. So they're influenced by the culture of those big companies, right? So they will actually know, even if they don't have product managers, the engineers and designers will know how to interview for product managers or how to interview the potential product managers, right? So I think it's really similar, but when it comes to startups, you can't really do a lot of research because the chances are, you know, so like when it comes to big companies, if it's a well-known company, I would recommend that you do some sort of specific research for that company, sort of PM interviewing processes and types of questions, but startups really similar, but I don't think you can sort of specifically prepare for them, yeah, yeah. I think going off of that, what about product, people who want to be product managers who may not necessarily have technical background? I think Google tends to hire more technical people, but I think, for example, Amazon can, you can get in without technical background. What about for those who don't have technical background? Yeah, I read an article that Amazon is hiring all the MBAs in the world, right? I know Google has MBA, PM hire programs, I don't think they will ask technical questions there, so I would look for those roles, specific roles that wouldn't require technical background. I can't think of any other companies that would actually require you to have a technical background for all their PM positions, like, apart from Google, like Facebook doesn't do that, they do general interviews. Can you think of any? What about for like a startup? Yeah. Obviously it depends on the startup, but do you, and it depends on what product, specific products you're working on. Did I just answer my question? Yeah, I mean, it depends on the, I mean, so like, I like to think that there are like, three different types of PM. You can be a technical PM, you can be a very design-oriented PM, and you can be very business-oriented, right? There might be more categories depending on how you look at it and who's looking at it, but there are opportunities for all three types of PMs, if you wanna work at Google, the chances are you might have to, not only have a technical background, but like you need a specific degree, I believe, right? Like, it's not enough for you to prove that you can code, like they actually require you to have like a technical degree. So like there's very little you can do about that, right? But I think most other companies don't have the requirements, I would look for those opportunities. Again, like there are very sort of business-oriented and UI and design-oriented PM roles. So if one of those, if you think you can be one of those, I think I would sort of try to build my skillset towards those opportunities. Yeah, for like three months before I started, yes. Nevermind, I was gonna ask, how do you think that experience has aligned with? It's a very sad story, I don't know if I wanna... So I joined IBM, so I grew up in New Zealand, and it was 2009, right? So all the companies were basically canceling their projects and downsizing because of the market crash here. That's when I joined IBM. So like I joined the company, but they didn't have anything for me to do. I don't know if I should be telling you these guys this, but anyway, I very quickly started looking for another job. That's why I found the Google opportunity in the United States. Yes. No, no, no, I mean, that was my own startup, and I'm an engineer by trade basically, I have a technical background, so I always intended to code. That's something I wanted to do. So I wasn't forced into the situation. So if I remember correctly, and if there are any strong sort of masters in the room, please correct me if I'm getting this incorrect. Product owner is not a position, it's a role. So like no one hires product owners. If they're hiring product owners, there's something wrong with them, in my opinion. So a product manager is usually the product owner. Where it makes sense, they can put the lead engineer in charge of being the product owner. It can be a project manager that becomes a product owner. But I don't believe, at least in terms of how strum defines that product owner is not a sort of separate position, but it's sort of the role you take on. Same as the strum master. Like you don't hire a separate strum master for your engineering team. Usually the engineering lead becomes a strum master. And you sort of lead your engineering team through your sprints. Product owner, again, should be the person who knows about the product and the market the most, in my opinion. And that usually has to be the product manager, again, in my opinion. If that person is not the product manager, there's something wrong with the product manager, in my opinion. So I think in most cases, product manager should be the product owner by default. But where you, I don't know. In some cases where that may not make sense, or maybe you don't have a product manager dedicated to your team, it can be someone else. Yeah, basically. So we don't use the term product owner, but I'm basically the owner of the products. There's equity plan. What's the question again? I'm sorry. Business owner and product owner, for your own idea. I mean, if you are the founder, by default, you're kind of both to begin with. As you grow and as you have more capital and more people to help out, I would delegate to someone else. But if your question is, is it possible? My answer would be like, you have no choice. Like you have to do it anyway, right? You have to make it possible. So by definition, yes, it should be possible. But yeah, I mean, as your team grows, I would definitely sort of try to have sort of specific role requirements for everyone. Does that answer your question? Okay. Google head program managers, yes. So, I mean, if it's between those two, definitely the engineering team. So I think literally every organization will have different definitions on product manager, program manager, project manager. I think Microsoft actually calls their product managers, program managers. I think at Google, like if you are an owner of a product, then you're a product manager. But if you're without a product, it can be a program, right? It can be, and I'm an example here, but if it's not a user-facing product per se, like there are program managers who oversee sort of these initiatives, right? So they may not be working so, and this is probably case by case too, but in general they may not be working so closely with the engineering team, not necessarily. But by definition, each product manager should have their own sort of engineering team that they're working with, at least at Google. So the question was like, what's the difference between APM and the normal PMs at Google? Do you guys know the story of how APM program came to be? So Mercia Mayer, who was the first female engineer at Google, basically set up the APM program. And the logic behind it was that they couldn't hire great PMs fast enough as the company was growing. So they decided, what the heck, let's get some college graduates, put them through this two-year program and see what happens. I think that's how the program started and they've been doing it ever since. To my surprise, we are not treated any differently. Like, the day you walk in, you're expected to own the product the same way as any other product managers. Of course, people will help you, but the idea, at least from, the idea was always, you hire the right people, yell at them for two years and they'll turn you to great product managers. Like, there was some motivation behind it, as I understand it. So there's very little difference between you. No shadowing. They just put me in charge of a thing and I was doing it and I was scared. Yeah, right, right. I think the perspective, the altitude that I talked about, I think that will definitely adjust. Like, I'm flying pretty high these days, talking about strategic sort of perspectives that I have to sort of have on a day-to-day basis that will probably go away if I join a really big company. I will have very specific thing, highly likely to be a small part of a product that I will own, right? So I will be having more of an implementation perspective. So I think I'll have to sort of readjust myself there. I also talked about sort of having to manage up as a product manager, making sure that your team has its own area of specialty and ownership. Like, I think that's a product manager's job to do that for your team in a big company, also making sure your leaders and the rest of the company is aware of what your team is doing, sort of telling them about it, bragging about it. I think that's a big part of it. So I think that's something that I have to sort of work on as well. Right, yeah, I think it's an adjustment for sure, yeah. Any other questions? Yeah? One more, last one. I probably could give several talks on this topic. Let's do this. Have you, and I'm gonna butcher this, but have you seen this Quora article? And I'm trying to remember who wrote it. I think it was, so go to Quora and literally search for that, of best traits of PM. And there is a really popular article that keeps popping up at the top, that lists six to seven different traits of a great PM. And I don't feel like I have enough time right now. Which ones did you have that made you successful? I don't know if I'm successful just yet, but as a product manager, you're supposed to have, some of the things, even some of the things that I talked about today, you're supposed to have both the high level perspective in terms of your product vision, strategy, market, everything, but at the same time, you need to understand sort of intricate details. You have to have the ability to sort of communicate across your vision to the rest of the team, the rest of the company, to your leaders, all of that sort of communication is very important. Execution, being able to sort of launch, build, preferably on time, that's also important. There's so many different things, I would actually recommend that you look it up, because I'm not gonna do any justice to that question if I start speaking right now in detail, yeah.