Better Together: How Mutual Respect, Curiosity, and Shared Goals Create the Best Product & Engineering Collaborations

Speaker A: Welcome to our podcast, Practical Product Management. It is a podcast about how there are lovely theories in the world, great books about product management, but product management is done in context and needs to be practical for where you are and the team you're on. And now that Marilyn has made me giggle, I will say welcome to the podcast. Alicia. We're so happy to have you here. Why don't you tell us a little bit about yourself and then we'll dive in.

Speaker B: I am so excited. Thank you for inviting me. Like, I'm honored. I'm super excited. This is gonna be so fun. Um, so of course, I'm Alicia Crony. So I'm an engineering leader, been an engineering leader, started as an ic, um, and let's say I'm currently the Director of E Commerce at Moderna. For the past two years, I've been doing that. We've spent a lot of time actually into E Commerce payments, a little bit in ads, billing spaces. Um, I kind of think I have one of the most fun jobs in the world. I love building. Yeah.

Speaker C: Well, it's nice to have, uh, it's really nice to have you here, Alicia. Thanks for joining us. And it's really nice to bring two of my favorite people together. Um, so I think this is going to be fun. And yes. Sorry, everybody. Right before the countdown ended, I said something a little silly and got everybody giggling. But I think we all know that happens in Maryland land. Um, so just, just, you know, being a little crazy at the beginning of the podcast. Um, Alicia one, like, I've had the privilege of working with you for the past couple years, so thank you for that. I always, uh, you know, you know that, that people working with you is a choice. Um, and so I've had a lot of fun, but one of your superpowers, one of the things I've observed about you is you have this innate ability to bring together a lot of people, cross functionally, um, and create these really highly aligned, motivated teams of people, from engineering to product to TPM to regulatory and compliance to accounting, um, and people that are more purely business and get them highly aligned against a goal, um, and then driving all in the same direction. I think that's very unique. Um, so talk a little bit about, you know, maybe how that came about or, you know, is it intentional or is it just Alicia magic?

Speaker B: I like the Alicia magic that might be. Might start saying that. Exactly. Magica. Um, first of all, thank you. Actually, I think, I think it's just that's kind of where the fun part of the Job is. So being an engineering, I feel like you can sort of take maybe one of two roles. You can be like the engine, like you're driving things, things, things forward, you're building things. Or you can sort of be the, uh, order taker where it's just like, yes, you're building things, but it's like, here's what you build. All right, we built it. Like, that's it. Like, cool, maybe we walk away, we build something else. Uh, and so I don't like that one. And so to do the first one, um, what I like to tell teams is just forget about the titles for a bit. Yes, we all have our own skills. For me, it's tech. Like, I'm going to come in with, here's how I think we should build it. Here's not a great way to build this to meet our goals, right? Like, let's try this. It's the people, leadership, um, product managers. You're coming in with vision, you're coming in with requirements, with understanding customers in the market and bringing that knowledge. Everyone comes in with their sort of slice of the pie. But instead of seeing that as like, you can only operate in that space, I see it more as, uh, this is like the value, the skills you're bringing to the conversation. And now we just work together. And I've been an engineering leader at different teams, different companies, different industries and the job's never been the same, right. And you kind of have that core trio. You have PM design, engineering, probably some of the people you kind of talk to most. You've got TPM if you expand it to four. And I've never seen those four, like operate, ah, in the exact same way. But I've had such like, fun, pleasurable, effective teams with that. Uh, and it's about just kind of finding like, where do you all fit in that? Because you, you bring, maybe you have a, you know, PM who's incredibly good at vision, but like, maybe the worrying of requirements is a little bit more collaborative or maybe, right? Like you have an engineering team who's like, I really want to know all the things about the customers, right? And they're like, can I talk to the customer? Right? It's going to be a little bit different, I think, where you're at. And so just finding that what works and with that balance.

Speaker C: Yeah, it happens in context is what you're saying.

Speaker B: What it does, uh, it, uh, does. And I will say it only works with trust because I've seen it, right. You can kind of swing too far and have somebody be like, why are you all up in my business? Right? Like, half, half. Maybe a, uh, designer or PM who's just like, why are you asking these questions? Why are you. Why are you questioning me? Right? Then instead of asking questions or questioning someone that's like, ooh, we didn't build the right trust there. Right? Like, I'm not here to tell you what you're doing wrong, which is to understand so we can build better together.

Speaker A: Yeah, that's an interesting point, because I think there is this really fine line. Even as a leader, there's really fine line between being super curious and trying to give. Ask questions, to give a little direction and a little bit of like, here's some. I have some questions to help us with boundaries and people being like, you're a micromanager. And you're like, whoa, whoa, whoa. I did not tell you what to do. And so I think. I think the trust element is so important. What do you think? Like, how have you gone about that in terms of building trust? Like, what's your. What's your, like, way of going at it? Because probably everybody does it a little differently.

