SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for November 30th, 2007

Making All Software Into Tools Reduces Risk

Posted by Bob Warfield on November 30, 2007

Here’s a radical idea:

All software should be a tool or language because it reduces your risk of failure.

I’ve written before that if an area is important enough, it eventually becomes a language.  We’ve watched it happen over and over again, sometimes in the most unlikely places.  For example, Adobe made it’s start by turning printing into a language called Postscript.  It gave them enormous advantages over the competition.  Here’s another prediction: we won’t see the real universal Social Graph until it is expressed as a language not an application.  Why?  Because as I have said before, it is a living breathing dynamically changing entity that means a lot of different things to a lot of different people.

Why do I say tools and languages are lower risk?  Certainly this flies in the face of conventional wisdom.  Many VC’s, for example, want no part of a tools play.  They see it as extremely risky for a variety of reasons.  Dealing with IT and other technical types seems hard.  As customers they are seen as too demanding.  They want it all for free as Open Source, etc., etc..  That’s one particular market, and there are answers to those questions, but making software into a tool does not necessarily require that you sell to that market.  Sometimes, the tool nature is almost invisible.  Spreadsheets, for example, are really languages.  Creating a spreadsheet is an odd form of programming.  In fact, it’s great because it’s probably the most widely used and understood language that’s ever been created.

Here’s another way to look at it.  I recently wrote an article called “Why Small Software Teams Grow Large“.  It was a response to a number of questions that had come up over my proposition that you need a small team to write really great software.  Here is a question that relates to this post:

Aren’t all the great small team examples tools?

Linux, Delphi, and Quattro Pro are described by Chris as “generic tools built without regard for any specific business logic.”  There are two ways to think about this.  Chris takes the path that says the example is irrelevant because most software isn’t that way.  I take the path of saying that the example is spot on because all software should become a language if done right.  The benefit?  Your small team is enormously more productive as are your customers if you can actually make the language something they can grasp and use.  There is a reason these small teams built languages (though I’m not sure I view Linux as a tool/language).  In fact, Quattro Pro had no less than 18 interpreters buried in the guts.  Very few of them were surfaced for end users, most were there to make the code simpler and the product more powerful.

You see what’s at work there?  Languages/Tools make it possible for smaller teams to be even more productive.  If you buy into the idea that small teams are the best, you must want them to have the best possible tools as well?  What could be better than to make the software they’re working on a special purpose tool?

I’m certainly not the first one to think of things this way.  There is an entire area based on the idea of Domain Specific Languages.  The idea is to create a language around the problem you’re trying to solve in order to make it easier to solve the problem.  Tools like Ruby on Rails or Lisp are extremely good at that task.

Rather than dive into a highly technical tangent, let’s get back to the theme here.  Why would making your software into a tool reduce risk?  We’ve already hit on one aspect–it can make the developers much more productive.  Here is another: a tool makes it much easier for the software to adapt to changing needs of customers.  I do a fair amount of what I call “Termite Inspection” for various VC’s around the Valley.  Some of these engagements boil down to, “This company has a great idea, but they seem to be stuck in a rut.  What should they do?”  Many times what has happened is a company started out with a great idea and some knowledge of the domain.  They built a piece of software that is a very literal embodiment of their view of the domain.  So long as the whole domain and all the customers fit their view, life is good.  However, for most non-trivial (i.e. interesting market size) domains, nobody knows the whole domain.  You learn as you go.  Customers throw curve balls.  If the only way to adapt to that is to either keep adding tons of features to the software, or do expensive custom work on each deal, that’s way too much friction to scale.  A domain specific language makes it possible to manuever a bit at low cost and give customers what they want.

I finally put two and two together on just how important this can really be when reading Fred Wilson’s excellent article on Why Startups Fail.  Interestingly, he classifies all of his failures (and presumably others) into two categories:

