 I want to talk a little bit about being an adaptable product manager. I'll walk you through the framework that we use at Lola and how we think about developing our products. But first, I thought I'd just start by sharing a little bit about my background, how I became a PM, what I think PM life is like, the dream team in my mind, and then how to thrive in chaos and some of the benefits of having unique paths into product management different than your typical like engineer to product path. And then some resources that I really enjoyed and have helped me along the way. So to get started, grew up in California, did a lot of push ups growing up. My father was in the Marine Corps. We would often, I have two older sisters, we'd often be fighting somewhere, restaurant, car, driving down the road in the middle of the rain. And my father would say, you know what, we're stopping, drop and give me 10. Anywhere we were, that happened. So, you know, I started out life and it's influenced me along the way, this military background for my family, which led me to my freshman year of high school when I went and visited my sister at the Coast Guard Academy. And I said, you know what, like dad, mom, there's no way I'm going to the service academy. Like I see what they do. I see all the rules. I'm not doing it. Then you fast forward four years and I'm swearing in as a cadet at West Point and starting my journey, my own journey as for military service. Four years later, I graduated from West Point with a diploma in one hand and then a commission as a second lieutenant in the U.S. Army. I had an obligation to serve five years, so over the course of five years I had the opportunity to lead soldiers in combat, both in Iraq and Afghanistan. And this is really, the reason I share this with you guys is because it has driven so much of who I am and how I operate today. And I'll kind of share more of that along the way. So my path into being a PM started at Lola where I am currently. I got out of the military, moved to Boston. My wife got a job here and I said, you know what, like I'm no longer in the military, what am I going to do? So I started with, what did I not like about the military? Well, there were a lot of rules. I did a lot of push-ups. It was a really tough environment, which I absolutely loved. Like I loved being in combat because we actually got to go and execute all of the training that we had done in stateside. So I said, okay, I don't like big companies, maybe. I really like the hustle of being in the military. So let me look for a startup. And that led me down some random internet, like black holes. And I woke up one day and I had been connected with our former VVIP product at Lola, Ellen Chisa. And she said, let's grab coffee. I said, awesome. That'd be great. I'm really interested in being a product manager. She's like, what do product managers do? I was like, no idea. Absolutely no idea. But I think I might have the skills where I can apply them and do it well. She said, well, okay, let's start with just starting to learn a little bit more about product management. Unfortunately, we're not hiring at Lola right now for a PM. But we are hiring on our service team. So I said, you know what, I don't have a problem working hard. I like starting at the bottom. This is an amazing team, Paul English, who's the former, he founded Kayak. He was starting this team and it was really from ground zero. I could go in and start at a company. So I said, great, I'm going to do it. And I was on the service team, which really introduced me to how incredibly hard it is to provide service for a product, especially not a well-built product or an early-stage product. And really gave me a lot of empathy for the customer, which I think can often set you up really well for when you become a PM because you're really serving the customer with everything you do as a product manager. So after about a year on the service team, I had the opportunity to move over into product. I think it was kind of a combination of people were tired of hearing me give feedback about the product. Maybe they thought I was passionate about it. All these things really led, I just voiced over and over and over and over ways that I thought we could think about the product or feedback from the customers and they gave me the opportunity. So I advocated, but also people saw it in me and gave me the opportunity. So that was about two years ago. Since then, I've gotten to take on a bunch of different projects. And now I lead the product team for our admin tool. So we do software for business travel. So it's everything a company does. They come in and set it up. And that's been an amazing opportunity. So I don't know if anyone uses Concur, but one day it's going to be instead of Concur. Okay, so this is what I call hashtag PM life. There's a lot of inputs into being a PM. You probably are fielding questions and feedback from every single team at the company every single day. In addition to talking to customers, interfacing with stakeholders, it's an incredible amount of information. And you have to make a lot of decisions and make them quickly with the information you have. So the framework, well, actually, let me take a step back, the dream team. So quickly starting with, I fundamentally believe that you're going to build the best products if you work hand in hand with your design and engineering team. And personally, what I felt is there's a lot of, you hear this term CEO of the product. And that means that you're leading everything, right? And I have felt responsible for making sure we know exactly what we're building. Do I have the spec written? Do I have the designs? Have I communicated with it? Do I have all the right meetings set up? But what I realized over time is it's not so much about being completely organized and getting all these meetings set up and making sure everything's squared away. It's about having the right team with you. And starting together from ground zero. So I often now just think of them as my thought leader. So I look at product as the base to power design and engineering to really put forth the best product possible. So the way that we do it is right from the beginning, bringing design and engineering into the conversation. So that means we're all hearing the customers, understanding the customers. We have a really, really deep knowledge of the customer. And I think that could be everything from bringing design and engineering into customer interviews, going to user research, sharing with them how you're thinking about and making decisions. And then asking for their feedback, being hungry for all their feedback and debating things back and forth and letting people question exactly what you think you should build. So you always start with the problem, right? If you can define the problem, then that's the first input. So you had the earlier slide where you could see every single team is talking to you, you have tons of inputs. All of that is a lot of noise. And what I would say is just all synthesize and analyze it down and start with the problem. Next, you really want to start to define the outcome that you want from the problem. So you say, for instance, we have hotel guidelines within our product. So we're trying to figure out the best way that a company can apply a rule across any city in the world to allow their team to book hotels. So the outcome that we want is that the admin has control that they need. But the traveler's experience is not sacrificed. So how do we do that? That's really the outcome we're trying to achieve, right? So then we start to say, okay, what solutions can we do? What ways can we think about this? Not just the usual set up match budget across any city in the world. No, really, what are the different taxes we can do? And I would say, although it says determine the solution, you're gonna have a lot of different tactics, right? You're not just gonna be focused on one single solution that you need to solve the problem. It doesn't always work that way. If it did work that way, that'd be amazing. But I wouldn't be afraid to just think completely outside of the box to try and understand what are all the different tactics we can use to get the desired outcome that we want. So once you're thinking about these things, determining the solution, you then want to measure the impact. A lot of teams become feature factories. So they just measure the output of the teams, right? They're saying, build, build, build, build. But that does a couple of negative things to both the team and the product. What it does is the team is just looking to ship things. They're not connected to the customer, right? They don't know how what they're doing impacts the customer in any way. So you really want to move the goal line to measure the impact. And what that can look like is when you have your outcome, you can tie it to a metric. So you want to tie it to a metric that allows you to know whether or not you're on the right path with the tactics that you're doing. And it also does another thing for the team mentally. It says, okay, we shipped this. Now, what did it do for the customer? How are they using it? Did they use it the way that we thought they would? Did it move them needle enough? And you really just extend out the goal line so that they're focused on that instead of just shipping. Additionally, what you see is that they're excited, right? And they're driven to really solve these problems for these customers. They're not just looking to ship the next feature. So it's both mental for the entire team and then also for the customer. Because you really see the huge impact that it's made on their lives. So it's kind of a two by two matrix. If this helpful to you, you can see problem solution, outcome impact. This is the simple framework that I really like to think about when we're developing the product. To really reduce the noise and take all of that feedback and input and come away with it with an action plan. So that you can go forward and execute. I think what I've seen along the way is you don't have to do everything at once. You just need to start with the problem. Then you need to determine what your outcome is. And then you need to look at what the potential solutions are and then measure it and see what the impact is. And go ahead and start over, right? You may discover a new problem when you solve a different one. And it's okay, it's constantly iterating and developing and iterating and developing, iterating and developing. I will say it's similar to combat in the sense that you don't know what you're gonna encounter. So you don't exactly know how a customer is gonna use the product or what they need. And when you're in combat, we would do a lot of convoys. For instance, my unit was in charge of going and providing engineering resources. So we would go and push a lot of dirt around in a lot of different places. Mostly to build fighting positions for people or to provide more barriers. But as we are convoying, we would encounter all types of different situations. And we really had to start with saying, okay, what's the problem here? What do we need to address first? And what are all the things we can do to really handle this situation? And then we just had to make a decision and constantly iterate as we got more information. So it's funny how history repeats itself. It's done the same thing in my experience from combat to being a product manager. So I talked a little bit about in the key takeaways that I wanted to share with you guys from this talk was really what are the benefits of unique past? How many people are getting here are current product managers? A couple? Okay, how many of you came from an engineering background? Two? Interesting. So most of you, all different types of backgrounds want to get into being a PM. The way that I think you can sell it, right, are when you don't come from this traditional background of engineering to PM, that's a great background way into being a PM. But I think you have a lot of hunger, right? You have a lot of hunger to really prove yourself. You don't know if you can do it. You lack a technical background, which for so long I think has been the driving force to people to say like, you need an engineer to product. Like that's the best person. I'm not saying that it's not good. I think it can be awesome. But you have a hunger to prove yourself and this desire to constantly learn more in a prior framework so that you can succeed. I also think you bring a unique perspective. So if you're coming from a technical background into being a PM, you're trained as an engineer, which is great. And that's one perspective that you want. But you want diversity. I think there's been a lot of stats recently about how Fortune 500 companies are performing with higher levels of diversity. And they're often outperforming lower levels of diversity. So I think it's the same thing when it comes to product. You need everyone thinking about it in different ways because you don't know where the next best idea is going to come from. Or for instance, I was in a meeting today and we had design, engineering and product all thinking about it. And we are just riffing off of one another. But we are all thinking about it completely different. So the designer was thinking like, how do I design this? Like, what would this be? And the engineer was thinking about how do I build this, right? And product was really saying, okay, what are all the problems that we've identified from the customer? And everyone coming together with these unique perspectives drives for the best product. And then the last one, team. This is me personally. I don't know if this is true of everyone. Always identifying with the team before yourself. So I think when you don't necessarily know how you fit in coming from a unique path into product, you're really driving to push the team forward. And I think what's great about that is like, your team is serving the customer. So you're always, again, focused on the customer through serving your team first. So here are some resources that I've used that have been really helpful. Other PMs. Like, that is gonna be the biggest source of information possible. I have a few good friends that I meet regularly with to grab coffee that are PMs. And it's fascinating to see how they're approaching problems or how they're doing things in their company. So I would say, if you're looking to get in to be a PM, just reach out to someone. Like, ask them for 30 minutes. Have them sit down and talk to you. You know, grab coffee with them. Like, you're gonna learn so much. And I've also found that like, similar to different perspectives and wanting the dream team to be design engineering product, that it's been the same way meeting other PMs outside of Lola. Because we do things one way, right? But we aren't necessarily always looking outside of ourselves to say, how can we do this differently? And those PMs have shared ways with me that I can bring into Lola to really improve our product management team. The other thing is Silicon Valley Product Group. Marty Kagan is a huge thought leader within product management. I definitely would recommend checking out the Insights blog. They write regularly about product management. And his frameworks have been incredibly helpful to me in applying them both in real time and thinking about product and how we develop the best products. The High Growth Handbook. There's a whole chapter just on product management. It's pretty cool. I don't think you have to take any of these for like, this is exactly how I should do it. But it's interesting to think through, okay, this, it was written by a VC. And so he's seen thousands of companies and thousands of product teams. And definitely worth checking out. And then lastly, Gibson Biddle. He was the former VP of product at Chag and at Netflix. And he's got some really great ways to approach product management.