Episode 49: Marrying Product Management and Engineering with Maura Kelly
Maura Kelly is VP of Engineering at Mailchimp. With over 17 years of experience in the tech industry, Maura is an expert in software development and programming. She joins Melissa Perri on this week’s Product Thinking Podcast to provide engineering’s point of view, and to share helpful tips that will improve the way you as a product manager are collaborating with developers.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Maura talk about in this episode:
Maura’s traditional path to engineering, and her experience at Mailchimp, where the culture is about empowering the underdog. [1:45]
Mailchimp’s first product managers came from other internal disciplines and were workers who already knew Mailchimp and their customers very well. Over time, they continued nurturing people into product managers and started hiring people with product management experience externally. They also mixed up the teams, so that people new to Mailchimp could learn from veterans of the company. [5:44]
There is a misconception that engineers don’t care about customers and should keep their heads down doing code, Melissa says. “Engineers want to work on stuff that matters,” Maura claims. They want to be part of a larger mission that makes a difference; it motivates them and enhances their performance. If your head stays down, it’s hard to know the context and information that can help you build a better product. “First solve the problem, then write the code,” she adds. [11:03]
Why engineers should be involved in the discovery process, and how this can be done. [12:12]
Combining something that someone wants to do with something the company needs, is a great way to both solve a problem and motivate an employee. Maura shares how Mailchimp conducts this ‘management magic.’ [15:05]
Melissa and Maura explore how product managers and engineers can work with leadership to ensure their teams focus on the right things. If there are people that aren't a good fit or aren't doing the best work that they could be doing for whatever reason, that should be discussed at the leadership level. [17:16]
One thing people don’t realize about engineering is that there is a lot going on behind the scenes. Not only do they write code for solving customer problems, but they also have to write that code to certain coding standards; they’re also getting code reviews, giving them to other people, thinking about the security of the feature they’re writing, among other things. [20:35]
Product managers often struggle with understanding the technical side of building a feature. Melissa asks Maura how they should be checking in with the engineering team about the timeline of things that need to be done. [25:28]
Resources
Maura Kelly on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of the product thinking podcast. Today. We have more Kelly, who's a VP of engineer at MailChimp here with us to talk all about how product managers and engineers can work better together. So welcome Mara. Thank you, Melissa. So Maura, you came into MailChimp when it was very early, but before that you had an illustrious career in engineering, we were talking about how you kind of got involved with it. Tell us, like, how did you end up at MailChimp? What was your to get there? And what was it like when you started?
Maura:
Yeah. So one of the things I love about MailChimp, we have a lot of folks in engineering who did not follow traditional path into engineering. They're amazing and creative people. I followed a pretty traditional path into engineering. Um, I majored in computer science and I worked at a startup to start. And then in, in Atlanta I worked at the Atlanta general constitution and then its parent company at Cox enterprises. So I came to MailChimp in 2015 and it was much smaller. Um, we were about 350 people and everyone was wearing a lot of hats at the time, had just really great energy, but I've seen it grow and scale a lot in my time here.
Melissa:
Yeah. What was it like when you walked in? Can you describe kind of like the culture and the people and what was going on those days? Yeah.
Maura:
So one of the things I always tell people early on when I was, when I would interview other people to come to MailChimp is I had this idea about the MailChimp culture and just sort of creative misfits. And we're all about empowering the underdog. And it was true. Everything I heard was true, just, just a really great energy. Uh, we were in a building at, on a street here in Atlanta called means and call it mean street. Then later we moved into pond city market and everyone just sort of sitting together, working really closely together. It was, it was a really exciting time.
Melissa:
And MailChimp was really founded by design people too. Right? Like that, that was the founder's big push was, he was a designer. He wanted to make really cool emails for people. What was it like in the early days? How did like designers product managers and engineers all work together? Yeah. So
Maura:
The funny thing is that when I, I started, we definitely had engineers and designers, but we didn't have any product management at the time. Everyone was kind of wearing many hats and kind of everybody was a product manager at that time.
Melissa:
Did that work? Like did, was it confusing? Was it hard to prioritize or, you know, things just worked fine.
Maura:
I think every organization, you know, it works for the size that you are and you know, it might change over as you scale. So, you know, at that time, one of the stories I like to tell is we had a billing part of the application obviously to take the money and we had one engineer working on that. And nowadays we have a whole team of a whole cross-functional team working on that. And that's just the, sort of the evolution of the company growth.
Melissa:
So now though MailChimp does have product managers. Right. Right. So, you know, when did you guys all decide like, Hey, we actually need this role and what caused that?
Maura:
Yeah. So I think that that was really just a, kinda a company wide scale thing, right? So we were going from, uh, we would always say internally startup to grown up. We were going from a, a team of generalists and starting to build out teams of specialists. One of the metaphors that we used a lot during that time actually comes from an article by Molly Graham who was at Google and it's giving away your Legos. So you have to, it feels very worrisome to sort of give away parts of your job, but it's all about scaling the org to do more. What worries.
Melissa:
Some of the, the problems that you were kind of seeing that made you go, Hey, we could use product management for this to give some context. I get asked this question a lot is like, when is the right time to hire your first product manager? Usually it's the founders who, you know, were the product managers. They have this really strong vision for what the company is. And then you start scaling, like you said, and we start to think, think about, when do we introduce the first product manager, three 50 people sounds like a lot to get to without product management. So I'm curious like how decision making was made before then if you're all the product managers who was really like leading that prior decision decision, the vision decisions, and then what broke where you were like, Hey, we need product managers now. Like we need to specialize. We need to keep going. Yeah.
Maura:
So I think the, probably some of the driving force behind that was taking MailChimp from an email platform to a marketing platform. So the complexity of the product grew and that's, that to me would be like a really obvious time to start thinking about having product managers, focusing on different areas of the product. And of course, different maybe customer segments that might be served by those. Another thing that we did at that time was our first product managers actually came from we're all internal. So they came from other disciplines into product management. So to start, it was people who already knew MailChimp really well already knew our customers really well.
Melissa:
And those people who transitioned into product management as well, how did they learn what to do? And, and how did you make sure that they were set up well to succeed in their role?
Maura:
Yeah, so obviously we're all learning how the job every day, but over the time, introducing product at MailChimp, we've both nurtured P people from internal to become product managers. And we've also hired some, um, outside people with experience and product management. So kinda doing both.
Melissa:
Yeah. I find that helps a lot is like, if you can mix up the teams and have people to learn from who have not worked inside that company before, or have done that before, to me, that's been the most successful thing to getting product managers up to speed. But I also have a question about like the rest of the organization. Was there any tension between the engineers and the product managers when this started, if you guys were playing the product management role, did anybody go? No, that's like my job, what are you doing? Are you taking it over?
Maura:
Yeah, of course, right. Like this is a change and like all, all changes. It requires communication navigate. There's definitely a learning curve and change curve to get people through. Again, we talked a lot about the Legos metaphor and how to grow up as a company. We needed to have people specializing in different areas and we would, we would all do more together that way.
Melissa:
So what types of things do you do as a team at MailChimp to make sure that the engineers and the product managers and the designers like all work really well together,
Maura:
This gets into planning, uh, one of my favorite topics and we have tried a, a number of different ways to do MailChimp one way we did for a long time, which ended up sort of just becoming too difficult as we scaled to manage the whole team, but we would do a planning week and that would, every single team would, would stop their in progress work for that week. And everyone would get together and just really dig into the next quarter of work. They wanted to do understand all of the needs from all the disciplines. So from product, from engineering, from design, what we would need to do to accomplish that work, we have gotten big enough that doesn't really work for us anymore, but we do try to look at like quarterly roadmaps, usually kind of planning out for a quarter. And we do a lot of review on those from an engineering perspective. And then maybe also a design perspective to see, you know, kind of like what dependencies that we have, what gaps we have, what sort of resourcing we might have. So one thing do now is we do quarterly road mapping and we do some reviews both with the teams, but also at the leadership levels to understand what dependencies might be in those roadmaps, what resourcing needs that we might have, you know, kind of just what pitfalls might befall us and then work with our teams to, to address those. So as like
Melissa:
A VP level engineer, what types of activities do you do with like the VPs of product and with the VPs of design, what's your kind of, I don't know, week to week, month to month quarterly, big things that you do.
Maura:
So at Mailchimp, I'm a member of a team. We call the customer delivery team or CDT. And so that's folks at a senior director and VP level. And so we actually spend all Tuesday afternoon together with each other, just looking at what the teams are doing, anything that we can help with. We'll have teams come and, and report to us, or really it's more about them, you know, sharing, progress us in getting any support or advice that they need. We'll also take a look at kind of like our customer metrics. So we do, um, a voice of the customer voice of the customer session on a regular basis. So that's my Tuesdays. And then of course, other ad hoc things will come up during the week where I'm partnering closely with my peers and other departments. And then of course I have one on ones with my here's another department, just keep in touch that way as well. How
Melissa:
Are you involved with the product management team when it comes to like setting strategy, figuring out like, should we go into these markets? What should we do to like extend MailChimp? Like I know you guys went through really big transition that you were kind of talking about just a little bit before from moving from an email company to a marketing company, and now you've been acquired, you've got this massive platform. It does so much more than just emails. Right? It does a lot of different things. I think from a product perspective, a lot of the people listening to this know how product strategies set from like our world, but how do you bring the engineers into that? What types of questions do you wanna be asked? How do you wanna be involved in that?
Maura:
Yeah, so I think what, what we really wanna do there engineering for sure, but all disciplines is get them thinking about the customer problem. I think a lot of times strategy can be, or, you know, we kind of are communicating to people like, go do this, go build this specific thing or go finish this. Or we need this at this state. Um, very typical conversations we have. Right. But I think the best way to have folks involved is to bring them along and make them part of the solution to the problem. So what customer problem are we trying to solve? What business problem are we trying to solve? What markets are we trying, maybe trying to go into, or what folks are we trying to target with these new capabilities in the app? And I think that gets you both more engagement. And of course, like deeper thinking about what those solutions might be.
Melissa:
I think there's this weird misconception with product managers. Sometimes that the engineers don't care about those things, right? Like they don't care about the customers. They, they don't need to go to, uh, listen to customers during interviews. They should just be heads down coding. What reality of that coming from the engineering side, like how should product managers involve their engineers?
Maura:
I feel like engineers are, you know, my experience are like everyone, we wanna work on stuff that matters. We wanna work on stuff that makes a difference. We want to help. We wanna be part of a larger mission and that's incredibly motivating and it gets us better work. I think that if your heads down, it's hard to know the context. It's hard to know that information that's gonna help you build a better product. One of the things I believe is that you have to understand what you're trying to do, or let me put it a different way. It's like, you know, first I've heard this quote and I'm sorry, I don't know who attribute to, but it's like first solve the problem, then write the code. So like you have to figure out what you need to go and do before you actually write the code and figuring out what code to write is actually the most important part. That's
Melissa:
Interesting. So like what types of activities should we be doing with engineers to make sure that they understand the problem really well?
Maura:
Yeah. So I think as much as you can evolve engineers and discovery and talking to the customers and actually deciding the solutions that we're gonna go after for these problems, not only will it give engineers the context to solve the problems, the engineers have great perspective and they deeply know what's possible. So they can also help with a different, even a different direction to go to that. That might also work,
Melissa:
Which activities in which parts do you feel like during the discovery process? Should we plug engineers in too? Because I I've also gotten this feedback sometimes as well, when I've tried to help people transition into more of these modern ways of thinking with product management, I feel like sometimes you could go too far. Right. And the engineers go, well, you know, I do actually have to go do some work, right? Like I don't wanna be everywhere. That's your job. What's the right level. And like, how often should we be saying like, Hey, come here, let's go to a customer interview. How often should they be involved in all the discovery work? Where do you find like the right balance for
Maura:
That? Yeah. I think there's a healthy tension here. Right? And I think that this is a little, little bit about time management. So, you know, engineering is, is a creative work where you need to have space and time to do it. So, you know, if I were gonna look at one of my engineers calendars, I don't wanna see them in meetings all day long because I know they don't have space and time to do their work. But I do think it's important for all of us to be involved in this, in the discovery part, us as like we talked about. So I would say in general, it's a tension and you have to balance it. If you're going really, maybe really deep with a customer, you probably don't need like the whole team there. But if you interviewed several customers and have come to a conclusion based on that, that data, you should share that with the entire team, some of that stuff can be done asynchronously. It doesn't all have to be done, live in a meeting. So you can give engineers documentation to read or things that they can sort of engage with on their own schedule. But it's ultimately a healthy tension of protecting that space and time to do the engineering work and being involved in that discovery.
Melissa:
I like that balance a lot. It was something when I was a product manager, I did a lot of open sky. I had this team of, it's funny, almost all their names were John. Um, but this team of Johns in, um, Nashville who are still some of the best engineers I've ever worked with what I found too. And you tell me if this is true, cuz I, I don't know just from coming from it, but in my work I found that there's some engineers who are like super motivated by like solving problems customers. But then there's also other engineers I've run into who are super motivated by solving like hard engineering problems. Right. We had one person that we tried to make like a VP of engineering and he was like, I don't wanna do this people management. I don't wanna go to customer interviews. Like I gotta chase this bug. Like there's something crazy in the back end of the system that I built from scratch and I gotta figure out what it is. And that's what really motivated him, like getting into the architecture, getting into the design of the systems. Do you find that's true with, uh, engineers, like the way that they're motivated by different types of problems that they can solve or, and what do you look for when you're a product manager to figure out how to motivate them?
Maura:
So that's a great one and I, I totally agree. People are obviously motivated by different things, but the good news is, is there's so much work to do. And so many problems to solve. Like we can, it's no problem. one of the things I always say is like the management magic is when you can take what somebody wants to do and what the company needs and put those two things together. I mean, a simple way to think about this maybe is like for what mostly my teams do is, is product engineering. So it's very, cross-functional focused. It's very collaborative. There's certainly other engineering disciplines that maybe aren't as out in front, you know, talking to customers or working with designers. I mean, I think in the modern workplace, we're all working collaboratively, but, and it's, that's about fit too. It's like getting people in the right role for them.
Maura:
What I've found though, is that really, um, important customer problems are often can often be really important engineering problems too. Right? So you can, you can often and put those two things together as well. But if there's, but like I said, some of it might just be that there's a slightly different role. That's a better fit for that engineer. I always say like, I love the stuff that touches the customer. Like that's where I want to be working. That is what motivates me. I wanna be collaborating with design, product management, marketing. Just that for me is what gets me out of bed.
Melissa:
So here's the tension that I've seen quite a bit with product managers when they get into a new team or, you know, a team they never worked with before, they're trying to figure out what motivates their engineers. They're maybe bringing them along into the, the work with the customers. They're like, Hey, come to the interviews sometimes. And I get this question from people. They're like, what do I, when my engineers are not motivated by those types of things like tactically, right? How should they go to somebody like you, like the VP of engineering you, um, you know, manages them and works with them. And you know, we don't have control as product managers over who's on our team. That's the difference to me between like a CEO and a product manager and why I hate many CEO. Like you don't get to choose who's on your team. That's not up to you, but how can you work with leadership? How should product managers and engineers like go and, you know, approach these problems with their leadership to make sure we have a team, you know, focused on the right things, motivated by the types of problems that we're actually looking at and all working really cohesively.
Maura:
Together. Yes. So, I mean, I think it's what you said. We need to talk about it. So if there's folks that aren't a good fit or, you know, for whatever reason, you know, aren't doing the best work that they could be doing, that's absolutely a conversation that needs to happen at a leadership level. And it's interesting, you're talking about product managers, not picking who's on their teams, which I agree with and, and it's valid, but like we can have a conversation about that, right? Like we can kind of like figure out what's in the best, best interest of everyone, but absolutely bring in your engineering management counterparts to help with
Melissa:
That. Yeah. I feel like it, it might be like a scary topic cuz it's not like, Hey, we wanna get rid of the person on my team, but it's true. Like if they're not, if they're not working on the most impactful stuff for them and it could just be the wrong time of people's careers. I feel like too, like the person I talked about who really wanted to chase that bug and didn't wanna be a people leader is a fantastic people leader now. Like he, he went on to become, the CTO, does a fantastic job at it, but I feel like there's probably just stages of people's careers or times where they were more motivated by different types of things. And it's important to like really have a good conversation about that and suss it out. But I hear a lot of people get stuck. Like they're just afraid to go talk to management, I guess cuz VP of engineering like sounds scary. so it's like, I'm not that scary, but how, how do you wanna be, how do you make that less scary? How do you wanna be approached by team members about these conversations? Like how should they bring you in and make sure that it's like, you know, cool for everybody?
Maura:
I mean that's a really great question and probably one that a lot of high level leaders struggle with. I don't think I on approachable, but I'm sure there's some folks who are scared to come talk to me. I can tell everyone listening. I'm happy to talk about these things. Definitely, definitely approachable. And I think one of the things that, that I can do and, and do, and other folks can do is be proactive about that. Like reach out to your product counterparts, read out, to reach out to your design part counterparts, see how things are going. One of the big reasons I do one on ones with my peers and so we can and have that dialogue going. So hopefully if there's something that they need to bring up they'll yeah.
Melissa:
That's great. So we talked a little bit about too. What motivates engineers? How do we find out what that is bringing them around onto the teams? So we just talked about, you know, motivating engineers, getting them to work better with product managers. What do you wish product managers and knew about engineering and like how you do your work that would help them understand your role better, right? Like what you do on a day to day basis. I feel like a lot of product managers, especially if they didn't come from a tech side, like I dabbled in engineering for a really like a hot second and , it really opened my eyes to how things get done. But so many people are transitioning into product management that don't have a technical background. I know it makes them really nervous as well. All my students at HBS are like, oh my God, I don't know how to code. Like, should I take a coding boot camp? Should I do that? And over and over again, we have engineers come in and be like, no, that's my job. Right? We talked a little bit about giving engineers time and space to work on problems. What else do you wish product managers understood about the job of engineering that you think they might not get?
Maura:
I think the thing that maybe people don't know is that there's a lot going on behind the scenes that they maybe don't see. And I would guess this is true for every discipline, right? Like I'm not a designer. I don't know what's going on behind the scenes and design. But you know, if you think about, especially like a modern engineer's role, they are not only writing the code for whatever customer problem you're trying to solve right now. They need to be writing that to probably to certain coding standards. They're getting code reviews, they're giving used other people. They're trying to think about the security of the feature that they're writing. They might be having a transition to a new framework or maybe they used to write everything for managed servers. And now they're running everything in the cloud. There's just like a whole world of things going on behind the scenes that might make everything that, that sort of simple thing you're asking them to do actually be a lot more complicated.
Melissa:
Yeah. That sounds like a lot. I imagine too, like the engineers don't know how often product managers are like sitting in meetings, arguing about things, trying to like help the prioritization or deal with difficult stakeholders. So, so much behind the scenes on, on both of these parts, one of the things that we were talking about as well before was getting the engineers more in tune with the customers, making sure that they really think about their problems. And you were telling me about this customer obsessed sprint that you did at MailChimp, where you all just took time off to, to work on it. Can you tell me a little bit about what that was and how engineering was involved and, and what that actually looked like.
Maura:
Yeah, absolutely. I love to talk about this. So over the summer we did, um, a two week sprint, which we called the customer obsess sprint. And the cool thing about this project was kind of at the time, there were a lot of folks and even in different departments thinking about something like this for our customers, their busy season is the, is the end of the year as the holiday season. We're trying to not to be disruptive. So we're not trying to like push out big changes right now that might mess anything up. We try to kind of keep it very calm right now. And this is the ti the time of year that we usually maybe dig into some of these customer bugs and maintenance work. But if you think about it being the busy time of the year for customers, we actually wanna fix these things for them earlier.
So a lot of folks that kind of been thinking about like, how do we, how do we pull this, this work up earlier in the year? So I had talked to several folks from other departments about this and that started to sort of coalesce into a proposal that we put together. And I, you know, kind of hopped that around with my peers. I, you know, I, I talked about it with our executive leadership team and said, Hey, let's take two weeks, all the teams at the same time and say, Hey, let's just, let's fix cut customer issues. Let's, let's work on things that are affecting our customers. And you know, it ended up being strangely a really nice break, like a nice, a nice time to sort of just focus on kind of smaller things in these big sort of project product initiatives. But we were able to resolve a ton of issues, a ton of JIRA tickets. We have Zendesk is what we use for our customer team. And so a ton of those issues linked to those share tickets.
Melissa:
But so what was the result of the customer obsessed sprint? Like you put all these things out there really fixed a lot of issues. Did you get feedback on like, oh my God, this is amazing. What was the success metrics after that?
Maura:
Yeah, so, I mean, I think the, the first success metric as the team really enjoyed it got a lot of great feedback from folks who, who were able to do it. We obviously know how many kind of tickets that we looked at. And we looked at some really old issues, like many years old tickets that were sort of hanging out. So that to me was also like a really big success metric and just working on some things that had played our customers for a really long time that were, we were able to kind of wrap up, which is really nice. How did you
Melissa:
Prioritize the things that you wanted to fit into that sprint?
Maura:
So we started with, we did this in a couple different ways. We have a large team and so kind of, wasn't kind of one answer that worked for everybody. But we started with a prioritized list from our customer team of kind of like top burning, burning issues and especially some old ones that have been out there. But again, with kind of having everyone involved in the process, we also encourage the teams to look at their product or their area of the product and things they know that needed to be worked on as well. And all the teams sort of prioritize that for themselves with those inputs.
Melissa:
I feel like these types of things, sometimes the customer problems come from, from our support teams or from customer service or for product managers, we funnel that down. But then we've also got like all this tech debt that we usually have in these companies to fulfill. Right. And I, I think it's amazing that you've did the customer of self sprint, cuz I usually hear about tech debt sprints. So that's U that's like what I, what I've heard from other companies. So I love that this one was focused on changing things for customers that were bugs or things that just not working for them. One of the top issues that I hear from product managers as well is understanding like what the cost is of tech debt. And I feel like from a customer obsess sprint perspective, if it's like a UI thing, bug, something that you know is coming through support, people can put like a number on it a little bit or they can understand the problem.
I think where product managers sometimes struggle is understanding the technical side, right? Like, Hey, it's gonna be 10 times slower to build this feature on this old platform that we've been using. We have to restructure it or re architecture it. How should product managers be checking in with the engineering team about the health of the platforms to when those things are coming up and to make sure it's not too late, you know, when you go back and look at it and what types of questions should we be asking? How should we be having that dialogue? How often should we be really looking at that? Yeah,
Maura:
That's a great question how you should at, you know, but I think about twofold, you know, I think of is the result of decisions that we've made and honestly frequently they were the best decision at the time, right? There was a decision we made at the time with the information that we had. I think that in order to go forward in a low tech debt world, we wanna be asking questions like, do you have enough time to do this? What are the implications of doing the, this, you know, some things we just have a fast turnaround time on and that's fine, but not everything is like that. Other things can be negotiated. So we wanna be having that dialogue on a regular basis, every sprint to make sure we're just not rushing everything out the door as fast as possible and creating technical debt. And then I think for the things that are, that are longer running, like you talked about, you know, I find those always those always surface and they often surface this, maybe a little bit of that behind the scenes stuff, technical debt will surface and cause issues for teams and product managers.
Don't always see that, right? Like if someone gets paid because something's broken, you know, product manager might never see that. So you can ask questions about that too. And I, but I also think that sort thing is on engineering to, to product management as well. Like, Hey, this area is really causing a lot churn. And if, you know, if an engineer is getting paid for it, that means a customers problem. Right. And that's all of our problem to solve.
Melissa:
Yeah. Definitely. One of the things that I've seen teams do is take like percentage of their sprint and just work on like technical issues or tech debt. Do you advocate for something like that or do you think there's better methods to make sure that we're paying down our TETA as we go?
Maura:
I like that method in the sense that you're doing it all the time. I think that we're kind of setting ourselves up in a bad spot. We're just like, oh, we're just gonna take one sprint to do TETA and then it'll be solved. Like we kind of know that's not the way it is. I would rather stay on top of this on a regular basis and be talking about it on a regular basis. Just personal philosophy. I think that I like rules of thumb that you might break sometimes. So like if you said that I wanted 20% of my sprint to be spent on tech debt every time I think that's great now. And again, you know, you're gonna have to either like lower that or raise it depending on the current needs of the team.
Melissa:
Do you know, like you should lower it or raise it, like what types of things would make you go 20% is not gonna handle this? Like we have a huge problem here.
Maura:
one of the things that can maybe drive that is if you're gearing up for something big, like maybe you're working towards something large where building on a, on the old platform isn't gonna work for you. That might be like a really good indicator if you're getting a lot of pages or, or dealing with a lot of customer complaints, that might be another good driver. Great.
Melissa:
Yeah. I think those are really good things to look out for when product managers are thinking about prioritizing it. I'm curious too, like on the VP level, how do you have those conversations? You know, leadership level, when you have to do a massive overhaul or a massive re architecture, like have you ever had to like rebuild the platform from scratch and how do you decide whether to just build it behind the scenes and transition or do it in stages? What types of conversations happen there?
Maura:
All of those ways that you talked about doing it, I've probably done it all of those ways. Sometimes that might happen. Like you said, a little bit more behind the scenes. One of the things that we've been working on at MailChimp is migrating more of our infrastructure to the cloud. And that's a thing that is pretty technical in nature. It is gonna affect the product and product managers, but you know, a lot of the, there can be done on the engineering side. And so that's a thing that you can prioritize, make the business case for that, you know, you need, you need people to do that sort of work for other things. It might be something like putting together a pitch, just like you would just like a product manager would for, you know, a certain initiative where, you know, if you wanted to modernize a part of your platform, that's gonna have deep product implications. I would write something up. I would talk about the benefits of it to the product, to the customers, you know, hopefully the sort of the sort of, you know, making a business case for things be familiar to your listeners, but kind of depending on the nature of the project, that one of those things
Melissa:
That, yeah, so a lot of these decisions, it sounds like are happening on every level, right? Like not just on the team level about prioritizing tech debt, but also like on the VP level, all the way up to the leadership levels and the executive level of how do we keep our systems moving? It sounds like it's just more of a conversation between product managers and engineers all the way up and down the organization, right. Of what's going to make this better for our customers. How are we gonna solve these problems? How do we transition our product into creating new value? Which I really like so more covered a lot of stuff in this podcast, which is awesome. I think it's really gonna help product managers understand how to work better with engineers, but I wanna hear what's your biggest tip for that? Like how, if you could give any advice to all the product managers out there listening, what would be your biggest piece of advice for how they can work better with their engineers?
Maura: Yeah. So I'll say two things. The first is all sort of reiterate something we talked about already, which is both involve engineers and creating the, and give them space and time to work on that solution. So involve them, but try to definitely give them space where they don't need to be in meetings and can do their work. But if there's one sort of one tip I could take away that you could put into practice right today would be, don't use the word, just, I think engineers here a lot, get a lot of request. Like, can you just do this? And I think that makes engineers feel like people don't understand all the technical work that might go into that little just request. So I try to take just out of my vocabulary when I'm talking to
Melissa:
People. Yeah. That drives me nuts too. So I totally see how we drive the engineers nuts. I think we all have really complicated jobs out there, whether you're a product manager, an engineer or a designer and using the word, just kind of belittles it a little bit. So lots of work that goes into building great products for people on every side, especially the engineering side as well. Thank you so much for being on the podcast today. If people want to learn more about you, uh, connect with you, what's the best place to get in touch. Yeah.
Maura:
So I'm on Twitter. You can also reach out to me on LinkedIn and I'd be happy to talk more about this with product managers and Melissa, thank you so much. I really, really enjoyed it.
Melissa:
Thank you more. Thanks for being here. So thanks for listening to this podcast. If you liked it, please subscribe to the product, thinking a podcast, anywhere that you listen to podcast. We always like that and stay tuned next Wednesday. For another episode of Dear Melissa.