1) It was a dumb idea and we realized it early on and killed the investment. I’ve only been involved in one investment in this category personally although I’ve lived through a bunch like this over the years in the partnerships I’ve been in.
2) It was a decent idea but directionally incorrect, it was hugely overfunded, the burn rate was taken to levels way beyond reason, and it became impossible to adapt the business in a financially viable manner.

Can you see where this is going?  Category 1 won’t be helped, and Fred correctly says you can identify this and cut your losses early on.  Building the software as a tool is a perfect antidote to #2.  The “decent idea but directionally incorrect” is strikingly similar to Marc Andreesen’s concept of achieving a product/market fit, which he says is the only thing that matters.  Fred Wilson gives us a great anecdote:

Dick Costolo, co-founder of FeedBurner, describes a startup as the process of going down lots of dark alleys only to find that they are dead ends. Dick describes the art of a successful deal as figuring out they are dead ends quickly and trying another and another until you find the one paved with gold.

Achieving the product/market fit is a matter of trial and error.  It is searching through an unknown territory filled with dead ends.  To survive, succeed, and prosper, your software needs maximum flexibility and adaptability.  That’s the definition of a Tool.  It can be adapted even as the requirements keep changing radically, and it can be adapted very cheaply and efficiently.

The principle should be clear by now, but there are troubling questions of practice. 

First, creating a tool sounds harder than writing an application.  My answer is that it’s harder because of who can do it and who can’t.  Once the tool is created, any developer should be able to use it to create new features.  Creating it is the province of developers a notch or two above the lowest common denominator.  The good news is that you don’t need to many of them.  Given my preferred maximum team size of 10 developers, you should easily get buy if 2 or 3 of the 10 are language creators.  Look for people who’ve done it before and are comfortable with the idea.  Look for people who are adept with dynamic languages and tools like Ruby on Rails. 

Second, delivering a tool sounds like a nightmare for users.  What do you do if your users are not technical?  Just because you’ve delivered a tool doesn’t mean you have to leave sharp blades and flaming torches hanging out of the toolbox.  Nothing is easier to attach a user interface to than a language.  That’s one of the great beauties.  But here’s a real quantum leap: combine your application-as-tool with a ui-as-tool for true power and flexibility.  I’ve been working with Adobe’s Flex along those lines and the results are amazing.  Other combinations that are similar to this would be combining something like PHP, which could be viewed as UI-as-tool with your application.  This is how the various social web 2.0 sites have gotten going so quickly and cheaply.  PHP straddles both sides of the spectrum and allowed these organisms to evolve very quickly.  In the end, you will wind up with a much better user experience because you’ll be able to quickly evolve your UI based on feedback.  Take it into usability testing early, and the combination of application and UI languages will make it straightforward to act on recommendations.

I hope you can get a sense from this post how powerful a competitive weapon having a language versus an application can be.  It actually reduces your costs, increases your flexibility, and let’s you respond with ultimate nimbleness to market demands until you’ve found the best possible product/market fit.

Posted in software development, strategy, venture | 10 Comments »

Interview With Lucid Era’s Ken Rudin, Part 3

Posted by Bob Warfield on November 30, 2007

This is part 3 of my interview with LucidEra CEO Ken Rudin.  If you missed Part 1 or Part 2, be sure to go back and check them out.  As always in these interviews, my remarks are parenthetical, any good ideas are those of Ken Rudin, and any foolishness is my responsibility alone.

How does SaaS affect the sales process?  Walk us through a typical SaaS sales cycle from initial lead generation to closing.

Ken:  Our sales cycle consists of meeting, often via teleconference and showing the demo.  90% want a 10 day free trial.  Our trial actually improves your sales organization and delivers value.  It’s on your own data so it’s real value.  During the trial, every other day we send the customer a killer report, which contains a cool insight about your business.

Bob:  How much do you need to invest to make your trial run on the customer’s real data?

Ken:  Customers using we can get running very quickly.  Most of our customers are there.  We have a prebuilt connector to SFDC.  We can can also talk to Goldmine or Siebel CRM On-demand.  We’ll take their data in a spreadsheet for all tier 1 solutions.  On the finanacial side we have connectors to Oracle Financials and NetSuite.  In terms of customization, we can handle custom fields.  We need a little work if we have to remap some fields.

