How to build to last (or at least grow for a good while)

One of the advantages of the software-as-a-service SaaS (or even a more broad Web 2.0) business model is that the starting costs could be relatively low and even with a few (good) engineers it's possible to reach a revenue-generation point in a short amount of time.  However, what do you do so you are able to profitably grow after you hit the first-revenue point?

As part of my consulting and advisory work, I have been involved in several SaaS companies this year.  Two of these companies helped me understand what kind of approach it takes to build a company for the long haul.  One of them: by not doing as they did; and the other one: by trying to do what they did.  Note that both companies were based on brilliant ideas.

Earlier this year I worked with a local internet advertising company which shall remain nameless (the protect the innocent).  Let's just call the company "J".  J was a very based on a very clever idea to use a mobile platform and integrate it with the internet to enable local merchants for advertising (to local markets).  I was consulting with them as their chief operating officer and as part of that I repositioned the company as a SaaS company and got them to a fund-able state (in a very un-funding market!)

J's CEO was the one who had come up with the idea.  She was an early employee of an early internet company (i.e. mid 1990's), but altogether she wasn't internet technology-savvy.   So, she decided to contract out software developers to build the technology.  The company was still getting formed, so she had decided that the employees (contractors and others) will all work remotely from home office, library, Starbucks, etc. - after all, that's one of the benefits of starting an internet company.  Due to her management style, she wanted to be the broker for all information sharing.  In addition, "to cut costs" we never got together early in the process to define terminology, hand-offs, procedures, etc. - and decided to instead do it on the fly when we needed it.

None of the above prevented us from moving forward, creating a product, marketing it, selling it, etc.  But ....

1.  Since we had contracted out all of our software development, every time (literally) we needed a product feature enhancement or a new capability added, we had to decide and approve first the cost of estimating the development cost, and then the cost of actually performing the development.  Even a small feature update or bug fix caused a decision point.  We spent more time deciding on minor iterations than actually performing the iterations.  The team spending time on these decisions was at not expense (we were all "paid for") but the software development was an expense.  In more cases than none we decided to postpone the bug fix or the feature update, in order to save on expenses.

Making minor (and even major) iteration on product capability is a critical part of product formation in a high technology company, and we were handicapped by not being able to nimbly address them.

2. During the early days of startups, what is really important (and cannot be replaced) is the free and open brainstorming.  In their early days companies brainstorm on everything:  product, business model, personnel, financing, selling points, everything .... down to the color and the location of an item on the website.  Some of these decisions are more or less critical to business, and some are not, but even the ones that are not critical to the growth of business might be a key emotional enabler for personnel issues - at every brainstorming session there are emotional stakeholders.

Not having a common work place, we either had these brainstorming sessions on email or on the phone, which a) are extremely ineffective, and b) do not meet the emotional needs of the stakeholders.  I can't believe how much money we didn't save by not meeting face to face everyday for a good number of hours.

3.  When we did meet, we spent a fair number of minutes making sure we're all talking about the same thing.  One example: We once had a conference call to decide what needs to happen on our "landing page".  This conference call included people from the Los Gatos, Saratoga, Santa Clara, Sunnyvale, Campbell, as well as somewhere in Pennsylvania.  For 20 minutes at the beginning of the meeting the discussion was going around circles.  It suddenly became obvious to me that the term "landing page" had different meaning to different attendees.  So once I suggested to first define the term, everyone agreed (in relief) but we spent the next 40 minutes discussing the definition itself.  That meeting did not achieve what it was meant to achieve.  This is only one example, but a telling one!

Then ....

A couple of months later, I started my advisory role at Xuropa.  Xuropa had been in business for about 9 months.  They were almost at the product release point.  But they had done things differently (than J).

1. Xuropa's founders included a technologist (software developer) - a very capable one.  The original seed technology was not contracted out.  This had two major benefits:  1) the code base was not a hack done by several short-termed developers and it was constructed by one single team and "all parts of the software were talking together"; 2) The cost was already incurred, so each enhancement was not a new "expense" and hence not subject to an ROI discussion.  As a result,  when I suggested an update or feature enhancement, it was done quickly -- sometimes in a matter of minutes: the developers were involved from the first day so they knew exactly what and where needed to be changed - they would just make the change if they agree with it.

2. Xuropa had an office space - nothing luxurious but very functional.  Many might argue with its necessity, especially with the costs involved and in such an early stage.  Xuropa took a very interesting approach.  They started with an office space to get the company started and to a solid and stable point, and only then they decided to become "remote" to minimize the costs.  They had realized that the brainstorm time together in the early days is critical and worth far more than any savings they would make by not having an office space to collate everyone.

3.  From what I understand, Xuropa's founders spend a good part of their first 6 months defining terminology and processes.  This made the company extremely efficient in meeting times and other exchanges.  Emails became shorter and shorter without losing any of their specificity and content.  Conference calls and meetings were efficient.  A few weeks ago, I had a blog post on doing better rather than just doing more.  A lot of companies advocate over-communicating to make sure things move forward without a glitch.  I prefer communicating better rather than just more, and if the terminology and processes are defined in advanced, it's very easy to just communicate better.

###

I'm not hoping to rewrite the book "Built to Last".  Nevertheless, a few observations, just this year, made me realize that there's always the tendency to think penny wise and pound foolish.  If one is building his company for the long haul, he needs to resist the urge.