From Curiosity to Execution: How CPO Ravi Ramsaran Drives Product Excellence

Introduction to Product Management Journey

Rina Alexin | 00:01.306–00:59.631

Hi everyone, and welcome to another episode of Productside Stories, the podcast where we reveal the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rina Alexin CEO of Productside And today I have the pleasure of talking with Ravi Ram Saran, who is a Chief Product Officer at Nextria. Ravi leads the development of secure on-premise generative AI solutions for defense and government sectors.

but he also comes with over 20 years of experience in product management, starting with roots in actually being a developer. Ravi has transitioned into product leadership in creating enterprise applications and hardware across many industries, such as education, retail, as well as the military. Ravi also has contributed to how many? Six startups, maybe more.

Ravi Ramsaran | 00:59.631–01:00.752

Six and counting.

Rina Alexin | 01:00.752–01:14.526

Thanks for counting. And he combines his technical expertise with the strategic leadership, those soft skills I’m hoping to get into today to deliver impactful customer-centric products. Welcome, Ravi.

Ravi Ramsaran | 01:14.526–01:22.66

thank you so much for that introduction, Rita. That’s amazing. Looking forward to this chat and sharing a little bit of what I’ve learned through the years.

Rina Alexin | 01:22.66–01:43.746

I’m excited as well, Ravi. feel like you and I met over a call, I don’t even remember how many years ago, but you’ve been such a pleasure. And I don’t think I’ve actually heard your full story of how you got into product management. And I really like to start here. I hear a different one every time. So share with us, how did you get into product management?

Ravi Ramsaran | 01:43.746–03:44.826

Well, I think like most product managers, think, you get into it coming from the technical standpoint, the technical aspect. I grew up in Trinidad, small Caribbean country, kind of close to South America. My parents bought me a Commodore 64, and I got the development bug from that point on. I I think what got me into product management, I think is the same thing that got me into programming.

So programming to me and creating something, that’s an art. So I look at developers being an artist. It’s almost like having an easel and a paintbrush and your paint and you’re sitting there, you’re creating something beautiful. people are looking at it they’re going, wow, I like that, I want that. And that was the addictive part of being a developer. And early in my career,

The one thing that really frustrated me in some of my earlier jobs was I would create this beautiful work of art. And then I felt like, why isn’t this selling? Why aren’t people using this? What’s going on? What am I missing? And so I actually extended that piece of art. So I was like, OK, I’m going to have to learn what is it people looking for? Why are they buying this piece of art? How can I expand this art to other people? What are they looking for?

And that was the natural extension for me going from being a developer into product management. And I was really fortunate because at the time when I moved and I transitioned into product management, I was a Java architect back in the days when Java was really cool and hip. So I was an architect, and my product manager went on maternity leave. And it was just a natural transition from being sort of the lead of the tech.

I of, I dipped my boots into sort of the business side of things. And you know what? I never looked back from there. I went under her wing and, and thank goodness I did that because that became like a 20 year career from that point on.

Rina Alexin | 03:44.826–04:36.238

So I’ve heard this story a lot. So you’re not wrong to say a lot of product managers do start in the technical space. But as you’re kind of talking about right now, it’s not about the solution. It’s about the value it brings to a market that you need to be very curious about. So I do wonder. I like to talk about product management as this focal point in an organization, because if product management does its job well, the whole organization benefits.

whole ecosystem benefits their customers as well. But there’s still a lot of tensions because product management has to work with all of these different groups. And a common tension is the development team. So have you found that in your career first? Like, where does that tension maybe come from? And maybe you could share some advice on what to do about it.

Ravi Ramsaran | 04:36.238–06:42.84

Yeah, I mean, of course, being that sort of you coming up from a technical mindset. Unfortunately, early on, I actually lean more on the technical side, right? And as you well know, that’s a pitfall for product managers because you’re focused on the tech. It took me quite a while to really transition into a mindset of, let’s become outcome focused. But during that transition, I really understood that developers, start talking specifically about developers.

Developed mindset is very specific. They’re very much focused on their tech. They’re very much focused on the products and the features that they’re making. And as much as a product manager can say, well, this is the problem we’re trying to solve. And this is what the customer really wants. And to kind of put them into those shoes, I find developers have a hard time understanding that because that’s not their mindset.

