Nidhi Bhatnager is the VP of product management at DataStax, a real-time AI company that builds products based on open-source Cassandra. She brings more than 20 years of experience in the database and cloud industry, including prior product roles at IBM. Nidhi is skilled at bridging product and engineering and creating a culture of collaboration in her teams.
Nidhi discussed her transition from engineering to product management, provided tips for leading cross-functional teams, and shared insights on incorporating customer feedback loops throughout the product life cycle.
Our conversation has been edited lightly for brevity.
I started in a technical role. I’ve always wanted to learn new things and do things differently.
In engineering, you want to be able to talk to customers — the enterprises who are using the products — to really know what they’re doing. In that spirit, I moved into a pre-sales role in IBM Cloud. I was working directly with customers on specific deals and the capabilities they were most interested in, engaging with them in using our product, and going through the sales cycle.
Moving into product was a natural transition. I knew customers, what they really wanted, and how to make that work with the engineering. I have a pretty interesting role, it’s a good mix of technical and business skills and the leadership that accompanies it.
On a high level, understanding how different capabilities work and what particular features should look like helps, especially in comparing your product to the competition. It helps you find out where you’re doing better than competitors or where to invest in technology to match them.
But it’s the communication piece, definitely — when you can speak engineering’s language. Having been in their shoes and knowing what engineering teams deal with helps to build that relationship and close any gaps.
I also feel that, when it comes to product management, having that domain knowledge for enterprise technical products is extremely important. Because I am in the database industry, I talk to technical architects at our level about long-term, technical, strategic decisions that will impact how our product works.
For me, the most exciting one is the vector databases. Especially in the last six months with the generative AI boom and interest in the ChatGPT, vector databases are a very important piece of the whole ecosystem. They provide the long-term memory that ChatGPT lacks in real enterprise use cases.
LLMs like ChatGPT work on a vector-embeddings format, internally, so you need a database that can store those vectors and embeddings. A vector database can store the data — user interactions, their behavior, and their style. Then, when you pass that to the LLM to retrieve or generate content, it can use that to create more meaningful content for that particular user.
For example, say you’re talking to a chatbot. When you say “OK, summarize this again. Explain it better,” it knows maybe the last two or three messages you sent it. It doesn’t have a long-term memory of an actual user interaction, and that’s where these databases are helpful.
At the same time, companies don’t want to share their enterprise data to tune these models. Vector databases are a great way to provide enterprise-specific data to generate content with OpenAI without really sharing that data. You can provide the context as a piece of your own enterprise data, pass it to the LLMs, and generate the kind of responses that you would like.
I feel that products in the data space will be integrating with or wanting to take advantage of AI. It’s been evolving over the last couple of years.
Generative AI has been pretty revolutionary. The amount of interest that OpenAI has seen in the last couple of months has been more than anybody has ever seen in a product within this industry.
Considering that and the macroeconomic conditions that we are in, the only space that every organization is really willing to spend is AI. If you are in any data platform product, having the necessary skills and awareness of what’s happening in the AI space, what your competitors are doing, and what can you do to build or integrate with AI is going to become more of a need than a want.
That’s definitely a hard one. But what I like to do, especially in the leadership role that I am in, is to start with the big picture. When I see the team getting into the weeds of things, I have to pull them out and say, “We’re going back two levels. Let’s go back to where we started.”
It’s about having that mission in mind — to be able to help and delight customers — and always keeping that focus. Step back and consider, “Are we really thinking about customers or are we thinking about ourselves?” As successful product managers, we need to have the passion to solve customers’ problems and think of them first.
Thinking about making money, that’s an important business problem. But you’ll make money and do good things for your product if you’re satisfying your customers anyway. It’s not as much about balance; it’s more about looking at the big picture and making sure that the whole team always has that big picture to excite them.
I’ve always encouraged my product teams to talk to at least a few customers every week. This implies having quarterly reviews with all customers and also having segments of customers to speak to more frequently. If there’s a customer having issues or who’s unsatisfied with something, it’s important to meet with them regularly as well.
One thing I’ve found helpful is to regularly engage with field folks or people who are close to the customers. That helps me know which touchpoints are more critical at the moment.
I’ve also found that when building products, it’s important to always look for early feedback from customers. Customers who’ve been looking for a particular functionality will be really excited about trying it early on. Engaging with those customers on a technical basis for early feedback is super helpful. They will be the friendly, early adopters with large deployments that will help me understand, broadly, what kind of problems other customers might have.
Identifying and working with those customers to get that feedback early and keep a feedback loop open is big too. Reducing the friction of customer engagement is important as well, like how you can make sure that your customers have direct access to you. The more we, as a product team, can build those relationships, the easier it becomes to have a two-way dialogue.
The most important thing is building trust between the teams and having a healthy relationship between product and engineering. You want them to feel like they are one single team working toward a common goal of building world-class products for customers. I have seen friction between the teams and it becomes counterproductive.
But I feel that it’s more of a cultural aspect of building the right relationships and the right team spirit that goes way beyond the tools and mechanisms. From the product side, the biggest skill set for a product manager is communication. Product managers are the center of communication in all directions.
I tell my team, “There is nothing like over-communication. You sending an email doesn’t hurt anybody. They can ignore it after the first sentence if it’s not meaningful to them.”
Most importantly, putting ownership in terms of who you need to take action is a really important part of this communication. That is key to the success of the overall product.
I don’t like to think of agile as a process or a tool, I think of it more as a mindset. It has very basic principles. Being able to pivot based on market needs and having a framework that gives you that ability is important.
Being able to take early feedback is another important aspect that was introduced by agile. You want the feedback earlier rather than later.
We follow agile, not to the fullest of every single ceremony, but as a framework. I like to encourage teams to adopt whatever pieces of it make sense.
Yeah, absolutely. I always tell people that there is not a single recipe for success in your team. Everybody gets motivated by something different. And the type or frequency of coaching each person needs is different as well. So my advice is, don’t use the same methodology over everyone. Try to find what motivates each person.
Being selfless is really important. That’s what is expected of you as a leader. Even if you have a key person on your team, if that’s not the right spot for them, then helping them find what is right for them is important too. Because if you don’t, they’ll probably find their own way, but you will lose that relationship.
There is a really good saying that goes something like, “Most people join because of the organization, but a lot of people leave because of their manager.” That’s the person that you really rely on a lot for your current role, as well as your future growth. Giving your team members that ownership, listening to their needs and where they want to go, and showing them what their career path can look like is really important.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
A strategy map is a tool that illustrates an organization’s strategic objectives and the relationship between them using a visual diagram.
Insight management is a systematic and holistic process of capturing, processing, sharing, and storing insights within the organization.
While agile is about iterative development, DevOps ensures smooth deployment and reliable software updates.
Aashir Shroff discusses how to avoid building features or products that replicate what’s already in the market but, instead, truly stand out.
Learn more →
