Building AI-Powered Products at Scale with Mario Rodriguez, CPO of GitHub

Rebecca Calogeris: Want to take your product management career to the next level on your schedule? Now you can. With Pragmatic Institute's Product manager certification in a new on demand format. Learn proven frameworks, market driven strategies and real world best practices. Now available in a fully flexible, self paced format with interactive activities, case studies

Mario Rodriguez: and flexible learning, you'll gain the skills

Rebecca Calogeris: and certification to drive real impact for

Mario Rodriguez: your team and organization.

Rebecca Calogeris: Get the world's most sought after product certification now available anytime, anywhere. Uh, hello and welcome to the Pragmatic Product Chat series where we tackle the biggest challenges facing today's product management, product marketing and other market and data driven professionals with some of the best minds in the industry. I'm Rebecca Calogeris for Pragmatic Institute and your host for this episode. Joining us today is Mario Rodriguez, Chief product officer at GitHub. Mario leads product strategy for the platform that becomes really, it's an essential infrastructure for 150 million developers. 77,000 organizations rely on this daily. I think he's in a really unique position because he's steering product decisions for a platform that not only is evolving really quickly, but has such a diverse user base from solo developers to Fortune 500 companies, all of who also think of themselves as technology experts. So that's a lot of pressure from your user base. So uh, today we're going to dive into how he and his team make decisions and prioritize in that environment, um, what they've learned as like really being early in on AI and where uh, they think this is all headed. So welcome Mario.

Mario Rodriguez: Thank you so much for having me, Rebecca. I'm really looking forward to the conversation today. So it's great to talk to people about product management, especially in the era of AI where everything is changing and the future kind of gets forged almost on a weekly basis, right?

Rebecca Calogeris: Yes, it's very hard. There's no like two year roadmaps anymore

Mario Rodriguez: before you had, you know, we call it an LRP, which is a, uh, long range planning and in LRPs before you could be very, not necessarily accurate, but directionally aligned. And today you have to look at that on a quarterly basis in my opinion.

Rebecca Calogeris: Absolutely, absolutely. Okay. So I always like to start, Mario, with everybody's sort of origin story, like how did you get where you are today? Why are you so passionate about product? Give us your history.

Mario Rodriguez: Yes. So I was born in Cuba, so the accent that you hear is from that. I migrated to the United States when I was 14, went to high school in Miami and then to the University of Miami in the reason why I'm saying this is. I went to study at the University of Miami, electrical engineering. And my father had an electrical engineer, um, electrical company. And kind of the idea was I would take over the business after I would graduate. I started tinkering a lot more at that moment with radio frequencies. And I was like, oh my God, this WI fi stuff is really, really interesting. And, um, I took an internship of Lucent Technology. And at that moment Lucent Technology had, in my opinion, one of the best technologies when it comes to the tower where these radio frequencies go and they will power things like transferring your call from one tower to the next one. Which if you think about it, if you're walking, that's not really hard to do. But if you're in a car, then it's really hard to do. Exactly. So when, uh, I don't remember who's the company that was really bad, you would constantly get dropped calls. It's because the tower couldn't do it the right way. So the tech inside that tower was really, really important. So I went there, you know, I'm an electrical engineer. I know capacitors, do a bunch of things, you know, heat dissipation circuits. And um, you're playing a lot more with RF frequency as well. And the team had me program in Perl at that moment. I don't recommend Perl as a programming language to get started, but like, maybe it is, it's a scripting language, so it's good. But nowadays probably you will get started with something like Python, but. And I programmed 10,000 lines of code and I was like, what am I doing? Like I, I could just type and this thing just happens and I'm here doing things in cad, in matlab, maybe I should switch. And I decided to also give computer engineering. I couldn't do a CS degree at that moment in uh, that short, um, period of time. So graduated and I was like, I was determined then to go to a software company and was one of the top software companies in the world, Microsoft. Uh, but I didn't have the, necessarily the pedigree but like all of the, I would say requirements, the deep CS requirements that you would, you will have to have. But I was a college student and college students are really good at playing games. So I applied to the Xbox division and I got into Xbox as what I was called at that moment, ste, which is a software test engineer. And that's really profound and formative for me in the sense of I worked with some teams in there that were world class. So imagine you come out of school and you get to work with some teams that are just absolutely amazing. In the Halo team at uh, that Moment with Halo 2 was great. Worked in the Fable franchise that was led by Peter Mullinux. Um, I worked on Forza Motorsport and the first ah, installment of, of that game. So it was just really, yeah like really transformative. And I was like, maybe I want to jump from being an engineer to being in a producer in a game. And that uh, led me then to exploring product management. And producing a game is very different than product management what I do right now. But in the end I decided no, I love being an engineer. I think producing is great too. But where I want to spend more of my life, it's on that product making and not necessarily of a game but something like, if you think about what I do today, something like GitHub. So I took a bet on um, a team here in the east coast and I just moved from Seattle to the east coast to start as a PM one Like I think uh, at that moment you couldn't move from ST to PM just laterally. So I started just as a PM and from there the world's history. I said in PM over the last um, probably 20 years now and has been a ride and have enjoyed every single part of it.