Speaker B: Oh, that's a good one. I. I like to start by really telling a team, like, this is why we're here. And that. That's, uh, kind of goes back to, like, that vision. And then, honestly, I feel like there has to be space. Where is everyone bought in? Like, is it the right vision? Right. And if you have questions or you think something should change, like, I do think people should, like, there should be space for people to be like, I want to change it a little bit, go this way. Honestly, I think that often does the trick. But beyond that, I really think on an individual level, it's like, put context, frame why you're asking a question. And that's actually. It's actually something I really learned from my engineering team. So to, uh, to sort of throw myself under the bus a little bit, I tend to. If you talk to engineers that have worked for me or with me, one of the things they tend to say is like, yeah, she asks a lot of questions. And I had, uh, some of them, at some point, they were like, I'm honestly afraid to answer because they were like, what if m. I answer wrong? And when I found that out, I was like, no, that, uh, is not the point of me asking the question. That is terrible. And so I had to really think of, like, why is that the kick? Like, why are they going there? And that's actually where I realized, like, that is the, that is the trust factor. So have it frame like before you ask. Hey, I'm asking because I'm actually, I really want to know your thoughts. Like there's no right or wrong here or I'm actually learning something new. Like you're going to teach me something. I'm not asking because like I have an answer in my head and if it doesn't match that I'm going to be angry at you.

Speaker A: Right.

Speaker B: So, so framing that and maybe reminding folks like you're the expert. Right. I'm just here to, I'm here to be curious and sort of maybe try to understand the different pieces and put them together.

Speaker C: I think this conversation is really interesting because it's led me to a bit of a self realization around questioning. Um, because I'm very curious. Um, and I don't like. So I don't know if you know this Alicia, but Leah and I have worked together for a long time.

Speaker A: Maybe over.

Speaker C: I m don't even want to say because you know we're, we both started working when we were five. Um, but we worked together a long time ago.

Speaker A: Right here is Marilyn.

Speaker C: That's probably from me actually. One of my favorite things about Leah is she's so strong on um, platform. Um, and we were paired together on a particularly difficult project um, at Amazon. And when we, when we started um, I think there was a, there was sort of a how do we fit together moment for us. Um, but we walked through that and here's the thing. She knows so many things that I don't know. Um, even though she's now worked in the front end part of the world but like Leah has all of this knowledge that I don't know. Um, and so if I'm able to sort of like ask questions, I'm not, I'm not being a jerk. I'm like I'm either genuinely curious or it's going to help inform some thought I have on my side. Um, and I think I've carried that. So thank you Leah for teaching me that lesson. Um, I've carried that through my career. Um, and I think one of the things you'll hear me say as a leader is like I'm curious and I have an opinion but I'm very rarely the decision maker. Decisions have to come up to me. There's a freaking problem. It doesn't mean that I don't see a broader picture. And so I ask questions to figure out how the puzzle fits together. Uh, because that's kind of my role is just to make sure the teams are all running in the same direction or make sure that people are all have the same thought in their head.

Speaker B: Right.

Speaker C: Because we can all think of the same word, and it'll have different texture, context, and meaning around it. And the only way we get to sort of a common understanding is to sort of say, well, you know, hey, does it mean this? Does it mean that? What do you think about this scenario? And that trust factor and being able to. To have the conversation around the thing I think is critically important. Um, so thank you both for leading me down that little mental path this morning.

Speaker A: But I think. I mean, I feel similarly, like, I have had. I had a principal engineer at one of my last jobs that he always said, man, Leah always has an opinion, but with a. But if we give her data, she's willing to change her mind. Yeah. And I'm like, that's true. I hold my opinion pretty loosely when I know other people have more information than me. And so. But I mean, I. I can't come into the room and be like, I am a blank slate. What are we gonna do? Like, that's, uh, not, you know, it doesn't get us anywhere. Right. So. So I have done some research. I know what's going on. I have some idea. But there's often pieces I don't know because I'm sitting at a distance from it. And there's pieces they don't know because they're sitting at a distance from what I'm in charge of. And so my goal is to always be like, well, I mean, I have a thought about that, and then people are like, okay. And then I share it. And if someone says that's not how it works, I'm like, enlighten me. Yeah, right? And let's go. Right. And so I. But I don't. I just don't feel like. I don't think it does us any good for me to just be opinionless. Right. And have no idea where we're going. But it also doesn't do me any good for me to clutch my opinion and be like, we're doing it my way because that we would build terrible things. Like, I've done that already. I did that early on.

Speaker B: Right.

Speaker A: So.

Speaker B: So that's a superpower. I think people don't value enough, uh, changing your mind quickly and easily. Like, that's a. That's a skill. I feel people tend to be so on the. Like, well, if I have an opinion, then I just have to be right, and I'm never gonna move from that spot. No. Right.

Speaker C: But you've seen that. So let's. Let's go back to the Alicia superpower. Cause I. I have watched you work with people who are not interested in learning more. They're not curious. They don't know how software is built. And they walk in the door with a thing in their head and they want to stand on the mountain and raise their little scepter and be like, I am Thor. And this is what we're doing. And don't question. And, oh, by the way, I already told the CEO it's going to launch on this day. And here's some pictures that I made up with a design team that I've never shown anybody.

Speaker A: Yeah, that's.

Speaker C: That is a really negative behavior pattern. And I have watched you break that down and build trust. So tell us more.

Speaker B: Oh, meeting them where they're at. Because, like, if they're. I like to. Honestly, like, I like to start with the simple thing of, like, assume the best. Even though, like, that interaction, it's so negative, right? Like, when you're in a room, we've all been in rooms like that, and someone's sort of coming from that standpoint, they're certain they're not going to move. They're kind of telling you there's no room for you to even be here. That's what it feels like, right? So I like to kind of go, wow, like, how did you get there? In my mind, that's not good. That can't have been a great journey for you to get there. And so then asking, like, I like to state things in a. So what you're saying is X, right? Like, okay. And then they're like, yes, yes. So they start to feel heard and they are being heard. Um, and it's the. I think the being able to see where the other person's coming from and even understanding it without agreeing. Because I really don't agree with anything that you're saying in that moment. Right.

