 Hey, hey everyone, this is Carlos and the founder and CEO at Product School today I'm here with Rondi Mertis who is the VP of product at Salesforce. Hey Rondi. Hi Thanks to be here. Thanks for being on the show. I was taking a look at your background on LinkedIn and there's a couple of interesting things that I found once you you started Economics and business and your first job was at funding so I got pension fund analyst, right? Yes How does someone go from that role to now a VP of product at Salesforce? What was the inflection point that that took you into this direction? Well, it's funny when I was in college I always steered away from going too deep into engineering because I always thought that oh engineers don't talk to people and it's really boring profession, but I've always had this kind of instinct for for software development and software engineering So my first job followed my path of being a economics major in Finance and then I ended up working for a company that was building software products for retail banking and I was an implementation consultant going out on the road Doing everything from support to implementing to even like building little one-off solutions And as we started to move our product to kind of the next generation We didn't have any product managers so the company recruited a bunch of the implementation consultants to go sit with the engineers to get that product launched and When I moved over there, I realized I Think it's just my nature. I really love this. I love the creativity I love the the building aspect of product management and so I just never left They couldn't get rid of me and so I ended up being the second product manager in that company and That company ended up getting acquired by Oracle So I went from being a product manager and a little company to being a product manager in a much bigger enterprise software organization and then it just Spiral from there. I notice that and you you were at Oracle for around eight years That was in the so usually the 2000s and so and the product definition of product the world of product has evolved quite a bit What was like to to working product at that time when maybe wasn't as mainstream or as cool as it is today The battle days of product management. Well, yeah, it was pretty funny There is no and even today. There's no such thing as a product management degree So everybody comes at product management from different backgrounds and different experiences And I think it's in some ways It's more of a mindset than a degree that brings you into product management And I remember when we were first trying to figure out how to write requirements documents We went and looked at IEEE specifications which are mind numbingly detailed and We used those as our starting Template for how we would build out product specifications where you had to write an explicit detail every little step along the way for every UI and every interaction That didn't work as you can imagine It was ridiculous and then we moved to use case modeling and then agile came along So I've seen this whole evolution of first trying to get inspired more by More electrical engineering pure engineering and think about product management from that perspective to where it is today Where it's really a much more agile But the thing that I love right now is a tool to use as more user narratives Where are you just telling a story and then that story really elaborates what your requirements are and so that's it like a entirely different Way to think about how you put together your product management requirements Totally, and I remember when this waterfall mindset Yeah, almost a roll-around like detail planning before moving into execution. We're now probably on the other side of the spectrum But at the same time when you are in a larger organization with like a portfolio of products where the stakes are really high How do you still keep that type of agility as as you grow Well, it really depends on the organization and the culture of the organization so Organizations can be very large but still have a very agile mindset and have an agile approach to how you implement solutions But you've got to nurture it. You've got to nurture it You've got to have the right people in the organization that will have that kind of point of view of how to think agile I think small how to think incremental because it's actually Incredibly critical for a large organizations to be able to Incrementally develop and have solutions that can grow over time So in your case just to get an idea of of the the the current team that that you You have and like the different product portfolios without, you know, too many specifics But how many how do you define product of your organization? Like what are the main products that you are responsible or teams that you are responsible for? So what I do at Salesforce is our employee service solution And I sit under a broader service cloud umbrella So it's every company that I've worked at is a little bit different What's really unique about Salesforce is that we sit on top of this incredibly robust platform So a lot of what we do as product managers is more about Taking the tools in the toolkit that's available to us from Salesforce And then figuring out how to use those and leverage those for the specific use cases that we're developing against so it's um A product focused on employees, which I think everybody can relate to How do you better engage employees? How do you better serve employees? How do you create better experiences for employees? And I think that is something that from the outside is not always an intuitive Because there are multiple products within an organization Especially in your case you mentioned that that platform that is powering a lot of different products and and use Right and there is this dichotomy between Creating and sustaining the platform making sure there's integrations with additional products or initiatives that sit on top Yeah, that's right and I I've worked at companies that don't have that solid platform And seeing the cost of it and it's as a product manager It's really frustrating to not have that platform that you sit on top of because You're spending so much time in your infrastructure That the time that you can actually devote to that value add that that you as a product person really care about the things that really drive Great experiences for the user personas that you care about um So I always when I get into an organization Encourage let's invest in a platform. Let's invest in a structure that we can sit on top of so all of those Commonalities that go across to everything that you're trying to build We're doing them once and then we get to do the fun stuff Which is create those great experiences that sit on top of them and you can do those more efficiently and quickly And get them out the door more easily Yeah, I see the value in investing in in the infrastructure. I've made the mistake of Creating too much technical debt in the past Yeah, I'm going to go too quickly too fast, especially in smaller organizations where Time is everything So how do you go about making those type of trade-offs with engineers with other pms? So they can understand that sometimes you need to invest a little bit more To go maybe slow in the short term in order to get more long-term gains Yeah, I think it's telling the story You know, it's the the war wounds that I have that I carry with me of Just getting a product out quickly But then being beholden to all the tech debt on that product So you get something out quickly, but then you're you're living with this pain of not being able to take it to the next level Because you're continuing to pay the price That you didn't pay initially and there's a balance to it too, right? I've also seen the other side Where you've got a really engineering driven organization and they want this pristine architecture that you never actually get to that level of The differentiating value that we as product managers fall in love with I think you brought up a good point. It's like the culture or the bias of the organization And some organizations are more engineering driven marketing driven. So now fortunately for us We're seeing more product led or product driven organization um in the case of your current organization like What what is the role that product plays? Um, I would say it it's a pretty traditional road map development requirements gathering What is unique about Salesforce and something that I've really Enjoyed learning more about is that product is very tied in as you can imagine being Salesforce into the sales cycle and the deal cycle and getting More directly involved in kind of working directly with account managers to understand How do they position our product? How do they? develop demand within the their customer base for our product and our solution So it's definitely all the traditional stuff that you think with product management but with a stronger lean towards working closely with the the sales organization And obviously sales is a huge stakeholder for you and also obviously your it's some of your customers are Some of the sales for customers are sales place teams Engineering, I don't want to forget about engineering and design um, especially design because when we think about b2b products at least in the past There was they were almost getting a pass as okay. Well, they can be ugly. They don't they don't need to be as Maybe efficient or nice as a b2c product, but obviously that has changed and For sure is the new b2c in that way. So I want to learn a bit more about how you're integrating design into your process Oh, absolutely. I I think I I've really come to love the the triad of engineering and ux and product all coming together and doing joint discovery from the beginning And in my last role, I actually had ux reporting to me and I learned so much From my ux team and my ux researchers. How to think differently because ux really comes to The table with no bias product. We often come with a bias of what we think the solution should be um Whereas my ux researchers and my ux designers they they come to it a little bit more open-minded And so they ask really interesting questions And then the engineering comes to the table and they sort of tell you the reality of the situation and that Balancing act that happens between product and design and engineering is what creates the best Solutions like I was just the other day Having the conversation with my engineering team and my designer all all together um, and I realized that The cost of what I wanted to do Was more expensive than the value it was going to deliver And cost when you think of cost it's not just in terms of what does it cost to engineer it? But it's also what is the cost to maintain it? How many bugs are going to get logged? How many people are going to confuse how it's supposed to work? And then not use it effectively And I wouldn't have known that without having that combination of us all working together and bouncing ideas off of each other and making sure that um I'm thinking about the engineering side. I'm thinking about the design side and I'm thinking about the product side all together I think you're great. Uh, you gave a great Example, I've lived many times. I continue living that you show up to the room or the virtual room And you have people that are representing There's different interests Obviously, there's a global interest, which is whatever is best for the user, but the approaches can be different Yeah, and where you are as a p.m. Or product lead with Technically, you are not the best designer. You're not the best engineer. You're not the best person The best sales person, but somehow you are negotiating the a potential solution. So how How do you really go about really hearing hearing? What the other team is feeling and then ultimately making a decision that you know is probably not going to please everyone in the room so So starting first with your question around how to hear everybody It's the environment, right And I think as a leader coming in um To the conversation Important for you. It's critical for you to make sure that everybody in the room is being heard um So you need to have that person who who comes to the the meeting And is listening for who's talking and who's not talking And that's a role that I think a lot of times as you've met the product management chain You become more and more that person who needs to be that one to make sure that your product managers Are seeing the full picture but to be negotiating with the the engineering leadership or the design leadership to make sure Um that they're hearing each other as well So let's put ourselves in the worst-case scenario We have this uh situation. We are trying to hear everybody in the room. We make a decision for some reason The users are not reacting effectively to it and it's time to change our mind like In general in the smaller organizations that tend to be a little quicker just because there's less people and also there's less users. So in a way like they Impact both good or bad. It's just smaller than Salesforce for example, so Yes, I just want to kind of bring people into that room into your mind of like, okay Like you are dealing with like a big team where you're responsible for a lot of users for a lot of revenue potentially so How do you go about like not only making the decision but also having the flexibility to adjust as you see more results Right. Well, I think it actually starts Back a little bit that the solutions that you design you've got to design them To enable that agility So I I've had a lot of experiences where I overbaked a solution And I made it too complex or I made it too complicated or too difficult to implement And once something's out there as a feature you can never back away from it It's like you built it you own it forever So I think it actually starts first with the way that you designed the solution in the beginning that you've got to design it for Agility so that you can evolve it you can change it you can Build it in a more complex and complete way as you get that feedback as opposed to Um, and this is definitely something that happened in enterprise software a lot because we Were doing once a year releases or you know The organizations that got really agile are going six month releases And so you felt like you had to throw everything in To the feature or the solution because you had this one or two Times a year opportunity to deliver something So Definitely having more releases and having more of a continuous release cycle helps with that So that you don't feel like you're having to bake everything in front But you're allowing for a simple solution to get out there and then Get the the feedback That you get from your customers to drive. What do you want to do next and what do you want to do next? I mean, that's agile 101 when you do get into that situation where you realize you completely hit the mark Um, it's a tough. It's a tough call to make of how do you back away from that? um And it's that's the position that you don't want to be in so if you can avoid it you want to avoid it all together Yeah, and I and I appreciate your sincerity here because part of What I I try to show is that we're all humans and we don't always have this The solutions or the answers to everything It's really more about through this discovery process and asking the questions where we we try to make progress And it's okay eventually to change our mind as we get new information I know you mentioned design a few times you truly care about about design and you you're coming to thermal like product design Bear curve. So can you tell us a little more about that? Yeah, well, and it speaks to some of the things that we've been talking about but When you initiate a new project a new feature that you want to develop What I've seen is just this um pattern that often happens where you start and you think It's simple for use cases for user stories done We're going to get this out the door in a month And then you start to drill deeper into it and the complexity Increases with time and you start asking yourself these questions and you start concocting these designs and you create this like Really really complex solution At the top of the bell curve and sometimes you stop there and that's the worst place to stop Because if you continue having those conversations with that triad of design and engineering You realize that you've overbaked the solution and you start to simplify and you start to come down the other side of the bell curve and so The thing that I believe I've learned is that you got to know that that bell curve is going to happen You're going to start simple. You're going to over complicate the situation. But if you give yourself enough time To get to the other side of the bell curve You're going to come up with a solution that is more elegant and simple and easy to develop and easy to maintain going forward Yeah, and I like what you said about the bell curve because It's tricky like sometimes especially when I when I hear this. Oh, it's easy It's fast From someone who doesn't have to do it Let us really Understand the other implications that might not be as obvious Before we really pull the trigger Yeah Yeah, I've also used the term defensive product management And what I mean by defensive product management is that When you're designing a solution That you have to think defensively What what's going to go wrong? What are going people going to misinterpret? What's going to generate more bugs? So the more complex of a solution you design the more likely it is to be misused um generate bugs generate um Support tickets that may not be buds, but people just don't understand how you use the solution so they're not doing it effectively It's going to increase implementation time and so it's this Like I'd love to be creative But you at the same time you have to be defensive about what you built and think about all of those other things that can go Wrong and make sure that you're counting for them and you're baking them into what you deliver That to me is one of the hardest things in product I think first having the humility to realize that I don't have all the answers and I want to create space for others and then That I cannot do everything that I would love to do There's a lot of things that sound amazing and yeah, but there's only so many things that you can do at a given point and that type of facilitation and sometimes Sharing bad news say no Um, it's hard. So when when people we have a lot of uh students who are spying pms like I want to be a PM at Salesforce or other cool companies like well, are you really sure like yes? I'm biased and I and I love it But there's also a lot of tough moments where you know, I don't think people realize what it really takes to be an effective PM Yeah, there's a lot of disappointment You know, because I do you think that most people go into product management because they like to build they're builders Right. We're all creators and builders and we love to build things and create things and create solutions and designs and um that The reality is that I've never gotten to build The perfect thing that I wanted to build because reality always Comes into play and so I like to think of it as you You have your dream of what you want And you got to have that dream. You've got to like have that vision that Nor star that you want to achieve but then you also have to accept that You're probably not going to get there But at least you can move along the pathway to get to there But you got to start with a dream and then you got to like Roll it back to what are you actually going to achieve? In the next six months five months one month And you're right. I think the detailed products are never done You can always make them a little bit better. Your dream can always get a little bit bigger And it's just that constant disappointment, but also excitement to To do something in the right direction that I think gives me going at least Yeah, for sure So let's talk about your your philosophies around Building a product team and giving people the opportunity to go to grow once they're in that in that product team um How do you usually go about that? um Are you asking more about how do I recruit people or how do I grow people the ones I've recruited? How do you recruit people then we can dig a little deeper into how do you grow people? Okay So we've talked a little bit about the product management mindset and They're we'll first off You have to understand your organization um Which I've worked in a lot of different organizations and product management means different things to different organizations so When you are recruiting In an organization you have to understand. What does that organization want sometimes organizations? They want a strategist. They want somebody who's thinking big who's innovating who's coming up with a big idea Sometimes they just want pure execution. They want this the person that can sit beside the Engineering team and write user stories and acceptance criteria and get things executed And there's a lot of phases in between so when you're recruiting Within an organization you've got to understand what that role is so that you can really pinpoint the right person that fits that role um But I'm typically looking for people that they do have that creative mindset that builder mindset That they're looking for how do I make things better? How do I make things more interesting because they've got to have that motivation To grow to have that big idea that's out there um Yes, I think also especially in your case. I love that you're in on on this on the other side of the table giving people the opportunity to to join a product team because This is whole misconception around What degrees someone should take or master degrees someone should take in order to work in product and Even your own story thing is really inspiring So when it comes down to more hard skills or other things that You can you can see on a piece of paper Like how do you identify potentially in a candidate at least to give them the opportunity to show that they actually think big That they can actually build and grow yeah, well It is definitely a a question of what excites you What what makes you interested are you a naturally curious person? Do you? What do you what do you do to? um Learn do you have that growth mindset? And I think there are characteristics that you can see just to talk by talking to somebody to see Do they have that just intrinsic desire to to build and create and learn and um discover and That ability to communicate to Because it's so key with any sort of discovery or any sort of product role to be able to Talk to people and understand what they need and what they want So those are baseline characteristics Of an individual they don't have anything necessarily to do with technical skills And I've always found that people that have that intellectual curiosity they have that creativity They have that collaborative mindset They've got the right base skills. Then are they going to have the right technical skills? So are they going to be able to write effectively? Are they going to be able to break down and decompose solutions? Those are things that are a little bit easier to train on um, but there's certainly like I've had a lot of People in engineering that want to move into product management um, and that is often a nice pathway in but You also as an engineer you come with certain baggage. So you've got to be able to like separate yourself from the technical limitations and really understand the the product side of it and ask that What and why question and not that how question And that's what a lot of engineering people that come into product management They say still focus way too much on the how and you've got to divorce them from that Because now you've got to be thinking about what and you've got to be thinking about why I completely agree. I come from an engineering background And I definitely had that bias and I would default towards okay But how is this going to work or let me do it because I I've done it before right? And I think taking that step back and I'm creating a space to to facilitate Conversations and empowering others for me was like one of the hardest challenges Honestly regardless of the of the background. So I also that's what I want to discuss with you Let's say someone is already in the product org they proven Value they're definitely good individual contributors. They they know how to write effectively how to negotiate how to the decompose complex solutions What are some of those additional characteristics that you need in order to give that person The opportunity to go to the next level and maybe have a team or a bigger Scope of responsibilities, right, right? Yeah, and there are definitely two pathways. So there are a lot of organizations Which I think this is a shame that drive career development Down the management chain But it happened. So it's probably we're speaking to so a lot of times you'll be in organizations That the only way that you go to the next level is that you start to move into management and have people underneath you um And so that's a another completely unique skill set that you need to understand is how do you start managing people? How do you step away from being the executor the one that does things to being the one that relies on others to do things? So that's one one pathway, which is Really like management capability management skill set. How do you manage others and how do you make others affected in their role versus want to do everything yourself For organizations that have more of that kind of technical architect, which is just a pathway to like grow within the product management role Then it is about thinking more strategically away from the execution side of things into that What are we going to do next and it's not just like knowing What you're going to do next, but how do you come out that executive communication skill of how to um Take an idea in the thought process that you have but then how do you pitch it? How do you define it? How do you make others interested in? How do you actually Give people excited about it That's the skill set and definitely something that can be learned with Just how do you put together stories? How do you make them concise? How do you make them interesting? How do you understand what people really care about and Understand and define this metrics so that you can pitch it in a way that it actually looks meaningful and valuable What i'm hearing from from your answer is that maybe what made someone very successful as a individual contributor p.m. Is not necessarily going to make that person successful as a A manager there's a different set of skill sets related to you know telling the story empowering people and motivating them that maybe are not that necessary or at least That critical when when someone Well, and I think there's two but fall in love with the idea of getting the the title. Yeah, um but Then they get that title and they realize that that's not the role that they want it And so in some teams i've actually put together a role of a functional architect Um because i'm you know happy they they don't want to go into management They don't want to be the strategist. They don't want to be pitching the ideas But they're amazing at coming up with these like really complex design solutions and approaches And so I think it's really important for Those that are looking at their career is to take a step back and say what do I really love to do? And what am I really good at? And try to find those opportunities. So don't just go after the director title Um, because it sounds really good, but you don't actually want to manage people Yes, and and I think that is happening for I've seen other companies doing what you just mentioned creating alternative Career paths for people who want to grow as individual contributors They can still have more recognition and a cool title maybe other type of rewards Without feeling the pressure of like oh now I get promoted and you kind of lose a good individual contributor and gain maybe a And not excellent manager. Yeah, for sure Cool. Well Rondi, this has been awesome I learned a lot from you and and I hope this was a good time for you. Is there anything else you would like to share? No, I just um, I see a couple of questions in here Um, so I saw when do you have to have a technical background to join product role? Well, I didn't So hopefully, um, I'm representative of the fact that you don't have to have a technical background But you do have to if you don't come with a technical background You got to spend the time really understanding technology because you it's very hard to be successful without that understanding Um, so I just wanted to ask answer that one question. But thank you so much for inviting you. This was really fun Um, a really great opportunity and I love product school. I think what you guys are doing is amazing Thank you so much. Bye. Bye