How Rigorous Qualification Helps RevOps Build a Better Product

With Adam Ballai, Co-founder and CEO

RevOps helps SaaS companies automate their pricing. Companies like MemSQL, productboard, and Very Good Security use RevOps to send better, faster, and smarter proposals and close deals faster. Currently, RevOps has a team of 8 that is fully distributed.

RevOps helps SaaS companies automate their pricing.

Adam Ballai is the co-founder and CEO at RevOps. Neel and I recently chatted with him to understand how rigorous qualification helps RevOps build a better product.

What is RevOps?

For enterprise products, most SaaS companies have a fairly lengthy process with approval chains to determine how to sell their product. This process is called "quote to cash" and what we're trying to do is make the process as frictionless as possible for Sales & Finance teams. Today, most people are using Word and Excel documents for this process, even after being in business for seven or eight years. To solve that problem, they end up buying very expensive tools that take years to integrate. But RevOps is something that's very simple and easy to get started with.

What motivated you to start RevOps?

I operated a number of different teams in my career, but one of them was a billing engineering team. I joined as the first engineer at Twilio, and even early on, back in 2009, our billing engine was falling over—it just wouldn't scale. The main problem with that engine was that no one in the company wanted to work on it. And so when nobody wants to work on a problem, and it breaks, the question is, why is the company having to build that themselves? We should just buy a tool for it. We tried to find a solution, but because Twilio's business model was actually based on increasing the number of developer signups on a top-up credit model, no existing system was able to support our needs. So we needed to invent one—we decided to invest over 40 engineers into it over a seven year period, and scale it out.

When I later joined Stripe, all the enterprise pricing did not have any automated architecture around it. All these different sprawling pricing plans that the sales team would come up with at Twilio also existed at Stripe, and we didn't have any solution. We had this spreadsheet called "deal desk rules". And the spreadsheet laid out a bunch of rules: if a deal has a 20% discount, escalate to this sales manager; if it includes this product, route it this direction; if it's in this country, route it that way.

And I started to wonder if there's an actual product to be built here. And so I quit. I found my co-founder who I've known for quite a few years, and we decided to embark on the journey.

Can you tell us how you got your first users?

Before we even started anything, we wanted to make sure that we were building the right product, we went and talked to a bunch of customers who would potentially buy this product in the future. And so we bought a couple plane tickets, we flew to New York, we sat in on a bunch of meetings. And we said, hey, we'd love to help you with pricing. And so we looked for processes that looked like deal desks. And you know what the best way to actually understand how pricing works in a company is to put on our pricing consulting hats. So we became pricing consultants for a few months.

And we even got to the point where like, should we just do this as a business? We pulled back really fast but we actually sold pricing consultation for a couple months just for fun to see what would happen. We would enrich deals won and lost data on Salesforce, we would look at product usage data to understand what their customers were doing with their products. We talked to the product managers, we talked to the sales people, and we learned so much.

We fiercely prioritize the users we take on. When we onboard one company, we don't just onboard one customer, we onboard 40, 60, or 80 customers. And to make their journey successful, each and every one of them needs to be a priority for us. And so we need to be selective in what kind of customers to partner with. We generally look for design partners before we start to add non-design partners. It's a ratio: for every four customers that we onboard, we look for a fifth customer that would be a design partner working with us.

How do you onboard new users?

We are in a product-market fit stage, which is we've built an amazing product. Our customers love it. We are building champions with people who are adopting it. Our goal is actually to complete a large narrative before we decide to go into our next stage.

Today, we fiercely prioritize the users we take on. When we onboard one company, we don't just onboard one customer, we onboard 40, 60, or 80 customers. And to make their journey successful, each and every one of them needs to be a priority for us. And so we need to be selective in what kind of customers to partner with. We generally look for design partners before we start to add non-design partners. It's a ratio: for every four customers that we onboard, we look for a fifth customer that would be a design partner working with us. Otherwise, we're not going to get enough feedback in the process to build a better product and build more innovative things in the future.

When we talk to potential customers, we categorize them in three ways:

  • There is your traditional ecosystem buyer: they're shopping around with a grid and the checkboxes for what you're looking for. We immediately disqualify those kinds of customers, they're going to require us to fill a lot of gaps. And at our stage, we not yet ready to fill those checkboxes as it might require a bigger team, it might be a different direction than we want to go in.

  • The second type of customer, that we do start to qualify for, is the customer who is looking for a solution but doesn't know what the solution looks like. And for that kind of customer, we see whether they are willing to accept what we propose to them, and be on board with it, and give us some feedback on that process. That's a low engagement design partner.

  • Then there's the customer that's actively looking for a solution. They know what they want, and they know we're the company that can deliver on it. And that is the design partner that we choose to work with all the time.

What are the channels you use to engage with customers?

  • Video is the most important one in this stage. If you don't get on a call, you can't get a visual temperature of what's going on with that customer you're working with. Are they happy? Are they sad? Are they eager to learn more? Are they excited? Do they want to engage with you or do they want to turn their video camera off? There's all these things that just kind of pop up that are important. And it's important for our team to actually hear what they have to say and see how they react to some of the products that we build.

  • And then there's Slack team channels that we mostly share with design partners, but we try to do it with all customers. It's really just a stylistic question—it depends on the culture of those other companies we work with. When we get them on to Slack, we do get a rate of engagement that's much higher than the companies that don't.

  • Some customers prefer to use email and we so support them there as well.

Ready to take a data-driven approach to customer feedback?

Herald helps product managers align their team around customer needs.

Who is responsible for talking to customers?

All eight of us talk to customers.

What is something that your team does well with respect to listening to customers?

I think it's this model our team likes to follow. We call it the Double Diamond design process model, where we start trying to understand as much as possible, what the actual pain points are of the customers before we decide what the product is, and capture as much feedback as possible. Our lead designer does UX research at that stage, and our product team will go out and talk to as many customers as possible about a topic like renewals or talk about up-sells or these other things that happen during deal desk operations and pricing. And then they'll come back with all this data and try to condense it down into the first diamond: we'll go beta that product. And then we'll understand feedback on the beta and refine the product before doing a broad release (the second diamond).

Adam, thank you for talking with Userstand. It was great to learn a lot more about RevOps and how rigorous qualification helps your team make a better product.