We are shamelessly proud to have been the first investors in Marketo when Phil and his team had nothing more than a vision and a powerpoint presentation.  Today, with more than 1500 customers in the US and Europe, Marketo has done a great job helping companies to transform the role of marketing.

Ok…enough of the Marketo plugging and to the topic I really wanted to write about.

When I showed up, I expected the typical hotel-based seminar with 50+ attendees and a couple hour sales pitch on Marketo. You know, a dull powerpoint on the company and the requisite product demo. Instead, I found something radically different.

First, instead of 50 people, there were about 500 people crammed into a standing room only conference room. And, instead of a 2 hour sales pitch, the company had broken the event into two parts – morning and afternoon.

In the morning, they held a customer-only event training customers on how to better use features of the Marketo application suite and to capture direct feedback for product marketing. In the afternoon, they invited prospects and customers to commingle and focused on customer use cases that exposed best practices and industry conversion metrics to everyone, making it feel far more like education and training than a sales event.

Most interesting to me, was that I was sitting next to a few customers who each had a laptop running. However, instead of checking their email and FB posts as I typically see at these events, they each had their own version of Marketo up and running and were learning how to better use the application and showing prospects what they were doing.

Of all the years I spent at Oracle, Siebel, etc. I never attended a single event where customers could actually run their own version of their software during an outside event – not even at our own User Group sessions.

The end of the event was capped off with a nice party-like, cocktail atmosphere where Marketo employees, partners, customers and prospects could all interact.

I thought that Marketo’s use of the time to combine training with sales in an education format – where customers could follow along with their own implementations was just outstanding. Customers, in effect, were selling prospects on behalf of Marketo – is there anything more powerful than that!

It was extremely effective — and something that could not be done prior to SaaS. Thanks Marc Benioff!

So, just when I thought that physical sales seminars might be going the way of the dinosaur, the duck-billed platypus and the pet rock, I think the way Marketo delivered the Revenue Rockstar event might be a fork in the evolutionary path that keeps physical seminars relevant and alive.

Joining me on the panel were Byron Deeter, a GP at Bessemer Ventures and Joel York, CMO at Xignite. I really enjoyed the panel members and the audience interaction and was reminded again just how bright the people are throughout Silicon Valley and how fortunate I have been to work in an industry where the US still continues to lead the rest of the world.

Some of the topics the panel bandied about regarding the SaaS business model reminded me of lessons I have personally learned that I thought were worth repeating here.

The first big question thrown at the panel is whether a company can successfully negotiate a hybrid model that embraces both SaaS and traditional software delivery.

My point of view – based upon personal experience and observing other companies attempting to do it –  is “no”. While a number have tried (e.g. Microsoft, SAP, Oracle), I still haven’t seen any existing company do it very well, at least not yet.

The problem is at least two-fold:

1. The SaaS model demands that a company not only be a software development organization but it must also take on the responsibility for running the sofware 24/7.  It requires a different way of thinking about how you develop, market and deploy your products v traditional software.
2. The differences between the business models drives completely different comp plans, completely different behavior throughout the company and different expectations by Wall Street/investors. For example, a traditional software model is sales capacity driven, a SaaS model is typically marketing/demand driven. It’s hard enough for large ISVs to address this schism let alone a small company with extremely finite resources – while I haven’t seen any company do it successfully to date, I’m willing to keep an open mind here and if you have great examples of companies doing this well, please tell me about them and how they are doing it.

In addition to these basic structural issues, I think back to when I took over Siebel’s CRMOnDemand division after returning from a long sabbatical. I found myself having to learn a different vernacular and to develop an instinct for managing a different set of operating terms (e.g. CMRR, ACV, Churn, CAC Ratios, etc.).

In addition, we had to create a different organizational structure to manage the business model. For example, I created a Customer Success function in order to ensure someone woke up every morning worried about customer usage and adoption to manage Churn. In a traditional model, this responsibility was largely an issue/expense that the customer bore.

Where I had no cost of labor associated with managing software in a traditional model, the SaaS model demanded that with every new customer Ihad to ensure that performance did not diminish. This meant putting in more CPU, more storage, and doing a lot of SQL optimization work – especially for our analytics/reporting modules – whatever it took to ensure our customers were happy.

Of course, this is all “old hat” for execs at pure SaaS companies but for those ISVs who are just now contemplating deploying a SaaS solution, this will be new ground to cover.

The point I – and many others – have made is that embracing SaaS is just not as simple as doing a technical overhaul to make a product “multi-tenant” or to virtualize it – virtualization is the Larry Ellison method of delivering SaaS which Gartner now “endorses” as another viable form. Remember when it was sacreligious to say you were a SaaS company if your underlying architecture wasn’t multi-tenant?  It must be those high fees Oracle pays Gartner.

Actually, to Larry’s credit, he is right about the fact that companies don’t like commingling their data with others. Some market reports I have seen show there is demand for companies to deliver a “private” SaaS offering where each company’s data is guaranteed to be kept separate. Those reports also show that companies are willing to pay more for this offering.

Another big question asked of the panel was if/when the Back Office/Mission Critical applications (e.g. ERP, etc.) would open up to a SaaS delivery model. The key constraints that most of the attendees identified as impediments to the sales cycle for these types of solutions today revolve around objections regarding performance, reliability, scalability and security.

These objections reminded me of a lesson I learned at Oracle back in 1987.

At the time, I worked for a recently anointed Oracle VP – Tom Siebel – in the newly formed Product Line Division. Under Tom were DEC VMS (Oracle’s biggest product line at the time), IBM MVS/VM, DG AOS, Unix and PC organizations. I was given the responsibility to run the Unix division – a nascent product line.

One of the great value propositions that Oracle provided was that you could take an application built to run on top of Oracle (e.g IAP/IAG and its sucessor SQL*Forms), and run it on top of an Oracle RDBMS irrespective of the operating system/hardware platform.

In 1987, Unix was a fledgling commercial operating system and was primarily used in academic and/or scientific environments. It had few mainstream commercial applications. Then, Unix lacked a lot of what enterprises felt were basic requirements – clustering, disaster recovery, fault tolerance, scalability, etc.

