Leader Spotlight: Knowing where customers are aiming, with Ravit Danino

---

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.

---

Understanding customers’ end goals

Could you talk about your background in product management and the aspect of the profession that you’re most passionate about?

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.

When you’re developing a roadmap to anticipate and address future customer needs, what customer data do you think is most important to have?

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.

Gathering data through customer meetings

At Totango, how have you interacted with customers and built a process to incorporate their feedback into your product? How do you deduce what you consider as you’re building the next sprint or set of features?

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.

Do you find any of these strategies to be more useful than others, or do they each offer different perspectives and impacts?

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.

How do you consider customer data in aggregate from all of your different customers?

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.

Keeping everyone informed

How do you give customers insight into your development process? Do you let them know if and when their feature request has moved into development, for example?

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.

I imagine you have a lot of interaction with your customer success team. How do they drive customer-generated innovation within your product?

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.

M&As and deciding to build vs. buy

You’ve previously been involved in mergers and acquisitions. Could you talk about that experience in deciding to pursue an M&A and how you built the team once you made the decision?

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:

• How will technology address the problem that we were trying to solve?
• What’s already available?
• What will the experience for customers be with each choice?
• How will, or can our products integrate?
• What is the meaning and value of integrating the solutions?

From there, then it’s an even more detailed conversation on the engineering side — getting into code, language and developer expertise.

What was the financial side of the discussion like? Were you involved in that at all?

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:

• If we include this new product or feature, does that reach a new market?
• How much does it add to operating expenses, and is there a change to our customer acquisition cost?
• What new customers would we reach with this additional product?
• If there are new customers, are we already in those channels or do we need access to new buyer channels?

The importance of a diverse skill set

Other product leaders often say that there’s a certain set of skills in a product management hire that are more important than others. Specifically, what do you look for?

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.

For you, why does it matter to have that differentiation of skill sets on a team under you?

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.