Rebecca Calogeris: I, I mean we're all biased here, but it is the best profession, right? It's such a great combination of things. And again what you also get to do at GitHub is enable other people. So you have your product and you get to enable other people to bring their product to life. So it's like this wonderful circle.

Mario Rodriguez: Yes, yes, GitHub is exactly. And I think the way I explain what I do as uh, a living actually to my wife and kids, I say look, humanity has already invented the fire and the wheel. Everything else we're going to be doing from this point forward is going to be powered by software. So my job, or daddy's job is to make sure that I am giving software teams the best tools in the planet. And if I'm doing that then, you know, humanity should be advancing forward at an accelerated rate. And that's great to do. And like you said, I'm actually creating product not only for software developers, but also for those product managers that interact with the software developers. Marketing right now is super involved in the software, in what we call that SDLC or software Development Life cycle. If you think about legal, they're also in there. So like it starts bringing in a lot of other disciplines as well. But yes, like, I talk to my product team about creating product for ourselves and I talk to our engineering team about creating product for ourselves, which is a very nice cycle because you could, you get to play with the tool or you get to play with what you're making constantly. It's kind of like molding clay. And in some jobs you can do that. And in this job, like, I consider myself incredibly lucky on that end. You just constantly, constantly shaping clay and dog footing or using what you know, what you're creating with the hope of making it better every single day.

Rebecca Calogeris: That's true. Right. You are, uh, users of your product in a way that very few of us can be as authentically. Right. Um, and that does keep you. I mean, it's good. It's hard. It can be hard too, because you can maybe, uh, be somewhat distracted by the way you guys work and remembering that not everybody works that way. Right. So your tools need to support different ways. But on the other hand, like, who's going to be harder on your. Like, no, you can't, you can't hide the flaws, right? Your team's going to be like, this does not work.

Mario Rodriguez: And like you said, Rebecca, initially, like, we have 150 million people in the platform. That's a lot of opinions if you think about it. So how. And they're all valid, right? Like, we all have opinions and that's the beauty of humanity. Like, the opinions are valid, they're ours to hold. And how do you then shape a product that is not low common denominator on all of those opinions, but is constantly moving the craft of software development forward? And when you have a team that is only serving 100 customers, that's a very different team than when you have a team that is serving 150 million users.

Rebecca Calogeris: Um, yes, and let's talk a little bit about that because not only do you have 150 million users, but they range like, right, from like the solo person coding just an idea that they have they want to play around to some very large enterprise organizations. How do you then in your team prioritize your efforts? Forget, you know, technical debt. We can talk about that too. But like, how do you prioritize even just which audiences to serve and not end up doing the lowest common denominator

Mario Rodriguez: product, which you brought up 100%, I would say. It's so hard seeing it's more art than science at times, I think. Priorities, um, you know, if you think about priorities and setting priorities, it's all about trade offs, in my opinion. And why I tell the team, constantly doing a great product is a really hard thing because you have to constantly keep in your head not only what you're doing, but also the trade offs of it. It's kind of like, you know, um, the color white would not exist without the color black or like, you know, like the space that holds in, um, in a glass. Like they both are needed, right? So you both need to have an opinion and you also need to understand the trade offs. And that is, in my opinion the art at times in prioritization is understanding what is it that you're doing and why you're not doing as, ah, equally as well. And what are the second level and third level effects of that decision overall? Um, so going to your question or going back to it, the way that I think about it, it's more as, hey, where is it that we're going and what does success look like? Like if you really as a product manager, and I really mean this to all of the audience listening, like if there's one thing that I would say really helps a product manager is understanding with extreme clarity what does success look like. Because if you really understand what the success look like and that could be for that feature, that could be for the quarter, that uh, could be for the year, then making those decisions with trade offs becomes a lot easier, becomes a lot more objective. It becomes a lot more of an open discussion on curiosity. And when you don't, then that's when you actually do things in a biased way. So the way that we think about priorities is okay. Like right now as an example, we know that maintainers need a lot of things from us and that's very different. A maintainer of an open source product or project is very different than the administrator of an f, uh, Fortune 500 company.