And so that’s where I feel most of the tensions sort of arise is that the product managers come in and they go, I want to make you understand about the market. I’m to make you understand about my customer. And they’re going, I don’t care about that. I just want to know, tell me what to build. But the reality is they do care. And so how do you bridge that? What I’ve found is two things.

One, you really need to understand your team. You need to understand what motivates individual team members on the development team. So for example, even though one person might say, I’m highly technical, just tell me what to build. Under the hood, they want to get what everybody wants, which is, I want to know that what I build is valuable.

So how do I communicate that to them? What is important to them? So you have to understand what’s important to each one of your team members and not treat the team as one thing. So I spend a lot of time talking to each of the team members, understanding what drives them, what motivates them. So I know how to talk to each one of them individually. So as you can see, communication for me is a big thing. The other thing that I do is…

Ravi Ramsaran | 06:42.84–08:15.504

Typically, because I’ve done a lot of startups, my sprints and my iterations are very fast. So we’re talking about one week, two week iterations. Within that time, things get dropped. It’s just the natural order of things. I might say, this is what my customer wants. They might interpret in a different way. And by the time it comes to the end, they say, here’s my product. And I’m like, well, that’s exactly what I asked for. And that’s always a cause of tension. So how do you bridge that?

The way that I’ve done it is at the end of my sprints, I actually present back to them in the voice of the customer. So they see how a customer is struggling with certain features, what’s happening, so they understand. as much as I can write down in the use case, as an end user, I’m going to do this because of that. Here’s my success criteria. Here’s my preconditions. Here’s my post conditions.

I guarantee in a one week delivery cycle, something is going to be missed. And I find that just by mirroring back what they’ve developed so that you can see someone using their product, they come to it going, that’s what they mean. that’s what they’re really looking for. And so my style of working with the development team has never been about you miss this, or you should do this, or you should do that.

It’s about they need to come to that conclusion themselves to try to understand how the customer thinks. And I’m the conduit to that.

Rina Alexin | 08:15.504–08:27.746

So are you talking here about bringing developers onto, let’s say, a customer interview, or you are pretending to be the customer yourself and essentially demoing in front of them what has been shipped?

Ravi Ramsaran | 08:27.746–09:57.84

Yeah, so I demo every week in front of them what’s be sure because I know what the customer needs. I know what they want. I’m in their head. So now when usually what happens in that conflict is I would say, build me this. This is what the outcome is. They might build it. And as product managers, sometimes you look at it and you go, know, on paper it works, but you know, the flow isn’t quite there. didn’t quite meet my expectation because

They think as a very, in a computer science point of view, like in a mathematical point of view, A plus B equals C. When really people don’t really think like that, yes, they do want to achieve an outcome, but they also want to do it and they want to be delighted by it. And that’s the part that sort of gets missed sometimes. So I find that when I demo it, I go through it and I purposely struggle in certain parts.

And I said, oh, that was hard. And I don’t necessarily say that was bad or this is what you should fix. It’s like, oh, that took me like, oh, that was like three things just to do that one thing. And then usually the conversation starts. Oh, we could have done it like this. We could have done it like that. I’m like, yeah, that’s what we were supposed to do. So that’s the way that I found that getting to those conflict items.

It’s really about trying to get them into the shoes of the end customer. And I always feel like that the role of a product manager is that.

Bridging the Gap: Communication Strategies

Rina Alexin | 09:57.84–10:12.257

really like, first of all, what you’re saying here is because trust me, it’s a little scary. There are some product managers that cannot demo the product. So this is a really good habits, right? It’s almost like a practice session. So you can demo the product with the, with the development team. I think that’s useful by itself. But what you’re talking about here is that whole context of, you know, the frustration. It’s almost like.

Ravi Ramsaran | 10:12.257–10:21.56

you

Rina Alexin | 10:21.56–10:34.327

If there’s a button I could click that will get me there, but it’s not obvious to me as the user and I can’t see it, it doesn’t really exist. On paper it exists, but if I’m not able to use it, it’s not useful. So bringing that out to light, yeah, I really like that.

Ravi Ramsaran | 10:34.327–11:19.044

Right.