A number of Unix systems start ups emerged to take advantage of the fact that Unix was relatively “cheap” to license and they could instead focus their engineering dollars on delivering fast, relatively inexpensive hardware systems. Companies such as Pyramid, Sequent, AT&T Information Systems, began to take on the mini/mainframe computer markets with these low cost systems – low cost when compared against a DEC VAX, IBM Mainframe, etc. vis a vis price/performance.

However, these new systems lacked commercial applications.

My strategy – er, Larry’s strategy – was to go after the Unix systems manufacturers and to get them to license Oracle so that they could then take applications written on top of Oracle for DEC and/or IBM and have them immediately run on their machines for substantially less.

It turned out that the “magic” ratio was 10:1. Once the Unix vendors could offer an Oracle solution for 10x less than a comparable DEC Vax Oracle solution, many of the issues of security, reliability, etc. that previously plagued the Unix vendors selling into a commercial environment began to evaporate.

Instead, companies found areas where they could use an Oracle/Unix combination that wasn’t as dependent upon security, reliability, etc. and Unix vendors used the profits from these sales to fund R&D to plug the commercial gaps. A classic Innovator’s Dilemma cycle occurred.

We all now know how it ended up – Unix is now the standard operating environment for many/most commercial applications. Many Unix vendors were acquired and many incumbents disappeared – the computer systems landscape was irrevocably transformed.

I think it is easy to use this history lesson to predict where “cloud computing” is going to end up. Today, many large enterprise IT departments decry cloud computing as not reliable, not secure, not scalable, etc. However, with recent price/performance ratios tipping 10:1, we are beginning to see cloud computing enter the periphery of the enterprise and we will see a lot more in the next couple years.

It started first with front office applications. Now, it’s penetrating the back office at several different levels that include applications (e.g. Workday) and infrastructure (e.g. AWS, Rackspace, etc.).

If history repeats itself – and I do not believe there is any reason for it not to do so in this case – I predict that within 5 years, private clouds and public clouds will achieve massive penetration inside the Global 2000 and completely disrupt the way computing is deployed and managed. It will also change the vendor landscape, irrevocably.

However, as much chaos as this will introduce now, in 10 years, I doubt that cloud computing will be a big topic of discussion because it will be de rigueur; just as Unix is today.

I look forward to any feedback you might have. 

Background

A problem that seems to plague relatively large, successful companies is that their ability to innovate and bring new products to market tends to be inversely related to their success and growth. That is, the bigger they get the less innovative they become. There are two primary reasons for this perplexing phenomenon.

The first is that existing customers place increasingly significant demands upon the company’s product resources to provide bug fixes and deliver enhancements to current product lines. Over time, maintenance and product revenues from existing customers dwarf new customer revenue so companies must invest the majority of their resources to secure these revenue sources, leaving few resources for new product initiatives. Second, the public markets expect companies to generate increasingly better operating results – improved revenues and margins each and every quarter.  Investing in new product initiatives result in little short term revenue increases. The problem is compounded by the fact these new product investments immediately impact the expense side of a public company’s balance sheet. This can lead to poor margins and a depressed stock price which in turn can jeopardize a senior management team’s employment tenure with the company.

An advantage a successful company would seemingly have is access to cash to fund new product initiatives. However, while many of these companies do throw off a substantial amount of cash each quarter the quandary they face is that they are unable to use that cash to finance new development initiatives without negatively affecting their quarterly income statement. Interestingly, if they allow their cash balances to grow large enough, shareholders begin to demand the company increase its overall returns through quarterly dividends. Therefore, other than providing a safety blanket buffer for liquidity, cash offers virtually no medium-long term competitive advantage for a public software company.

Some companies have adopted the strategy of using their cash and/or stock to innovate and grow through acquisition; the in-quarter investment expense correspondingly offset by an equal increase in total assets. The downside is that this can take a substantial amount of cash and/or requires very liquid stock. Therefore, this approach is generally limited to a very few large companies such as IBM, Microsoft, Oracle and SAP.  Additionally, these companies are reliant upon finding companies that are willing to sell, they must pay a premium to the market value for the company, the technology they acquire must be architecturally consistent with their current products to gain immediate benefit, and more importantly they must entice existing key personnel to stay. None of these are necessarily showstoppers but each of them introduces complexity and expense and requires a significant investment of executive and employees’ time.

These problems, and others, can result in product innovation stagnation over time and lead to competitive vulnerability for established companies that must serve customers and investors simultaneously.

Proposed Solution: Spin In

A potential solution to this dilemma is the use of a “spin in”. While several definitions of “spin in” exist, for our purposes I am defining a “spin in” as a company formed with the explicit endorsement and investment – including personnel, cash and IP – by the parent company and outside investors. The express purpose of the “spin in” is to build strategic products and/or go after new markets with the ultimate objective that the parent company will acquire the “spin in” at some point in the future.

The concept is relatively straightforward and has been tried, tested and proven most successfully by Cisco but it has also been used by companies in other industries as well as by the federal government. However, this approach has not typically been employed by software companies. One of the reasons it has not been used in the software industry is due to the Not Invented Here (NIH) syndrome many software companies possess. The attitude is typically “we can do it better, faster, and cheaper ourselves.”

However, the facts tend to conflict with the attitude; as companies grow, few really new products are started, completed and brought to market. The primary reason is that each year when the products organization and executive team sit down to consider all the proposed projects for the following year, there is a very finite budget to distribute. A line is drawn and all the projects that fall below the line go unfunded. The projects that are usually funded are those that are the current mainstay of the company; the ones that are most likely to generate short-term product and maintenance revenue.

The dilemma is that those projects that fall below the funding line could very well be the innovation the company needs to compete and secure future revenue streams. In addition, many of those proposed, unfunded projects are the brainchild of some of the most talented personnel in the company. When those projects don’t make the cut, the product team associated with those projects can become extremely frustrated and ultimately threaten to, and often do, leave the company to pursue “their dream”. This can put a significant brain drain on the company and set the company up for disaster in future years.    

A “spin in” is one approach to solving these problems. The framework of the “spin in” structure I am proposing is different from Cisco’s approach and is an attempt on my part to address the issues of each of the constituents involved: parent company, outside investors and “spin in” management/employees.