Rebecca Calogeris: Hm.

Mario Rodriguez: And we cannot just say, oh, we're only going to do things for maintainers and we're only going to do things for the enterprise. The reality is what success looks like for the GitHub platform necessitates investments in both. So we have a maintainer squad and you then have to look at the portfolio on how you're investing. It's kind of like when you do in the stock market, you look at your investment portfolio and you're making sure that it's appropriately in the risk profile of how you want to do it towards that success. You know, for some people's retirement, for some people it's buying a house, for some other people, whatever it is. And this is why I say important, because if your Definition of success is retirement. That's very different of hey, I need end money to buy a house and I'm going to invest this way to do that.

Rebecca Calogeris: Right.

Mario Rodriguez: So, so we always talk deeply about what the success look like and then prioritize based on that and then kind of ah, arrange what is it? Because like every team we, we do, we don't have unlimited set of people to work on things. So it's really very important to us to then make sure that we have our investments. Meaning our people are wonderful people kind of in the right problems. And we have a maintainer squad. We're working right now on a set of enterprise improvements on what, what we call our licensing and teams product. And of course we're investing in AI, we're investing in actions, etc. So that's kind of the framework that we use. But we're always what does success look like? How many people do we want to kind of put within this bet and then within that making sure that we have this mosaic of those investments across the product portfolio.

Rebecca Calogeris: So that makes a lot of sense to me in terms of like sort of having teams or uh, groups that are focused on these different priorities. And I could see then that you could resource up or down depending on where you wanted to invest and where you were going to take the big bets. Uh, it does create the um, the we all, we, we all have horror stories somewhere in our past where the parts of our product were moving separately and forgot. Right. Forgot to make sure that there was still alignment. Do you guys ever have or how do you keep yes. From having like oh, they changed that and that broke this.

Mario Rodriguez: Yeah, there are still problems going even to the previous question too if you think about it. Maybe a solo developer will use our feature set this way. So let's call that X. And then a uh, team of 100 people working on a mono repo will use that same feature but they want it to be shaped more like Y. So how do you reconcile between the X and the Y? And that becomes a lot of interesting discussions overall. And what I would say is the way that we think about it, we work more on horizontal features that enable both of them to be successful. And when we get it wrong is when we try to say no, uh, I would say Y wins over X. And when the reality is what we could be doing more is just enabling the workflow horizontally and then enable other people can then build the tools on top of that horizontal piece to do things uh, on it. So that's one thing that I would say is very unique at GitHub is yes, sometimes you do have to have a position and we do take it. But a lot of time what we're trying to do too is create the. What's the best word, I would say the primitives that are horizontal to enable both of those use cases to happen. And in some cases, uh, which I don't think is a bad thing at all, we go ahead and say, you know what, we're just going to do the API first and try to see how people built on top of that API. Is it specifically for I would say the enterprise Persona. There are times where like doing the feature in the UX is not at all what you should be doing. And we need to enable the API first, learn a bunch and then you could do a UX on top of it if it's even necessary at that moment that we're still learning that at GitHub in my opinion we, we want to be more API first and you know, we're getting better every single week at that. But we're not there yet. So I continuously challenge our team own thinking. API first. But that's kind of one aspect of it.

Rebecca Calogeris: No, that's smart too. Like to not do the people tend to go in the polished thing first and you're like let's go back, let's do like what is basically a live wireframe version of it, you know, in API or whatever version it is.

Mario Rodriguez: Correct, Exactly. It could just be a sometimes like

Rebecca Calogeris: what if we did it manually in the background until they saw they actually used it and then we could automate it. Right. Like there's all kinds of. Yes, yeah.