Speaker A: But I'm not going to say that

Speaker B: that's not going to help us out here. But, uh, but just being able to say, like, okay, okay. Like, I. And then just that start. I feel like that just starts to build that little bit of rapport. Just the tiniest amount of trust. And then just being like, well, but here is how this piece works, right? Like, I can't do these things that you're saying. And that is not a, um, me thing. Like, feel free to ask other people, right? Put other people in this spot. Like, this is just loss of the universe. Can't. You can't go faster here, or we can do this, but you're gonna have all these problems down here. And like, coming in sort of with. With these facts and then kept showing that, putting your cards very on the table. I think, honestly, transparency is just such a good way, uh, to fight when people are so entrenched deep into where they're coming from. Just being very open with. Like, I've looked at all these things and like, here's. Here's where we're at. You know, that's. That.

Speaker A: Yeah, it's a good point. I. You know, it's funny as you're saying that, I'm thinking one of the things I tell my coaching clients often, that's something that I learned in therapy a bazillion years ago. I lean heavily in those scenarios on the two words confused and concerned. I. I'm confused about what you said and how this fits together. And, you know, so I'm confused, or I'm concerned that we're not on the same page. So I. Let's. Let's see if we can come back and work it out. And part of the reason I do that is those words make. Puts it on me. I am the one not understanding. So please lean towards me and help me understand. Like, they love to be like, let me help you. Right? And then, so when they do, you get information that you can go, ah, uh, now I understand why I've been confused, because this thing is not possible, right? Or you can then take it kind of to where you were talking about. And I tell people all the time, when you do that, the other person leans in towards you and wants to be like, let me help you. And often then you can kind of untangle the conversation. You meet them where they're at, and, um, because they're at, I'm really sure about how to do this. And you're at, it's not going to work.

Speaker B: So, yeah, and I really like that because then once they get into the, okay, we're leading in, I like to add on top of that the, like, none of us as people are the problems. There is the problem, uh, like, which is nothing to do with us, really. Right? Like, that's just what is. If we all quit that day, the problem would still exist. And so then being like, okay, we're all right, like, let's bring it back to what is the thing we're trying to achieve or solve, right? Is it this? And then, you know, hopefully they've. They've leaned in. You're Kind of there. Hopefully, then you can start to untangle. I like that word you use there. Towards something that can work.

Speaker C: Oh, my gosh, you guys are so much more evolved than I am, because I'm going to take these learnings in this conversation and I'm going to use them in my life, but my brain is going. Or that person's totally the problem.

Speaker B: And,

Speaker A: I mean, they have bad intention and they're terrible.

Speaker C: They don't have bad intentions. They're just dummies. Like, they. I didn't say that. Not qualified and not curious. Um, and I do. So, like, let's. Let's bring this back to our audience, because we have a bunch of product managers of varying. Varying levels on. On our listening people. Our listening people, or whatever you call people to listen.

Speaker A: Hi, guys.

Speaker C: Um, I think what happens, especially with junior people, is they are letting their ego write the checks. And so in some instances, they're so completely convinced that they now have this job title that says that they define these things and that they're the smartest person. They're reading it as if they're the smartest person in the room. And their job is to go direct this other group that. That can't possibly exist without them. Um, that they have this sort of really arrogant place in the world. And it's not that the person's a bad person, it's just that they don't understand how the things get done. So let's. Let's sort of, like, craft a message for those people for just a minute, um, and talk about how, like, you need to walk in the room with the authority over the things that you know for sure.

Speaker A: Yeah, right.

Speaker C: You're bringing this to the team. And you said this really nicely earlier, Alicia. You're bringing your skills to the team, but it's a piece of the piece of. Um, and those pieces don't stay separate.

Speaker B: Right.

Speaker C: It's not like your piece has boundaries. Um, and you got to figure out how to mesh with the. With the intelligence and the authority of everybody else in the team, um, to make a pie, because you're not the only damn piece. And so how would you talk to a more junior person? And I get, like, confused and concerned and all that's really nice, but, like, someone kind of needs to say, friend, you can't build software by yourself. You're never going to achieve your goals if you go at things this way.

Speaker B: Yeah, well, I'll give the bad answer first, which. The nice thing is being engineering is you can say no, and then nothing Gets built. That is such a. Like there's there a lot of power in that. I don't. Not a big believer of just like, no, walk away. But the, just the, you know, the ability to say like, where are the builders to like junior pm? Like that's not going to work and I'm not going to build it. O king. Um, I think that holds a lot of power because it's a bit of a big like red stop sign. Like you're going down the wrong direction. Um, and then having that conversation of like. Because often I feel like you kind of do see those conflicts I think probably between PMs and engineering when they're like, it's this, we're gonna build this in this way. Like, boom, go do it. And then you're like, no. And here's why. Right. And then I like to. Especially to your point, Marilyn, if it's a bit driven by ego, I kind of like to bring it back to success. Like, you want to succeed, right? I want to succeed. Do we agree on what success looks like? Well, that like you gotta trust me, what you were trying to do, it's not gonna get us there. It's gonna feel horribly and right. Like, and if you want it like if that conversation keeps going like you, you honestly, you may have to escalate to like five. We have to go get a tiebreaker. Right?

