Nimesh of Rockmetric on onboarding enterprise customers in finance

In this session of Implementation Stories, we spoke to Nimesh Mehta, the founder and CEO of Rockmetric, a data analytics platform that uses Natural Language Search to automate analytics at scale for enterprise clients.

In this conversation, Nimesh shares his honest reflections on his journey, what’s worked for them, what hasn’t, and the ‘people’ struggles in implementation projects. 

Let’s get started. 

Note: The conversation has been modified for brevity and clarity.

Tell us a bit about  Rockmetric

Rockmetric is an automated analytics platform that automates the jobs analysts do on excel and other platforms—think of it as a search engine for data where business users can interact with 100–200 GB tables and get insights instantly without any building or manual intervention. Most of our clients are banks and large enterprises.

How did you go about getting your first customer? 

When we began, we spoke about IBM’s Watson and how our product was like that. Our pitch to most Innovation teams within companies was that our platform could perform better than IBM Watson. That's how we got our first 20 pilots and POCs such as HDFC and Unilever. 

What we quickly realized was that most of our early customers didn't care about speed. In fact, when we told them that we could run deployments in 2–3 days, they thought we were immature and we even lost a few deals. I’ve realized that 2–6 weeks is more comforting for customers.  

There was a journey of about a year and a half where people like the product—departments would like it—but leadership at the CTO level would scuttle it. The apprehension was that we wouldn't be able to scale our team to meet their entire organization’s requirements. 

My experience has been that you can’t sell speed to enterprises, they are more interested in agility. They worry about their speed of use, not our implementation or onboarding speed. 

So, a small semantic change where you build the project to give more agility worked for us. Our pitch for Indian customers wasn’t cost reduction, it was growth—to enable them to deliver to a larger target audience with the same team size.

Were there any tips and tricks that you used to display maturity and present yourself as more agile?

When I say agile, what they are looking for is for the product to be agile in their environment. We saw that even larger companies like Microsoft, Deloitte, and Google were doing free POCs for them. We started with free POCs and then paid ones. 

What you really need for enterprise clients is a sales team to talk to customers every day so you can focus on a few things that the customer actually wants. 

What does your go-live look like?

At the very beginning, the customer tells us the scenario, we meet the business teams, they tell us the objectives. Then we have conversations about the source data tables, whitelisting, hardware, integration—mostly over email. Having a checklist and getting them to do it is the easier way. 

Post this, they share sample datasets, and only once there is consensus on that, do we proceed to data extraction. Once deployment happens, we move to phase 1—where they have to push the data or automate the pipeline in our system. 

In phase 2, for data modeling or platform configuration, we send them a requirement document that they fill. 

After that, it takes roughly three days to get the first dashboard ready, then we train the team and hand the project over. In a good scenario, we could go live in 3–5 days. Sometimes this can take 5 weeks also. The key, we’ve realized is to figure out who the people responsible are for each task. 

When do you go about setting the rules of engagement?

Though we have these at the senior level right at the start, at the junior level it really is a people issue, not a process one. For instance, you can have status calls but juniors rarely escalate issues.  

In such cases, having tools helps. For instance, we set up a small mechanism where we send status updates automatically. This creates an automated escalation mechanism that is non-threatening—where information goes to bosses when there is a red zone, and our life becomes much easier

My experience is that customers don't log in to our own systems, making them log in to another for status updates is a long shot. I’ve seen they actually prefer a short crisp summary email. We are building these capabilities within the platform itself—so they can go to different screens and find pending issues. 

Free template: Project communication plan

As a data company, what has your experience been— having conversations about who does that? 

Firstly, our product is designed such that we don't have to do much data massaging—the product does on its own, but three different aspects. But at an early stage, we agree with the senior level that Rockmetric will not touch the data at their end—they ingest the data, we do a one-time configuration, and post that, they can ask questions and the system will respond.

However, somewhere down the line, junior employees ask us to touch the data and that is always a nightmare—we deal with hundreds of GBs of data, showing productive work for that amount of effort is just not possible. 

We had to tell our customers that data is not our responsibility and that we can’t do anything if their data isn't clean—that’s a clear no-go zone. 

Any tips and tricks that you have found to work in dealing with these people-dependent challenges?

I think it’s important for senior employees at the customer end to break down processes into tasks that juniors can communicate during review meetings. For junior employees, make sure you don't give them work that they can't communicate during meetings with their managers.  

You need to identify the steps—make them less a threshold, say 10. If the number of things is more than this threshold, then just managing the process becomes a task. In that case, it makes sense to identify a program manager who does that just and someone else to actually do the tasks. 

We’ve seen that it also helps to ask the boss/manager to assign one day for training—sometimes just going there and doing that with the customer helps. 

What does your customer onboarding team look like?

We have a four-member team of analysts who are dealing with customers. We also have product architects and an account manager who is the program manager for that account—delivery within 3–5 day cycle, that is our focus. 

Setting up your first customer onboarding team

Is there a way you gauge if there are other high priority projects going on for the company—that could cause your project to be sidelined?

I think this happens on a few levels. In many cases, the customer team will ask you for a POC without even speaking to their managers for a budget or even to get them on a demo call So, after the POC, things don’t go anywhere. A good sales guy will always sniff this out—your sales team should be able to assess whether to invest in a POC or not. 

Even after the POC, it helps to understand what their focus areas are—by going back to the boss and get him to put a name to whoever is responsible for owning it from their end.  

Reviving a customer onboarding project when you’ve been ghosted

How do you decide the scope in terms of ROI? Or is it a land-and-expand approach? 

My experience has not been that we built out a feature that makes them buy from us. It has mostly been that they bought from us and then we build it out for them.   

Another challenge is the difference between the business team and the IT team’s approach. The business user wants to see if you can help build their roadmap as they don't want multiple vendors. But when it comes to IT, they are not looking for functionalities that the business user will benefit from—they are worried about taking the hit if you mess up. This is why prefer to work with trusted vendors. 

With IT departments, I’ve seen that it helps to be okay with starting small. Showcase everything to say your roadmap within the company — but start small. Earlier I was insecure about starting small, but now, even if two departments like it, it's okay. 

Here’s what we do:  when the first department comes in, they do a POC and pay for the pilot. After that,  even if the land-and-expand happens, the first department will not have to pay for licenses. That is the incentive. Then, the first department becomes a champion for us at the customer end. 

Summary and takeaways

Here is a quick summary of some of our key takeaways from the hour-long conversation with Nimesh. 

1. Capacity to support customer growth: Enterprise customers are more focused on their growth and your  team's ability to match that over your ability to deliver quickly.
2. Land and expand: Be okay with starting small—especially in larger companies where the priorities of the business and IT teams are not always aligned. 
3. Agility in the product: Focus on features/functionalities that make your product agile in the customer’s environment. 
4. Resource/personnel issues: Set up tools/mechanisms that create an automated escalation mechanism that makes it non-threatening. 
5. Process planning: If managing the process is too intensive, separate the process from the tasks, and assign purely the management of the process to a resource, instead of expecting the customer team to handle both the process and the actual tasks.

Join our private, invite-only Slack community and attend the next Implementation Stories session. You will also gain access to peers, get to share knowledge on customer onboarding, implementation, and customer success.