Yeah, even a simple thing like some of that, I might look at a button and I’m looking at going, look at this, like, I don’t feel, do you guys know where that button is on the screen? Wouldn’t it be nice if I clicked on it and it suddenly like, it made a little shape that made me feel inviting. And I would just like throw little tidbits here and there.

And eventually it becomes part of the culture. Then they kind of understand, you know, it’s not just about the feature, but it’s about making people feel good about using the product. It’s about making things obvious. And those are the things you can’t write in a use case because you want it to be part of the culture of the development team. And so you have to change that culture.

Rina Alexin | 11:19.044–11:29.004

Is there anything that you find product managers may sometimes miss about what the development team is looking for from them?

Ravi Ramsaran | 11:29.004–13:18.01

Yeah, think that developers sometimes think, the development teams think that the product managers don’t quite get the technical debt stuff. All the stuff that we have to do in the background to make this thing happen. So you, as Mr. Product Manager, you’re asking for a button that flashes. my gosh. But you don’t know, I got to bring in, we got to find a UI framework to do that. How are we going to test it? What colors are going to look like? Are you going to decide that?

I feel that they think that we oversimplify. And I do think that product managers do oversimplify a lot of things. And so that’s, I think, but that’s healthy. I really do think that that is healthy. I try to tell the team, because I have a technical background, it’s hard for me. Sometimes I have to shut up. That’s hard for technical guys or technical product managers. You have to know when not to say something. So even though in my head, I know these things are happening.

What I want for them to do is to communicate to me that, hey, Ravi, that’s a great idea. However, have you thought about this, this, and this? I’m like, yeah, I didn’t think about that. Does that mean it’s going to go from one day to two weeks? And they’re like, yeah. I’m like, is there a way to do it? And it becomes a conversation. Is there a way to do it shorter?

With all that conversation, that’s where the conflict arises. And that’s where most product managers sort of, I think, don’t quite get where the development team is coming from. Because their job is to make something that is repeatable, scalable, all the beautiful things under the hood that people don’t quite see and don’t see that’s valuable, but the developers do. And a good product should have those things.

Rina Alexin | 13:18.01–13:33.741

Ravi, I just have to commend you right now because you said in our current conversation, you’ve said a few things that I think are nuances that can be missed. You’re very careful about your word choice first. You say, it’s hard, not this is bad. That’s so important to do because now you’re talking about the problem, not the personal attack. And then the other one is you’re not playing dumb exactly, but you’re leading the witness.

Ravi Ramsaran | 13:33.741–13:40.119

Yes.

Ravi Ramsaran | 13:40.119–13:47.192

That’s right.

Rina Alexin | 13:47.192–13:48.343

a little bit, right? Around where you want to talk, you want to have a conversation, but because you need to get them to buy in, you’re kind of showing the road without saying exactly what the destination is.

Ravi Ramsaran | 13:48.343–14:03.084

Right.

Ravi Ramsaran | 14:03.084–15:46.354

That’s right. In fact, my goal, Rena, is for the development team to run without me.

And so the only way that’s going to happen is if they understand my psyche and what I want and what our customer wants. And the faster I get them to that, the better it is because then I can focus on other things. I don’t want to be at the daily scrums. I want to get to a point where I trust my team to execute. And then the thing that comes out of it, I know that it’s actually perfect and it meets my customer’s expectations. And you have to be

patient with that. And the only way that it happens is, like I said, number one, I think most product managers don’t think about it, but talk to your team on an individual basis. Understand what are their fears? What are their wants? What are they looking for? What do they think is valuable working in this team? Like really understand them and, and

reciprocate that back to them. So you’re not just trying to say, hey, Rina, tell me, what don’t you like? How was your day? How was your cat, Rina? That’s outward, a real empathetic approach that part of marriage should have.

my belief is that you have to form that level of trust with someone. I’m like, I would be open with them saying, you know what, today was not a good day. I met a few customers, you know, it was pretty hard. I ran into these issues and you know, it wasn’t great, you know, talking to you, I feel better because now I understand what you’re working on and it’s making me feel like the product’s going in a good direction and you made my day better. Like you do need to connect with people.

Empathy in Product Management

Ravi Ramsaran | 15:46.354–16:00.416

And especially technical product manager, product managers come from a technical background. Sometimes you’re so focused on the outcome and you’re so focused on the iteration and on the feature that you forget that all this is about people in the end.

