The Why And The What – Product Management Podcast
The Why And The What – Product Management Podcast
Building Relationships with Non-Product Teams – Head of Product, Aaron Rothschild
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Aaron Rothschild, Head of Product at Likemoji talks about his journey into Product, and how to build strong relationships with other teams.
Resources:
mindtheproduct.com
news.ycombinator.com
Hi, welcome to the why and the what product management podcast. I'm Daniel Kahn. In today we're speaking with Erin Rothschild who started in product management with Toshiba and Eloqua. Aaron was one of the first team members at Influitive where he led product. He is once again an early team member as head of product with like Moji. We explored errands path into product management, how we thinks about product as serving as the voice of the user and how he builds relationships with other teams outside of product through shared ownership of measurable goals. Hey Aaron, thanks for chatting today.
Speaker 2Hey Dan. Thanks for having me.
Speaker 1Yeah, it's a exciting to have you on. I'm excited to dig into your journey with product. Um, why did you tell us a little bit about how you got into product to begin with. I know you've been doing God product management with a number of different organizations over the years.
Speaker 2Yeah, absolutely. Um, I take a bit of a different path and I think a lot of other product managers I've met and uh, I've come through the customer side of things. So for myself, uh, early on in my career I started off in a customer support sort of scenario and then moved into product management. Uh, and I was lucky enough to find that path cause uh, I'm not sure how else I would have ended up there.
Speaker 1Yeah. I think it's, um, it's cool that that's your journey and that, so my journey into this space also coming from the customer side, but I'm obviously a pretty new to it and still finding my feet. How do you find that's been a sort of advantage disadvantage coming from the customer side as opposed to engineering?
Speaker 2Yeah, absolutely. I mean I, I find it a huge advantage. I mean I think that by my definition in a way, you know, product management is really being the voice of the customer. And frankly, by just listening to customers all the time on, on the customer side of things, it makes it really easy to, uh, put the customer voice implicitly within your head and just really think about how it customer x, think about what I'm just talking about right now. And I think that that's something that product managers often need to learn as a skill, but it comes naturally to people who come from the customer success and customer support side of things.
Speaker 1Well, I certainly appreciate that coming from that space. Hopefully that's a advantage. I'll be able to lean on myself as well. Um, you, you started out with, I'm doing product management with a to Sheba and Eloqua and then you were one of the first members of Influitive before moving over to your current role with, uh, like Moji. How did you see a product management evolve between those different organizations? Uh, what's changed through the years as you've been working with different teams?
Speaker 2Hmm. So it's an interesting question actually because then it just got my mind going. But, uh, I think ultimately today what's really different is the amount of tools available to product managers actually is certainly a big change. Uh, you know, I think thinking back to the day, it was a lot of, you know, Evernote or note taking Apps, a lot of outlook. Uh, but really today there's just so many options in terms of how you do it. Uh, but I think also, you know, obviously a big change from waterfall style execution to much more agile. Uh, but thinking back to it all, what I've always, you know, instead of recognized for a long time, I think is that there's a time and place for things. And in a product organization, you know, there's a time and place for certain tools and there's a time and place for a certain process and a certain amount of not process. So, uh, that's what I've recognized over my career. Looking back on things is just, hey, I may have brought that tool in that worked for me really well at this time and place in an organization's history, but it's not the right time for this right now. And recognizing that I think is being, uh, you know, for me what I've noticed as a, as a, I guess, change over the years, but something that you need to be attuned to, uh, but there's certainly a much larger smorgasbord of, uh, product operations applications out there today.
Speaker 1Yeah, there's a ton of stuff that's available to us these days. When you're working, I guess especially with a new team and um, you've worked with teams of vastly different sizes, do you have a tool kit that you start to evaluate even if some of those tools aren't going to be right for the team at this moment, for the current science of the team or for the operations, um, process that is being followed, are there tools that you, we are at least looking through a standard kind of list of here are the things that I like to use in evaluating whether or not they'd be right for your current environment?
Speaker 2Yeah, I think you always have to start off with the basics I think is where I, where I start off, it's really easy. I usually keep a spreadsheet of the different services and SAS services that were subscribed to at a company because it's really easy for it to get some of that a hand and I include free ones and that as well. Right. Um, cause there's an integration overhead to them and whether that's like a human integration or whatever it may be. Um, and bring it back to basics I think is really like a Trello type task board, whether it's, you know, Trello, Asana, that sort of thing. Uh, obviously Google sheets is the lifeblood I think of any product manager today. Uh, just from a collaboration perspective and the toolkit elements. And, uh, but to me those are the, the most basic elements of it. Uh, I don't get too caught up in, in exactly what the tools are, but really what kind of problem you're trying to tackle. And most often I just find when I'm coming in, oftentimes it's about prioritization and really getting a bunch of ideas down or things that have been stagnant for awhile. And then saying like, these are actually the things that we need to work on now because those are really important. And you know, it's most basic Trello just really lets you do that. And then I think tools follow behind that. Uh, obviously this can take place on a whiteboard or whatever. But, uh, that prioritization tool kit is very likely the first tool that you need to figure out.
Speaker 1Yeah. Tools, helping to facilitate process then and really understanding what that process is. Is uh, sounds like the, the right way to go about figuring out what you actually need to have in front of you. Um, do you have a process that you prefer to follow? What does a, the, the team currently follow at like Emoji as far as development and prioritization? What is the sort of overall workflow and process for you as a product manager leader there and the, um, the overall team?
Speaker 2Sure. So I mean, I think as a product manager we all go through different cycles where, you know, you're an early product development cycle versus you know, launching a product. But at all times you know, you, you get into different modes re dive deep on to things. And you know, just yesterday I came back from a conference where, you know, speaking with a huge variety of people, right, that are all potential customers, prospects and users of our product and person through a lot of that information that I just pulled. Um, you know, out of meeting with all these various awesome people, you know, it takes a lot out and I think that, but at the core of it, it also distills down like what is a process and product management. And I think the way you get that voice of the customer out of your notes and out of your discussions and all those various different items is and artifacts that come back from whether it's meeting with customers on site or meeting with them at a conference is making sure that you're pulling the things that you can action on looking for patterns. Um, basically digesting those contents in a variety of ways. I often go back over, um, notes, but also think about, you know, how does this relate to other conversations? I've had other conferences recently and to me a lot of product management is about pattern matching. And how you develop pattern matching I think is a about gathering a lot of disparate sources of data and in product management, I think that that really ranges from, you know, customer interviews to just casual conversations to, you know, diving deep into data sets to understand like a problem that you're facing. Uh, but then really pulling that back into have a framework where you can tie that to whether it's a prospect, a customer, or an internal customer, like an employee. And being able then to divvy that up and slice and dice it, um, based on are they someone who's helping to move our software forward, like a customer support person. So by fixing this problem, you know, is this something that's going to not just help this one customer but help, um, my own internal customer of, you know, the person who's sitting on, on the phone helping people, how can I help them? And so that's one of the things that comes into my processes. Identifying, you know, which person's going to benefit from this. And maybe the support internal organization. It may be our customer, right? Um, and pulling that out and documenting it. There's systems out there, uh, tools that we can talk about later that really help you process it. But at its most fundamental level, you know, you need some metadata that you can pop into a spreadsheet and go from there. But there's tools that make it easier than to tie in like revenue from those customers. And what's the prioritization of our three largest customers and what did they think are the most important features? And then tying that and saying, well, does any of that overlap with what our sales team is also looking for? By doing that? You know, I think Anne and being conscious of it as you're gathering the data at the outside of these conferences and things like that, you can then make a more conscious effort to making better prioritize decisions ultimately. Um, because using all that metadata to make the better decisions is actually the hard part of product management.
Speaker 1Do you find that you're typically aligned with the other members of leadership when you're actually going through and picking out what the uh, the right stories are to work on? Um, how do you actually decide what is most valuable and, and build that alignment with the, uh, the other members of the team that aren't themselves holding a, a product title role? Sure. I
Speaker 2think, I think there's two parts to that. I think that there's an element of first coming to agreement that there is, you know, what is the fundamental problem or are we all looking through this through the same lens? You know, oftentimes and product managers too, we, we come to a a pre solution, right? And I think keeping our minds open to what the problem really is. Uh, and then acting as a way of saying, hey, all of us as a leadership team, can we all agree that this is the fundamental problem here? I think that sometimes that's a step in itself, right, of, cause it's everybody on the leadership team is getting inputs from various different places. Customer success leaders obviously getting it from the front lines, you know, but even like the finance team, they have things that are impacting the product. And when you all look through it through the same lens, it makes it much easier to identify the things that probably the product team should be working on because I think sometimes it gets down to features and functions, but by looking to the rest of the team and getting aligned on that, um, and you come up with product solutions that kind of often fit the problem much better. Uh, so I'm not sure if that answered the question that I kind of veered off in a bit there.
Speaker 1Yeah, I think so. It's, um, it sounds like it's just making sure that you've got as a starting point, that collective understanding of the problem space, what is it that you're, you're trying to solve and then you can sort of focus in on getting the right data and understanding the right stories from the, the various customers and users to align on what the best priorities are for the, the organization. Um, one at task, a little bit about, um, process from a development perspective. Um, do you follow, it sounds like you, you have over the course of your career moved more towards an agile process. Are you following anything formal, like a, a scrum or Kanban process with your team at the moment?
Speaker 2Uh, as much mark Kanban right now, uh, in the past, you know, I just find depending on the size of the team or teams that are being, you know, working together kind of a definitely influences that. But right now it's really combine focused where, Hey, what's, uh, what do we need this week? Cause I met at a conference about this person with this person about this. So we're gonna, we're gonna need to talk about that. And uh, having that flexibility is pretty much the stage that we're at here at like Mudgee. So, uh, that, that's the mode that I'm in right now. But certainly, um, I think when there's Inter team dependencies as and when it really becomes like a different story altogether, not becomes more difficult.
Speaker 1Yeah. Okay. That's, that's interesting. And the, the size of the full like Moji team, do you feel like that influences it? I think he came from larger teams at the path in the past. I'm most certainly you saw the early stage days of Influitive, but by the time you made your move over to like Moji was, uh, a much larger organization. Um, do you feel like team sizes is part of the influence on that? I think you were just saying that.
Speaker 2Oh yeah. I mean a team teams has really interesting component of, you know, the development process. Uh, I think what sticks out to me is recognizing, you know, when a smaller team is better and when, you know, you may need to throw more, throw more resources at something. Um, and I think it's not always defined by, you know, we need more front end or more backend developers on this, but what type of problem it is and what type of developers can really help kind of crack that problem. Uh, which I think isn't often taken to account so much. It's more of like a resourcing type of issue where people are just, hey, we have an API team and there's five people on it and there's a, you know, front end process team and there's five people on that too because that's how many people we have. But I think having dynamic teams that you can kind of bring together based on certain problems that the company's facing can be really effective is what I've kind of found, uh, to be the case, not just purely based on number of team members in it, but what are their qualities and what do they excel at? Having that flexibility certainly seems to align with that, that agile mindset to deal with the problem of the moment that brings the most value forward. Um, you've mentioned a number of different kinds of engineering rules that are involved in the process. What is the, the makeup of the, the team that you find yourself working with 'em as head of product at like Mochi? Who, um, who are you spending the time with during your day? Yeah, sure. So I mean, as a employee five here, like Moji, we're really small. Uh, you know, I've worked in companies like Eloqua at Influitive where there's a couple of hundred people. Uh, but my day to day with my developers right now are a really, you know, very agile, very, uh, casual frankly. Right? It's more about, hey, when I was speaking with customer x, Y, z about this, this is what's come up. These are some of the problems we've faced. Um, the team is generally more in sync about those things and it's less of a distraction. But at the same time, you know, being a small startup, limited resources, we have a strong list of things that need to be done, you know, in the next little while. And so, in a way, it really is great at forces prioritization. Um, sometimes it's really hard and you end up spreading the peanut butter too thin. What I'd like to say sometimes where you'd take a, you know, like when you take a bite of a peanut butter sandwich, at what point is it no longer a peanut butter sandwich? Because you know, it's, it's a giant sandwich, but there's nothing related taste. So I, I like to focus with my developers today on just what are the issues that we're encountering that we need to conquer in the next month, let's say. And it's not so much about roadmapping, but it's really just about engaging with our developers, you know, with Steve and Ben and trying to figure out a, hey, did anything changed from last week when we were talking? And, uh, that agility just makes it really possible for us to thrive, frankly,
Speaker 1other than the, the developers themselves and, um, and yourself as a product who's involved in the product planning process as you're deciding what the next key features to build, or if there's a, a bug that's becoming more and more of a pain in the, uh, the side of customers that needs to be dealt with. Um, who else has been involved in that process with you?
Speaker 2So it's used the, it's me plus depending, uh, you know, it's a mobile app bug or if it's a web bug, depending on who's involved. That's kind of how we split, or two developers that we've got here. But at the same time, you know, bugs and confusion points and sticking points and friction points, those are all things that are really important to all of us. And so actually my CEO, you know, we'll have conversations on a daily basis going over what are some of the key parts that are really like slowing down adoption or you know, impeding how we explain our product to people. Those are really important things. And so it's, it's not just me and it's not just our developer, but really all of us at, at like Moji involved in that.
Speaker 1Um, when you're working with those other stakeholders, um, there's, there's certainly various scopes of who's responsible for what, how do you build relationships strongly with engineering and with sales and with the other members of leadership as a person in product and help them to understand where that value is in having a product function.
Speaker 2Yeah. I think there's, there's a couple of quick questions in there, I think. Uh, how do you establish,
Speaker 3yeah,
Speaker 2great relationships with people outside of pm is something that's incredibly important to product managers. And I would argue that if you can't do that, you can't really be a great product manager. Uh, I think a product person needs to be externally aware of the various different forces and be very empathetic. And I think that the empathy is often, um,
Speaker 3okay,
Speaker 2put out there as a, as a catchphrase for product managers for their customers. But I think it's so important for product managers to really be empathetic towards their other functions within the organization. I think really understanding what's really hard about developing a product and then launching it is difficult for, for a typical product manager to necessarily understand unless they're in, they're in the, in the weeds working with the product marketing team and the marketing team to really launch things and to go and support the sales team and make sure that their products is being supported as well. Uh, so I think it's, it's something that carries across the entire organization. And if you can't establish great relationships with sales, marketing, customer success in operations, you're going to have a hard time at some point launching a product or ending the life cycle of a product or really gaining the adoption of a product because all of those other units are basically, um, you know, choke holds to your success. Um, I don't think that I could be successful as a product manager without interfacing very well with those other teams. Um, are there times where it could have done better jobs interfacing with sales, marketing support, all of them for sure. But at the same time, I know that in my career, some of the great relationships I've had with both sales and marketing have made real differences in our product and the success of the company. And I, I think for me, that's what's really exciting and the best way of laying that groundwork, I think is trust and credibility. So I'll leave those two kind of big words as just, uh, you know, say, Hey, if you can establish that sort of trust and credibility with your sales and marketing team, you can build great relationships upon that. Otherwise it's really difficult.
Speaker 1Yeah, totally agree that, um, having strong relationships with the other functions and stakeholders and teams is extremely important. Are there sort of any tactical, um, approaches that you have to ensuring that you're strengthening those relationships and making sure that you are keeping sales and, and marketing in the loop as you're moving forward with product decision making?
Speaker 2Sure. I think obviously like touch bases on a very regular basis, uh, are super important. But I think having a relationship that involves a key metric that's shared between departments or organizations in some way is something that really carries it together and makes it something that is a habit and makes both, both sides accountable. So when I know that I've committed to, um, you know, selling x number of dollars of this new skew product that we're going to be rolling out. Um, that's something that, you know, just even me tying my horse to gives a sales, you know, manager and leader, the sense that hey product is really hitching their horse to this and is really involved in it. And coming back to that and making sure that we're reporting on, hey, how's this product tracking towards that key metric that both of us agreed to be really important, really carries the conversation forward and makes it easy to have those types of relationships because it's built on a, a number. Um, but be also something that you're both really interested in. It's not just like feature a was adopted by at 37% of our customers. It's like feature a was adopted by 37% of our customers. But that matters because the head of sales means that that impacted 22 deals, which resulted in us hitting our quota for this year. Right? Yada, Yada. But that's the sort of thing when you have that conversation.
Speaker 3Okay.
Speaker 2It's much more interesting to someone outside of products to, to know that you're, you're interested in their success as well. And that's, I think what's weird about product is that it's basically about making sure everybody else in the organization is successful. Right. And your success is really tied to them directly rather than the other way around.
Speaker 3Okay.
Speaker 1Yeah, I like that idea of having that shared metric to make sure that there is alignment between the teams. And like you were saying, it also then forces that there's some sort of regular conversation to make sure that you are on pace for it. Um, when you are working with these other team members, how often do you find that you are actually meeting with them? Do you spend most of your time sitting with engineering or what would you say the split is, um, in your conversation between working with engineering versus working with the, the other stakeholders?
Speaker 2It's hard to say because this from the slicing perspective, like I look at it as a life cycle element, but I would say it generally ends up probably being about a third, you know, pm engineering time and then sales marketing, customer support, kind of being the other two thirds of it with a bit sliced up with uh, you know, design time. Obviously the, it's everything else. But I think about that, that's my kind of mental split is probably a third of my time I spend with engineering and then depending on what month it is or what part of the month it is, um, you know, that that kind of dictates how much time I'll be spending with the other teams.
Speaker 1Okay. That's um, a good 30,000 foot view of where the time allocation goes and interesting to know. Um, that's actually I think a fairly high number to ensure that you are making sure that those relationships are strong, which certainly I think it goes back and aligns with everything you were talking about before.
Speaker 2Let's keep in mind, sorry, just to clarify there, when thing is like, you know, obviously it's been a ton of time with customers too, right? Like we're just talking about the internals, but so, you know, keeping all that as a, yeah, it's tough to keep that balance, but it's, that's the thing is I don't think it's a constant balance. I think I go into times where I spend two, three weeks just doing customer events, going and seeing a bunch of customers on sites and, and then I don't see a customer for maybe two or three weeks. Right. So it's a day in the life of a product manager is usually the month in the life of a product manager. I find.
Speaker 1Um, are there, um, regular things that you're doing on a daily basis to make sure that you are staying on top of all these different requirements? What does a uh, a typical day look like in your world?
Speaker 2Yeah, sure. It's, uh, it's tough, very frankly. That's, I, you know, I speak with a product, people who try to create products for product people to keep track of product requirements. And a, it's not a simple thing and there's a lot of things that can slip through the cracks. But, um, one thing I try to do is on a weekly basis, I try to have one item. I actually have a browser plugin thing. Um, I think it's called momentum, but it basically says focus on one thing per week. That's strategic. And so from there, um, that's kind of what I use just to focus myself and bring myself back to it. Uh, so that's my way of keeping on track in terms of particular strategic things that need to get done on an ongoing basis. And I find that then that just kind of informs me tactically that week, you know, what did I get? Did I take care of that strategically important thing and where there are three other things that were kind of of importance as well. So it really just brings my, kind of, makes me mindful of the strategic things that I need to make sure I'm on top of
Speaker 1making sure you're not spending all of your time putting out the burning fires. That's right. So Erin wanted to also ask you, um, do you have any resources that you would recommend for somebody in product?
Speaker 2Sure. Um, I'm a big fan of mine. The product, it's a, it's an organization and also has a community, uh, that you can tap into. It's got a slack, uh, you know, group that is great for tapping into different folks. Um, it's available at mind, the product.com I think, but they have a great, uh, annual conference as well. Really enjoyed going to that. I was going to say, one of the thing that really comes to my mind is like, uh, some mental models. So there's this, uh, on y Combinator if you search for mental models, actually I find it's, uh, there's some great resources that come up for product people and just gives you a great way of, you know, how do you look at the world through the eyes of a product manager and a, I find that hacker news is always just a great resource for that sort of stuff.
Speaker 1Okay. So mine the product, definitely something to check out. And, um, y Combinator is information on thinking about the world in product through the mind of a product manager as a, a second one to explore. Great. Erin, thank you so much for taking the time to talk through your experience with product and building relationships with, uh, with your team members. It's a had been a pleasure having you on.
Speaker 2Yeah. Thanks so much Dan. Really appreciate your time.
Speaker 1Thanks again to Aaron for outlining how he thinks about building relationships with other teams. If you would like to hear more interviews from people working in and with product, please subscribe to the why and the what. Wherever you listen to podcasts. We'll be back with another interview soon.