Ravit Danino is SVP of Product Management and Strategy at Totango, a customer success software company. She started her career as a project manager at HarmonyCom before joining Mercury Interactive as a software engineer. Ravit then transitioned to HP (Mercury Interactive was acquired by HP), where she worked as a functional architect before switching over to product management. Before joining Totango, Ravit served as Senior Director of Product Management at Marketo.
In our conversation, Ravit talks about how knowing where customers are aiming helps you better frame the discussion around your roadmap. She discusses her experience in mergers and acquisitions (M&As) and when to build versus buy, as well as how she leverages formal and informal customer meetings to gain specific information.
I’ve been in product management for the past 16 years or so. I started as an engineer, and I very quickly figured out that I like to be the person who interacts with customers, hears their problems, and creates solutions that will address their needs. I then transitioned into product and relocated to the US to start this journey.
The component of product management that I’m most passionate about is customer interaction. I love speaking with customers, understanding their problems, and finding a solution that will help them.
Data that reflects the customers’ status right now — their objectives, goals, and what they think they’re going to try and achieve in the next year or so. Once you understand their end goal is a year out or beyond, such as two or three years down the line, it’s easier to frame the discussion on your roadmap. Knowing where customers are aiming helps you understand the things you would like to address, as well as the day-to-day problems that specific customer has.
I try to personally schedule two meetings with customers per week. Our original idea was to do ongoing meetings with our bigger customers, like our top 50–100, but we’ve expanded beyond that. Ideally, we talk to a different person in a different role on the customer side each time, and our goal is to understand what they are looking to achieve. What is their experience with the tool, what are they challenged by, and are they trying to leverage other tools to address these challenges?
In addition, we also have a customer advisory board with executives from those companies. We talk with them more about what’s happening in the market and trends they’re seeing. In CAB meetings, we want these executives to interact with each other — the idea is to foster conversation between all those people to raise questions and have the kinds of conversations that aren’t as easy to have when you speak with someone one-on-one.
Of course, we also have ad hoc meetings when the customer success team or a customer asks us, but the ones we lead can usually be the most fruitful.
I think the data that is being shared is a bit different. Ad hoc meetings usually happen when a customer has a challenge or problem they’re trying to address. In these cases, they are the ones who asked to speak with me to raise a specific problem that they have with the product and how either they or we will address it.
This is very different from the ongoing conversation that’s usually scheduled between executives in the company. It’s not usually about a specific detailed function in the product, but something wider.
One way was by facilitating interaction between the product managers. We have meetings where each PM shares what they learned in the last month to identify any common themes. That way, we can surface any recurring problems and address them.
Also, in the past 12–18 months, we’ve started to leverage AI tools to help us analyze the data and find these common problems. We fed the tool with anonymized information we collected and asked it to summarize it. It does help find a lot of similarities between the points that customers raised. We also use another commercial tool to summarize all our customer wishes, or what we call wishlist items. This tool has a voting mechanism for when we send questions out to customers.
The commercial tool I mentioned has a great visibility feature. When customers submit a feature request, they get an answer. Sometimes it can take a little while because we don’t review these items every day, but the customer will be notified when the item moves along the process.
Additionally, I used to write a bi-weekly blog for customers about the things that they should expect in the future. That came along with a roadmap presentation for them to see as well.
Our CS team has access to any written material we create, and can see the things that will come up in the future. Besides that, the product team holds office hours where we open the floor to questions from the CS team. It’s a one-hour meeting, and anyone from the company can jump on in.
It’s a very interactive call. It’s not super formal, but it’s something that we do that keeps the CS team and the rest of the company informed. It usually starts with us talking for about 15 minutes about what’s coming out in the next few weeks or months, and then they can ask questions and interact with us.
I’ve been through a few mergers and acquisitions, each with different opportunities and challenges to consider. When I think about the trade-off between building new functionality versus purchasing or acquiring technology through an acquisition, there are a few things that are always top of mind. The first question is, “What’s the cost and time required to build internally versus the cost of purchasing it and time required to make it available to customers?” However, to answer that, here are a few things that I like to consider:
From there, then it’s an even more detailed conversation on the engineering side — getting into code, language and developer expertise.
In parallel to the technology discussion, of course, there has to be discussion on what it means to acquire a company and its overall cost versus the cost to build a new product or service and the revenue it can yield. These are complicated scenarios, and it often requires building some projections both on how a new product or service would be sold as well as projecting the cost to create or maintain the new product as well.
Some questions we ask related to the opportunity are:
I think a team needs to have a variety of skills. The value of the team itself comes from different personalities and skills that know how to work together. A product manager needs to be, first of all, passionate about what they’re doing and have a high customer empathy. Creativity usually comes with passion. Where you feel passionate about something is where it’ll be much easier to create from. I’m looking for someone who can be passionate about a product — someone creative who can see the bigger picture.
A good PM also needs to look at the wider problem. I’m looking for someone that has the ability from one angle to scale to look at a bigger problem, but also knows when to drill down. They also need to be able to adjust to changes when those happen. Being able to communicate effectively with customers is important. Often, a PM will talk to customers and tell them they get what they need, but many situations also arise when the customer doesn’t get what they need. That’s an important conversation to navigate. Communication across the company, as well as with the customer, is key.
Whatever you are doing, whether it be designing your house or cooking dinner, it’s always good to have different opinions to consider. If everyone thinks exactly the same way, no one will ever challenge anyone else. And you need people to challenge you because eventually, good solutions will come from that.
You may have a very good solution on the table as a starting point, but once you bring people in who start to challenge that a bit, you’ll get a better solution. Collaboration between different people with different opinions, while managed correctly, eventually enables people to achieve more, drive a better conversation, and create better solutions.
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?
As the name alludes to, the way you frame a product significantly changes the way your audience receives it.
A Pareto chart combines a bar chart with a line chart to visually represent the Pareto Principle (80/20 rule).
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.