Rina Alexin | 16:00.416–16:12.864

imagine that product managers without the technical background may have more trouble connecting with the development counterparts. But what you’re talking about here does not require technical background at all.

Ravi Ramsaran | 16:12.864–17:01.968

No. In fact, I found.

I’ll be quite honest in terms of my unbiased opinion here, but I found the best product managers actually were the non-technical ones. The ones that I’ve hired were definitely the ones that did not come with technical background. The product managers with a technical background tend to focus way too much on the things that they’re building and not on the outcome. And I was one of them. Trust me, it took me a while to really understand how to communicate. So, you know, it’s…

It’s something that I don’t think most product managers are taught. It’s not in a book that they look at and they go, communication is sort of like the number one thing. It’s never like you talk about the five Ps, right, that everybody knows, like product, price, people, promotion, place. And when you talk about people, it’s really about the team. It’s not really about how do you communicate to somebody, how do you empathize with someone.

Rina Alexin | 17:01.968–17:15.552

place, you know.

Ravi Ramsaran | 17:15.552–17:25.53

So I believe that that’s really the next skill set for product managers in 2025 and beyond. I believe it’s that. It’s how do you become an empathetic product manager?

Rina Alexin | 17:25.53–18:00.972

So Ravi, right now there’s a lot of conversation obviously about AI. And companies are trying to figure out how does AI work within their organization for their own workflows and then also in their products. You work on a very unique, and I do want to talk to you about your unique constraints in your industry. But it’s curious because I would imagine from your perspective, working on a very specific AI type product,

you still believe that the top skill set for a product manager does not need to be the technical component.

Ravi Ramsaran | 18:00.972–20:02.036

No, in fact, like I am.

hugely excited about the changes that’s happening in our industry right now. I think AI, machine learning, chat GPT, Gemini, all these large language models. These like it’s very few times in our industry that there’s been inflection points that has transformed our industry. This is definitely one of them. I am not the doomsayer. I don’t believe that that AI is here to take away our jobs. I truly believe that this is a tool

as product managers, we have to have it under our belt because, you know, I look at what I do now to be able to summarize my users’ activity, to be able to quickly generate RFPs, all the stuff that you like, you know, just takes time and effort for me. I can now offload that and now I can think about truly creating beautiful, impactful products.

And that’s something that so far the last language models and AI can’t do. That comes from my creativity. And so I’m offloading all the stuff to, you know, just even when I do use cases now, you know, I don’t before in the old days, you know, you have your template and you’d fill it out. No, I just say, this is my outcome. Help me fill this out. And that saves me 20 minutes. Well, add 20 minutes to, you know, 20 use cases. That’s hours of work.

So I believe that AI and machine learning is absolutely here to stay. I believe that it’s here to increase our productivity tremendously. And so then you start thinking about, what is a product manager? What’s the next skill set? And again, I’m going to come back down to, in the end, creating a beautiful product is about trying to understand and empathize with your end users.

Ravi Ramsaran | 20:02.036–21:16.666

And communication is going to be the next skill. Empathy is going to be the next skill that that product manager should have. And you need to be not just empathetic to your customers, but to your inward stakeholders, your developers, your marketing team. And this is the hard part, Rena. You have to be able to feel comfortable, transparently and openly talking about yourself.

So empathy is not just a one way street where I’m here to listen to you, but also it’s an opportunity for you to connect with your people and your stakeholders so they understand you. Because when things happen, especially in a fast pace, I’ve done six startups now. So you can imagine how fast paced that is, how…

You know, not everything went smoothly. However, not once in any of my startups have anyone ever yelled and screamed at me for something. And it’s because we understand what each of our roles are. We understood where we’re coming from. So connecting with people at that level reduces the temperature a lot and increases collaboration to an nth degree.

Rina Alexin | 21:16.666–22:09.44

getting inspired just listening to you, Ravi. And I can say honestly, I full heartedly agree, especially I’ve seen a lot of different posts on social media talking about, you know, the depth of product management and AI taking our jobs and all of that. And I think that the true like the product managers are best positioned to take advantage of every all of the benefits that come with this technological change. Even if at some point we come to the part where

AI could do some strategic visioning and thinking. I think it’s the creative people who know how to empathize with humans who can uncover new unmet needs because I feel like there is just this potentially unfathomable well of needs from all of humans that only other humans can truly understand. And that’s what you’re talking about here.