Product Selection

The key to selecting the specific project/product as a candidate for a “spin in” is to ensure the product is considered to be strategic to the success of the parent company and that the market opportunity is large enough to support an independent company. A product idea that is just a feature of a larger product suite is not a suitable “spin in” candidate. Think of it this way, if it won’t pass a venture capital firm’s due diligence as a sizeable, standalone firm, it isn’t a viable candidate as a “spin in”.   

Financial Structure

There are several important elements required to make a “spin in” a viable financial structure for the parent company, the investors and the employees. Below is the basic framework of that structure.

Ownership

In order to keep the “spin in” company’s financials off the parent company’s books and to prevent it from diluting the parent company’s earnings, the parent company must own less than 20% of the “spin in”. While this is a minority position and could theoretically cause the parent company to lose control, the preferences of that ownership can provide the parent company with the terms it needs to make it feel secure in its downstream rights while other terms can be set to ensure other investors are equally protected.

Many of the initial key employees will more than likely come from within the parent company giving them the opportunity to pursue their interests while continuing to contribute to the ultimate success of the parent company. To attract a world-class management team and employees, the “spin in” will need to allocate a minimum of 20% of its valuation for employee stock.

Therefore, simple math suggests that outside investors will own 60% of the “spin in” at its onset and may need to provide up to 100% of the forecasted cash requirements. The parent company can contribute any one or all of the following: IP, key employees, marketing programs, a ready-made distribution channel, and cash to account for its percentage ownership position.

Collar

The primary difference between the “spin in” proposed here and the ones that Cisco has created is the use of a financial “collar”. The terms of the collar will give the parent company the “first right of refusal” to purchase the company at a pre-determined amount for a pre-determined period of time thereby protecting the parent company from having to buy the “spin in” in the open market at a potentially high valuation.

On the other end, the collar will provide the outside investors with a low-end threshold they can rely upon to sell the “spin in” back to the parent company by a certain point in time, thereby giving them a guaranteed return and shielding the outside investors from potentially losing their entire capital investment.

And, finally, it will provide the management team with the incentives to drive a range of increased valuation outcomes tied directly to revenue and expense objectives.

Lower Bound

The outside investors will hold a ‘put’ option valued at some multiple of total capital invested that can be executed not before 5 years but no later than 8 years after the initial set up of the company and requires a simple majority vote based upon ownership percentage of the outside investors. This approach incents outside investors because they are guaranteed to make at least some positive multiple of their investment in at most 8 years – this is a good, albeit not great, multiple and IRR for a venture fund.

Upper Bound

The parent company will hold a ‘call’ option that contains terms with a “first right to purchase” at the greater of some multiple of trailing twelve month revenues or a multiple of total capital invested, not before 5 years and no more than 8 years after the initial set up of the company. The parent company is therefore protected for a range of 3 years with a first right of refusal to buy the company at a price that is potentially less than the price it would have to buy a  successful company in the open market. And, while the investors could certainly force the parent company to buy the “spin in” even if the technology/business isn’t successful, this is a premium the parent company pays to gain the substantial leverage a “spin in” can provide.

The terms of the collar could state that the company cannot be bought or sold in the first 5 years without the management team’s majority approval. If the call option is exercised by the parent company, the employees of the “spin in” will be paid their percentage ownership based upon the valuation of the “spin in”. If the put option is exercised, the parent company will pay the management team 50% of their ownership percentage using a multiple of total capital in from the outside investors as the “spin in” valuation. As a result, the management team is rewarded by driving the valuation as high as possible, as fast as possible and incenting the parent company to exercise their call option. The management team will be held to an approved spending plan controlled by the board of directors so that the company cannot put the outside investors and parent company at uncontrolled spend risk.

For years 5 through 8, either the investors can sell the company to the parent company or the parent company can buy the company at the pre-determined values. After year 8, the company will gain the right to control its own destiny in the open market because the collar will have expired.

Examples

Let’s take a look at how this might work under several potential scenarios.

TBQ is a public software company with annual revenues of $1B, CAGR of 25%, 25% margins and a current market cap of $5B. The company realizes it needs a new suite of application development tools for their new open-fission architecture. However, after a thorough analysis, the engineering and products organization has a plan that requires 100 product managers, QA personnel and engineers working full time on this for the next 3 years, best case, in order to bring these tools to market at a minimum cost of $75M. They determine that with fully-burdened costs for each HC of $250K/year and 100 HC that it will cost $25M/year.

The senior executive team evaluates the proposal and realizes they do not have the current resources to build these tools and the additional expense will put pressure on the company’s operating results. The company decides to establish a “spin in” to build these tools.

The “spin in”, called Acme Software, is set up with an initial capital investment of $20M from 4 outside investors who collectively own 60%. The parent company invests $1M in cash, some IP and a few key senior personnel for 20% ownership. The employee pool is set up at 20%. This sets the post money valuation at $33.3M. For this exercise, we will assume the put option is 3x paid in capital and the call option is set at 8x revenues.

Scenario 1

Due to the aggressive performance of the management team, assistance by the parent company and the much lower overhead of Acme Software at $150K/year/employee vs. $250K/year/employee, Acme is able to develop V1.0 of Fission-Ware Development Environment in 2 years, not 3 at a total cost of $20M, not $75M and they generate $5M in revenues in year 3, $10M in year 4 (and went profitable) and $15M in year 5.

Year 5 is the first year the outside investors can exercise their right to sell the “spin in” to the parent company. They have the right to sell Acme to TBQ for $60M – 3x the total capital they invested. On the other hand, TBQ has the right to buy the company for $120M or 8x twelve months trailing revenues. Clearly, under these conditions, the outside investors would not want to exercise their put but TBQ might want to exercise their call option to prevent potentially having to pay significantly higher for Acme by year 8. Since the parent company elected to exercise their call option, according to the terms, the employees pocket 20% of the $120M or $24M.

Scenario 2