Speaker C: Yeah.

Speaker B: And then it's like present your present sort of your point. And when you come into something like that with like that's very fact based, uh, of hey, I want to build X. I'm super bought into whatever we're building here. But here are like three reasons why I can't currently or right. Why I think this is a bad idea. Those are hard to like, you can't just say no. Those are hard to refute. Right. Like then it's more, okay, let's talk through them. Like we can work out how we resolve it. Um, so I like to. I guess I feel like you fight ego with facts. Like eventually it'll get there.

Speaker C: Yeah. Ah, and Leah, you're that you're the opposite use case for me. Like you're a you. Like when I met you, you were just like this rock star product manager. Um, and you frankly won over a bunch of engineers that never wanted product managers. Um, Leah sort of walked. She walked in the door to help build Amazon local registrar and she run it. She ended up like leading all of the teams that built the payment systems at Amazon because everything had to change. Like everything had to change. And Helping those guys understand why I, um, think, frankly, was a crazy feat of, um, influence and communication. Um, and so I feel like you guys approach the problem from a very similar. Similar perspective, um, on that shared success thing.

Speaker B: Yeah.

Speaker A: I mean, I walked into those teams that didn't have. They didn't have product managers, and they were like, we m. Don't need one. And I was like, you do, but I'm not going to tell you that exactly. How about I just sit in here? How about I just hang out with you guys? Why don't you tell me what you're doing? But I think one of the things that you said that is really interesting, Alicia, is, like, when you. If the team wants to be successful, very rarely is there somebody on the team that, like, I hope this team tanks. Right. There's. Right. I mean, maybe once in a while, there's a real bummer of a person trying to make things break, but we know who they are, and we basically, like, cordon them off. Right.

Speaker C: And.

Speaker A: And get rid of them. But. But in general, the people in the room want to succeed. And when everybody agrees to that, then there's room for, like, all right, let's have a conversation. Because, like, the truth is, I.

Speaker B: It's.

Speaker A: It's an interesting balance for me. When I think about what you just said, Marilyn. Like, for me, it's always been. I. I know that if we build exactly what I think we should build, it's probably going to be wrong. Like, I know only as much as I know. But what I do know is that we have to make decisions quickly and. And move and then figure out, uh, learn on the fly. Like, learn while we're running. And if we're going to sit here and spin about every single decision, I don't have time for that. And I will let you decide and let you fail if that's where we're gonna. If we're gonna stay there too long, I would rather have lots of really cool, fast conversations and try some things and see what hits and go.

Speaker C: Yeah.

Speaker A: And so I think as a product manager, my m. Willingness to be like, I mean, it doesn't sound right, but let's do it. Has sometimes won over whole teams. For me, being like, this doesn't sound like a good idea, but I'm in. Can we start Monday? And everybody's like, okay. And then it makes them stop and go, okay, I better be sure. Right? If I'm pushing this, I better be right, because this person just gave me rope. Right. And. Or. And this is a. This is A very generous thing to do. To say I don't, I don't think it's right, but I'm willing to do it because I trust you. The trust you do when you, that you build, when you say that to somebody can, can overcome all kinds of problems.

Speaker C: Yeah.

Speaker A: When you say I trust you, even if you're like that idea, this is a little dangerous or I'm not sure. Right. But I've been wrong. There's plenty of times that I've been like, I'm not sure about this and then it works out fine.

Speaker B: Right.

Speaker A: And if it doesn't, I'm not like a, uh, dology. So I'm like, well, cool. That's what disagreeing commit looks like. Let's shift gears. What do we need to do? Let's try something else.

Speaker C: Yeah.

Speaker A: Right.

Speaker C: And I think this whole thing is predicated on two things. A trust, uh, and B, how fast can you find out if you're right or wrong?

Speaker A: Yes.

Speaker C: If it's an 18 month build and you're wrong, it's very expensive.

Speaker A: Yes, you're gonna be wrong.

Speaker B: I just, there's just no project that takes buts in. You really hit it out of the ballpark. That's just not possible.

Speaker C: Uh, you're setting yourself up for failure if that's your expectation.

Speaker A: Yeah. But don't you think that something about like, if, if we all are proponents and love Agile and iterations and learning fast and failing fast and all those things. Some of that is we have. You have to start that. That doesn't happen at the team level without it happening at the individual level.

Speaker C: Yes.

Speaker A: I have to be willing to try something, be wrong, try again, fail fast at. For myself. And if I am so un. Like my, I lack confidence in just trusting the process. I won't release the, the like team to do what it needs to do.

Speaker B: I can, I can imagine at the PN that's tough because I do think engineering tends to very often take an approach of like, what do you mean you've changed your mind? Like us, you've probably gotten that from engineering teams. Right? We, we tend to be like, you gave us the info, now we're building and that's that.

Speaker C: Right.

Speaker B: Like we're gonna build it, put it out there, we can do it. Right. Um, and so that's a, that's where I would, I would actually encourage PMs. Like, gotta have that conversation with your whomever your engineering leader like counterpart is on. Like, what is it, what is it going to look like when you do Change your mind, which I think is very healthy. I'm actually very with you to like, there's no way you can just get it all right in one go. So when you learn new data, what are you going to ignore it? That doesn't make any sense either. You're not going to get the best outcome. So like, how do we take in that new data in a way that doesn't bomb the engineering team? Gets velocity out the door, but like we're still taking it in and getting better outcomes. Yeah, yeah.

