Discovering the popularity and weakness of incumbent CPQ offerings
In 2015, I met my CPQ soulmate and Veloce co-founder Shaowei Mao when we both joined the market leader in the rapidly growing CPQ space running on Salesforce.
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 Salesforce platform would not work for complex CPQ.
Real world CPQ problems
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? How can your customers tell their salespeople and end customers to keep their product configurations under a certain size? 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. Not just room. There was pent up demand that was not being satisfied. We wanted to create a technology that actually did what CPQ technologies have long promised.
Finding our first (big) opportunity
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. So we just went after what we knew: the top dog.
I knew the problem well enough. And frankly, this unresolved problem still bothered me. I only lacked a CPQ product to solve it. 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. Shaowei said he only needed a problem to test it out on. And he said this tech giant provided the perfect test problem for his technology.
The birth of Veloce
I created some mocks ups, went back to the tech giant and told them what we could do for them. The tech giant encouraged us to start a company to work on their problem. No commitment from them, just a bit of encouragement. 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. No matter that most people couldn’t pronounce Veloce. It conveyed the core value of our company. We do things fast and our product runs fast. We went with it.
Generating the Salesforce Tower from a short description of its purpose
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. A magician’s trick. I didn’t expect him to be able to do it.
Shaowei, however, took it seriously and went to work. I didn’t hear from him for awhile. I wasn’t sure if he’d forgotten about our plans. 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. It wasn’t perfect but for a prototype it showed incredible promise.
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 had achieved a dream. 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.”
Read the Finale Part 3: What makes Veloce CPQ technology better?