Ravi Ramsaran | 22:09.44–22:52.848

Absolutely. Yeah. And I really truly believe that as opportunities arise with product management and our jobs change, new opportunities will arise. That’s just the nature of the beast. It’s just another thing. When databases came, and suddenly there were different types of databases, suddenly there was object-oriented databases, and then huge relational databases that did fantastic, tremendous stuff. Now there’s like…

There’s so much new things and new technologies coming, but never once did it ever remove people’s jobs. It always increased something. It always added something to the entire ecosystem. And I think that’s where we are going to go with AI. I truly do believe that.

Rina Alexin | 22:52.848–23:46.498

So right now though, we are, I will say, in the relatively new phase of introduction of this kind of technology. And we’ve already seen when so many companies become reliant on AI, and especially the LLMs, and the LLMs go down system-wide, now suddenly it’s whole companies that are going down. So it does introduce a system failure risk in some cases. And that, to that point, I…

I can understand why you’re building on premise for the government, right? Where there is no room for that kind of failure. So I’m curious how working in the space that you work in the defense industry where, yeah, you can’t fail. You really can’t. And you still have to innovate. Like how does that dynamic influence how you work?

Ravi Ramsaran | 23:46.498–25:29.25

Yeah, and I’m sure there are product managers listening to this podcast right now.

thinking about, well, I work in a large corporation. I work in a large company. And the pace of innovation is changing so much. How do I bring this innovation into this, into my sphere? It seems so daunting. And that’s what we have to do. It’s like, if you think about, like you rightly said, in the defense sector, there is no room for failure. In terms of those five Ps, product is like almost number one. It’s top of my.

because it’s about it’s 100 % about being outcome driven. In fact, even more so than I’ve ever seen any other industry because it’s mission success or mission failure. There’s no in between. And trust me, you don’t want the mission failure part. So it’s all about mission success. So then the question is, well, well, that seems to be pretty weird. Doesn’t it? Like you’re talking about innovation and rate of change and large language models that just really came out, you know, two years now.

and developing products like that, and then working in an organization that is highly risk adverse, that has a lot of governance structure in it. So how do those two worlds combine? And actually, let me just say one thing about the defense sector.

I think it’s a misnomer that the defense sector is not innovative. I think in my, what I’ve seen is actually the more innovative than any other sector I’ve been in. And that’s because I almost feel like a producer of a movie. You create something from scratch, from an idea, you build the script.

Innovating in a Risk-Averse Environment

Ravi Ramsaran | 25:29.25–25:50.736

you produce it, you do the movie, you do the plot, you get it into the theaters, it’s out there, and then suddenly everyone’s seen it and it’s gone because that mission is done. And now you go to the next thing. So apart from every other sector I’ve been in, this sector builds product very fast, gets product out, achieves a mission, and then throws it away.

Rina Alexin | 25:50.736–25:51.008

Wow.

Ravi Ramsaran | 25:51.008–27:47.832

and it starts over again, and that entire thing starts over and over again. So it’s actually highly innovative. So now I’m going to come back to the question is, how do you innovate in a space that is highly regulated? Because of course, there’s governance controls, quite rightly so. So.

The way that I was able to do that within the defense sector is we created, I would say, it’s called the destroy almost two spheres of development. So think about one development team that’s creating something. Within that development team, we’re going to cut that development team in half. So.

part of the development team is what I call the lab. So in that team, they’re going to run really fast, like almost on a daily basis. They’re creating some it’s where chaos rains and that team is protected from the organization. The organization doesn’t know that team exists. They’re allowed to, to, to learn. They’re allowed to learn fast. I like the word learn fast versus fail fast by the way, but they are allowed to learn fast and quickly and come up with all the crazy stuff.

And the second team is the team that everybody else sees, the stable. Anything that comes from that team is 100 % right. So the trust in the organization starts to increase as they start to see things coming out from that team. My job is to get the information from the chaos team, the lab, into the launch team.

And I keep those two teams separate because the thinking and the way that these two teams work are very different. The developer on this team, on the lab, almost destroy the developer on the production team because they don’t see the eye eye. They’re both doing two different things.

Ravi Ramsaran | 27:47.832–28:50.926

Their job on the lab is to just to create, is to innovate, is to fail, is to try different things. My job is to protect that space. The developer on the launch team, their job is to make sure that thing does not fail. And so my job is to pick the stuff from the lab that look like, all right, of the 10 things you’ve tried, that is the thing that we’re gonna actually bring to market. We’re gonna get into production.

Then we hand it off to the production team, and then the lab team forgets about it. And now the production team now takes it and makes it scalable, secure, they make sure the governance controls are on top of it. And that’s how we’ve done it. So we innovate in this protected space. Let’s put it like that.

And my job is to protect that innovation and also to make the organization confident that my team can deliver high value, high outcome, 100 % bulletproof solutions.

Rina Alexin | 28:50.926–29:20.812

Yeah. So what you’re actually describing reminds me a lot of what I think a lot of corporations try to do with entrepreneurship teams. If you’re familiar, know, large enterprise wants to create essentially some of them even call them labs, right? Where they’re trying a lot of things. It’s interesting though, from what I’m hearing from you, your timelines are not the same. So the labs in these enterprise tend to be, you know, dated in months. You’re dated in weeks.

of what you’re trying to test. Yeah.

Ravi Ramsaran | 29:20.812–29:25.722

updated in weeks. There’s nothing more than three months that is in my mind. After three months, it does not exist in the defense sector. I usually work on, like I said, the longest death cycle for me might be a week. Typically, it would be like, yeah, that’s something different.

Rina Alexin | 29:25.722–29:38.224

Yeah.

Rina Alexin | 29:38.224–29:48.035

Wow. So that’s big difference.

So then let me ask this question, because I’ve also talked to product leaders in the public sector, but not in defense specifically, where they don’t have this idea of a proof of concept, because once they launch, it has to work for everybody everywhere. taxpayers are not very forgiving of mistakes. if you have such short development cycles,

Ravi Ramsaran | 29:48.035–30:00.45

Yeah.

Ravi Ramsaran | 30:00.45–30:10.742

That’s right.

Rina Alexin | 30:10.742–30:19.788

know, what is what kind of product are you really like, what is what are you trying to accomplish with each sprint? It must be small versus wide. Yeah.

Ravi Ramsaran | 30:19.788–32:32.782

Very, very small. Yeah, my philosophy has always been release small. So I’m gonna come back to the communication and why communication is so key to this. Because typically someone would come and say, this is what I need. Okay, I want a language model that translates a document into French.

Right, that’s my need, right? Build me that. And what you really need to understand, and you can think of that, well, that’s not a weak project, right? That’s a much longer project. So then the question is, well, tell me why you need that. So what about if I give this to you today, how is that going to transform how you’re going to do your job? Tell me what you do this for. And that’s my job.

When it comes down to it, it’s usually just one thing. I just have a piece of text I’m going to translate into French. I’m like, OK. So now that I can do. So now my job is not to figure out, I know we want to get to documents. I get it. But how about I give you a text box that just translates a sentence? Is that good enough? Will that help you transform what you’re going to need to do today? And they go, yes. I’m like, all right.

That’s my MVP. That’s my one feature that we’re gonna build. So I build one feature at a time and I make sure that one feature works. And I’m on the same page with that person. They understand what they’re getting. They understand the risks. They understand what any limitations that they have that they’re gonna get for that. But I really focus, I hyper-focus my team on one thing at a time. Everybody’s driven to one purpose, which let me build this one thing.

And it forces even my stakeholders to even think out of the box. So I am upfront. never, I don’t have the luxury of over promising. So it’s always about, what if I give you this? Would that help you? No, that doesn’t help me because it does this and this. I’m like, okay, so let’s just troubleshoot together a little bit. So.

Small Releases for Big Impact

Ravi Ramsaran | 32:32.782–33:40.101

But Rina, comes, that kind of communication, I can’t stress it enough to your audience, that communication doesn’t just happen overnight. That communication is a communication of trust.

that has to happen with that stakeholder and that stakeholder’s trust does not happen overnight. And it’s usually of me reaching out to that person, even when I don’t have to, hey, how’s it going? Hey, the last thing that we’ve developed for you, are you still using it? Why aren’t you using it? Oh, you know, I saw this thing on the news. What do you think? You know, did you watch the hockey game last night? It’s those little things, And then that way, they-

They open up to me and I open up to them. And they know that I’m not there, I’m there for their success. And what I tell them, they trust me. And so it’s hugely important to me that when I say I’m going to do something that it’s done because that’s all I have. All I have is as product managers, that’s all we have. All we have is credibility.

Rina Alexin | 33:40.101–33:41.39

See you.

Ravi Ramsaran | 33:41.39–34:05.2

The biggest risk of product managers when you go out and you say, we are developing this in three months, you are getting this and all sorts of stuff happens out of your control. And you sit there in three months time and you go, I’m sorry, I didn’t, I didn’t get this out. And that rules trust. And so you have to be very, very careful about that.

Rina Alexin | 34:05.2–34:11.788

So two things, one first really quick. I don’t know if you did that on purpose because I’m a huge hockey fan of calling it out. You might have, that’s your magic. That’s your magic. And then what you also talked about is you said that you don’t have the luxury of over-promising. And truly what you’re saying right now, nobody has that luxury, like no one. And it’s…

Ravi Ramsaran | 34:11.788–34:32.012

That’s right. We talked about that.

Ravi Ramsaran | 34:32.012–35:53.872

No one. But Rina, don’t you see it over and over again where product managers come and they go, this is the beginning of the year. This is our roadmap and this is what I’m going to develop for you. And I guarantee you half of that stuff is not going to get done. And yet you’re, stand in front of people and you go, I’m going to, I’m going to get this to you. And the problem is that you have all full intention. Everybody has the best of intentions. Development team has the best of intentions. You have the best of intentions, but things happen.

The market changes, somebody leaves on the team, all sorts of stuff can happen that can derail your focus. And I’m not saying you shouldn’t tell people what your plans are.

What I’m saying is that you have to be very cognizant about your words as a product manager, because all we have, we have no control over the timelines. All we can do is prioritize and bring problems to the team. And so for our stakeholders and our end users, they have to look upon us as the voice and the face of the organization. And that’s why all this stuff falls on our shoulders.

That’s why it’s so important you have to be careful of your words and what you promise so that to build that trust with your end users.

Rina Alexin | 35:53.872–36:19.875

I wish we were in a world, Ravi, where it was 100 % possible for product managers to avoid those conversations. And I think actually maybe what we’re talking about is culture setting from the top. Because the reason why I think a lot of product managers stand up in a room is because they are expected by leadership to say, what the heck are you working on? And it’s a, you

Ravi Ramsaran | 36:19.875–36:22.76

Mm-hmm.

Rina Alexin | 36:22.76–36:34.84

I think you’re absolutely right. I think that can erode trust and the worst case scenario is your stakeholders’ eyes just glaze over of, not even going to listen because it’s not going to happen. It’s interesting. I think you do need to start at the leadership level to make sure that you have the right culture. it’s possible, based on what you’re saying to me, it’s possible to even create this culture of experimentation.

Ravi Ramsaran | 36:34.84–36:51.616

Yeah.

Rina Alexin | 36:51.616–37:07.064

in the most risk averse type of environment. So product leaders who are listening and maybe are not in the most, know, they’re not, if they, if their product fails, it’s people’s lives are not necessarily at stake, right? You have the highest stakes that if it’s possible for you, Ravi, it’s possible for them.

Ravi Ramsaran | 37:07.064–37:12.494

Mm-hmm.

Ravi Ramsaran | 37:12.494–38:20.356

It’s absolutely possible. I believe it’s like your developers would love you. Like imagine if you said, hey, by the way, I’m going to create a space for you. I want to create. I want to help you create a space of innovation. How are we going to do this together? Forget about what the organization does.

That’s something that’s out of your control. That’s something out of our control. But you and I together, we want this. Because I see the value in not just me giving you stuff to build. I see value in you tapping into your creativity. And I want to give you your space. How can I do that? Have that conversation with your team. You don’t need approval from your director or your VP or anybody like that. Right?

All you care about is, am I going to get the outcome I’m going to expect out of the door? Yes, you can get it done. Well, why not give the development team 20 % one day a week of innovation? Why not? Promise less, give them the space, and you’ll see magic will suddenly happen.

Rina Alexin | 38:20.356–38:26.532

Mm-hmm.

