“Yea…thanks for pointing that out,” I said as if I hadn’t already seen the article and been contemplating on how to boost my ratings for next year.

She said, “You need to post regularly if you’re going to win these things, you know.”

I said, “Thanks for the marketing advice.” Having adult children who aren’t afraid to point out your failings can be extremely annoying. I need to remember this the next time I look at revising the Will.

I had thought about making some sort of lame excuse about “being busy” but the truth be told I just haven’t felt compelled to write a new post until now.

When I first started this blog 5 years ago, I said I wasn’t going to post anything unless I felt I had something substantive to comment on. And, as I went back through the posts I have done, for the most part, I think I have lived up to this original commitment. Although, a few of you have pointed out that some of what I have had to say is “a waste of digital ink”. Unquote.

Still, I feel compelled to continue with the blog. You have to put yourself out there and risk the negative comments in order to learn from others. Not always pleasant but I think it’s worth the trade-off.

So, what compels me to write this post is to solicit feedback on a recent deal I’ve done — one of 3 which has kept me busy and not making blog posts.

The CEO of Biba is Carlin Wiegner. Carlin was also the CEO of CubeTree (a previous investment of mine) which was acquired by SuccessFactors in 2010. SuccessFactors was purchased by SAP and CubeTree has become the undercarriage of SAP’s social strategy and is now called Jam.

Carlin’s big idea, and it’s a bold one, is to build a Unified Communications as a Service (UCaaS) company — one that is built on top of AWS and uses an entirely different business model — that will enable people and companies to seamlessly move from a variety of communication services such as: conference calling, video, screen sharing, messaging and chat.

Today, if you want to collaborate/communicate, you must either purchase/use a variety of discrete services that are not unified, such as: Intercall for conference calling, Skype for video, Webex for screen sharing, etc. and as you move from one service to another you must set up an entirely new and different session. Or, you can invest in a Unified Communication (UC) system – such as MS Lync or Cisco Collaboration – and invest 10’s of $1,000’s – even $1M’s– in hardware, software and the personnel to run it — even then, many features of the UC system only work as long as each member of the session belong to the same company.

1. Market — This is a large and addressable market that has 2 large incumbents (Cisco and Microsoft) that have antiquated business models and architectures that are ripe for disruption. There are other providers of discrete services and these represent 10’s of $1B’s in market opportunity.

2. Team — Carlin is a fantastic product executive and has built several fantastic product teams and delivered commercially-successful products (e.g. Brightmail, CubeTree)

3. Technology — Biba is building a brand new technology stack (from VOIP codecs to cloud-based back-end server utilities) that could not have been produced even a few years ago.

The initial offering from Biba is focused on conference calling — other services will be added over time. The app is “free” and individuals can sign up themselves and invite others to use the service. However, getting individuals to use the service and then converting that usage into paid subscriptions from companies is a different matter.

This is a raw start up with zero credibility in corporations. Communications/collaboration isn’t something companies just turn to anyone to do. Communication vendors must demonstrate viability and reliability — “4 9’s” and “carrier-grade” are de rigueur.

So, my question to you is as follows:

If you were going to counsel the company on how to win corporations over (think about Box.net or Evernote — or Salesforce in their early days), what advice would you give to Carlin and his team?

The company – and I – have several ideas but I bet you may have some we haven’t thought of.

I have had the privilege of meeting with many early stage business software CEOs and teams over the past 5 years since moving from an operational role to an investing role.

Each of these teams is passionate about the products they are creating. However, many, in my personal opinion, share something in common that may prevent them from growing their companies as fast as they might otherwise.

Most are so intent on building their products for and then marketing/selling to daily practitioners they forget about creating a version of the product or a set of features in the product for the people who aren’t likely to use the product very often, or at all; the people who must approve the expenditure.

These are typically the CEOs, CFOs, CIOs and/or other senior executives.

This group may not necessarily appreciate the specific product features required by the personnel who will use the application/product on a regular basis but I believe it is critical to ensure that the product contain features that are directly applicable to them.

Without such features, it makes the initial sales process more difficult than it needs to be and – in the case of recurring/subscription business models – it puts the yearly decision for the company to continue to use the application and sign the contract up for unnecessary scrutiny.

Most of the people who sit in these approval roles are measured by and interested in key operational results of the business. Consequently, I believe there are 3 features every business application should contain:

The ability for key executives- or their staff – to set thresholds within your application that they consider to be KPIs (key performance indicators) and to have the application automatically notify them via email when those thresholds are met/unmet and the reasons why.

The ability to deliver graphs/charts that can be easily configured to identify and highlight critical elements of the business that your application helps operationalize.

Usage reports that can be delivered periodically that include user login statistics along with key operational results.

You want your application to touch key senior executives on a regular basis. That way, they are reminded about your company regularly (increasing your brand presence and importance) and realize that your application is providing their company with value. Without these fundamental application elements, you are in fact leaving it up to the skills of your daily practitioners to convey the value of the application(s) up the management chain.

While many may be quite good at doing this, others may not be quite as adept. As a result, in the case of software companies that use recurring revenue models, you are putting your annual contract renewal in the hands of lower-level personnel.

If you want supporting evidence of what I’m talking about, pick any start up and go to their website. While you are there, I am confident you will see comprehensive product feature overviews and use cases, etc. for daily practitioners. However, seldom will you find any discussion regarding product features for senior executives and/or material for the daily practitioner to “sell” their upper management on why they need your application.

So, if you build business application software, I would encourage you to look critically at your product and your website and ask yourself if you are really addressing everyone from the lower level practitioner who may need to use your product daily to the senior executive who may never use your products directly.

With a few relatively simple changes, you might help to accelerate your company’s revenue growth and decrease your churn rates.

I recently attended a Marketo seminar held at the Sofitel in Redwood City. The title of the seminar was “Silicon Valley Revenue Rockstars” and was replicated in a number of cities. The focus of the seminar was on how the role of Marketing is being transformed from primarily brand creation and management to a function that is held accountable for revenue production.

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.

I recently had the opportunity and pleasure to speak on a panel held at Oracle HQ in Redwood City, CA. It was a small conference – sponsored by Oracle – and attended by current Oracle ISVs to discuss the issues of converting and/or building a SaaS business. The panel was moderated by Kevin Dobbs with Montclair Advisors .

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:

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.

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 wrote about the dearth of innovation within large companies a couple years ago but I didn’t post anything in this blog on the topic. Based upon a number of conversations I’ve had lately, I thought I would dust off and update what I’d said previously and reintroduce the idea here.

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.

Strategic projects that might not be funded because they are below the line are able to get funded.

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.

The parent company is able to effectively retain key personnel by enabling them to exercise their entrepreneurial spirit.

The “spin in” company retains some of the parent company ‘DNA’ so cultural issues that affect most acquisitions are minimized.

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.

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.