Speaker C: And that interface is so key, um, because I do think from a, from a personality standpoint and I'm going to wildly over generalize. I think a lot of product managers are curious and adaptable and want to go like, learn new things and test things and um, and figure out what's going on with the customer. And they have an early thesis and they, they create a solution pretty early on and then, and then they go and they learn as they, as, as things happen or as pieces of the product get rolled out. You know, obviously every time you put something out in the universe, the customer touches it and your directions change.

Speaker A: Like, oh, right.

Speaker C: A lot of engineering teams or a lot of engineers are uh, structured, uh, their solutions based, um, they actually have in their head probably a whole idea of what the solution is going to look like in 18 months. They're happy to build the piece now, but that sometimes churn, churn or decision flipping in product like blows up their heads. And so this, this notion of how do we keep information bidirectional so that the engineering leader, maybe not the whole engineering team, because the junior engineers will blow up, um, understands the things that are known, known the things that are, you know, we, we think of this, we have a pretty strong feeling, but we're going to go understand some of these things further and they may change the approach. Um, and frankly, like understand the data exhaust coming back in, whether that's from users in production or, or data, uh, coming back in through the platform, like what's happening at the edge or data coming in from, you know, the systems to know where things are failing or what's going on. Like, you as a group need to understand all of that information so you can see where things are likely to change and making sure that your engineering counterparts, whether that's your engineering manager or your principal or whomever is bought, like bought in. And also asking questions. Hey pm, I'm seeing this happening in the servers and this to me signals something. We built something weird here. The product manager is obligated to have that conversation and understand that.

Speaker A: Yeah, yeah, yeah.

Speaker B: Well, that's. You have to have engineering teams, but don't just understand the customer, but are interested. And that. That is something at least in teams that I leave. Like, I. It really bothers me if I'm like, if there's an NGA team and they're just purely focused on things, the tech, and not considering who's using the tech. Right. Why are they using the tech? What are we going to do in six months with it? And none of the, like, answers to that are, like, written in stone, but you have to have an answer in that moment because it informs so many technical decisions. Like the, the thing Marilyn, you said about, like, they probably have an idea of what it looks like in 18 months. 100. Yes. Like, every time I've built something, I've sketched out, like, my team sketched out a much bigger system that, uh, you

Speaker C: know, hopefully one day maybe will come

Speaker B: to pass, maybe not. But that's not the point. The point is, like, we do that because in a healthy relationship, like you and the pm, we're out there. You understand the customers. You're so aligned on, like, the future direction, the wire, building it. I really liked what you said about, like, you need to highlight the areas of, like, low confidence, high confidence. Like, what's likely to change or change probably not going to happen. Like, where do we feel we have to be right? Because it's also really hard to change. And you need engineering to inform that. Like, to tell the pm, like, this thing here, if we get this piece wrong, that's. That's a year. It's super complex. Got to get that right, all these other things. And if we're wrong, like, fine, Sprint or two later, like, we can totally go in a different direction.

Speaker A: Um, and I would say, I've seen Marilyn do that. Really seen her. I've seen her go in and say, you know, I don't think, um, we're learning something new. We have new information. Some we. We likely need to come back and change, explain the situation, but then ask, what do you guys think we should do? Yeah, not just like, and now we must pivot. I'm gonna go right. 20 new user stories and, you know, or whatever, it's like, no, what do you guys think we should do? Should we finish the swing on this thing and then come back? Should we. So I've watched you do that, and I think that there's a. There is a, um, an art to that that is about respect and being willing to say, I know I'm coming in to throw you a curveball. It is the curveball I've got. It's also a curveball for me usually. But I've had time to kind of come to terms with it while I've been looking at the data and talking to customers. And now here we are. And sometimes I'm even kind of excited about it, quite frankly. I'm like, oh my gosh, I learned a new thing. And the team's like, oh, please stop learning.

Speaker C: Stop learning.

Speaker A: Would you please knock it off? And it's like, I can't. Right? Like it's not, it's not what I do. But I've seen you do that really well and ask those questions and be respectful of the. I, uh, know this is hard, but,

Speaker C: but we all need to pivot and I, I'm going to go back to what you guys were saying about common understanding of success. So I think one of the primary messages that the product manager has to carry is why is this important to the business?

Speaker A: Right?

Speaker C: And so if you can say like, hey, our business driver, our uh, top line business driver is X revenue, whatever. Like you, you've got a top line business driver and here's where we're at and here's what the data say. And oh, by the way, I learned this new thing, um, understanding that this is our top line driver. Like there's about six ways we can solve this, right? I need help because we are collectively successful.

Speaker B: Yeah. Yep, yep. And that, yeah. I, I've so to plus one, delete. I've seen you've come to me and said crap.

Speaker C: Never good when I start a conversation like that.

Speaker B: Oh, I, yes, I actually uh, very much agree. But I want to add a caution because if see so it's that like that bi directional height of information. You're probably like engineering products or some of the closest partners in these working environments. But I would say the caution that I'll add what I've seen and it's as the engineering side actually I think I tend to add to this problem is products can get too sucked in to day to day working of then like sitting with the actual engineers and like you know, they're coding up things. They're, they're, they're like, oh, how does that look? They're like, no, we're gonna do it a few pixels to the left, right?