Unfortunately, the management team is unable to deliver V1.0 of Fission-Ware Development Environment until the third year. They are forced to raise another round of $20M comprised of $5M from TBQ and $15M from outside investors for total capital in from outside investors at the end of the second year of $35M. In year 3, Acme generates $1M in revenue, $3M in year 4 and $5M in year 5.

Under this scenario, in year 5 the outside investors may be inclined to exercise their put option – requires simple majority vote by the outside investors based upon ownership percentage – which would generate $105M for them. The call option would give the right to TBQ to buy the company for $40M (8 *$5M) except for the fact that the term of the put option gives the outside investors preferential rights. Under the put option, the employees are penalized and paid based upon the formula 50% * 20% of $105M or $10.5M and are paid this amount by the parent company.

Under Scenario 2, the total paid by TBQ to the outside investors and Acme employees is $115.5M which is nearly what TBQ paid under Scenario 1 where the management team executed well. As a result, the financial incentives are structured around the collar such that they reward the management team – and the parent company – for achieving success.

The interesting point is that with either the over-performing or the under-performing scenario, TBQ gets their product earlier than originally forecasted by the internal team and for less overall expense. This result is a win for every party involved.

Summary

The potential benefits of a “spin in” approach for large, public software companies are numerous.

1. Strategic projects that might not be funded because they are below the line are able to get funded.
2. The cost of development is carried off the parent company’s balance sheet until such point the product is in the market and generating revenue so it is potentially non-dilutive to corporate earnings.
3. The parent company is able to effectively retain key personnel by enabling them to exercise their entrepreneurial spirit.
4. The “spin in” company retains some of the parent company ‘DNA’ so cultural issues that affect most acquisitions are minimized. 
5. The products that are developed can be managed such that they are architecturally consistent with the parent company’s products so there is little overhead integrating the “spin in” products.
6. The new company is not constrained by the parent company’s branding and marketing budgets and policies.

There are numerous issues not addressed in this basic analysis that must address specific issues around stock class preferences, governance and compliance issues, parent company controls and employee incentives, etc. However, these are issues that have been well documented by some of the better law firms that helped Cisco and others create their “spin ins” and can easily be incorporated.

Crowdsourced Logo and Graphic Design by crowdSPRING

The article includes some comments from an IDC analyst who suggests that due to this outage, companies must now have a “conversation” about what they keep inside the four walls and what they place outside ‘in the cloud’ – as though systems managed inside a company are somehow safe or safer. Ridiculous. Companies with internally-managed infrastructure have outages every day. It’s the strategy they’ve put in place to handle these outages that matters.

Just as companies today weigh the cost of investing in disaster recovery for their internal systems, companies that rely upon cloud computing vendors need to perform a similar assessment. I would assert that the “conversation”  suggested in the article should really have been targeted at whether or not you need disaster recovery services and how much you are willing to pay your PaaS/IaaS vendor to supply them.

Disaster recovery services are  available ‘in the cloud’ – as the article points out that Netflix has availed itself of -  but these services aren’t automatically included and cost more. The companies that experienced outages when a portion of Amazon’s cloud infrastructure went down chose not to pay for disaster recovery services and they got exactly what they paid for.

I would suggest that a more accurate headline for the article should have been something like, ”Lack of a Strategy for Your Cloud Computing Services is a Disaster Waiting to Happen”. Unfortunately, this boring title wouldn’t be nearly as sensational and wouldn’t sell papers…or online subscriptions…and it’s probably one of the reasons why I’m not a journalist.

Valuations and deal sizes for “hot start ups” are reaching lofty heights.

Just off the press is an article from Dan Primack, a journalist for Fortune magazine. In his article titled, “Venture capital shows sign of bubble” he writes the following:

Venture capitalists invested $5.87 billion in 736 U.S.-based companies during the first quarter of 2011, according to a new MoneyTree Report released by PricewaterhouseCoopers, the National Venture Capital Association and Thomson Reuters. That works out to $7.98 million per deal, which is 18% larger than the average deal size during the prior quarter. It also is 21.6% higher than the average deal size in Q1 2010, and a whopping 47% larger than the average deal size in Q1 2009. Moreover, the average early-stage, expansion-stage and later-stage deal was larger in Q1 2011 than was the comparable deal in 2010. That’s important, because it indicates that this isn’t just reflective of VCs putting more of their eggs into less-risky, later-stage deals.

He goes on to cite the following statistics:

Overall, software companies continued to lead all industry sectors with $1.1 billion raised for 187 companies last quarter. This was followed by industrial/energy with $1.03 billion for 75 companies and biotech with $784 million for 85 companies. The quarter’s largest deal was a $201 million round for BrightSource Energy, an Oakland, Calif.-based thermal power plant developer, that raised $201 million. The rest of the top five was Plastic Logic ($200 million), Fisker Automotive ($111 million), Tabula ($108 million) and SoloPower ($78 million). Per usual, Silicon Valley led the nation with $2.49 billion invested in 212 companies. New England placed second with $639 million for 90 companies, and New York Metro snared $580 million for 69 companies.

So, the question currently being bandied about the proverbial watercooler is are we or are we not in a bubble? If we are in a bubble, are we in 1998 or 2000 (referring to the relative beginning and end of the last formally recognized bubble) and if we are in a bubble will this one end like the last one or will the ending be somehow different this time.

From my own perspective at InterWest, we are seeing more deals than ever in 2011. The weeks are literally jammed with back to back meetings with great entrepreneurs with great ideas. And, the deals that are getting done, for companies in a hot sector (e.g. consumer internet) and/or with a proven team are being fought for and won at valuations that may be hard for the entrepreneurs to live up to — and for the venture firms to generate a great return if anything goes wrong and the company takes longer and more capital to reach its goals.

That said, one observation made by Keval Desai, an early member of Google and VP at Digg, is that:

•  There are 7B people on the planet.
• 2/3rds of them don’t have Internet yet
• 95% without smartphones
• Facebook only has 10% share
• There is an entire new generation that is using mobile tablets, as infants, that will learn, socialize and play completely differently than anyone born prior to them.

In addition, the rapid rise of the mobile/cloud computing market is also driving a complete transformation and overhaul of back end systems thereby creating opportunity throughout the technology markets.