Mario Rodriguez: And you know nowadays with prototyping tools we have spark internally, then you even can just bycode that very easily and then just get internal opinion on what that would be. And then your second thing is, you know, as we're trying to create this mosaic across the portfolio, there's two things that are always trade offs. Um, one of them is what is that end to end and how you end up not shipping the org chart, what usually people say. And the other trade off that I do also see is how like imagine that there's three teams that have the equal opportunity at achieving something but you don't. You, you can only make two bets how you end up doing that and that does cause a significant amount of conversations. And I'm not gonna come here and tell you that those things don't happen because they do. That is the art of product making. Like if you knew that the Way to PMF or the way to success was just this linear thing, then our job will be very different. By the way, it's kind of like creating a build. Let's say if you have the plan of a building and then you just need to get it up. We have figured out that as humanity. Same thing with agriculture, we figured that out. Creating software is not something as easy as that and it does necessitate a lot of creativity at the end in decision making. So what I would say is the way that we think about that is more on the human side and we talk a lot more and maybe we could get into this later. But recently I've been talking a lot more about understand, identify and execute. This comes a team from Naomi, uh, from Facebook, from Meta, and I recently got introduced to it. But I'd really like that framework of kind of going deeper into that understanding, identifying execution. And the reason why I'm mentioning that is at times that forces alignment in the horizontal across three teams. Like if all three teams really understand what is it that we're trying to do, they all kind of, you know, identify those touch points. And it's very easy to heal, to build something that you're not shipping the org chart whenever you don't have that common understanding. I would say it's when you do get into situations that are a lot more tricky. And at GitHub, we're getting better at it. You're starting to see a lot more features that go horizontally for us, uh, that are deeply integrated into what we call workflows. And I'm really proud of the team for doing that and happy for us to continue to get better at it.

Rebecca Calogeris: Excellent. Um, so you know, you started off at Microsoft.

Mario Rodriguez: Yes.

Rebecca Calogeris: And then Microsoft followed you. Right. Because you guys were clearly. It was you. Uh, but yeah, you guys were really early with Copilot, right?

Mario Rodriguez: Yes, Yes. I joined GitHub in 2018, part of the Microsoft acquisition. And my first job at GitHub was to immerse myself in the enterprise and especially the enterprise product, this called GitHub Enterprise. We had both a server product and also a cloud product. And my job was to immerse myself into the needs of the enterprise and make sure that what they needed from the GitHub platform we were, you know, we're building. So I did that and then after that I was, I worked for a year in what is called core productivity or the core platform, if you want to think about it. That's like version control, meaning get pull requests, issues, things like that. Um, and learn a ton then about kind of that part of the product set, which is very different than the enterprise product and framework and platform that we were building, um, in the first year. And then I transitioned to Copilot. And I still remember, um, when Copilot was doing this public preview, I was actually not in that team. I was in a sister team working on a product that was going to do a public preview to the same day. And I, um, you know, probably a month before that I had seen the first. Actually probably was significantly more than a month. It was, I would say, several months before I had seen the first version of Copilot that was going to transition to shipping in that timeframe. And I was like, this is just gonna be absolutely insane for the software industry. And I remember having a conversation with uga, um, who was at that moment leading the release of Copilot. And I'm like, you take my spot in releasing your product. Your product is going to be 10x of this other thing that I'm working on.

Rebecca Calogeris: I want to follow that.

Mario Rodriguez: So he did, um, and, um, I now have been, you know, I've been collaborating with a Copilot team and then after that worked, um, leading Copilot to what it is today and then transition into a shift product officer role.

Rebecca Calogeris: I love that. So you guys, you know, you had Copilot, you also. So you, you've experienced AI from several different ways early on. Right. You also have an enormous number of users who are now scrambling, running, racing to build AI to leverage AI. Um, what has that been like, both from a, ah, for like managing your team as it goes through that process, but also managing your, your platform to enable others to do that as well.

