The Story of Veloce Part 1 of 3


As written by the beloved Greg Davis, Veloce Co-Founder and CMO, before his passing in 2020.

Preface

Technology is built by people. But technology companies don’t often share the personal experience behind their technologies. Our personal story explains how we were able to create a CPQ technology that a global tech giant told us is “light-years ahead of the competition.”

The “HR experiment” that launched a career in CPQ

I got started in CPQ in 1997 with my first job out of college. I was hired by Siemens to be their system administrator on Calico, an early CPQ technology. True story: my hiring was an “HR experiment” to test Calico’s assertion that “anyone off the street” with no technical background could manage their system. I fit that description perfectly as a recent graduate in the decidedly non-technical field of international relations.

Struck by how many problems customers tolerated from CPQ

At Siemens, the first thing that struck me was how many problems customers tolerated from a CPQ technology. Calico had issues. Calico’s chief problems were around performance and scalability. Calico choked under the load of 5 users. And what about that HR experiment: could anyone “off the street” manage Calico? As it turned out, I did learn to manage Calico. But the spirit of the experiment failed because in order to manage the system I had to transform myself into an IT expert, highly literate in Calico’s underlying programming language that looked a lot like LISP. A programming language designed for academics with AI expertise. Hardly BASIC. In effect I had become the first person in history to go from writing papers on political economics to CPQ programmer in under a year.

Hooked on CPQ since 1997

I found the challenge of CPQ insanely interesting. CPQ is not easy. But if we just optimize here and re-architect there, we could get it right. I really fell for it and I’ve been hooked on CPQ ever since. 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. And I was equally intrigued with the technical challenges of achieving the perfect CPQ system. 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.

Finding the ingenious engineer behind the most powerful CPQ systems ever

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, the inventor and brilliant mind behind Veloce’s CPQ system.

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, 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.

The mother of all CPQ challenges

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 was disappointed. I had made a huge effort — including many late nights — but failed. I really wanted to solve this problem. I just didn’t have the right technology to do it.

Read Part 2: The Birth of Veloce CPQ

Latest Blog Posts
Ready to accelerate your revenue growth?
Let's talk.