Given all this, it could be entirely possible that we see many years of growth in many, many different technology areas without the big bubble pop we saw last time. Companies started today that see early traction and growth - and revenue – have a good shot at not suffering the fate of the Bubble 1.0 companies like “pets.com” but instead could survive to become the new large incumbents that help to reshape the world in which we work and play.

Of course, this doesn’t factor in exogenous issues such as instability in the Middle East, natural disasters, etc. which could act as a countervailing dampener.

So, while hot start up valuations may appear to be “bubbly”, we may look back and feel they were actually fairly valued. The next few years should be pretty interesting…but hopefully “interesting” in a good way.

The report states, “13 public SaaS companies tracked by Pacific Crest Securities have increased in value 40% since the beginning of 2008. During that same period, the S&P index has yet to return to its pre-recession value.”

It goes on to say, “…not all public SaaS companies have performed equally well. To be a standout in this space, growth needs to be greater than 25% per annum, and the market opportunity needs to be significant (e.g. CRM, ERP, HCM, etc).”

They claim that growth dominates over profitability for a couple of reasons. The first is that the SaaS market is still immature with only a third of the entire software market spend. The second is that these companies have been able to demonstrate significant profitability after sales and marketing spend is cut back.

I’m not sure I necessarily buy into this last statement because I’ve yet to see any high growth SaaS companies that have cut back on their sales and marketing spend in favor of profitability. In fact, I remember a few years ago speaking with Phill Robinson, the then-current CMO of Salesforce. His comment to me was that he had not reached a point of diminishing return from his investments in Google Adwords – and Salesforce has continued to invest heavily in sales and marketing – mostly “brand” marketing v demand marketing surprisingly.

Here is the chart that SaaS Capital showed with the relative performance of each of the 13 public SaaS companies.

So, it’s true for public SaaS companies but does high growth spell high valuations for private SaaS companies?

The answer is a resounding “yes”. In fact, even more so. For fast growing private SaaS companies, valuations have recently been over the top. In the public markets, the high multiple ranges but is about 10x-12x annual revenues.

In the private markets, a high growth SaaS company with “only” a 12x multiple could be a great deal for an investor. One of the companies I looked at last year had less than $5M in revenue but the pre-money valuation of the round when it was completed was in the mid $100M range – all because its YoY growth rate and its pipeline had grown so fast and it was in a very large and addressable market.

In contrast, a low growth SaaS company is in a precarious position. The authors of the SaaS Capital report cite a private SaaS company they have been working with that generated $11M in revenues and is profitable but only growing somewhere north of 10% per annum. The company was unable to find any interested strategic investors and is hoping to get a financial buyer to pay 1.5x revenue this year. If they do, I think they should consider themselves fortunate.

So, if you want a successful outcome for your SaaS business, by defnition it needs to generate high growth. To do that, you need the capital to invest in sales and marketing. And, as I have written about in previous blogs, in a high volume SaaS model, lead generation not sales capacity, fuels growth. This is one reason why I believe we haven’t seen any leading SaaS companies emerge that haven’t been venture backed at some point to fuel growth.

So, by definition, if you’re a SaaS company it’s incumbent upon you to find marketing personnel who are experts at lead generation. I know this is one of the critical hires in each one of my SaaS portfolio companies and it is becoming increasingly more difficult to attract this highly sought after talent.

Given the importance of lead generation for the SaaS model and company valuations, I suspect over the next few years, that marketers with proven lead generation skills in the SaaS market may see base + variable compensation on the same level as sales personnel.

According to the article, from $33M in 2009, GroupOn’s revenue virtually exploded in 2010 to $750M. From an employee base of 120 in 30 cities in 2009, the company now has 4,000 employees across 565 cities. Holy cow!

As I read the article, it reminded me of the significant challenges companies must deal with when faced   with explosive growth.  We were faced with a similar challenge at Siebel Systems in 1998 as we  had doubled from 1997 and we were preparing to double revenue the following year (from $418M to $800M). As it turned out, we doubled in 1998 ($813M) and we doubled again in 1999 to $1.7B.

While this is a high quality problem to have, the fact is this type of growth places enormous stress on executives, managers and employees. And, it is a problem that few executives/managers have personally had any experience with.

One of the issues we faced at Siebel was not only with external hiring, but also ensuring that our executives/managers could scale with the business. For example, people who may have been great first line managers were becoming second and/or third line managers in the course of a single year. Not everyone had that experience nor was everyone capable of making that type of transition.

To his credit, Tom Siebel realized that in order to “keep the wheels from coming off” (his words), we needed to put in place a hiring program that would ensure that employee 5,000 was as capable as employee 100. Additionally, we needed to ensure that managers who whose organizations were exploding internally, weren’t collapsing under the weight of new/different responsibilities.

We knew it was an impossible challenge to make perfect external hires and transition every manager from one level to the next. Therefore, we needed to put in place a process that ensured when we made a mistake and hired the wrong person or we identified that a manager was failing that we had a mechanism to quickly identify and rectify the situation.

We needed  a plan to hire several thousand people in a single year. This meant that people who we had hired within the past year would likely be responsible for hiring additional people within the year. These would be people who themselves had limited experience with our “Core Values” and/or our operating principles.

The opportunity to do this wrong and hire a lot of people who would be detrimental to our business was extremely high. This would cost us a lot up front and even more downstream with our customers, partners and shareholders.

To address the the critical challenge of talent acquisition, we put in place a recruiting and training function across the company. Working with HR, each senior executive was assigned a dedicated recruiter who helped to draft the job roles/specifications that aligned with employees who were currently viewed as successsful in their role within their groups.

We held “Super Saturdays”, where we would bring in dozens of candidates and have them interview with current employees and managers in an intense day long process. By the end of the day, we accumulated all the comments on each candidate from each interviewer and assessed whether or not we wanted to make an offer. For those candidates who made it through the process, HR generated an offer letter and the hiring manager met with the candidate at the end of the day and personally made the offer. It was  a long and exhausting day but we were able to make many great hires within a single day without impacting the business during normal business hours.

Then, in each group certain managers who had tenure with the companyand the organization, were tasked with creating a training curriculum that helped to train new employees. For example, in the Alliance organization, we took the dozens of recent MBAs we had recruited earlier in the year and put them through an indepth program where they were trained on how Siebel created and managed its alliances.