Mario Rodriguez: Yeah. The truth is it's been a tornado is the way it's um, I would say, like I was telling you when I first saw one of the demos, one of the key things that I think Copilot did that was very different from a technology perspective than what you had before with these MLOps models and things like that, is that you could really understand human language, like natural language. That's what really made the huge, like, it understood it. Like I would say the acceptance rate at that moment was probably of code completion was probably in the 20s. Um, so it wasn't great. It will fail. Like, if you think about it will fail 80% of the time. And even though it will fail 80% of the time, it still was like, oh my God, like every time it will get it right. You're like, this is, this is better than sliced bread. In the profoundness of it was that study understood natural language. And since then all we have done is really just lean in on um, two things. One is copilot, which means human epicenter, we really believe on that. Um, and the second thing is this deep understanding of natural language kind of unlocks a lot of creativity that we could have in the software industry. So if you think about it, what we have been doing is getting ready for the next model that understands even more. Sometimes people talk about it, ah, as stacking PhDs and that's okay, like if you're going to be, you know, doing math and physics and things like that. For us really is the intelligence of the model, it's getting better and better and better, which then allows us to pass it tokens that it could understand and then translate that into intent and code. And that has been, I, um, would say shifting and improving at an amazing rate. Like if you think about GPT3 or the first codecs model M compared to just GPT5 that just came out. And if you think about anthropic and the first version of cloud to what, 4.5 that just came out. It's just unbelievable what we can do with that level of intelligence if you pass it the right token. So for us it has been an um, ever. It's a relentless pace to keep up, um, and to make sure that we're creating for the future. This is one of the key things that I do think is different also for us is we will lose if we only create for the present. Like if we're like, oh, the model right now cannot solve X and then you just give up on that. You will not create the best product three months from now or six months from now. So you constantly have to both have a deep understanding of what are the limitations in product making today, then make sure that you're doing some things of it without over indexing on them and then constantly then going towards that future. So when the model drops, then you cash up very quickly into that product experience that you wanted to do. So we started with code completion and then it was a conversational experience, then it was agent tech. Um, and that's the place that we are right now is in this agentic world. And that is changing everything. It's changing not only the developer, but it's also changing product. I use Copilot every single day to do something in production that would be, I'm writing a PRD as an example. And yes, I still make uh, even though I'm CDO I always like to be deep. So many times I create a PRD or many times I'm kind of exploring a specific feature a lot deeper and I want Copilot then to help me as brainstorm that and then be able to create a document for my team. So I use it a lot for that. I use Copilot for prototypes. Like I was saying in Spark, I use then Copilot for research as well. Like if I want to go deep and research something a lot better and I use it, then I use it at times just to like, have a back and forth on, on a specific problem space where not necessarily I'm researching it, I'm just trying to improve my understanding of it. Um, or maybe, maybe another way is increasing my competence on that specific line. So I use it for product all the time. Like I'm gonna do an interview with a customer. Well, I may use Copilot for that too, and then kind of structure my notes. So even in our space, there's this thing where you have to be constantly using AI to get better at AI as well. And I think the product teams are not using AI today will start diminishing because those companies will not be successful at the end.

Rebecca Calogeris: Yeah, uh, it's interesting too, because you talked about the sort of the tornado, the relentless face of change. Right. And it's true. And I think we, um, I don't think it stops right. Sometimes we go through these other things and it feels like there's a big surf, but you're like, okay, but then we're gonna, and it's gonna slow down. And I don't, I don't know that that's gonna happen. Right. I feel like we're just gonna at least, uh, 100%.

Mario Rodriguez: I think the next 18 months do not look like a stuff. I actually joke with my teens sometimes that, uh, I tell them, look, no model provider did a new model this week. We'll get a break. And that's a little bit of a joke, but like, but it is true. Like sometimes every single week we're doing a model release and we simship with many of these providers, which is, you know, both a challenge and also an amazing experience because you get to, you know, every time that happens, you get to have your product to be better and, um, a specific place. We also believe very deeply in what we call developer choice. Like, we know for a fact if you look at history of time, developers are now like, oh, I'm only going to use one tool in this specific way. And they said, like, they love choice, they love experimenting, they love tinkering, they love going in and customizing something to what they really desire. So that that DNA in GitHub of developer choice then requires, not requires. Like it's our responsibility to make sure that we're leaving to that DNA every day and making sure that, hey, you want to use this model, go ahead and do it. And you want to kind of try these type of experiences, go ahead and do it as well. And enabling that at scale is a challenge, but it's incredibly rewarding too. But yes, I would say from an 18 month perspective, things might be increasing in speed instead of decreasing. If you think about open source models, if you think about technology on indexing, if you think about new algorithms that I'm starting to see, if you think about rl, um, um. We're very lucky to be alive at this moment, I feel.