Bob:  (Being able to run a trial that is essentially a full install is a huge competitive advantage for Lucid Era.  It means there is almost no friction involved in getting the customer to see what the product means for them.  This is the sort of model most enterprise software companies only dream about.)

What platform is your software running on?  (e.g. Solaris+Oracle, etc.)

Ken:  Lucid Era is almost all Java except some core C++ for high performance.  It’s Linux and all open source.  We use Broadbase’s database which is good at queries and analysis.  It’s a column store.  We bought and open sourced it.  It’s now LucidDB.  We also run an open source OLAP engine called Mondrian.

Bob:  (This was interesting news.  It seems that LucidEra didn’t just take the tried and true MySQL route.  It isn’t surprising, because Business Intelligence places some radically different demands on the database.  But this marks the first company I’ve talked to that uses the new column store technology.  This is a technology that Michael Stonebreaker and other database luminaries have been talking about a lot recently.  David DeWitt offers a good overview of the technology.  Suffice it to say that most existing databases access the data by rows, while a column store can give you rows, it works on columns.  This yields higher performance for a lot of operations because you’re not really ready to look at rows until you’ve done a lot of column processing.  For example, to find all sales transactions > $100,000 is a matter of looking at the sales transaction column.  This is an over simplification, but the benchmarks are promising.  LucidEra has also gone after an OLAP engine, which is similar to technology Arbor pioneered that was acquired by Hyperion.  It’s another alternative to row-based databases that is ideal for slicing and dicing data in a lot of different ways when you need maximum flexibility and don’t necessarily know what questions you will ask in advance.  It’s also interesting to note that they bought the Broadbase technology and open sourced it.  This creates a community around the code so Lucid Era doesn’t have to bear the full burden of support and development by themselves.  )

How big was your Engineering team and how long did it take?

Ken:  Significant investment was made.  Bigger than many others.

Bob:  (Ken was very cagey about this one.  I have a hunch he doesn’t want to make it easy for competitors to triangulate on what it takes to build a knock off.  Given the technologies he has described, I have no trouble believing LucidEra has some technology barriers to entry.)

Is Lucid Era a multitenant app?  Why is multitenancy so important for SaaS companies?

Ken:  We are totally multitenant.  It’s important to me, not so much the customer.  It keeps costs down.  We share operational resources internally.  We have the option to put a customer on a box.

Bob:  (This is a pretty standard answer for a new SaaS company.  It is important to keep operational costs down.  A SaaS company has to achieve a 16:1 improvement in cost of operation versus on-premises to be competitive.  That’s a tough hurdle, and one that most people are surprised at when they see it quantified as 16:1.  Multitenant helps tremendously, but there’s a lot more going on than that.  It’s also interesting that they offer the option of putting a customer on their own box, presumably at a higher cost.  All SaaS companies have multiple instances, though they don’t like to talk about it much.  This is not to say they give customers the option of their own instance as Lucid Era does.  Rather, it’s an operational convenience for the SaaS vendor.  Multiple instances may be used to stage new versions of the software, to split up loads, or even to make sure there are instances available at more than one datacenter in case disaster strikes.  Depending on the economics, it seems to me that it would make sense to let customers pay more for an instance if they’re particularly paranoid about keeping their data separate.)


Lucid Era is a fascinating business.  They’re in an interesting place now that the old school BI vendors have largely been bought.  Even more interesting is their approach of delivering a solution rather than a tool, and getting the customer up and running as the first stage of the “sales” cycle.  Add to that some radical new technology in the form of the column store LucidDB, and we’re seeing a total reinvention of what BI means.  We’ll see more of this sort of thing where conventional vendors are relegated to the Tools category and the SaaS vendor is providing finished solutions that can deliver value extremely quickly.

Let’s keep an eye on these guys and see where it leads!

Posted in saas | Leave a Comment »

%d bloggers like this: