Leader Spotlight: Momentum, motivation, and the power of “why,” with Neeraj Mallampet
Neeraj Mallampet is the Director of Product Management at Keeper Security, where he draws on his background as a backend developer to guide teams through complex technical problems. His career has been shaped by an early realization that people do their best work when they understand the bigger picture — why the work matters, who it impacts, and how it connects to a broader goal.
In this conversation, Neeraj discusses the PM’s role in keeping teams motivated as the tech landscape becomes more crowded and ideas are harder to make feel “new.” He shares how his developer background shapes the way he collaborates with engineers, why teams lose energy when goals shift or progress stalls, and how to reignite an original spark of excitement when projects get derailed. Neeraj also explains how he evaluates candidates for their ability to inspire others and the small shift in his own leadership style that had an outsized impact on team motivation.
The power of purpose in product leadership
When did it click for you that inspiring and motivating teams was critical to being an effective product leader?
For me to give something my all, there needs to be a rationale. There needs to be a reason for why I’m doing it. That either comes in the form of me knowing what the goal is and that this is a step toward realizing that goal, or it’s something that’ll give me a lot of benefits. I have to be interested in what I’m doing to give it my all. That’s just the type of person I am.
When I started my career, there were a lot of things I had to do just to do them. I noticed that if someone told me the reason why I’m doing it and how it fit into the bigger picture, it gave me more motivation and inspiration to give it my all and do more. It fostered this productive environment for me so I could excel. That’s when I realized how important it is to give people that same bigger picture if you want them to be fully motivated.
How has that perspective evolved as the tech landscape has become more crowded?
I started my career in 2015. In the tech world, every time you were doing something back then, it felt new. There wasn’t that much competition. Think about YouTube and all these other great products out there — they were the first of their kind.
Nowadays, it’s more important to stay motivated because it’s hard to think of doing something completely original. Instead, you’re doing a variation of something that already exists. A lot of people get discouraged or feel defeated because some other big tech company is already doing it. You have to give your team a reason to keep doing what they’re doing.
The way I see it, it’s actually easier to motivate people now. In the past, you could just say it’s something new and you don’t know if it’s going to work out. Now you can say, “Although we’re not doing something new, we’re doing something that’s better or faster, or that will benefit our audience a lot more.”
Motivating developers with engagement, not direction
Having worked as both a backend developer and a PM, what have you learned about what truly motivates developers versus what PMs often assume motivates them?
The root motivation is the same for both parties. It’s identifying the problem, understanding the problem, and knowing how to solve it. But the key thing with what I call the “technical audience” — anyone in R&D, development, QA, release engineering — is keeping them engaged.
People tell me that, given my background as a developer, I have a key advantage because I can speak developer language. I would say that’s an advantage, but in a different form. The key thing is still keeping them engaged.
There’s a difference between a PM telling everyone what the problem is, tying it to the big picture, and then giving the solution, versus actually engaging the audience. In that first scenario, they’re just hearing it. They’re not being engaged. They might just forget it the next day.
How does your developer background shape the way you work with engineers?
What I like to do is present the problem, but let them dissect the problem and give me their explanation on how they would go about solving it. This is where my technical background is a key advantage because I understand what they’re saying and I can ask the right questions to further dissect the problem. I’m just presenting the problem. I have an idea of how it can be solved, given my technical experience. But I let them explore the problem with me and give me their perspective on how they would go about solving it.
This can lead to other discussions like architecting an appropriate solution, how to further innovate, and so on. Then I can tie it back to the original problem we’re trying to solve. Again, it’s about keeping the audience engaged — where the audience, in this case, is the team that’s working on the problem.
What drains early excitement — and how to rebuild it
Building something new usually starts off with an initial spark of excitement. In your experience, what’s the most common thing that drains that early energy?
What usually kills that initial excitement are two things: any drastic changes to the goal that we’re working toward, or if we’re not making any progress.
For drastic changes, those things are out of our control. Sometimes they just happen. But to keep everyone on track, keep the momentum going, and keep everyone energized, it’s about sticking to our roots — explaining the big problem and why we have to make changes. You have to practice effective communication. Then the team can judge for themselves whether these changes are out of their control or something that needs to be done for financial reasons or other purposes.
A real-life example was back before COVID, when I was working at a biotech firm. We built a database management solution for big clinical companies. Everyone was excited. But we built an on-prem solution. Then COVID hit and there was a dramatic shift in the market where everyone was demanding cloud solutions.
Many features we created from scratch that depended on an on-prem infrastructure became obsolete. We did all this work and everyone was happy, the hard work paid off, but in the end we couldn’t do anything with it. That was a case where external forces out of our control derailed the project.
What do you do when months of work suddenly feel wasted?
I always paint the big picture. At the end of the day, we are employees at a company and we want to do what’s best for the business. In that case, I framed it as, “This is where the money’s at, so we, as a company, have to chase the money. We can be the first to build this.” We kind of had a moat — we were like early Salesforce for clinical data management solutions, where we were the only ones doing it. So I inspired and motivated my team by saying, “No one else is doing it, we can be the first ones, and we can capture a wider market.”
Keeping this momentum train going by telling them what the goal is, and why we’re working toward that goal is, in my experience, the best way to keep people going. If they know their work is part of a bigger goal, they work happier and harder.
Navigating disagreement and building shared investment
Sometimes a team member doesn’t like an idea but still needs to work on it. How do you get someone who disagrees with a direction to still feel invested in building the best version of it?
There are three types of problems. For this, I’m going to ignore the first type: human conflict. Someone not getting along with others is something else.
The other two types are more straightforward. The first is when someone doesn’t want to do something in the way it was planned. There’s a problem, we have a solution, and they’re working on a certain aspect of that problem, but maybe one developer wants to implement it one way and another developer wants to implement it another way. This is very common. What I usually do is hear both parties out. It’s not a matter of choosing the best one; it’s choosing the one that’s the easiest to achieve.
Another thing I do is always deliver solutions in phases. Maybe developer A wants to do it one way and developer B wants something a little different, but it’s more involved. I say something along the lines of, “We’re trying to deliver this by the end of the year, but we’re not stopping after that. We’re going to continually improve it.” Phase one is the MVP we deliver this year. Phase two is a more polished and improved product.
The third type of problem is when we have a goal, but a developer wants to do something that’s an extreme variation of the goal. Unless there’s really good justification, most of those get shut down because they drastically change the end result, and then we have to go talk with stakeholders and get more information. In those cases, I have to further dissect the problem and understand why they want to do it that way.
Do you have any exercises or rituals that help teams identify opportunities to improve existing products?
Prior to starting a project where we’re creating a platform, not just one feature, I create a report where I identify how others are doing it and tie it to the problems associated with it. There’s also a phase where I’m working with customers who are using legacy products or features to understand their pain points. I create a report on the pros and cons of the existing legacy product or features.
From there, I have a discussion with the team to get insight on their end. For example, when talking about legacy features, we identify the pain points and discuss how we can resolve them or make them better. And we go from there.
Hiring for the ability to inspire others
When you are hiring PMs or developers, are there any specific signals you look for that tell you somebody has the ability to inspire and engage others?
Every time I’m interviewing another PM, I look at the way they’re communicating. I want someone who gives me the big picture — the context, what the problem is, how they approached it, and what the end results were.
So when I’m interviewing PMs, I look for that. Not a yes-or-no answer, but someone who gives me enough context and keeps me engaged. They’re telling me a story about the question I’m asking. That’s what we want, because when a PM is presenting a problem on the job, they have to be thorough and give the full picture.
A small change with a big impact on motivation
What is one small behavior change you’ve made as a leader that has had an outsized impact on your team’s motivation?
Before, I was very direct — this is the problem. The slight change I made was always giving the “why.”
Back when I was a developer, I had a lot of managers. They were all good managers, but there was one particular manager who always gave me the big picture. They would always answer the why. Why am I doing this? This is the project, this is the rationale.
So that’s the small change I made. Every time I’m talking about a new project or problem, I always give the why: why this needs to be done. Just knowing the why motivates people. They feel like they’re doing something that has an impact.
Do you see that ‘why’ as giving people a deeper sense of purpose?
Exactly. Going back to my personality, I need to know why I’m doing something to give it my all. I feel like that’s universal. As long as people have a reason for why they’re doing something, they’re working toward something. Unless you’re lazy, you make sure it gets done, and it’s hard to be lazy when you have a career because you’re getting paid to do it. Having the rationale of why you’re doing something and the impact it has on a wider audience makes it more authentic.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.