We operated a “boot camp” where newly-minted alliance managers learned the general policies of  Siebel Systems (e.g. Core Values) along with organization-specific issues such as the structure of the Siebel Alliance Program, how to write an alliance business plan, and how to work with other functions within Siebel Systems. At the end of the month long training each manager was tested and certified.

Similar training was performed in Product Management, Sales, Engineering, etc.

Consequently, new employees were able to quickly assimilate into the company and understand our Core Values, our policies, learn who were the key people in different functions across the company, how to work across the organization and how to work within their own organization.

In addition, we knew that not every employee – new or otherwise – was going to work out and as important as it was to bring on great people, it was equally important to be able to identify and remove people who were unable to contribute as we needed. To address this very real issue, we created an objective process.

Every employee at Siebel had a set of quantifiable and written objectives which were captured in an internal system we developed. Today, there are products like Rypple that will help companies capture and track their objectives/commitments. As a result of this process, every six months we stacked ranked every employee across the organization and we eliminated the bottom 5-10% performers.

I don’t claim this was a perfect process by any stretch – I don’t believe everyone liked/agreed with this approach or that mistakes weren’t made from time to time where we terminated or kept the wrong employee – but overall this program helped to quickly identify and resolve employee situations that weren’t working out.

Between these two programs, we were able to “keep the wheels on” even in our hyper growth days.

I think these ideas can even apply to companies that only need to make a few hires. Many times interviews take a back seat to the business and are stretched out far longer than necessary. From what I have seen, most start up companies are poorly prepared to execute quickly in this area. Interviews can be disjointed with candidates left wondering who they need to interview with next or where they stand. Offer letters take days/weeks.  

For high tech companies, people are our most precious asset. So, just as it is critical to have a world class development process, having an outstanding hiring process is critical to success.

For those key hires that could make/break a company and who are likely to be highly desirable by your competitors, putting in place a world class hiring process so they join your team vs. someone else’s could be the difference between your company becoming the market leader or an also ran.

So…ask yourself “how good is our hiring process?” Even if you aren’t in hyper growth, are the wheels coming off?

I thought it might be interesting to follow up that post with an interview with Jon Innes. Jon and I were colleagues at Siebel Systems and he has worked on enterprise software for Siebel and SAP as well as consumer software for companies such as Intuit and Symantec. He is currently a consultant who helps companies understand how to improve user experience. Jon is a member of UPA, HFES, and ACM CHI with a graduate degree in human factors psychology from New Mexico State and imminently qualified to discuss the impact and importance of UX/UI. He can be reached at info @ uxinnovation.com.

In this interview, I’ve asked Jon to focus primarily on back office enterprise application software, more commonly known as Enterprise Resource Planning (ERP) software. This is typically complex software that enables companies to “run the business” and covers major functions such as: accounting, billing, invoicing, order management, etc. Due to the complexity of these applications, UI/UX is especially critical but has traditionally taken a distant back seat to functionality.

Q. Jon, ERP applications are typically “mandatory” applications. That is, if you are an AP clerk or call center agent or a member of the Purchasing department you must use an ERP application to perform your function – you spend your entire day sitting at a keyboard staring at a monitor feeding data into an ERP system.  As a result, you would think that companies would be extremely focused on ensuring that workers were as productive as possible and that the UI/UX of the ERP software was as easy to use as possible. Why, then, is ERP UI/UX so challenging?

A. Actually Bruce, your question hints at the answer. “Mandatory” applications don’t have the same feedback loops of consumer products. The AP clerk is unlikely to be involved in selecting the system and has little input into the requirements and design process.

This is historically one of the key challenges in enterprise software. There are so many stakeholders involved compared to consumer products and each of them tends to have conflicting agendas. This is the real reason ERP systems are known for having poor UIs. It is not the UX professionals involved, or the lack of resources, but the nature of the problem itself. Think of all the different stakeholders associated with ERP systems and their influence on the design and purchase of ERP software:

Individual Users

The individual users are the accountants, call center representatives, sales personnel, and countless others who record transaction-oriented data into ERP systems. In cases of self-service-oriented purchasing or expense reporting software, it could include anyone who is required to do those tasks in the company, not just the individuals in the purchasing or procurement functions.

Unlike consumer software end users, they don’t have a say in purchase of ERP systems. They also don’t have a way of providing feedback to the vendors about user experience problems.

Functional Managers

The functional managers on the team perform specialized functions in the organization. Examples include managers of sales divisions and customer support organizations. It’s important to consider managers’ goals for ERP systems during design, such as providing consistent ways of combining sales forecasts, or tracking support issues. This extends beyond what the individuals do with the UI to how that work is coordinated and measured. Functional managers occasionally have limited input into purchase decisions at companies. Unfortunately, they almost never have a direct line of communication with vendors to discuss product enhancements.

Enterprise Executives

As the “E” in ERP implies, the systems are designed to serve enterprises and their executive management. Examples include aligning sales predictions with manufacturing plans or the related staffing and support budgets. ERP systems are designed to meet the needs of the executives who are the ultimate customers and decision makers regarding ERP purchasing. They have significant influence on ERP vendors, but typically this is channeled through individuals with IT responsibility, such as the CIO or CTO.

Unfortunately, enterprise executives rarely, if ever, actually use ERP systems. So while they hold the purse strings, letting executives select an ERP system is much like having your grandmother select your clothes for you (thanks granny, that’s lovely…)

Other Stakeholders

The other stakeholders include customers, business partners, and analysts that “guide” the customers of ERP systems. Ecosystem members have limited-to-no input in ERP purchase decisions. Analysts can significantly influence the decision makers, but rarely focus on user experience aspects of ERP.

Q. What are the other challenges beyond the feedback loop?

A. Another big factor contributing to poor ERP user experience is sheer complexity. ERP suites, which contain a broad range of functions, might have tens of thousands (if not hundreds of thousands), of pages or screens.

