 weekly YouTube live like yours to have a conversation with others. I think it's much more fun. Sorry. Oh, there we go. Good. My Yeti picked up. What did you say? Weekly like? I said, welcome to our YouTube YouTube, weekly YouTube live. I said every week, I should do this style. It's more fun. But I don't know why it's not linked to the right thing. Let me check. I see my team didn't link it. It says live. Can you see me live? It should be live. This is delay. This is delay. So I was live. Okay, cool. Hey, guys. Yes. I was like, it's not even live. Cool. We have a special guest today. Let me play one minute countdown timer. Cool. So welcome, guys. Hello. Hello. And we have everybody here. Welcome. Okay. All right. Hey, guys. This is Dr. Nian C. Lee. Welcome. Welcome to our weekly YouTube live today. We have a special guest, which is Ben. And Ben is also the owner of a brand which is called Seattle Data Guy. He's a very popular brand on LinkedIn. He also has his own YouTube channel. Quick introduction regarding what we plan to do today. And quick introduction. Hey, if you haven't, it's the first time you come to our channel. This is Dr. Nian C. Lee. And I am a director of product featured in Forbes and have helped 100 people blend the Dream PM job offer in fan companies, a unicorn startup and continue to get promoted as a product leader. Every Wednesday, we try to provide some free coaching to teach people how you're able to actually advance your career as a product manager or even break into product management. And today, we do want to welcome our guest as well. I do like your cat. Ben, I think he can stay. Yeah. And so I started chatting with Ben and I started to change the style of our YouTube live, start bringing more guests. And because I believe it's much more fun to have a third-party conversation and also share with you guys the real life experience. What does it look like to work with part managers from different functions? So behind scene stories is also very valuable and especially Ben himself, years of experience working as a data engineer, working for meta. He knows the insider, inside out of different big tech companies, how can they use data to make data-driven decisions build amazing product and from the engineering perspective. And of course, he also has his own data consulting company and very excited to learn about all the adventures he had, of course, very, very popular YouTube channel. Everyone should just follow him, just search Seattle data guy and find on LinkedIn or just find out in the description this video with hacking in all our posts. You should be able to find him. Awesome. So let's do this without further ado. Let's talk about today's topic, which is how the product managers actually work with data engineers together to build amazing product. So Ben, can you quickly introduce yourself? I've been making lots of introductions. Why don't you quickly introduce yourself? And then we jump into today's topic. At the same time, people will comment on the chat whoever is here, come and say hi in the chat, what's your name, where you're from, and what specific questions you have regarding data and product management and the combination between both. Okay. So Ben, yeah, turn it over to you. So tell us more about your background. Yeah. Yeah. I mean, I think you covered some of it, but yeah, I've been working in data engineering for the last, I think like eight or nine years at this point. Originally started working at like a hospital and then a healthcare startup, Facebook. And then all throughout that time, I'd been consulting at the same time. And so at this point, I'm just consulting and helping companies either set up their data infrastructure, set up their day strategy, kind of help them move forward, you know, so they can get the most out of their data. So that's my current focus. Awesome. So Ben, let's dive deeper regarding how the relationship between data engineers and PM work has changed throughout different experience you have, because you already work for a smaller company regarding you mentioned in the healthcare startup all the way to the one of the biggest tech companies. So can you tell us how the radiation had changed between small companies and big companies between data engineers and product managers? Sure. Sure. I mean, I think overall, at smaller companies, you know, the relationship generally was a little tighter, I think. And to some degree, I think that's because at this specific company, the product and the data engineering were very interconnected in terms of like what we did was directly going into the product. So instead of like generally at some companies where data engineering might just be part of the process of collecting data that then informs, you know, product managers, which features are doing well or things of that nature. In this case, the literal product was often being supported by the data engineers. So like the work that I was doing was actually being put into the product itself. So I think that was like one of the key differences is like, well, the actual product here, we're not just trying to gain information about the product. This is the product, right? And so I think that was kind of the key difference. To some degree, that could be more of the company that I work for, unless of the difference. Are you saying that when you're working for startups, your closer to product was able to really directly influence the product even much closer compared with when you're working for Meta? Am I right? Did I interpret correctly? Yeah, I think that's true. I think the other thing that was different was that the data engineering that I was doing, like the stuff I was building was literally going into the product itself. Whereas generally a lot of times your work done as a data engineer is tracking features that software engineers have created. So creating whatever pipelines to track whatever software engineers have created that then just goes to data scientists. And then data scientists use that to kind of inform their discussions with product managers. Can you tell us the differences between data engineer and data scientist? I personally was really confused about those two terms. I saw one person can play both roles, but through our sign conversation before this talk, looks like they are doing something slightly different. Can you tell us the differences? Sure. And I think for a while, there was definitely this expectation that data scientists do everything. When the role came around, it was also the era of Hadoop and a lot of things that were changing in the data management space. So there was this expectation that data scientists would both do Hadoop-type work as well as their data science work. And I think that's kind of when people realized it's really hard to do both. And so they ended up kind of specializing, whether it was on purpose or on accident, they kind of became this natural bifurcation between data scientists and data engineers. So data engineers shouldn't be the people who build and own the data sets that then data scientists use and rely on. That way, there's a little more focus on what's actually getting done. So which means, for example, the latest all the AI talk track regarding Cheshire BT is in the news every single day. And myself also use it a lot. I also make several YouTube videos about it. So if we talk about data scientists trying to leverage data to create like those machine learning algorithms, do you think they're more towards how we use data, which data scientists, not data engineering? Am I right? All the AI stuff is more science. Yeah. I mean, it's definitely more on top of that. Behind that, there are obviously somehow storing that data and accessing that data. And that could be a data engineer. It would depend on how they're actually storing the data. They might just be storing it like in some form of raw form. But my guess is they've done some level of like pre-processing. Like you've done training. They've done all this stuff where they're collecting all this metadata, and then that metadata gets stored somewhere. So that as you're building and testing out that model, you can use that efficiently and easily. So yeah. Very cool. Can you give us specific examples? For example, I think it's easier for the audience. Most of my audience are more PMs. We're not very hacky, but the easier to make it down for us. For example, use some product as an example. Some say what you describe if I interpret correctly. For example, one of the products I launched in the past, which when I spoke on your YouTube channel last week regarding the product use AI, which is machine learning, machine vision to help reduce car crashes, basic smart camera, detect the movement of cars, pedestrians, and figure out when they're about to hit a pedestrian and doing the like action predictions. So all of this, it began with metadata, like collecting, this is the car, this is a pedestrian, and this is also biker, and this is a crosswalk. Those are like metadata we collect. And then we actually at the time when we designed the architecture, we like locally store them. The analytics actually happened on the edge, which inside a smart camera, and then turned into metadata, which equals to, hey, this is like this pixel size equals to a car with confidence of 95% likely something like this is the car. And then with this geographical location, and then it happened to be on a crosswalk equals to this is not safe. And those are metadata, and then we send it to the cloud. You saying that from the data engineers perspective, you guys are the ones who decide how to create those metadata was a format of the metadata. Would we store a store in the cloud store in the edge or sending them between those two places? Is that am I am I right at the data engineer? Yeah, to some degree, that might be something we take on. Nowadays, there's been a further specialization in like things like MLOps. Thinking back to that example, and I talked about like building like a data product, you know, what that product did was like a lot of fraud detection in healthcare and things like that. So we had someone that was essentially our data scientist who, who like built the models. And then they handed like, like they did the research, they kind of like figured out what it should be. And then they ended up handing it to us. And, you know, it wasn't ready to go into production yet, like I was like, okay, here's what it should do. And then we implemented it, right? I think there's definitely been a further specialization there where it's like, yeah, now, you know, data engineers don't necessarily do as much model deployment and figuring out exactly like all how features should be stored. Things as much now you've got MLOps and people are more machine learning engineers. We'll take that on. But that's generally what happens, like generally data scientists, depending on the company, but a lot of data scientists do a lot of research. And then they'll kind of talk about their findings. And then some sort of someone that's more on the engineering side, whether it's a data engineer, an ML engineer will likely implement that and figure out how to store it and figure out how it should actually, you know, be operating in real life. Perfect. We, when we teach students, we always use like case studies. Would you be able to tell a specific case that may be a matter? Or your healthcare company, either one, either one to find whatever you feel comfortable sharing without telling too much confidential information, just high level use cases, right? In this case, I'm a data engineer and working with ABCD product. What's my day-to-day look like? I do this and this and this. And then I hand over the data to you this and this. And then when does PM actually come into picture? Can you give us a case that you give us some overview? And for people who actually in and put in comment in the chat, feel free to continue to put your questions here. I'm going to get back to you guys. I see Chris here, Leo. Hey, UG and Anchik. Are you guys, I see your questions here. We'll get back to you guys later. Feel free to put your questions here. Okay. So Ben, yes. Let us know, like specific case studies. So it's easier for people to digest. Yeah, I'm trying to think if there's like a specific sample. I mean, besides, besides the healthcare startup, I mean, at Facebook. Or you can use the healthcare startup either way is fine. Sure. Sure. Thinking through the healthcare startup. Again, like we built several products there. I think while I was there, we built, I don't see the two or three. I don't remember which one it was. I have to like my resume. So yeah, we built several products. And in both cases, like, you know, we kind of had this whole process where first, like, you know, oftentimes, essentially our PM would talk with our stakeholders. For example, we built something for like opioid tracking, tracking like how much people were prescribing opioids to see if there were like people that were over prescribing it. So we could, you know, obviously crack down on that. So, you know, our PM would talk to our stakeholders as well as like professionals in the field. So like actual doctors and dentists and be like, all right, like, what, what, what should I see what's normal to kind of understand what's, what's important, you know, what's important, what should we be reporting on? How should we be reporting on it? Like what would be useful? So they kind of gathered a ton of information. And at the same time, while they were doing that, our data scientists and kind of data and data engineering were kind of working together to prove out that we could basically meet some of these needs. So like stakeholders like we'd like, we'd love to see whatever some sort of heat map of like where over prescription happens. And like, okay, can we do that? Do we have the data for that? Like, do we need to get more data? So we would like go back and do a quick analysis, the data scientists might like, you know, put together some numbers. We might start putting together either some baseline dashboards based off those numbers and just proving that like, yes, this is possible based off the data that we can do. And so I think that's kind of like that first step is like figuring out, okay, what do you what do people want? And then what can actually be done based off the data that we do have for the specific product? And so then after we've kind of like gone through that cycle and been like, okay, we can kind of prove this. And on top of that, not only is it possible, but it's actually useful. Because I think that's the other thing. It's like, well, okay, it's possible. But maybe every like, if you were to put it on a heat map, and look at like whatever average prescription per county, it's the same for every county that's not useful. And so also like, you know, you're going to this that level of like, okay, is this actually useful? If I was an end user. So we kind of went through some cycles with the PM, the data scientists, you know, us as the data engineers, as we're trying to figure out like exactly what things should look for look like. And then once we've kind of like, I think set all that up, then we kind of develop, you know, your project plan, we think like, well, what's the end goal? Like, how do we want to launch this feature? Okay, this is our feature. This is how we launch. We kind of just move backwards from that. It's like, okay, what we'll need to get built to build this whole, you know, kind of product. And then just again, going backwards, and then essentially, we'll kind of develop from there. But that was kind of the general process of how we worked with the PM and that product. In this case, it was probably more similar to that of like a software engineer, I think, whereas like, you know, you might be testing and building products versus I think traditional, again, traditional data engineering at a large thing, you're likely, I like to say, you're kind of the middle child in the world. Well, you know, like the software engineers get to build things based off what the PM says, the data scientists kind of get a demand the data that they want. And data engineers just kind of have to give both people whatever that will make them happy. The software engineers just do what they want. They'll add new columns, they'll add new features, which impact your data model. And then the data scientists will want to analyze those new features, or maybe they want to analyze all features, but then the data's, you know, removed because the software engineers have removed it. So usually in large organizations, you're definitely a little more of like this middle child or you just kind of have to accept that you are the least in control and you're just kind of accepting whatever everyone else is doing on both sides of you. Yeah, I was about to bring up the relationship with software engineers as well. Interesting. Hold on, hold on. Let me break down a little bit. I actually have two questions, two follow up questions. Very, very, very meaningful and eye-opening, by the way. Now we know everything into and behind the scenes, how self such was made in different companies. And so now, Ben, specifically, for your health care case, where did you get those data? Like who won't even give up the data regarding how much like those prescription drugs is prescribing different places? Is the public available information? How do you guys even get it? No, no, it's not public. Under HIPAA, there are, you can, insurance providers can give data to third-party analytics companies. So there are some stipulations there that like, yes, you can totally get claims data if you are, you know, fall under a certain category and then like have met all whatever criteria the government says you must meet, you know, everyone's got to be HIPAA certified after that. There's still criteria after that. It's not like you can go to any analytics company. It needs to still, in theory, go to a specific type. But yeah, so that's how insurance providers are often interested in this as well, because they're like, well, we don't want our people being over-prescribed or, you know, we don't want to be, you know, we don't want to be the cause of something, you know, that actually with opioid, right, like the whole, one of the things that people found out, they're like, I think there's like one city I don't remember where in America that like it was like, they were getting like a hundred pills per day per person in that city, like, like it was something, something like crazy high. And so it's one of those things where it's like there, there is some validity because like, if you're an insurance provider, do you not have a little bit, if you're writing those, like writing those checks to approve that, do you not have a little bit of like, responsibility for being like, that seems weird. And I mean, it goes for everyone obviously, like in that chain. Very high. 100 pills per person per day. It was something crazy. Like you can look it up. There's an article, there's like a few articles about that. I'm honestly pulling that number out. I just remembered looking at it and being like, that is a crazy number. Like, yeah, that's an unnecessary number of pills. So that's like, I think that was one of the points that like, really, if I recall, like hammered home, why, like I think Purdue and several other companies got sued so heavily, Purdue Pharmaceuticals, not the university because it was like, this is, this was clearly, you know, this was obvious guys. So are you saying that the pharmaceutical company who, who produced, who manufactured those pills was, was sued or the doctor who prescribed it was sued? I think it was the actual pharmaceutical companies that, because like there was also some other things where they were like pushing it on, like there was multiple levels of things in there where it's like they were pushing it. They were saying it's totally safe. Like doctors are like, okay, cool. I think doctors were getting like huge kickbacks. So there's like layers upon layers for this. There's, there's a, I think there's a show called like dope sick. If you want to like see it in an entertaining fashion and not just, you know, read about it. But Wow. That's what's going on. And, and then insurance company was ones who actually people pay premium, but insurance company will cover those drugs cost if they prescribe too much and also impacted the health of people living in the city, whatever they ensure they need to pay out more money. That's how the business works, right? So that's why they're very incentivized to crack it down. Yeah, there's, there's multiple levels of why. But yeah, I mean, like, you know, if you're, if you keep people healthier, you, you in theory have less, less costs and insurance providers in particular, like often someone wants to point it out is like insurance providers are, are great because they get to charge you money when you're not sick because usually, you know, you usually don't get sick till you're older. And by the time you're 65, you're on Medicaid. So the insurance providers don't care. Like they're like, all right, you gave us our money while you were healthy. And now that you're, you're, you're old and sick, you can, you know, um, yeah, I, I don't have the cells to do product management, but like, yes, this is the, the wonders of insurance and healthcare. Oh, oh, we just learned something new regarding how that, I didn't think that way. I'm just thinking about it right now. We're not getting sick. So don't want to get sick. But yes, once you're older, when you really need to pay people to go to the hospitals, they're off the hook. The government takes over. Yeah, because you're not working anymore. So you don't, you're not on your work insurance anymore, because you're not on your work insurance anymore. You don't need, you're not going to use that, that insurance. So either you have to pay a really expensive insurance, um, or you, you're on Medicaid and I, I guess, I guess now there's like, um, you know, uh, what do you call it? Not Obamacare. I don't know what the actual term is, but that one. But even that, it's, you know, it's not great. So yeah, it's, it's basically the government's job after, after a certain age where it's like, all right, you're on, you're on the government's dollar at this point. Um, no, it's, it's a great, it's a, it's a great business model in terms of like, how much money you can make. I think if I recall, like those, like, what is it, like UnitedHealthcare or whatever, like after, uh, after, um, again, Obamacare went in, but I'm trying to remember the actual name. Um, after it went in, like, like tripled or quadrupled the size of those insurance providers over like 10 year period, um, in terms of like market share or well, uh, not market share, but, uh, whatever, valuation. So yeah, yeah, no, it's, um, it's a quote unquote great business. Um, so. Wow. That's what's going on. Wow. Do we have any comments out to listening right now? There's, there's no secrets here. You know, it's, it's all, it's all there. It's all, it's all, it's all there. Um. But most people didn't know how exactly they, they made so much money and actually tripled their variation or like three times. I don't like, I'm definitely pulling numbers out of here, but I know it's like stuff that if you were to look at, you're like, wow, that is actually, yeah. All right. If I would have invested in healthcare, I would have made a lot of money. Like don't invest in big tech, right? Yeah. I was like, don't even check now. Uh, drop a lot. So now let's talk about tech. Surprise, surprise, surprise. Um, data engineer is the middle child. I was, I was about to ask regarding how do you guys actually work with soft engineers because they're all engineers. So from PM perspective, we group you guys into engineers. Usually when we go into the, how do you work with engineers? Oh, that's how we do it, right? So group all of you guys together. Yeah. So now, so, so make it a little bit, break it down a little bit more. Are you saying that in meta, let's, let's, do you mind mention the type of feature you worked on? I mean, I was mostly working on internal, uh, enterprise, uh, solution. So like I worked on getting like data from like the recruiting solution that we have. Um, we, we didn't use, I think it out of the box recruiting solution, like, you know, your usual, whatever you want to call it. Um, like, not ETS. Yeah. I mean, there's an ETS component, but like also just like your general like, I'm trying to think, like, what would you call it? It's not a CRM. It's not a, you know, ERP, whatever you want to call your, your recruiting version of a CRM, right? Like where you're managing all ATX system. Yeah. Okay. Okay. Yes. That in ETS system. So yeah, like basically that. So just getting data on that and pulling it out and like also tracking, like how people are interviewing, how often do they interview who passes, things like that. So, uh, that was kind of the product that, that I worked on. So it was almost more, it was less, um, less about the product itself in this case and more about the process of like hiring people, uh, especially then when like meta at that time was like hiring like crazy. So that was like a major, a major point that they were just trying to to gather talent and figure out the best way to find talent and, um, you know, so, you know. So you build those product and, and focus the like internal product and then specifically are you saying that the car manager constant changing ideas and then soft engineers just keep on deleting columns of data was like, what happened? How exactly guys communicate that? That's weird. Usually you, I assume, well, at least in the interview, we will say the point as an interview. Oh, as a product manager will also define what's best for our customers, what kind of KPI when you track, and then we'll work with our engine and design the best solutions. So are you saying that you do it on the fly and you say delete stuff or changing our ideas and it's, it's not that it's done on the fly. It's that like, especially in things, right? There is an incentive to constantly build and change and try new things, right? Like that's, that's how you get promoted for, for everyone, right? Like PMs, software engineers, data scientists, like data scientists need to find, you know, new value or, you know, they won't get a promotion. Software engineers need to build new things. Otherwise they won't get a promotion. So some degree it's like the incentive of the process and there is a process, but oftentimes data engineers are like software engineers, I think feel like data, not necessarily data engineers, but like the process of getting data and tracking it can be a hindrance to that, to them building, right? Like for them, for their view, software engineers want to build, right? Like they want to build things that function and then it doesn't necessarily want to connect it. Like they're not going to like think about like, oh, I need to connect this for analytics. It's like, does it work, right? Like does the end user, you know, can they, can they work with this product? Yeah. So basically they build the MVP fast. Yeah. Well, MVP and even just the features like, Hey, it works. Perfect. It's, you know, great. You know, and then later on that some data sciences or some PM might come in and maybe they were, had some metrics early on, maybe they didn't generally they do. But overall that there might be some gaps in terms of what they're tracking because maybe later on they're like, we need to track this or, you know, Hey, we remove this feature or remove this column and I broke all my pipelines. So that's what I mean when I say that it's just like adding in data engineers into the process just feels like a slowdown to, to a lot of people in the whole process. Because like, okay, we could tell you that we're updating this thing and then we could give you enough time to update it or we could just change it and then like, you'll figure it out. So yeah. Wow. Wow. Huh. That's an attitude within the company. But isn't it supposed to be, okay, so I think we can start a secret big tech companies. Isn't supposed to be a collaborative environment and also isn't like that's why people thought, Oh, this will also attack that that's what it's causing, right? So people just keep on trying to do new things and then fix it later on. Yeah, I mean, like, I think that's definitely always a discussion, right? I think this was something that like, people called out in Twitter, like if people are like looking through the code base, they're like, Oh, like someone pointed out this, like, yeah, there's like 10 years of tech debt. And I think this was like employees internally. And, and like, they were saying I was like, well, yeah, because we're incentivized to build new things not to fix old problems. It's not that it's not collaborative. You know, there's definitely a collaboration, I think between PMs, data scientists, software engineers, I think data engineers can be the ones that can kind of get left out. This is why like, I don't know if you know Chad Sanderson, but like he's got this whole concept of like data contracts, which basically is just this assumption that like, hey, from the product, this data will be provided to you. And the only way you can change that is through essentially like some sort of code or some level of governance and not just like, Hey, I made a change. It's like, well, what if we like captured that change and made it like a, you know, some sort of code or version controlled system? Yeah, I always like the way I would often sometimes be reminded when changes were happening at Facebook was like, Oh, hey, we see you're connected to this MySQL database. Well, this column just got dropped. So good luck. Like I get like an update like as it happened. And so my job would usually run at 12 o'clock at midnight. So it's like, well, okay, I could make a change before that, you know, before that happens. But like, it wouldn't be a person. It'd just be like some automated system that's like, Hey, we see you have this, we see you rely on this. So we're just letting you know this has changed. So we dropped it in the middle of the night. Stopping. No, it's not in the middle of the night. I more mean like the pipeline itself will run in the middle of the night. So usually, you know, if they dropped it at 8am in the morning, you'll get that email at 815 from some automated system. And you're like, Okay, I got to change this pipeline before 12 o'clock tonight. And then it's fine. Oh, yeah. And I imagine to some degree, it also depends on where you are. Like if you're probably on the product side, I assume there's much more conversations because breaking a data pipeline that has far greater consequences, where it's like, you know, if it's internal people are probably like, Well, you know, we don't have as much data to deal with. And you know, maybe maybe they feel a little more relaxed. So I think there there are, you know, you're always going to have varying experiences depending on the team you work on. Yeah, I like specifically picked the team because I was like, I don't really want to wake up at 4am and get a call that like a pipeline is broken. And I must fix it now. Whereas like the internal team, it's like, Well, if that happened, if something broke, it's like, All right, we'll deal with it later. So, you know, This is what what a surprising to discover what it's required. So once it crazy. So we have audience Andre Andre Andre is actually one of my students inside of PMA. He said, Department of Management, Data Engineering, Healthcare, I'm sad I couldn't get it on time. It was tater for me. Andre, feel free to put your questions in the chat. Okay, we can highlight certain parts that you have your own confusions. Ben can like recover or like, show some insight for you later on. And we also see some audience from Paris. Um, Denver, Chris, Chris is also in Denver. So just like, Ben, you're there as well. Yeah. Yeah. Same, same, same location. Probably that's, that's your friends or your fans. Coming over. This is awesome. Let's see someone. Yeah, several people from Denver, another guy from Denver. Extension today from Denver. Everyone from Denver. Everyone from Denver. At your audience, just say, I don't know if I am. That's good. Good to hear everyone. I mean, I'm in, you know, my, my company, or yeah, my company named Seattle Data Guy. So, but if you look at my LinkedIn, it says Seattle Data Guy now in Denver, I think. So it's not like, there's no secret. D, D, D, D, D, D, D, D, D Guy. Nope. Nope. Nope. So when we keep the brand names, make Seattle Denver, we'll think about it. So when did you move from Seattle to Denver, by the way? When did I move from Seattle? Well, I actually, so in 2018, I moved down to SF. I was in the Bay for a few years and then COVID hit. That's what met her. Yes. Yes. Yes. They were like, you must move down. I was like, okay, fine. I mean, you're, if you're going to pay me to move down. And then I, I, I lucked out and found like a place for 1400 a month. And I was like, all right, we got a place that's not $3,000 a month. This is, this is fine. So, yeah. And then go ahead. Yeah. Talk about the tech move. What about tech in general? Uh, well, as we know, I just mentioned, I was in when working for a tech company, there's more, much more complexity than what it seemed like on the outside. When you move for, move for tech companies, do you think it's worse if you look back, move your entire family there and have a great career and later on move away from Silicon Valley? So what's your career? How do you decide and how you design your career? Do this thing worse if once you look back? Um, I mean, I, you know, design suggests that there was some plan. And I mean, like to some degree, there were things that I think I planned, like I knew I think consulting was going to kind of work out eventually. So I think I was always kind of doing that with that in mind. So I think in terms of moving, I mean, I think it's going to depend on a person's stage in life. It was an easy decision for me. You know, I didn't have, you know, I, I don't have kids. So it's like responsibility was low. I'm like, worst things that happen. I get fired in six months and I have six months more of my lease. And then I go back to Seattle, right? Like, so that's where I was like, all right, this is fine. So, so that, you know, again, with no responsibility, it's totally different. If you have kids and a family, it's right. Like making that move, making that, it's a much bigger risk and thought process that goes in there. Yeah, but I think, you know, if you're special, if you're, you know, at any age you can do it, but if you're younger and you've got like zero responsibility, why not? Why not just go out, take a job somewhere. If you think it sounds fun, if it's interesting, and you can figure out the rest of the details later. I think the biggest thing is like just make sure, I think it's Gary, I don't remember his last name, but he says like, you know, you either got to be learning or earning. And I was like, well, I'm definitely earning at Facebook. And learning. Yes. Yeah. And learning, of course. But like, you know, I'm definitely earning. So, you know, we at least know that one's going to be crossed off. You know, so it's just one of those, like, it seems like a good choice early on, just to just take that on. Yeah. Before I ask the next question, you show me your cat. Let me show you my peacocks. Oh, you have peacocks? Nice. Wow. I was going to ask, are they wild or they're your pets? Do you see it? I can't. And I do need to show off my peacocks. Yeah, I don't know. Can people see my peacocks? Well, I'm blind, I guess. Oh, now I see it. Okay, no, that's moving. I can see it. I was waiting for movement. I'm like, where's it? Where's the moving? Yeah, it's my peacock. No, it's not mine. Well, they come every day. They come every day. It's crazy stuff. Sorry for interrupting. Occasionally they come. I was like, nice, you show up on my YouTube live. This is awesome. Hold on. Let me let me plug in everything. Hey, Ben, I do want to ask you sorry. So I do want to ask you this question. So you talk about moving for tech companies, enjoying tech companies. And now we're going through COVID episodes, right? We're going through recessional past COVID, people that the entire world has shifted. Just like you moved to Denver, I moved to Miami, and discovered peacocks in my backyard, like crazy, crazy stuff going on. Now here's a dilemma. I'm not sure if you fail the same way. At least that's what I heard. People were like, oh, you know what? It's very hard to join tech companies now. Or at least they heard the news. They heard the news and said, oh, you know, they're all laying off. Maybe let me just do as a stub in different industries. Maybe do healthcare or oil gas. But there are two different types of career paths they can choose. So they can work on non-PM functions in tech companies, such as support, or any, or even self-support from data, using data as an example. Or like, if data engineer, they can be like self-support. So they're technical support, right? So they can then get into still join tier one company, Uber and TikTok. They're still hiring. They're still hiring lots of people. For product manager, product manager also think about, well, maybe I can join like, like doing operations for tech company. I have a friend and he works for BCG. He really want to become a PM. Very interesting. He learned a job at Google doing like finance, finance operations. But he didn't take the job. I support that decision. Eventually he joined a startup doing like what he really loves to do. Do you see this dilemma for data space in terms of the whole tech industry in general, what were more impacted in the recession space? Do you think people quit their, the temporary, temporarily past the dream of doing what they love to do? For example, it could be a data scientist or data engineer in a tech company, then they took something temporarily in a different track. Do you see this happening in your industry right now? I don't know if I specifically see that. I think usually what I see is people who are maybe earlier on in their careers, maybe they like want to be a data engineer. And usually what I tell most people is like, it's hard to become a data engineer straight off of the bat. Most people I think go into their data analysis or something similar to that first, just to get some experience in the data world. And then kind of shift it over later on. And that's usually because data engineering just has so many skills that are required that just weren't taught in school. And so you kind of have to do some work on those things. And data analysis or data analyst roles are generally the easiest place to get it. So that's usually kind of like the non data, data engineer role I see. I think the other thing I'm seeing is a lot of people wanting to do more consulting. And that could be obviously some bias compared to what I do. I don't talk too much about consulting on LinkedIn until recently because I had a lot of people reach out to me on it. So that's when I was like, okay, let's talk about this. Let's see if people are interested in doing consulting. So that's something I think I'm seeing more of, I think partially because if even at Facebook I can get laid off, some people are like, well, why not take a risk? Why not work for a startup? Why not start a consulting company? Why not do something for myself? So I think that's kind of a shift that I'm seeing again. And the same thing is like just as much as like consulting is like, well, why not work for a startup? Right? Like if it's the same risk of getting fired, it's like, you know, why not have some fun, do something interesting and new. And there's still a ton of startups being funded. I think I just saw Madrona invest in like a few dozen or a handful yesterday or something. I saw a seed series that was like $7 million for a seed series around. So I'm just like, dang. That's big for seed. These seed series are getting big. I think it's because it's in the, you know, yeah, in the AI space. So for multiple reasons, right? Like the talent is very expensive and things like that. But yeah, it's, you know, there's still a lot of money I think floating around in the startup world. So if you've got some interest there, that's also very open. Yeah, exactly. Actually, so since I moved to Miami, open my entire world view is crazy. So this loss of investors actually during the pandemic moved to Miami and never want to leave because we experienced the winter. The Miami winter, very nice. We never want to move just like me. So when I started talking to those investors and recently told me a deal, we should say surprise, totally surprise. Basically it's an intersection between the crypto and WebStreet. You know, lots of WebStreet. Originally Miami is very pro WebStreet. All the WebStreet people move here and now WebStreet went down. AI went up. There's a company with a combination between AI and WebStreet and just have those kinds of concepts like early rounds or guess what? And like before AI become a thing, you know, like crypto went down for a year, right? Before the AI become a thing and crypto went down, they're not even able to learn some kind of fun. It's like some like 50K paycheck, not paycheck, 50K investment check, right? Nowadays they oversubscribe just because there's AI came up. There's also there are the very few companies who can do a combination between AI and WebStreet. Now they oversubscribes and they don't take investors' money anymore. So those kind of companies continue to grow. Yeah, you're right. When you are like waiting for a big company to hire again, maybe it's a great time to join a small company because you're right. Same kind of risk getting fired anyway. You're losing your job either way. So why don't you do something fun? So because really you don't have that much opportunities anyway to do something fun while we're all doing recessions. It's time to just do anything anyway. Yeah, I think they often say like recessions are the time that people like tend to get their MBAs as well for that reason. It's like, well, might as well do this now. We got the time. So although with MBA costs these days, it's like, I don't know if that's true anymore. It's crazy. I have different opinion regarding MBA. For people who have lost a student who want to become a PM, right? So people like, I hate those influencers. I hate those influencers who already land MBA. Always, oh, you should get an MBA. If your purpose is trying to become a PM, don't get an MBA because only 7% of Harvard MBA became a PM. That was when tech was hot. I'm not saying right now. When tech was hot, they did analysis. Only 7%. And then MIT, 14%. That's it. 1,4. Not 1,4. 1,4. 14% MIT MBA is a very technical thing. You can put a manager. Not even the Google level of a manager. So in the past, among my MIT classmates, that was years ago. Don't guess how old I was. That was years ago. I only have like three MIT classmates who joined Google from the business school. And then one of them told me that, hey, Nancy, do you know that interview for Google three times? That this is the third time I got in. So it is actually like MBA doesn't give you a competitive advantage. The real competitive advantage is the experience you had. Even if you were for startup, you have launched something amazing. And especially it can be really amazing. So I said, well, during recession, we still turn our startup from almost no funding into next level, creating so many end users. I believe that's a better career path compared to people, oh, you know what? During recession, let me just hide doing like finance operations like at Google or Uber, finance operations. But you got MBA, you can do something greater. Why don't you join the startup, create something really amazing, like amazing product, regardless what your true passion is, could be a data engineer or whatever, um, product manager in those startups. And I think the better career path for lots of people. And people really just bought into the name of a bank company by doing finance operations. What's the purpose of doing something so boring? Well, personally, I think finance operations is the most boring work ever, except like tax preparation and counting juggles. So let's see any questions we have from the audience. Question for BAM, KUG, by the way, this is someone from YouTube, KUG Studio. I love this name. Question for BAM. An example of a good PM interaction and experience or a bad one from your seat that you how can a PM use data to the best? Okay. So two questions. Tell me, tell us, tell the audience examples of your interaction with good PM and bad PM, what does it look like? Then we go to the next one, we should say examples of how data can be used, use the best. Okay. So good PM, bad PM, let's do this. Yeah, I don't know if I've worked with a bad PM per se. Maybe a bad project manager, which is obviously a different thing. Different kind of PM. So it might be similar though, where it's like a good PM, when you have a good PM, you don't notice, but when you have a bad PM, you notice kind of situation because that's the case with project managers. That's how you explain it. If you have a good project manager, you don't notice the project manager or you don't even realize that things are just going. There's a flow and it's good. But with a bad one, it's like, we haven't moved forward for three months. Something is bad. So yeah, I don't know if that's the same with like good and bad PMs. I think, you know, usually I've, you know, people who have been pretty on point and pretty much like, you know, doing a good amount of like, using a combination of data as well as discussions with real people. Because I think it is that combination, right? Like you use the data to drive like a level of the certain products you develop and features you develop. But I think on the same time, you have to talk and understand people. Like I said, I think I referenced that earlier with the healthcare product where it's like, yeah, like, let's actually talk to people and understand what is useful to them. We just give them a number. It's like, okay, can they make a decision off this number? Like, what are they actually doing with it? Okay, if we give them this list, what would they do with this list of people like trying to figure out beyond just, you know, okay, we built this feature, right? Like, okay, but how is it going to get used? Is it useful? So thinking about those things. Yeah, getting the user insight, which is foundation building amazing product. Hey, I wonder what are questions lead to another great question. As as an engineer or data engineer or any kind of data scientist or engineers in total, in general, how much was the interaction with customers? When do product manager actually bring you into those conversations? Yeah, I don't think we had too many direct conversations with customers. Again, we're generally just kind of held in the back. You know, I think maybe a little more at Facebook. I might just because at Facebook, you're expected to have a little more ownership. So to some degree, maybe there's a PM that's kind of helping decide what gets built. But to another degree, it's kind of like, yeah, but you also kind of need to have some ownership of that as well and have some discussions and and be willing to state your opinion. So if Facebook, I think it happened maybe occasionally a little more that you talk with stakeholders and customers. But at the start up, it was like, someone else would go talk to the to the real people, we'll just build whatever needs to get built. What would you wish could have happened? Let's define this. So let's define a really good product manager. What do you wish the good product manager would do to, I don't know, anything to enable you talk to a customer to bring you early in decision making process or even like, I don't know, deliver the KPI earlier. So what would you wish the amazing define the imaginary amazing PM? What would they do in terms of working with you guys? I imagine this is different for everybody. Like I do like getting a little more involved with discussions just because I like knowing the why it's like, okay, why are we building this, you know, not just let's build this. But I also know like, and this is one of the things I think I've even talked about on my channel. It's like some people like data engineering, because you can kind of just hide and, you know, you do your work. It's not like you're not doing your work, but it's like, but you don't have to like, fully interact with people and fully understand you can just like, okay, I built you this thing. I've done my job. And so I think that you'll find people all across that spectrum where some people want to know why and they'll want to know early. And yeah, it's kind of nice. Some people don't want to be bothered by meetings and like, hey, when you have a feature and you have the requirements and you have everything you want, let me know, I will build it for you. So I think that kind of ranges. I see, but from your perspective, you love to know why I get involved in decision making process. Yeah, yeah, I think having that why is always helpful because otherwise you just kind of feel like you're doing stuff to do it, but there's no, you know, like, why am I doing this? Who's, who's this, who's this driving value for? So yeah, it's actually, I think that lead to entrepreneurship of yourself. That's why you start your own YouTube channel, start to have your own consulting business. And I think in general depends on how they, what the definition of successful career, right? So I was like you, when was I started as an engineer, systems engineering, working on oil rigs, can you imagine me oil rigs? Hey, totally, totally. Exactly, the hard hat, the helmet. Yeah, so I feel very disappointed if I was left out in understanding why, if I, if I didn't know what the bigger picture as an engineer, I feel very, very annoyed. I think it's based on what people's definition of long-term career success, that leading to what they believe is a good PM need to tell them what to do. Like, for people who actually don't want to be bothered, probably their definition of successful data, data engineer is to be the expert of creating best data set in a short amount of time, get it done and deliver. For people who want to be growing into entrepreneurial tracks, probably why I want to know why, or I'm just whatever, with a hammer in the tool set, you don't even know what I'm about to build together. I think that that's the difference. Cool. So now let's move to next question. This audience have a really good question regarding, from your seat, how can PMs use data the best? I'm trying to think, like this is such a broad question. I mean, for my understanding, at least like, you know, there's kind of the baseline stuff, you know, figuring out what features are people actually like using and working with. I mean, and engagement is kind of like this baseline metric that everyone can use. I think on the flip side, there's defining like your true North Star metric, but also making sure you think about whatever your countermetrics are. I think this is something that sometimes can get missed, right? Like in countermetrics, generally are like, oh, well, if our goal is growth, okay, cool. But if our churn is terrible, right, like or something else on the other side, I mean, you're growing maybe, but maybe you're, you know, in six months, you won't because you're churning at like 70% or something, but you're growing so fast, you wouldn't notice. But like, when you look at churn, you're like, wow, we're losing people very quickly. I think that's usually the classic example. But yeah, I think having that, and then maybe, you know, especially now as we're getting into a world where people are trying to be hopefully a little more concerned about more than just, you know, the numbers, you know, thinking about, you know, what other impacts are you having besides like growing products? Like, okay, we're growing a product, but we're, you know, with like opioid, that's a good example, right? Like, okay, we're selling more. Yeah, but we're selling, you know, one of these towns in these cities is getting 100 pills per day per person or something crazy, right? Like, that's not a good growth thing. Like, so I think, I think also thinking about what are the negative effects of whatever your positive metric is, your true North metric is. So yeah, this is awesome. You think like PM already, you also talk like the PM. This is amazing. Actually, I was doing here. She is a and many of these people actually all women surprised. Well, I have a male man in my program, but happened to be all the data of many students, they became data product manager. Yeah. And yeah. And some of them land job offer in a healthcare industry, some of them in the like, like a fraud detection industry. And also some of them then offer from like payex, those kind of like travel industry Expedia as a data product manager, which is similar to sounds like what you described, like they define what the data product look like and trying to understand what the North star metric different things with own data product. You, you, you sounds like PM already. Exactly. I would say North star metric. It's like, boom, my mind is amazing. Yeah. Just say what PM the same phrases we're using in our terminology as well. This is amazing. Awesome. Cool. So then let me see. What are the questions you we have? We also have questions from LinkedIn. LinkedIn people may need to say hi, Chris. Hello, hello. Thank you for hosting today's band. Thank you. Thank you for joining us. Awesome. Okay, great. Cool. So we are towards the end of this talk. Anybody if you like today's talk, make the panel to make sure to comment in the description and let me know if you want to do more of those kind of like bio chat, fire chat style of our YouTube live and if an additional question for BAM please comment below as well. Make sure to share this video with any like people who are who are interested in the intersection between data and product management. And also one last question to you, Ben, how can people find you if I have more for our questions and in general? Yeah. I mean, you can, you can pretty much Google the Seattle data guy and you'll see my probably newsletter, blog, YouTube, all on it, et cetera, et cetera. Awesome. Cool. Awesome. We're also going to link Ben's YouTube channel in the description of this thing. And we also have one for LinkedIn. We'll link the proper one for each channel and feel free to reach out to him as well. Thank you so much for joining us, Ben. Thank you so much for your valuable time and insight. Awesome. Yes. Thank you. Thanks for having me. Great. Cool. All right. Talk to you soon. Have a good day. See you guys now. Let me end my streaming.