By Sugath Warnakulasuriya — October 7, 2015
It was 1998 and, as the co-founding CTO of my first startup, I was intent on getting everything right.
The problem we were going after was stunning in scale. Our CEO had taken note that, despite the Petroleum mega-mergers of the era, lots of players had to get involved, often hastily, to move crude and refined products. A barrel was hovering around $20 and we could save them about $2 by getting rid of all of the friction. With 1.2 million barrels moving every single day, it was hard not to get excited by the sheer scale of what we could build. We put together a top-notch executive team from big petroleum companies and got early investors cashing out of Netscape and other IPOs to play. It was such a crazy time in Old Town Pasadena, with IdeaLab and many first-time entrepreneurs going after problems ranging from the whimsical to the outrageous. Even the addiction specialist Dr. Drew had an eponymous dot-com just downstairs from us. So in this crowd, we were the serious “B2B guys” getting lots of compliments. We even got to go to some fancy launch parties.
My job was to build the engineering team and the product. It was a new world, so we went all “agile” – we bought into the Rational Suite, used a J2EE stack and developed and rolled out the product in small bites. It was a big economic opportunity, but the chance to get re-skilled was the carrot I used to steal engineers from some big name companies. I first got them to show up after work, and then to leave their cushy full-time jobs altogether to join the revolution.
At the time, we didn’t use terms like “customer discovery” or “get out of the building”. But that’s exactly what we did, taking many trips to Long Beach Harbor, port of Seattle, and elsewhere climbing tanks, visiting pumping stations and getting out to tug boat yards, decked out in hard hats and armed with clipboards to gather “customer requirements” as we used to call it. When we showed the early customer prospects how we would replace their chalkboards, post-it notes, and hundreds of phone calls with simple web pages, there were nods of appreciation, and more compliments. We surely thought we must be on the right track.
With the product development in hand, I started going on calls with our sales team. The small companies who served the big producers loved it, so even more compliments. The big producers took meetings, heard the story, but they wanted to take their time. And the VCs wanted to wait until the big producers jumped on board, which made sense to us. Weeks turned into months, but we kept marching on. And then the climactic scene played out just like in a movie. We walked out of a Madison Avenue Private Equity office with a term sheet in hand and hailed a cab to JFK. When we got there, the airport lounges and bars seemed unusually chaotic. It was March 20th, 2000. Everything had changed in a matter of hours. We flailed for several more months trying to get a National oil company in South America to use what we had built. But our time had run out.
We made a lot of mistakes, and they all seem so obvious now. Here's what we learned:
□ A strong belief in what we did and the cognitive bias it created meant we conveniently ignored that, if you were the CIO of a major petroleum company at the time, your top concern was “Y2K”. The second pressing issue was putting up an “Exchange”. Saving money on logistics was something they could wait for. We simply had no idea about the length of our sales cycle, and didn’t see funding drying up anytime soon. Even today, I see many startup teams underestimating sales cycles with respect to their runway. The absolute top priority in startup execution is to understand and accelerate the sales or adoption cycle with respect to burn. Notice here the deliberate omission of any reference to “product”.
□ In another glaring oversight, we assumed everyone in the logistics chain wanted transparency to make life easy. Even petroleum traders wanted transparency, but the difference was they didn’t want anyone else to have transparency. Even today, there are businesses that live on information asymmetries. If you are playing in a complex ecosystem, get to know not just the value proposition for each party, but also the conflicts your business may introduce. It’s convenient to overlook these if you are not careful.
□ In looking back, we should have focused entirely on getting the big oil producers on our platform, as others would have gladly followed. In any multi-faceted market, there is usually one side that can drive transactions and liquidity. This is better understood today than it was back in the early days of online markets. But I still see young companies wasting time and resources by starting with the easy, low-hanging sides of the market.
□ It’s exciting to build and show progress in a product. It’s an easy way to keep moving in a positive direction: teams thrive off this energy, investors like to see this, and it generally makes everyone feel good. But if you haven’t understood your customer problem or how, why and when they will buy your potential solution, building the product is the wrong thing to work on. Focusing religiously on customer development, and first answering the question “should you build it?” vs. “can you build it?” is what Lean Startup is all about. If you are not fully on-board, you are greatly increasing the risk of failing.
□ As Tom O’Malia, one of my USC biz school professors used to say, “contracts, not compliments!” If you are getting lots of compliments on your startup, it means you are spending too much time in the wrong places doing the wrong things with the wrong people. This includes startup contests! Instead, spend that time with your prospective customers signing them up, or at least getting them to help you figure out how to solve their big problem. And I’d much rather see a startup team working hard to extract real learning from a customer, say as opposed asking for a “letter of intent”, which I consider the death knell of a sale.
I’m glad to see the recent spate of websites and blogs dedicated to startup failures. I’m hoping that, just like code, we eventually get to an “Open Source” movement for contextualized, highly usable validated learning.
And if you are in SoCal and want to share your learning, here is a great forum:
http://www.epicfailurescompetition.com/