When we founded Looker (then Llooker), there were nagging questions:
Conventional wisdom (and it's often right) is that you need to decide things early and focus. When starting out, we decided to put off answering some key decisions until the future was better defined.
We clearly knew the value we wanted to provide: Deliver flexible access to detailed data into the hands of as many folks inside of our customers' organizations as possible, so they could make better decisions.
What we didn't know was the best way to structure a business to do that. We really didn't know. Should we sell software? Should we sell consulting? Was the cloud really going to win? Would customers be comfortable having their crown jewels (data) in the cloud? How much hand-holding would it actually take to deliver our value (how much consulting)? Was the business a rocketship? Was it a cash cow?
We didn't know. We also didn't worry about not deciding.
We started not deciding by choosing our tool chain. Would we be a cloud service or install in our customers' infrastructure? We thought that, at some point, the majority of our installations would be one way or another, but at the early stage we couldn't know.
If we were going to be on premise, we'd probably choose to code in something like Java so the install could be easy and updates easily managed.
If we were going to be hosted, we'd choose Ruby, a language we loved. But Ruby, installed on a client machine, is a bad thing. Configuring Ruby on boxes is painful, and more importantly the source code is out there in the open.
What did we choose? JRuby. JRuby is a version of Ruby that compiles to Java bytecode.
This wasn't a simple decision. At the time, JRuby was new and pretty unstable. Many Ruby libraries didn't work with it (anything that used native code). And particularly, the sockets layer wasn't very stable, and Looker is a web server.
Clearly, if we knew we were going to be Hosted (SaaS), vanilla Ruby would have been a better choice. And if we knew we were going to be On Premise, Java would have been a better choice. But at considerable expense, we chose JRuby.
As it turned out, it was an excellent choice. JRuby is stable, fast, and reliable today.
It also turns out we were wrong about believing we had to make a choice. 50% of our business is On Premise today and the other 50% is Hosted. For good reasons, it looks like it's going to stay that way.
We started from value. The value of Looker is to get a customized data query interface into the hands of business users so they can ask and answer very complex business data questions, getting down to the row level on any inquiry. In order to build an application like this, of course there's customization. And in Looker, that customization is performed in a language called LookML, a language we invented.
When we started, we weren't sure if we were going to be a Service (like Palantir, where we do all the customization) or a Product (where we sell the tool and the customer does all the customization). Again, conventional wisdom says "decide this early." Of course we didn't.
We decided to take some customers in both models. For the Service customers, we did all the customization. For the Product customers, we did varying degress of customization, from none to say a month's worth of development time.
All these organizations had Hounds (business users that wanted access to data). Many also had Foxes (data scientists and programmers who were willing to learn LookML).
In our indecision, we decided on a couple of ground rules. "All customization will happen in LookML." We woudn't add any custom features that couldn't be represented in the LookML language. If we were to add features outside the language, it could lock us into being a service company. And we didn't want that, so we said 'No' to some tempting opportunities.
Fast-forward a year and it turns out that our indecision paid off tremendously. Our sweet spot is a customer with both a Fox and a Hound. We sell Looker as a Product, but we take a forward-deploy approach (our free trial), building out enough design patterns to ensure the construction of the application is very successful. So we are a service too.
Some great businesses aren't venture businesses. (Law firms are a great example.) Venture is about not having a cap on your upside, demonstrated by the inability to answer two questions: How fast can you grow? How big can you get?
If you are taking Venture, you are jumping on the race track. You are looking to build a fast-growing business that's going to be enormous. If you have great product/market fit, going Venture is a fantastic route. If your product/market fit isn't so good and you've taken venture, you may be locked into a strategy that's sub-optimal for what you've built.
We decided to wait and see if we were a venture business.
We chose to get customers very early. We could provide value almost immediately, so we also generated revenue very early. That early revenue created a discipline in the business to watch the numbers and pay close attention to the economics.
We were actually cash-flow positive when we decided to take seed investment ($2M). We took the investment to grow. We chose investors we knew very well and who would give us the most flexibility in our business model, timing, and approach. We didn't shop the deal. The size of the round wasn't important; the partners were. We chose Tim Connors at PivotNorth and Bill Trenchard at First Round.
Fast-forward another year. We knew we were sitting on a company that was a rocketship. We were seeing tremendous product/market fit (ask any Looker customer how they would feel about not having Looker) and a repeatable sales and delivery model.
It was time to go Venture. We did the whole thing in two weeks. We took $16M from Tomasz Tunguz at Redpoint, an investor we loved and someone who deeply understood our product and philosophy. At the time of the investment, we had $1.5M still in the bank from the seed investment.
By saying "I don't know right now," we chose flexibility over and over. Each time, we were surprised. Product or Service turned out to be a false choice, as did On Premise or Hosted. Deferring when to take money until we knew we were a Venture business made it much easier to raise the money. (Ironically, because it was obvious we were a Venture business.)
Not deciding too soon can be a very good decision.