About Veloce

I found the challenge of CPQ insanely interesting. I was fascinated with the magical promise of CPQ to provide an automated “expert system” over the web that could intelligently guide salespeople and customers to find, configure, and price the perfect product. I dreamt of one day owning a technology company that could deliver the promise of Calico and any worthy CPQ technology company: to provide an intelligent system that empowered their customers’ sales and one that could be managed directly by business people without the need for IT intervention.

In 2014 I was contracted to build a highly complex CPQ system for one of the tech giants. The problem is probably the biggest, most complex, and highest impact (in terms of financial ROI) CPQ problem on the planet.  And a very interesting challenge.

I created a custom solution for that company entirely in JavaScript.  This means it had no backend — all the display and configuration logic were intermingled in browser code.  

The solution — in spite of some front-end flourish — fell short and was never moved to a production release,  because it lacked a powerful backend technology to automate the configuration process. It required too much IT expertise to maintain. So I left that company with its huge product configuration problem still unsolved. I really wanted to solve this problem. I just didn’t have the right technology to do it.

Prior to Veloce I knew what a CPQ system should do. What I lacked — and what the marketplace lacked — was a CPQ technology that could do what CPQ systems had long promised to do. That is, until I met my co-founder Shaowei Mao in 2015, the inventor and brilliant mind behind Veloce’s CPQ system, when we both joined the market leader in the rapidly growing CPQ space running on Salesforce.

Little did I know that during the last 20 years while I was focused on the front-end of the problem implementing no less than five different CPQ technologies for a variety of Fortune 500 companies, there was this person, Shaowei — my other half, working with equal vigor on CPQ technology from the other end of the problem, the backend, with the same ambitions as me.

Shaowei’s experience was at the deeper core of CPQ. He was the key developer of two market-leading — and arguably the two most powerful CPQ technologies—over the last 20 years. I knew customer pains but he was the one who could alleviate them.

It took a short time after joining the market leader for both Shaowei and I to reach the same conclusion: the technology offered by this company was quite weak compared to CPQ products we were both familiar with from 10 or even 20 years prior. The company’s main claim at the time was that it ran natively on the Salesforce platform. Living inside Salesforce offered the advantages of security and reliability. It also provided some big disadvantages in terms of CPQ.

Knowing what we both knew about the depth, complexity, and dynamic sort of engine required to solve real world CPQ problems, we immediately realized that running such an engine inside the Salesforce platform would not work for complex CPQ.

The 1st problem with living inside Salesforce is that Salesforce restricts data usage. Nothing wrong with this, generally speaking. But complex CPQ requires data — lots of data. Many times more data than the Salesforce data limits allow. Shaowei and I both knew this intimately from our work on solutions for Fortune 500 companies over the years.

How can you tell your enterprise customers to keep their product configuration problems simple and small? This violated the whole premise of the CPQ: it is supposed to empower sales not restrict it!

The 2nd problem was performance. The system was as slow as a dog (sorry if I insulted anyone’s dog), even for a small CPQ solution. The sales engineers developed a variety of tricks to distract prospects while the system waited for a response. And the performance only got worse for larger or more complex solutions..

The 3rd problem: the administration of this CPQ product was dreadful. The company marketed their product under the mantra of “clicks not code” which made it sound easy. But in reality building even the simplest app was a painful ordeal and it took hordes of skilled IT resources to make anything work.

Shaowei and I talked. We realized that there was room in this market for a powerful CPQ product that was easy to manage. We wanted to create a technology that actually did what CPQ technologies have long promised.

In order to test this idea we needed an opportunity. We realized the perfect opportunity was the problem I’d left behind at that aforementioned tech giant. Mind you, unknown start ups generally pick easier targets than tech giants for their first clients. But we’d worked with the top technologies and top customers in the world for so many years we didn’t know of any small problems or small customers.

I knew the problem well enough. I described this world-class CPQ problem to Shaowei and to my surprise Shaowei told me — without hesitation — that he knew how to solve it. He had already developed the two most powerful product configurators in existence. And he had thoughts about how he could develop a next generation CPQ system that could solve any type of complex CPQ problem.

I created some mockups, went back to the tech giant and told them what we could do for them. They encouraged us to start a company to work on their problem. We jumped at the opportunity, however unlikely we were to get a paid deal out of it. Thus, Veloce was born.

Veloce (pronounced veh-LOW-chay) means fast in Italian. The name has been used for fast Italian products like sports cars and racing bikes. Now it was the name of the fastest CPQ system on the planet.

I told Shaowei I wanted to solve the entire massive configuration from a single user request. This was akin to generating the blueprint of the Salesforce tower from a short description of the building’s function. I knew this is what the tech giant wanted. I related this to Shaowei more as a dream than a requirement.

Shaowei, however, took it seriously and went to work. Weeks passed. When he finally popped up he had a working solution: a prototype. The prototype generated the entire solution from a description of the problem provided in natural English. In my 20 years in CPQ I’d never seen anything like this solution.

I was blown away by Shaowei’s working style. I’d never worked with an engineer as efficient, inspired, and capable as Shaowei. He didn’t complain about difficult requirements. He simply solved them. I knew at that moment we really had something for our tech giant and the broader CPQ market.
We shared the solution with the tech giant and they were equally blown away. We showed them that a 20 day process involving the collective intelligence of an extended team of human experts could be automated by our CPQ engine in less than a second. The tech giant did their due diligence and looked at other CPQ solutions on the market. And then this happened:

They came back and told us that our solution was “light years ahead of the competition.”

Veloce CPQ was born. The rest is history in the making.