Re:Role | The Product Manager And The Loop

  |  Compiler Team  
Professional development

Compiler • • The Product Manager And The Loop | Compiler: Re:Role

The Product Manager And The Loop | Compiler: Re:Role

About the episode

When building out an application, it can be hard to decide what needs attention, and what can wait. Maintenance is important, but development teams also want to add new features for customers. So they have to choose, and not everyone agrees. A product manager can help break the impasse. Good ones bring in customer feedback while providing teams with focus and direction. The result is a cycle that informs contributors on what’s working, what’s not working, and what future successes can look like.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

Subscribe

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcript

Our little startup isn't so little anymore. They've added an architect, a designer, and even a SysAdmin, and with the plethora of servers, services and data needed to get their app through initial release, that previous hire was pretty vital. Now that their work has been out in the wild, so to speak, there's feedback coming in. Customers like the user experience, but there are certain features that would make it even more valuable. This is important. The idea isn't just to build for value, but also for scale. As the app gets more and more users. The team starts mapping out development work, but there's a problem. With the size of the current operation, they can't work on everything at once. There are arguments back and forth about what to do, which feature has more priority, what is most important to do right now, and what can wait, and how can they balance those tasks with maintenance and bug fixes? While the CTO and the architect have the knowledge necessary to make those decisions. They aren't as involved in the day-to-day anymore, and as we discussed, they don't have the capacity to do everything. This work is for someone who has an eye for development and organizational management, but also an ear for customers' needs. What the team needs now is a product manager. This is Compiler, an original podcast from Red Hat. I'm Kim Huang. I'm Angela Andrews, And I'm Johan Philippine. We're following a fictional startup as they grow their business. As things move along, our hypothetical team realizes it needs to fill new roles. We're calling this series Re:Role. Remember, any resemblance to real companies or people is purely coincidental and unintentional. Today's episode, The Product Manager. If you'd like to listen from the start of the series, check out our episode on the CTO Producer Kim Huang is here with our story. We have a lot of ground to cover, so if you don't mind, Angela, Johan, I'm going to jump right into it. Go for it. Let's do it. So two people I want to introduce Ajay and Era. My name is Ajay Waghray. I am director of product management at Udemy for our consumer marketplace and co-host of the Product Happy Hour Podcast. Hi everyone. I'm Era Johal and I am a principal product manager at Udemy. I'm also the co-host of Product Happy Hour. Ajay and Era have a podcast where they share tips and strategies and experiences in product management over a beverage of their choice. But what I thought was interesting was Ajay and his background in startups. Did a startup for a year. It didn't work out, it kind of imploded. I was sleeping on couches in San Francisco, funny enough. This all started in Dallas and then in San Francisco when the startup was done, I basically took a couple of weeks, watched a bunch of “House” reruns on TV trying to figure out what I wanted to do, and I discovered this thing called product management. I'd never really heard of it before, but once I discovered what that was, it sounded a lot like the things I enjoyed about being in a startup where you figure out what your product should be, why it should be that way. Working with design, working with engineering really scratched a lot of different itches that I had. So I ended up joining as an associate product manager at a company in Austin and worked in product management. We'll hear it from Era and her experience in a bit, but I want to get down to business. I asked Ajay, what is product management? One of the things that I think really clarifies product management for folks is that product management is about figuring out what you should build in your product and why you should build it, which is a little different than something like project management. Project management is more about when things are going to ship and how. And so really as a product manager, your job is to focus on those two areas. It seems simple with that type of explanation, but really nailing that requires a vast amount of skills in things like product strategy, developing a product strategy, how to prioritize, how to decide between working on one thing versus not working on another thing. So then a product manager is someone who is concerned with the why as well as the what, in regards to building software. Ajay says their position is critical, but they aren't exactly CEOs. You don't own the team, you're not the general manager, but you are a leader on the team. You're out there playing the game, but you're playing that game in a leadership capacity and making sure things happen to be successful. Your success is highly dependent on the people you're working with, making sure that you can have those people, designers, engineers, stakeholders, product marketing, project management, all the people that are involved in making a product happen and making it successful, ensuring that they can all work together towards a common goal or strategy that's been well researched. It takes a village, right? It's not like a hero ball, as you would say in something like basketball. You can't just take the ball and try to score on your own. You need the whole team to do that. So yeah, it's a really critical part of the job. So as I understand it, in software development, there can be a lot of personalities, but according to Ajay, there shouldn't be egos involved. So no LeBrons, no Tom Bradys, no Ronaldos, they're not involved here. I am so glad he explained exactly what a product manager was because I was really conflating it with a project manager. I did not know the depth and the why and the what as he explained about what a product manager does. I really never took it into account. I just thought it was, oh, you're just managing how things work. But he really laid out what this role is and it does sound super important. How do you know what to work on? Yes, I've worked with product managers in the past outside of Red Hat, and they do play a very important kind of liaison type role between development teams and these kind of silos, essentially, who are working on these products and the outside stakeholders or the other areas of the business that are dependent on whatever that team is doing. It's a very specific kind of role, and it often gets conflated with project management, which is completely in another kind of realm. So people often do have that thought. Kim, I'm a little bit confused because a lot of this sounds like what a CTO would do, figuring out what to build and what customers are going to want, and then how to build it. That sounds a lot like what we were talking about, the CTO setting the vision and the direction for the company. How does what a product manager [does] differ from what the CTO or a head of engineering does? I had the same thought. Why can't a CTO do this work, especially in a smaller setting in a startup? I'll let Ajay tell us why. Even C-Suite doesn't get the option to just make decisions on their own. Oftentimes, they have a board, they have investors, so really nobody is an independent decision maker. But what's interesting about the C-level versus at the level of a product manager, let's say; you have different types of inputs. So a C-level type person is probably getting input from their board, shareholders, or if you're a private company, investors and they're seeing things at their level, which are going to be different than what you see at your level at probably at a product manager level, you're probably concerned about, oh, well, users are getting stuck on a specific part of the experience because our funnel conversion rate is going down. Or we have a bug that's really affecting users in India, for example. And so you have different sets of information. There we go: time and also other conflicts like investors and maybe a board (if you have that kind of setting in your company), those types of factors can pull a CTO in all different directions, and they may not have the ability to act on customer input because of the other expectations that they have to deal with. Yeah. That puts them a little too close to the nuts and bolts to the day-to-day. So it makes sense that you need someone whose job is just there to make sure that things like bugs and certain issues are dealt with. I can't imagine like a CEO going through Bugzilla, right? So yeah, he's really making this role make sense to me. Let me see if the way I'm thinking about it makes sense to everyone. Okay. CTO sets the vision and says, "We're going to build a financial application that's going to do X." All right. And then everyone says, "Okay, go." And then someone at the product management level is going to be more along the lines of, okay, we're having this specific problem here and we're going to build this little feature that's going to help the overall vision become a success. Is that more what the difference is between the two? Yes. It's kind of what Ajay was saying before with its connections to product strategy and to customer experience and also to organizational needs. So maybe there are different teams within a company that have a dependency on what's happening in the development cycle. It's managing all those different parts and then obviously prioritizing what work is more important and what work is less important or less time sensitive. That's great. Makes sense. So Ajay continues, I want to come back to him because he has a lot to say. So often when you're trying to figure out what your strategy is, it's really not just top down or bottom up. Usually when this goes really well, it's a collaboration, and so you're spending time working with your stakeholders really everywhere in the organization, but in particular with the C-level to develop that strategy in concert with one another. So they're thinking about things from a company level. You're thinking about things from your individual product or feature level, and when this comes together well is when those viewpoints are married together in a way that's cohesive and really allows you to 10x your impact across the products that you're working on. Lastly, Ajay says how important it is for managers to empower team members to work without micromanagement and constant course correction. Oftentimes, I think a product manager assumes that, hey, I got to be involved in every decision. Anytime design engineering need to get together or need to make a decision, I need to be involved in that. Well, actually what I've found is that giving systems to encourage the team to make decisions, often independently of the product manager, but with the right guidance, is a really big game changer for the team because product managers, sometimes when it's not going well, they're the bottleneck. They're not able to scale their decision making to the rest of the team. So being able to do that really opens things up. It sounds like product managers really need to trust their teammates to make the best decisions in their roles. I can't imagine how big some products are and all of the moving parts. I'm thinking about some of the products here at our company, and I can't imagine a product manager having to have a say in everything everyone does. Oh my goodness. Nothing would get done. It sounds like you're giving your team the autonomy to make the right choices and things tend to go well that way. I can understand the impulse to wanting to be involved with every decision though, because that is part of their job to prioritize, to make decisions, to help people decide what to work on, what not to work on and how to do it. But you were just saying, Ajay was just saying, if you're really into the details too much all the time, then you become a bottleneck and then nothing gets done, or at least things get done much more slowly than anyone would be happy with. Yeah, definitely. So we know why a CTO or an architect may not have the capacity or I guess the perspective to do that work, but why can't just another developer, maybe a lead developer or a lead programmer do this work? We are going to answer that question next. Oh, good. I'm going to bring back Era for her take on why teams need product managers. She talks a little bit about product intuition and representing customer needs. I think where you end up is with something called product intuition, but that intuition about how to evolve, how to grow, how to stretch, how to achieve that comes from humbling yourself by removing some of your biases and actually understanding factually what's happening. So you know, listen to a song or you watch a show and you're like, "Oh, I'd rather have it be like that." or "This is better." That's kind of how I started. It was like, "I think we need to do this and we should do it." And then you get some quantitative data or some actual feedback from your customers and you're not seeing these metrics move and then so you learn that you know what you think is what you think, but what you think cannot be translated to an entire population. She explained that very well. Yes. Perfectly. Product intuition. Okay. Yeah, Okay. Product intuition. So there's a lot of voices in the room that are talking about development and talking about building new features and the next release, but there's one voice that doesn't make it in there very often, and that is the voice of the customer, and that's kind of what a skilled product manager brings to the conversation. Era tells a story about a product manager she worked with who embodied this approach. I had a person I really looked up to who always seemed to have the right answer to the right question, and through shadowing this product manager, I realized that she spent quite a bit of time watching customer interviews, which is where her kind of response and quantified answers came from. So this perception, I mean, it might be a perception that, hey, this person is maybe acting like a Steve Jobs, but the reality of the role is the best product managers that I've ever experienced spend so much time immersing themselves in feedback on how things are going today, how the industry might evolve in the future, and the different techniques in how they can improve their experience. So yeah, I realized that this person wasn't born knowing how to build an e-commerce site, which I know sounds silly now, but there was just so much conviction in presentations and answering questions, but a lot of her backbone actually came from closeness to the customer and the problem and the space. What do you think of that, Angela? Wow. So I do agree. You have to understand what the people want and you have to give them what they want. So her manager's way of being so into understanding that feedback and watching interviews and becoming one with the customer's wants and needs, and then being able to translate that back to the team and how projects and things are worked on--that almost seems too simple. It's like you want to know what the customer wants out of said project, and you have to internalize that and bring it back to the team. And I know that maybe not all product managers may operate this way. Maybe they think their way is the right way, but we're building these products for who? Our customers. That's right. I thought it was interesting how Era discusses the right tools to implement to get not just customer feedback, but also performance data from whatever is out there in the wild whatever application or platform that you have that's serving those customers. Trying to see and unlock bottlenecks and areas where there may be unique challenges or something about the experiences. Maybe it's something about the experience is really good and you want to build a feature that kind of optimizes it or builds off of that success. But that's what a product manager is looking at most of the time, and that unique balance of performance data, data analytics, customer feedback and expectations, and also your internal teams and what their capabilities are and what they think. I think it's a very important balance to strike. And it sounds like a really difficult balance to strike, right? Because on the one hand, it's like Era was just telling us you have to really humble yourself and accept that your ideas are not necessarily the ideas that are going to be the most successful. But then on the backside of that, when you take all this information from the customers and the market and all that, and then you present it to the rest of the team, you have to give it with conviction and kind of really sell it to your team and say, this is the way that we should go. So on the one hand, you have to be humble, but on the other hand, you also have to be convincing with your opinion and with the informed opinion that you have in terms of where you should go and what you should build. Precisely. Era for her part says, for product management, learning and listening is more important than actually delegating tasks and deciding what to do. I think when you see a product manager at your company or you know one, you see them as highly organized, very authoritative in the sense that they understand and answer questions and kind of make the right connections. But yeah, one thing that's not super obvious is that that is kind of an outward perspective. That's something that you do when you're talking to stakeholders or people who are outside of your team, and that same kind of attitude or showmanship isn't really how you're effective inside your team. In fact, I see a majority of my day as learning from people around me and taking what I learned from my designer and translating it to my engineer and then translating what I understood from my engineer to some external team. It's a lot going on. I mean, I'm learning that this role is just so integral. That it's data analytics, it's translating information from one set of stakeholders to another, prioritizing the work and learning and listening is a huge part of that. I am very impressed by the role of product manager and I have to keep my ear tuned to do I know any product managers because I'm curious about just, I have a lot of respect for the work that they do. This seems like such an important role in thinking about just our company. I keep hearkening back to our company. How do we do it? How do we do it? There has to be people like this out there that are doing these things and listening to customers and being able to translate that back to design and engineering to make our products the best that they can be. *Tips hat* Yeah, definitely. I can tell you from personal experience, I've been on cross-functional teams working in development and I've worked with product managers before, and having a great product manager is so clutch. It is absolutely pivotal, and it makes the difference in your day-to-day like almost nothing else that I could imagine. It is absolutely sent from some divine being, like, it's really great. In that role, you're like an information gatherer and you're translating like Era said, you're translating different disciplines and what they mean for a project or what they mean for a development cycle to different people who don't have those skills and who don't have those disciplines. A product manager is dedicated to understanding where all team members are coming from. You are responsible for translating what your team is doing, impact learnings, but the way you get to that level of understanding is through leveraging the experiences, talents, work of the members inside your team. Actually, my nickname at my old company was ‘Rosetta Stone’, because there's a lot of playback you have to do. So I think first you try and get a shared understanding of people's perspectives. So when my engineer tells me we're blocked, I literally know that we cannot push forward. But when my designer says they're blocked, that means something completely different. Yep. This is interesting. Again, so this is a whole new role that has been uncovered, and I'm so interested in, I have to meet a product manager. I know I know one. I'm sure I do. But again, respect. It's there. This really opened my eyes, and hopefully our listeners are walking away with this really fond respect of what this role is and what it does inside of organizations. What I love about what Era just told us is that when two different teams use the same word, it can mean two very different things. Right? Now, in a lot of our past episodes, we've talked about how communication is so very important and how teams need to learn how to talk to each other, right? But my assumption has always been that they're kind of buried in their own jargon, and it's just words that the other teams just can't understand. But we also have problems where even when it's words that are used by both teams, they mean completely different things in different contexts, and having someone like Era and product managers be there to say like, "Oh, when they're saying this, they actually mean this." Right? It's not necessarily what you think, and that I'm sure comes in handy all the time. Yes. Kind of going back to that building a common language we talked about during Stack/Unstuck. Yeah. She is the Rosetta Stone. Yes. I wanted to know though, if someone wanted to become a product manager, and I'm sure that there may be people listening who do want to become a product manager or maybe just have heard about it for the first time in this episode and are curious about it, what should they be thinking about? I wanted to get Ajay's perspective on this. This is what he had to say. Often when you're a product manager, you're learning a lot of the skills that help you do something like that. How to go from zero to one, how to grow a product that you're working on, optimize it. Those are the skills that you're learning. So I think if anybody listening is interested in going into startups, understanding how to be a great product manager will really help you with that. And Era has something to say to teams who are willing to go without for too long. Immediately, as soon as you think you have a strategy, you should hire a product manager because you probably don't have a strategy. But having someone whose responsibility is to figure out how you go from where you are to where you want to be, and thinking about all the different levers to pull, that's a very critical role. I think the people who found startups may not necessarily be the sole drivers of every single decision that happens every single day. I asked Ajay and Era for their parting thoughts to newer product managers as they start their careers. Here's Ajay one more time. What I've found to be probably the most important, which is what Era was saying earlier, was having deep empathy for your customers. Learning how to set metrics, set goals in a way that levels the team up, makes them 10x more effective than they could be on their own. Developing that strategy of what you're going to focus on, why you're going to focus on it, and doing that in concert with your stakeholders and leadership is the way to be the most impactful in this role. Of course, knowing the design fundamentals, engineering fundamentals and architecture are important, you need to have that stuff. But the way to really, really be successful is to do those other next level type of activities. And here's Era. I tend to have this tendency where it's like I don't do things until I feel fully ready, but part of it is just if you're passionate and you have an opportunity, you should just jump in and there's absolutely no problem with learning as you go. In fact, I'd say that's better. There is literally no book I can read that would've taught me how to handle all the situations I face every day as a product manager. So if you're considering, just try, and have kind of a beginner mindset or a learner mindset, and I'm sure you'll find your way. So what do we think? Mind blown. This role encompasses so many other roles inside of an organization, and I think a lot of those roles were mentioned. Having an understanding of engineering, having an understanding of the product and design and accessibility, but also those, and I don't like this word, the soft skills, but being a good communicator, having empathy. You have to have this full set of skills to be a really good product manager. Analytics, understanding, being able to read the data. How are you getting this feedback from your customers? You have to analyze the data. You have to understand strategy, so you need to be able to understand what's happening at the C-level and how you translate that down. And most importantly, and she said this at the end, was the mindset. You really do need to have a beginner mindset and learning mindset, a growth mindset. That's where you're open to the possibilities and you're not afraid to take on another challenge. So again, shout out to the product managers out there. We need more good people like this. I agree. Some of the parts in this episode brought a tear to my eye. Me having experience with front end development, backend development, particularly of digital experiences like that, having a great product manager on your team makes everything so smooth and makes everything better, and you really feel like you are addressing problems that are going to have an impact on people's lives and on the things that you make. It is incredible, and it's not like what Ajay said, hero ball, right? You're really kind of sitting back and empowering the people on your teams to do their best and to reach their potential In these situations. It's not about taking the ball and being the star and being the center of attention. You're really taking these different perspectives, translating them to where they need to be, and making things make sense for people who may not share those skill sets. It is, I don't even think that the soft skill is a good word. It's just a skill, and it is so meaningful for people like me who have to do this work. Exactly. Johan, what do you think? I'm just amazed at the breadth of skills that they use in their day-to-day jobs. Right? Angela was just talking about this, the knowledge of the engineering, the knowledge of the design, the being able to read data, which it's a growing industry right now, the data science, but it's not easy to do. And then on top of that, being able to communicate, having to make decisions, having to know when to step back. That's just a lot of things that come into one role, and I'm amazed that these people are able to do so well with all of these different things that they have to juggle. Absolutely. So we've heard about product management and we have an understanding about what it is and why it's important. And a healthy respect. Indeed. Absolutely. Yes. If you know a product manager, buy them a coffee. That's a great idea. Or, like Product Happy Hour, a beverage of their choice. So, next up on Re:Role. Okay. Every company they say needs a website. That's kind of a no-brainer, right? And our startup is no different, but this website has to be more than just flashy. It needs to be functional. It needs to be stable, and it needs to be secure. Next episode, we meet the web developer. And that web developer better not use Flash. No, I'm kidding. Oh, no. A different kind of flashy. Ooh. We're so glad you sat with us through this episode, learning about the product manager. We want to hear what you think about this very integral role. Tweet us at Red Hat. Use the hashtag Compiler Podcast. We really want to hear what you think about one this series, and two, how does this role look in your company? We would love to hear it. And that does it for this episode of Compiler Re:Role. Today's episode was produced by Kim Huang, Caroline Creaghead, and Johan Philippine. Victoria Lawton is our Rosetta Stone. She does a lot of playback, and she is priceless. Big thank you to our guests, Era Johal and Ajay Waghray. Our audio engineer is Kristie Chan. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you like today's episode, please follow the show. Rate the show, leave us a review, share it with someone. It really, really helps us out. Thank you for listening. Don't forget to listen to some of the other episodes if you haven't caught them, and we will see you next time. Bye-bye. Bye. Take care.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Blog Post

Red Hat Enterprise Linux Common Criteria and FIPS certificates

2025年 8月 18日  |  Jaroslav Reznik

...

Blog Post

Friday Five — August 15, 2025 | Red Hat

2025年 8月 15日  |  Red Hat Corporate Communications

...

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.