Rebecca Calogeris: Yes, yes. Uh, and I think that I imagine the people on your team, the people here were very excited about those new developments. But there is a, there's a tax, as a person, there is a tax, right. And there's a tax on your team when the pace is, is, is that big for them no matter how much you like it. Right. And that's, and then probably you have a lot of people who really thrive on that, but sometimes they're actually more likely to burn out because they also enjoy it and so they don't really realize there's a problem until it's late. So how do you as a manager, like a leader of your product team, how do you, how do you, how do you keep the burnout? How do you build the excitement and give some relief on that sort of relentless pace?

Mario Rodriguez: Yes, I would say the way that I think about is sometimes people also talk about this as work life balance and things like that. Right. Like if you think about an athlete, right. An athlete needs rest in order to be, to perform at a top level. And they, they do that like they know they cannot just go in and without rest, perform at their top self. So they make sure that they have those breaks if you want to think about it. And I think the same for us as a discipline, not only engineering, but meaning people kind of developing day in, day out. But like even in product you have to take that rest to be able to perform at your peak. And when you don't, then you will get burnout and all of these other things. Uh, part of that is using AI more to be able to do things. So like you do have to get your productivity to increase. I Feel because it's not like what I call the inputs are decreasing. Like some things you could affect, some things you can't. Like as I was saying, model providers, shipping new models, I cannot affect that. Right. So those are inputs. So it's more about building than okay, if that is going to be a true statement, what is it that we could do to make sure we have better productivity when those things happen and it's not affecting us? And then how do we cycle things so not the same person is constantly dealing with it and then you get a little bit of that rest. So we have a concept of dris, which is direct, responsible individuals. Those will change depending on the model launch at times. And we have other ways that we are looking towards to create that rest overall. But I think it's important. And as a leader, what you have to do is constantly look at the places where either that individual is pushing themselves past the limits and then try to make sure that they understand that they could take a rest and that they understand that that is what is needed to perform at the peak. And, and then the second thing is you have to look for ways to do less instead of doing more. So if the inputs are going to go and increase, then me going and saying, oh, we have to do now, you know, 10 more features is not the right thing to do. So really what we need to do is do only three of them really, really good, which then puts a little bit more pressure and now you're picking the right three. But that is another way that you have to make sure you get stronger at is by then focusing more on the few things instead of on 10 things. You do end up doing three and the combination of both of those things ends up being successful many times. But I, I would not, I would say it's not easy. Like we all struggle with it. And what I try to do, even myself personally, is so I journal a fair amount. I try to ask myself every Friday, okay, how is it that, uh, like let's say I had a week that I did have to work 70 hours, as an example, 80, or, or, or some insane amount for X, Y and z reason, well, the next week I better not do that.

Rebecca Calogeris: Right?

Mario Rodriguez: So I try to journal and be

Rebecca Calogeris: like, okay, so you can like see back. You can see.

Mario Rodriguez: Yeah, like I could. Exactly. And then I could go on, keep myself honest. Because if a lot of. Look, a lot of driven people will

Rebecca Calogeris: go for an extent, it's our fault.

Mario Rodriguez: Yeah, exactly.

Rebecca Calogeris: No one's making us do it.

Mario Rodriguez: We go for an extended period of time. And you know, my wife also reminds me of those things too.

Rebecca Calogeris: But.

Mario Rodriguez: But like, my journaling is one way that I do it. And then I also keep track of like, oh, in that journal. Like, this team might need a little bit of rest. So, like, let's make sure that in the next iteration of things that we're rethinking that or be like, you know what, we just need to increase headcount in this team by 2x. And that takes a little bit of time because you're going to hire, let's make a small number, 10 people. You're going to hire 10 people tomorrow. So. And then get them all ramped up and all those things. So you have to get ahead of those too. But I'm constantly just looking at places where I know we are stretched or are running too hard and then try to figure out how to build that rest. And you always have to have the rest, in my opinion, to perform up top. And the people that don't actually are. I don't believe that that is the right way of creating product.

Rebecca Calogeris: No, no. Well, I think a couple of things there. One is, I think, and it's an important thing as leaders, is to demonstrate it. Like, we can tell people all the time that they should make sure they take rest and balance, but if we don't also demonstrate that behavior, I think it rings a little hollow sometimes to them. Right. Um, but another thing that you said and uh, you talked about it in the beginning and you brought it up, kind of alluded to it again, was the intentional nosy. Um, and one of the things we like the. One of the most powerful things and product we need to do is say no. But so often I think the no isn't intentional. Like, we said yes to these things and that's what everybody focuses on. But there's still a feeling of the other things, like just like creeping and poking, you know, like looking right behind you to be like, are you ready for me yet? And that leads to stress and different expectations from within and without the team. And you really talked about like, we're going to say yes, but that also means we're going to explicitly recognize that