Speaker C: Like, oh, right.

Speaker B: And then it's just like, oh, no. Like then it. You've got this wonderful likely like individual right. Like human connection and relationship and, like. And that part is awesome. You have to keep that. But that's almost where, like, I want to go against the advice that I said in the beginning, you should forget about the titles for a bit. Rigid lines. But know when to bring them in. Yeah, them has to step out. You got to be ahead. You got to be looking to the next thing. Once you know, like, all right, they're going, they're rolling. Let them. Let engineering roll and go figure out the next thing. The next thing.

Speaker C: That totally cracked me up. Um, because I had a, um. I had a team in a previous company, and, you know, you look at. You look at team health metrics, right? Um, how is everybody doing? What environments are they working in? Blah, blah, blah. I constantly had this product manager pop up with, like, a number of commits. It was like, what in the hell are you doing? You're not doing your job. And, like, I would go talk to the engineering leader and the engineering team, and they're like, you gotta get him out of our stuff. We've got no vision. We've got no. We don't know what we're building. But he's in there making, like, building things. And I'm like, go to my product leader. And I'm like, what is your guy doing? Like, why the hell is. Like, why is he showing up on this report? A, um, because I don't think he should be able to do them right. Um, and b, but, like, what is the business value? Why are we doing this? Why. Why should I, as a leader, continue to fund this team? Because that's my decision, right? I have all of these brilliant people, and if I look at them as resources, if you're not solving a problem for my business, well, there's lots of other problems. And I can move people around to solve a real business problem. Um, and this is my person that should be out selling the vision, telling me why we should invest the money, showing me the business return. And he's committing code and making me crazy.

Speaker B: I mean, we. We. Like it. We're excited. We suck everybody in. But no, that's a, uh. That's. That's terrible.

Speaker A: I. But I mean, I absolutely have had that same scenario where I've had an engineer, you know, a former engineer that becomes a product manager. I think it's one of the hardest things for product managers to come out of engineering. They can. I will. I had an engineer. I love him. He's one of the best. Ultimately became one of the best product managers I've ever led. But when I first when he first joined me, he was an engineer, and he became a product manager. And I would sit in our one on ones. I would be like, you are a product manager. You are not an engineer. If you want to be an engineer, I'll get you a job on the engineering team.

Speaker B: Yeah.

Speaker A: And he was like, sorry. And I'm like, no, for real. I'm, um, telling your engineering counterpart to turn off your access to GitHub. Yes, you're done. And he was like, okay. And I was like, no, for real, you can't write code. If you want to write code, I'll find you a different job, and that's fine. No, no harm, no foul. We. We have, uh, engineering positions open, but if you want to be a product manager, get out of the code. It's like. But what's funny about that is a few years ago, we. I was working at a company and we sat down with a potential partner, and I. I just loved their CEO. I thought he was so great. He was an engineer in the back. He used to be an engineer, and he was doing all this stuff. And during the course of the conversation where our two teams were meeting, one of his engineering leaders said something. And the CEO said, yeah, I mean, I'll fix that. Blah, blah. And I was all, what? Uh, the whole meeting stops. I said, what? And he's like, what? And I said, you let him write code. I said to the, to the CTO, I said, you let him write code. And the CTOs like, I can't make him stop. And I'm all, you need to get out of the code

Speaker C: position on the field.

Speaker A: Exactly. The CEO just like, ha, ha, ha. The next time we sat down to meet, he's like, they don't let me write code anymore.

Speaker B: Thanks.

Speaker A: And I was like, you don't belong in there. And he's like, you're right. He's like, I was making a mess. He's like, I was going in and fixing things that didn't need my, you know. But we all have to play the seat. Like, get in the seat that yours. Doesn't mean that we don't have these muddy places where we overlap in each other's space. And, uh, I'm going to do this TPM's job, and the TPM is going to do my job, and the engineering manager is going to do a little of this, and I'm going to. That happens. But there is a primary seat I'm sitting in, and I need to sit

Speaker C: in it or else the job doesn't get done. And I think that's where you see like a lot of, I mean, Alicia, you were kind of going this direction. I think that's where you see a lot of teams end up with, you know, they're, they are cranking on this next feature. But when you're starting to say, okay, what, what is the next problem this team is going to solve, like, we're close to launch. Like, yes. And we're going to grind through the next few sprints of getting this thing out and into customers hands. But what are we doing next? And the product manager is like, oh, I gotta go do work. And it's like, no, my friend, you're not playing your seat.

Speaker B: Yeah, uh, you're too late. Like kind of the trades left the station. Now what are we going to do with the beat? Engineering. We'll make it up. We're great at that. We'll fill the time. Of course you will go fix stuff that we're like, all right, I guess we got time. But as, uh, even like coming from engineering, sometimes, you know, you're like, yes. Love it. We've got some time to fix these things. But that is not, uh, the right choice for the business as a whole.

Speaker C: Yeah.

Speaker B: And we're all part of the business. Like, that's all part of that one entity balance.

Speaker A: Very cool. So I think we're ready for the lightning round. That time went so fast.

Speaker B: Yeah, way too fast.