These screens are designed to be used in just a part of a company, such as the call center, accounting, or human resources department. As one would expect, the design reflect the philosophies of modern corporations. As such, ERP systems inherit both the strengths and weaknesses of this way of conducting business. One key weakness in both corporations and ERP suites is that their modularity makes them resistant to change.

ERP is software for corporations, designed by corporations. While this might sound like a good thing, consider that most large corporations suffer from poor cross-functional communications. This presents many barriers to good design. User-centered design depends on regular, rich interaction with users throughout the development process. Better feedback loops result in better designs. Unfortunately, insufficient feedback from the user (note the use of “user” and not “customer”) is the norm in enterprise software today. Frequent interaction with users required for design iterations are rare compared to that in more consumer-oriented companies.

Q. What key techniques to making things easy-to-use apply to ERP UI design?

A. One key factor is just simple iteration in the design process. The iterative design process for a package of soap at Proctor and Gamble is subject to much more user feedback than most ERP modules. However, the problem is also in reaching the end-user. The ERP ecosystem is fertile ground for what former Microsoft COO Robert J. Herbold calls “the fiefdom syndrome.” Many players in the ecosystem are solving for their own short-term interests. Here are some of the classic maladaptive behaviors:

• Most of us recognize that the end users of ERP systems would be the best source for many UI requirements, at least for streamlining existing work. Unfortunately, these users face the conflict that they are under pressure to get their primary job done. This makes them hard to engage in the design process, even if you can navigate the organizational barriers necessary to reach them at all.

• Managers of functional areas in large corporations often have limited recent hands-on experience with day-to-day transactional work. They are rarely the best source of information on how to design systems for their staff, but often they don’t realize this. These managers also don’t want day to day productivity of their teams impacted by IT initiatives like providing feedback on the design of ERP systems. Nor do they have the time or motivation to get involved in IT projects like ERP deployments; they simply aren’t rewarded for doing so.

• IT departments in companies typically want to own the requirements for their ERP systems. Unless they have training and experience conducting user-centric research methods, they may not have the skills to do this work, at least at the level of sophistication found in consumer product companies. Making it worse, they are often discouraged by managers of functional areas when they do attempt to conduct any requirements analyses with end users. All too often, IT staff gets rewarded for introducing new technology, but not evaluated based on the impact this technology has on worker productivity. The net result is that corporate IT departments can become more of a barrier than a facilitator in any efforts to gather user feedback to refine ERP systems.

• IT consulting and professional services firms want to position themselves as experts to their customers. Often this means they fail to fully analyze the needs of each customer in detail, relying instead on their expertise. Rarely do they admit the need to conduct any type of user-centered requirements analysis. Doing so would require billing the customer for learning requirements for the ERP system, something they want to claim expertise in. Even if they do propose a detailed requirements analysis effort incorporating usability feedback, and have a staff skilled in doing so, this adds to the cost of the “scoping phase” of the engagement, which means it rarely gets approved. When requirements applicable across customers are discovered, this is often seen as an opportunity to create “custom solutions” for which each new customer is billed, rather than suggesting these enhancements to vendors.

• Sales people at ERP vendors are rarely motivated to assist in engaging the customer in any deep level of requirements discussions. They are primarily motivated to close each deal quickly. Any ongoing discussions with customers are typically viewed as conflicting with sales goals. Sales people may also want to avoid any possibility that customers perceive the current product as deficient, because it may impact short term sales efforts.

• Professional Services teams that are part of ERP vendor organizations are typically motivated on a project-by-project basis to gather requirements. Unfortunately, they may also be motivated to keep this information to themselves since this knowledge makes them more valuable. They may also develop “custom solutions” which they reuse unknown to the customer or the product teams.

• Support organizations often have plenty of insight into what is not working with deployed products. Rarely are they consulted before a customer actually deploys the product. Typically, they are rewarded for “closing” an issue as quickly as possible. This often results in them not having time to participate in requirements gathering efforts. When they do identify product improvements, they often struggle to get improvements implemented, as these are typically seen by product management as less strategic than new functionality driven by marketing considerations.

• Product management often has limited customer interaction due to the influence of the previously mentioned organizations. Even if they have significant domain knowledge, it often becomes outdated and or is limited to experience at a single company, which may or may not represent the market as a whole. All too often, product management is incented to focus on feature enhancements rather than usability and simplification. Another problem that occasionally arises is that product management may want to “own” requirement decisions so much that they fail to facilitate an ongoing dialog between user experience specialists or product teams and the customers and end users. Even when motivated to do the right things, they may struggle to overcome the organizational barriers within both their own company and those of any customers they do try to engage with directly.

• Development teams may not work closely with any of the above organizations. They are typically incented to deliver new functionality as quickly as possible and have little say in extending deadlines to address quality or user experience issues. In some cases they may not even work closely with product management, due to pressure to focus on completing development tasks on current projects. Rarely do they track objective metrics on UX related quality so tradeoffs go unnoticed at most companies.

• Another contributing factor is the lack of shared vision on user experience or other best practices within vendor organizations. Due to the size of ERP projects, many vendors have specialized product teams focused on each functional module, working with limited oversight. This means modules created by teams often fail to integrate well, creating usability issues that impair efficient collaboration among a customer’s functional divisions and even design problems at the enterprise level. It also results in a new twist on the “it’s not my department” problem when it comes to the UI design.

• When a product team member in a vendor organization, a user experience advocate in the partner or customer ecosystem, or an industry analyst tries to work with others to resolve user experience issues, the functional separation makes this difficult.

The end result is that ERP systems often look like they were designed by developers using different requirements, instead of a consistent, unified system. Efforts within vendor companies, customers, and the ecosystem as a whole are often uncoordinated. Interacting with other stakeholders requires navigating an ecosystem filled with individuals and organizations that have conflicting priorities.

Q. Ok, so you’ve done a good job explaining how various stakeholders can negatively influence the ultimate UI/UX of ERP. But irrespective of stakeholder influence, why can’t ERP vendors make their applications look a lot more like a consumer application “out of the box” or in the case of a SaaS-based system, “out of the cloud”?