Mario Rodriguez: we said the no. Correct.

Rebecca Calogeris: Right. Yeah, I think that's really important to do it so overtly, 100%.

Mario Rodriguez: And ah. And look, sometimes I would say even me personally, I'm not very successful at times at that either, so. And I think Vlad, um, so our CTO and I talk a fair amount sometimes about this and sometimes we call it seeking the truth. And when you really seek the truth on your product plan or the next feature or what does winning look like, then you get to those no decisions fairly easy. When you don't seek the truth on it, then those no decisions can be incredibly contentious.

Rebecca Calogeris: Or

Mario Rodriguez: you trick yourself into a, uh, yes, no, that is not very intentional, uh, reusing the words that you were saying. So for me, it's really about seeking the truth to get to that no. And seeking the truth might be, hey, this thing is burned out as an example. That is seek that truth and be like, we're saying no because of that, not because of anything else, or sometimes

Rebecca Calogeris: a bad idea because we can't do it.

Mario Rodriguez: Exactly. And the second thing might be like, hey, winning. Winning looks like X. This thing is not. Does not look like S, does not accrue to X, does not have that great correlation to it. So why would we do it? Like, I get it, it's a neat idea. We have those every day. But, like, it's not that. So I would say another arsenal or another tool that we have is seeking the truth to be intentional. And if you're not seeking the truth, it gets really hard to make some of these decisions.

Rebecca Calogeris: I think that's one of the things we talk about is like being in the market, really doing interviews, really understanding what's happening, uh, because then you make the right decision and there is a different level of confidence in that decision for you and for others. And I think, um, that can be hard right now. We talked a lot about AI. It's very easy to be technologically obsessed at the moment and forget to be customer obsessed or market obsessed. And I do think that it's that market obsession, understanding, seeking the truth, knowing does give you confidence in your decisions for sure, 100%.

Mario Rodriguez: And from a customer perspective. One of the things that we're seeing in building AI products, which sometimes every single feature you end up doing in AI, ah, it's searching for PMF or product market set. The closer you get to the customer, let's say pick five customers that have the same problem and just go and build with them. That we have seemed to be a lot more successful than saying we're only going to build for us. As an example, um, it is a necessity that we built for us, meaning that we're playing with the product constantly. If not, you cannot create good product in this space either. But it is also very important as you seek the truth, that the truth is not only yourself and that, uh, you also are doing it with customers. And that feedback loop and that feedback loop being very, very tight is very different now in the era of AI than it was before and increasingly more important. I'll give you another example, actually. We just recently released, um, I think it was September 25th, the copilot CLI. And we took a different approach to that feature. We're kind of transparently not the first one in the market. In the Copilot cli, probably some people would say that, you know, we missed it. Um, and, you know, there's a little bit of truth to that. And it's also not. Not really that. So we put it out there as experimental because we knew there was some gaps going back into intentionality. We had now worked on the CLI because we're working on agent mode, and we wanted to make sure that we had a great agent mode in Visual Studio code and in dot com, and we knew we would get to the cli. But at that moment, that was not the time. It was an explicit no decision. And then we started working on it. We're getting ready and the product is experimental and it doesn't have some of the features that other competitor products do. But that is not stopping us. We're in this in the long term and we started building in the open and we released it. And we're just learning in the open with all of our users and, you know, like, someone gives us a feedback, we're going and make that change probably within that day or, you know, definitely within the week. Um, and like, that's very different than building product before. And yes, you will build some things in the open, but now with this level of velocity and direction. And so I think it's really important, as we build in the era of AI from a product perspective, to seek the truth of customers constantly and just focus maybe on five of them and then just build for them. And you will get a lot more learnings out of that than going back in the lab, doing something for a month, releasing it, and then trying to learn on a m. Monthly basis.

Rebecca Calogeris: It's true when everything's moving so fast, if we wait till the product is finished, then the product is obsolete.

Mario Rodriguez: It's almost guaranteeing that it's not going to have the impact 100%. You're not going to. I mean, maybe someone out there is incredibly, uh, getting it right every single time. But I know that I'm not that good at predicting the future that way. Now what we are good at is making sure that we're building with customers. Now we're trying it a slightly different way. And building a lot more publicly than we have built before.