Speaker A: We could. Like I said, there is always a sweet spot in these conversations where if we don't. If I don't. If I don't insert the lightning round, we're gonna talk for two more hours. So I have to have to insert the lighting around. All right, Alicia, tell me, what is the. What is your favorite thing you've ever built? I know it's like choosing among your children, but I would love to know literally though.

Speaker B: Like, literally my kids. This is horrible.

Speaker C: Uh.

Speaker B: Oh, my gosh. Oh, my gosh.

Speaker A: Okay.

Speaker B: I'm m actually gonna say something really unconventional, I think. Um, I was part of a team. It accompanied one thing. At Offer up, they did one thing which is like local e commerce, and they wanted to do something completely different for the first time. And they tapped me to do it. One of the favorite things I've built because everyone gets to come in with the, like, we're not the expertise in this, like, new vertical. We're all gonna learn and work together and figure it out. That's where we built, uh, offer up jobs. So it's like the ability to like, find and Post like a local job in your community.

Speaker C: Cool.

Speaker A: What about you, Marilyn?

Speaker C: So I think my favorite thing I've ever built is not a product. Um, it is, it is metrics. Um, and most teams that I've walked into think they have metrics. Um, and I don't think they have metrics. And so being able to build not just a robust view of what the systems are doing, but what the customer is doing. Um, and so you have the qualitative or, sorry, quantitative metrics on what's happening with your systems, and then that layer of qualitative metrics where you start to get people's feelings and helping teams view their systems and their customers from a data driven way is my favorite thing. I build.

Speaker A: I love that.

Speaker C: That's very cool. How about you, my friend?

Speaker A: Um, yeah, so there's. My first answer from a product perspective is I loved building. I love sort of being employed employee number one on Amazon business. Like, I love designing the invoicing solution for Amazon business because I got to do it. Like, we don't know how to do this. I'm gonna do it from scratch. And I got to sort of, I got to draw the architecture and show it to a principal engineer and be like, that's right. And he was like, not bad. You know, so. And then start to lay out where we were going to go. And so getting to be sort of the very first person thinking about that was super fun. But I. Similar to what you said, I think, you know, during the pandemic, I was leading a, I was leading an engineering, design and product organization that was not high performing when I got there. And over the course of the worst moment in travel at a travel company, I rebuilt a high performing team and I made them believe that they could, they could all work for me, that I wasn't just a product person. Right. And, um, and that, and they were, I adored that team. Like, they, we, you know, we had some problems. There were lots of conflict. There was a lot of that. But man, they, they stuck with me. And I would just say, okay, will you give me a chance? Will you trust me? And they did. And so I, you know, I think that that's, I'm really proud of that team. So that's awesome. All right, um, Alicia, if you were going to, if you wanted, if you wanted engineers to understand something about PMs that you think that they don't normally know, what would it be after your, all of your experience working with PMs,

Speaker B: such a good one.

Speaker C: Uh,

Speaker B: but they don't have all the answers. Yeah, that would probably be one. Because I feel like engineering tends to operate. We look at things like it's just things to solve. Right. The way you solve it, you go get answers. You have to do maybe research. You look at how other companies did it. Like in, I mean, of course, like, there's tons of change in the industry itself. I mean, look at AI. Like we're going to change how we look at things. So there's even there, there's lots of growth. We know we can't literally look at all the answers, but it's still a very right, structured, logical, analytical field. And actually think product management, you've got so much of the analytical logic, but it's also storytelling feeling. It's also very like, you know, vague and messy and money. I don't think, you know, especially your junior sds, they're just like, uh. What do you mean you don't know?

Speaker A: Are you guessing? Yes,

Speaker B: exactly.

Speaker A: Yeah. Marilyn, what would you want PMs to know about engineers after all these years of working closely to engineers?

Speaker C: Um, I mean, it's going to be the same answer for both directions is that you are better together where, like, you're better leveraging each other's strengths and really becoming, you know, different facets of the same entity.

Speaker B: Yeah.

Speaker C: Um, and pooling your strengths rather than trying to separate and segregate things. And especially, especially in this day and age where, you know, tools are getting smarter and things are getting easier and, you know, people's jobs are going to change. They're not going to go away. Um, I don't think they're going to go away, despite all the weird headlines. Um, but they are going to change. And so you need to exercise the same skills to build software. To build software that solves problems for other humans. You all need to, you need to exercise those skills and you're going to have to different facets that are necessary and it's not you against your team. Like, not like I can't work with this engineering team. Well, you know what, that kind of tells me something about you too though, my friend.

Speaker B: Right.

Speaker A: Yeah.

Speaker C: Uh, because if you can't work with an engineering team, that's kind of your job. Like, I don't, I don't know how to tell you this, but.

Speaker A: Yeah, but you need to get a new career. Right.

Speaker C: Maybe project management feels fun to you. No. Um, yeah, you're better together.

Speaker A: Yeah. I would also say something similar. I, um, I think don't judge the team you're on now by a team. You were on before.

Speaker C: Yes.

Speaker A: Good or bad, Deal with the one you got. Dance with the one that brought you.

Speaker B: Right.

Speaker A: You're in like. You're on a team, so be on that team. I. And I.

Speaker C: He.

Speaker A: He will laugh because I tell this story a lot, but I worked with an engineering partner at Klarna, Marcus Grantham.

Speaker B: There you.

Speaker A: I see you.