Rina Alexin | 38:26.532–38:46.958

do more with less is to promise less too. I agree with that. All right, so then what advice can you share to aspiring product managers who might want to enter these really tough spaces where they have to balance innovation and a risk averse culture?

Ravi Ramsaran | 38:46.958–41:03.79

I think if you’re in a risk adverse culture, the first thing you have to understand is why, who are the stakeholders, who are the influencers in your organization? So they’re risk adverse for a reason. And there are people in charge that’s that is whose job is to manage risk on behalf of the organization. You have to understand who those people are and what motivates them. Why is there

governance control structure in place. What is the governance control structure? Who approves that? Okay, so many times I see people come up with solutions and then they’re surprised that, why the security guys hate this? Why did the governance guys hate this? know, suddenly I’m getting all this stuff on me. Like, no, it’s because you didn’t understand.

the jobs and the role of the organization to help you. In fact, I look at governance and security and all the stuff that comes around a software release, not as gate gateways, they’re opportunities. They’re opportunities to innovate again, because if I can figure out how to get the governance guy to go, yes, this is good, then that makes my product unique because it’s hard.

If everybody could just create product, everyone would just do it. And then you’d have products all over the place, but there isn’t. These structures are in place. And if you can get a risk-adverse person to agree with you, suddenly you’ve opened up a whole new market for yourself that you never would have figured out. So new product managers coming in who are in spaces of high, low-tolerance organizations like this,

Find out who your spheres of influence are. Stay aligned with the strategic priorities of the organization. That’s your guiding light. If you can always point to what your organization needs, you’re on the right path. And I would say the third thing is communication. I’m going to come back to that. I’m going to keep hitting that. You communicate transparently with people. You tell them.

Advice for Aspiring Product Managers

Ravi Ramsaran | 41:03.79–41:43.62

It’s not your job as a product manager to take all the risk of your product on your shoulders. It’s not. And I think as product managers, sometimes we do, we’re like, this is my product. This is, I am in charge. I am the CEO of my product. You you keep hearing that over and over again, right? And, and yeah, in a sense you are, but there are some decisions that have to be taken by others. And so communicating what those risks are, communicating what your product realistically does to other people.

empathetically connecting with those stakeholders. You know, the number one thing for product managers out there, do not ever go into a meeting and surprise anyone. That’s my number one, like my hard thing. Don’t surprise anyone. In fact, usually if I go into a meeting, I have to make a decision. The decision is already being made. You have to go, you have to make sure that things are aligned so that you can get your product out the door. That’s your job.

Rina Alexin | 41:43.62–42:01.828

Mm-hmm.

Rina Alexin | 42:01.828–42:07.598

Ravi, I feel like we keep circling back to essentially the prediction for 2025 and beyond is you need to work on your soft skills. It’s all about influence. It’s about mapping your stakeholders really truly building relationship with them, communicating. my goodness. I talk to stakeholders too, by the way. So I don’t just talk to product people. I talk to the people they work with. And number one complaint is I don’t know what product does. It’s like a black box to me. So

Ravi Ramsaran | 42:07.598–42:31.822

Ha

The soft skills.

Rina Alexin | 42:31.822–42:34.67

Yeah, that’s on product. have to make that work visible. You absolutely do. So, Ravi, it’s been such a pleasure to talk to you as always. So where can our listeners connect with you or follow you after they hear this recording?

Ravi Ramsaran | 42:34.67–42:39.883

Yep.

Ravi Ramsaran | 42:39.883–42:45.659

you

Ravi Ramsaran | 42:45.659–42:55.642

best place for me is on LinkedIn. Just hit me up. Look up my name. I’m there. Happy to talk to anyone. Just reach me up with a message.

Rina Alexin | 42:55.642–42:58.392

Awesome. Well, thank you again and thank you all for tuning into Productside Stories. If you found our conversation today valuable, don’t keep it to yourself, share it with a friend and subscribe to Productside Stories on your favorite platform. Visit us at Productside.com for more free resources, including webinars, templates and other product wisdom repackaged for you. I’m Rina Alexin and until next time, keep innovating.

Introduction to Productside Stories

Ravi Ramsaran | 42:58.392–43:23.994

Okay.

Rina Alexin | 43:23.994–43:23.994

Keep leading and keep creating stories worth sharing.