Rebecca Calogeris: Uh, so everyone listening right now is going to be, Is she going to go back and ask him about that? Uh, you brought up the understand, identify and execute meta framework. Uh, tell me a little bit about, like you said, uh, it had an impact on you and I'd love to hear a little bit about that.

Mario Rodriguez: Yes. In M. The reason why it has had an impact is because it's really easy. It's really um, simple. And like when things are simple but profound, you could use those frameworks successfully. When things are complicated to roll out or to deeply understand. Like, you know, usually, at least in product management, they're not a good framework overall. I, uh, think Shape up as an example from Basecamp, I love that framework as well because it was very simple to understand. You might not agree with them, uh, but it was very simple to understand. And like in the era of AI, I would say it really pays off to understand at a deeper level. And that understand comes with data with customers. And then you just create a extreme clarity then on that phase. And then from there you're like, okay, I deeply understand what is happening now. And then I go in and I'm like, okay, let me identify then how do then affect the change that I want to. And then from there you go to execute. Many people skip the deeply understand phase. And that was the profound, um, thing is.

Rebecca Calogeris: Mhm.

Mario Rodriguez: As an example, prior to this I'll be in many meetings talking with EPD teams and then we're like, hey, we are going to do these features. Like again, that conversation is about execute, not about understanding, not about identifying. Right. It's we're going to do these five features. This is when they're chipping, meaning this is the roadmap on how we're going to get it done. If I think about when I go to a customer, they're always asking me, okay, when what is the roadmap? Which again, that's the execution part of it. And the real magic doesn't happen on that. The real magic for creating a great product in my opinion, is seeking truth and understand and then seeking truth and identify. And then yes, you need talent to execute. Right. Like that's a, ah, necessity. 100%.

Rebecca Calogeris: Mhm.

Mario Rodriguez: But if you have the best talent in the industry and you really do not understand it and you really cannot identify the right things to do, it doesn't really matter. All you did was waste than your talent.

Rebecca Calogeris: Yeah.

Mario Rodriguez: So, so that's why it's. I feel the product discipline for not the longest time, but a lot of times in a lot of companies focus a lot on the. Here's the things that we're going to do and by when. So. And they do a lot of the what and by when. And yeah, sometimes you do, you know, who is, uh, it. Who is the Persona, things like that. But we don't spend enough time as product, um, in our craft on the understand face. And when I read what Naomi had written, um, in. I think it's, um, called now in systems. I think, uh, Naomi Systems.

Rebecca Calogeris: Yeah.

Mario Rodriguez: Um, when I read it and then really went deep on that understand phase, I was like, this is profound. And this is actually very applicable to my team and I think to more and more of product management, especially in the enterprise. And if we want to affect change, meaning if you and I can get better not only consumer products, but also B2B products and B2C products, um, then that's going to have a refund that's going to move to you. Um, that's going to move kind of humanity forward. For sure.

Rebecca Calogeris: Yeah. All right. This has been amazing. We talked about lots of different things. If you were going to have listeners do two things differently tomorrow, based on what we talked about today.

Mario Rodriguez: Yes.

Rebecca Calogeris: What would you have them do?

Mario Rodriguez: Okay, one of them is understand. Like, really go and understand what are you trying to do? And seek truth on that and have an understand phase prior to you get to any execution phase. So have to be extensive, but really challenge yourself to have an understand phase. Um, the second thing that I would recommend people to do is to, uh, maybe I want to pick three, but, like, use the product that you're building every day. Like, and if you had the chance to do that, then please do so for those that have the chance, then that would be the thing that I would recommend. 100% overall. You could even have a great understand phase. And then in the execution, if you're not using the product, you might still not create a great product. Now, if you don't have the opportunity to do that, then the closest you could come then is identify fast customers are using the product that you're building every day, and then just build with them, build with them, build with them. And I think those two things combined will get you to creating great product in the era of AI.

Rebecca Calogeris: Love it. All right, Maro, this was truly a great conversation. I really appreciate you coming on. Uh, and I'd love to have you on again.

Mario Rodriguez: Thank you, Rebecca, for having me. It was super fun to do.

Rebecca Calogeris: Excellent. All right, that does it for today's episode. Thanks, everyone, for listening. And don't forget to join us next week when we tackle another great topic designed to help you elevate your product, your company and your career.