Speaker C: Who.

Speaker A: One day, he was my engineering partner, and we. So he led the engineers, I led the whole domain, but was running the PMs. And so we worked together very closely. We shared an office. And one day I turned to him and I said, you don't like product managers. Like, it came to me out of, like, the. Out of the ether into my brain. And I said it out loud. I said, you don't like product managers? And he said, yeah, I don't. And I was all, why not? He's like, I've never worked with a good one. And I'm like, damn. And I said. I said, me included. He's like, you're all right.

Speaker C: Thanks.

Speaker A: And he said, all right. This other guy, Daniel Jensen, he's like, jensen's all right. You're all right. He's like. But the rest of them never worked with a good one. And I said, I need you as a leader on my team to give my PMs a chance.

Speaker B: Yeah. Yeah.

Speaker A: I need you to try again. Even though you've worked with bad PMs before and you think you know everything, I need you to try again. And he was like, okay. And he did. And I'll tell you a little secret. He's now a VP of Product.

Speaker C: Stop it.

Speaker A: So part of his problem was in the wrong feed, right? Like, he didn't like PMs. Um, because he was like, I can do this better. Right? So. And he.

Speaker C: And he's this great.

Speaker A: He's a great product leader. He's also a great engineer. But we have to focus on the team we're on and not be like, I miss my best engineer I worked with at that place. Or, you know, oh, this person's terrible. Or, I've never worked with a good pm. No, give. Give your PM a chance. Give your engineers a chance. Give your designer a chance. Give your stakeholders a chance. Give the team you have a chance. You won't build a good team looking over your shoulder.

Speaker C: That's such a good reminder.

Speaker B: I like that. Uh, that's a powerful one. Yeah.

Speaker A: All right. This was so fun. I'm so glad you came to talk to us, Alicia.

Speaker B: Thank you both for this. Honestly. We could go on and on and on for hours.

Speaker C: We could keep going. That's why we have the lightning round to stop us. Stop us before we do. Another hour.

Speaker A: You'll have to come back. This is just a good.

Speaker B: I have so many things. I'm like, I am.

Speaker A: Is there anything you absolutely must share that you're like, oh, I really wanted to talk about this. You can have, um. You can have a couple minutes if there's anything you think we missed.

Speaker B: We didn't touch on iteration. That's such a tough one. And I have a. I had a small, small story. It was drawing a design to my engineers, which I. It's. As the technical leader. But you've got so many smart people sitting behind you, looking at. You draw boxes on the screen. Um, I was trying to explain to them, like, from a tech perspective, when you build iteratively, like, what do you guys think? And I used to download all, like, let's say you build a mobile app that, I don't know, you sell something. And I was like, okay, like, maybe you could build the screen. All right, cool. Now you've got buttons. You can do this. And then your CEO walks in and is like, we brought a lot of money. Like, we spent it all. Funding's gone. Are you. Is it done? Like, what do we have to launch? We have a screen with buttons that does literally nothing. So I was trying to explain to them, like, iteration isn't build things in little components. It's like, build a thing that works, that does a real thing. Right? So in this case, like, screen with buttons that makes a purchase. Like, maybe it's, you know, you can only do one payment method because that's all we had time for, but it's real. Like, someone can go use that. And I was explaining that to them, but I realized that the thing that I think is so tough that I. I feel like I still haven't figured out is that there's the engineering side of that. But that only works with the product manager, who can also think like that.

Speaker C: Right.

Speaker B: Who can break it down in that way. And that's like, one. Yeah. I feel like I've seen it. I've seen it done, uh, like, better. But I still feel like in my career, I'm like, there's better. There's got to still be better that. That we can do working together to actually be iterative.

Speaker C: I think there's probably a whole episode on that, Leah. Um, because I wholeheartedly agree. Um, and I think that's part of understanding the business. Uh, and it's not just like, oh, I understand how the business works, but what are the economics of the investment that you're making? This Sprint and next Sprint. And what is the return on investment that you're going to get from a month's worth of work or two months worth of work? And how do you bring business return further up, closer, Right. So that you're actually, you're actually returning money to the business as you spend money. And, and so I, I think there's probably a whole conversation in there about we should.

Speaker A: I think we should schedule another later this summer and have another conversation, because I think I'm. I'm with you 100% because I think I'm. I'm having the interesting experience of getting to go back to real experimentation, figure out what the problem is and like, ab tests and test this little thing and let's see if it's working. Does it change the metrics? Okay, turn it off. Turn this one on. Try have four or five tests running at a time. Uh, and I'm like, ah. Uh, this is why I loved product management. It's like a reminder, right? When you get to do that again, you're like, oh, yes, this is the juicy, fun part, right? Because you're building slivers and saying, is it working? Is it working?

Speaker C: Is it working?

Speaker A: Is it where, you know, instead of like, uh, push the whole thing out. Right? So I love that. Well, let's definitely schedule time and come back and talk about this, because I think we could. There's a lot here. It's. And it. I think it would be great to have your perspective, Alicia. I think that would be awesome.

Speaker B: I'd love to. I think we.

Speaker A: That would, that would be very. Yeah, I'll send some dates around and we'll get that on the books and it'll be fun. Well, thank you so much for coming and talking to us today. Um, and everyone just stay tuned. She'll be back. So we'll do another. Thank you.

Speaker B: Bye. Bye, everyone. Sa.