A. Well I think the good news is that SaaS solves part of the feedback loop problem. At least now the vendor of the ERP solution can tell if users are actually using it. In the past lots of money was spent on ERP that really didn’t get fully used. Kind of like that funky sweater or tie grandma bought you for Christmas. Now it’s like grandma lives next door, and she knows you never really wear those presents. That is of course if she’s paying any attention which brings me to my next point.

The other half of the problem is mindset. You’d be surprised at how much the old “through it over the wall” attitude still exists at many SaaS ERP providers. For the most part they still don’t have the kind of user-centered design process or UX metrics that folks at Apple, Yahoo or Google take for granted.

One of my clients who is a midsize SaaS provider in the ERP space has not run a single A/B (user research) test in almost 8 years of business. They have over 150 engineers and no full time UX staff. That would be unheard of in a consumer website company. Now days most early stage startups focused on consumer offerings hire dedicated UX staff and run tests like A/B studies long before they get series A funding or hire more than a dozen engineers.

Q. What are some things that companies can do to overcome the issues you’ve identified with poor UI/UX associated with ERP applications?

A. Test the usability of their products and fix the problems. According to research by Jeff Sauros (a former Intuit UX guy now at Oracle) “usability problems are almost ten-times more common on business applications than on websites. The ratio is around 2 to 1 for business applications and consumer software.” His tests use what we call CIF-style summative metrics in UX.

Ten years ago, the Common Industry Format (CIF) for usability tests was defined after corporations like Boeing and Allstate realized the hidden costs of unusable IT. However, almost ten years after CIF was ”adopted” as a standard, most IT organizations and industry analysts remain largely ignorant about CIF and related UX research methods, which can objectively measure if a product or service is easy to use. Salesforce.com probably does the best with this stuff, but even their level of effort lags behind a company like known for ease of use like Intuit.

This isn’t surprising. According to the Standish Group, only 40 percent of IT organizations measure the success of the systems they deploy in any way! ERP customers should be asking for usability data like CIF metrics, and analysts should be publishing reports discussing usability test data not just opinions. Executives in CTO/CIO roles should be asking vendors about data on the usability of the latest updates to their offerings. Industry analysts should start asking about this kind of data too, rather than acting as extensions of ERP marketing departments to push further investments in IT, ignoring the high failure rate of ERP projects.

Another step in the right direction, some vendors have started focusing more on ethnographic studies of enterprises that specifically focus on workgroup and enterprise level factors in addition to end-user ease of use. These have long been recognized in consumer product companies as key to creating usable products. Studies of this type take time and planning, but they provide especially valuable data for designing useful, usable ERP systems where they highlight designs that don’t support group or companywide collaboration well. I helped introduce these at Oracle as a designer in the ‘90s but upper management didn’t’ understand the value they provided.

Success looks something like this: CIOs start asking vendors why they haven’t seen data on the ease of use of systems at their company. CEOs of ERP vendors start paying more than lip service to ease of use and UX. Finally, VC’s should probably be asking for UX metrics when they start considering writing term sheets for ERP startups. Dave McClure and some of new UX savvy wave of early stage investors already do this when funding ventures like Mint.

When I originally started this blog, I did it as an experiment; I didn’t give a lot of thought about the long-term breadth of topics I wanted to cover beyond “Software as a Service” nor the blog’s overall positioning. I thought that if it garnered a few followers I would circle back and consider its “look and feel” and branding.

Well, after 2 years since starting there are now nearly 2,000 people who read this blog each month, so I consider it to be a successful experiment – especially given the fact I’m not some Hollywood celebrity such as Ashton Kucher who apparently has a ton of interesting and intelligent things to say/tweet. Consequently, I felt it was time to finally “circle back” and put some serious thought into branding/positioning/etc.

The first thing about my blog I wanted to change was the title, “SaaS and All Things Software”. I wanted to do this for several reasons. Over the past few years, SaaS has evolved into something a lot bigger – “Cloud Computing”. Cloud Computing includes DaaS, PaaS and IaaS as well as SaaS and I am involved in companies and technologies in all these areas and others. Second, I have many other comments I’d like to make that go beyond “SaaS and All Things Software” and I’d like the blog’s title/message to be broad enough to encompass those observations.

I chose the title, “Rolling Thunder” for two reasons. The first is that it ties into “Cloud Computing”; Thunder. Clouds. Duh. The second reason is that Rolling Thunder is a PR term meaning “continuous communications”. I thought that it fit nicely with the intent of the blog. So, that’s the rationale behind the name.

Based upon the recommendation from one of my partners at InterWest,  I decided to try and use crowdsourcing to come up with a new design. So, I signed up with Crowdspring. Crowdspring is one among a number of websites that features 10′s of thousands of designers (called “creatives”) who look for interesting projects (e.g. websites, blogs, stationery, logos, wedding themes, etc.) that are posted by ”non-creatives” (my term) like me.

After signing up, I created a project, described what I was looking for in a new blog design, and pointed the “creatives” to my existing blog for ideas. In the initial set up, I had to come up with an award amount for my design – it has to be at least $200. In this case, I chose $500 to make sure my project received enough attention.

In total, I recieved about 40 different designs to consider. I ended up selecting one design style from all the other entries. However, that was simply a design. I still had to have it converted into an actual WordPress Theme. This wasn’t within the designers skill sets so I took the design to the web programming firm we use (HyperArts) and had go through a few more design iterations as well as having them convert the design into an active WordPress theme.

Although the Crowdspring approach didn’t give me a “blog ready” result, had I gone the traditional route, I would have spent several thousand dollars in design fees and would have been restricted to just a single firm’s imagination and skills. With crowdsourcing, I had access to many designers and felt I received a lot of creative ideas that influenced the final design outcome.

I relied upon Crowdspring to handle all the financial details, etc. It made it relatively simple and straightforward. None of this would have been possible a few short years ago. Pretty amazing stuff. My only negative comment is that most of the designs submittted are simply repurposed stock art so you aren’t really getting anything “custom” — at least not for the $500 award I offered. But, you do get some creative uses/adaptations of stock art and for my purposes this worked fine.

With that, welcome to my “new and improved” blog. I look forward to interacting with all of you in 2011 and beyond on topics that include SaaS but will branch out to general observations on a variety of things I find interesting…and, hopefully, so will you.