SaaS Business Architecture & Revenue Modeling

Little did we know when we published the "Reality of Freemium in SaaS" (PDF) report in early January 2010, it would hit such a nerve with the industry. In fact, you know we hit a nerve when I've been asked to speak at the Freemium Summit on February 26, 2010 in San Francisco, California to "bring a different view" to the mix.

Aside from being asked to speak at the Freemium Summit, the paper has been mentioned or used in a number of places...

Articles that used the paper as a jumping off point or looked at different aspects of it:

• "Why Freemium is Bad for Business" on ZDNet by Phil Wainewright
• Study: SaaS Pricing Is Still Opaque And Freemium Is Rare on ReadWriteWeb
• Justin Pirie's This Week in SaaS #10 - Interview w/ Lincoln Murphy about Freemium paper
• "Rethink Your SaaS Channel Strategies" on Sandhill.com - Looks at the Channels / Distribution angle
• "Users or Abusers" on PPM Today - looks at Users vs. Customers

Articles that used the paper to educate their customers or readers on the different aspects of Freemium:

• "SaaS Reality Check: Freemium is NOT a Business Model" on Under The Radar blog by Dealmaker Media
• "No Such Thing as a Free Lunch" on the Rackspace blog
• "Freemium Paper by Lincoln Murphy of Sixteen Ventures" on the Chargify blog
• This Week in SaaS for IT Management

The Best Feedback

While we had some great coverage, the best feedback has been from the readers directly. Some people chose to contact us privately via email while others chose to leave passionate comments in support of Freemium on the blogs. Passionate reactions means that we definitely hit a nerve!

The best feedback, and the thing that makes writing this paper worth it, was from founders or companies directly who had the following to say:

Executive from existing B2B SaaS company:

"...it is even causing me to rethink our Freemium strategy. The low conversion rate [common in the industry] blows me away. Something I knew, but until I saw it substantiated, I thought I was doing something wrong."

Startup founder:

"I've read your article and it was an eye opener for me in many ways. I'm currently working on [an application], which is designated to be distributed as a Freemium at least in the beginning. Now, your insights are making me reconsider many of my basic assumptions, which is a good thing to do when the project is still at early stage. So here are my thanks for your excellent work!"

Startup founder:

"I'm about to start a start-up targeting small and medium-sized financial institutions. Just wanted to drop you a note, thanking you for your paper on Freemium. [...] In my case, it helped me see that I would be using Freemium as a crutch to avoid having to sell (I am a technologist by background), and that providing services to users would be a potentially fatal distraction from acquiring and servicing customers."

Startup founder:

"I thought it was spot on, and reinforced my gut feeling that fremium is a waste of time, effort, and money for us. If you've solved a thorny business problem, then not charging for it will just lead to suspicion, plus your competitors are charging for their shitty legacy software. No business person is going to invest the time to configure your software if you think it's worth giving away for free."

Attorney that works with early-stage SaaS Vendors:

"This is a great reality check on the growing enthusiasm for the Freemium model. I think you put the analytical focus exactly where it should be: what's the quid pro quo? I'll definitely be employing your insights when we counsel our SaaS clients on pricing alternatives in their SaaS contracts"

These are the reasons this paper was written, not for all of the coverage (who would have expected a 23 page paper to go viral?) Even if the people that wrote to us or commented on the blogs do not do anything different, at least we got them and the industry to collectively re-address their business decisions. We really might have saved a company from failure and for that, writing this paper was the right thing to do.

Author: Lincoln Murphy (You should follow me on Twitter)

In 2009 we published our “7 SaaS Revenue Streams” (PDF) report and it has become the most viewed publication we've produced to date. The reason for its popularity? No one had ever broken down and detailed all of the possible revenue streams available to a SaaS company like this. We thought we were doing great work, and it turns out we were! The feedback has been incredible and you should certainly check it out.

However, what we didn’t count on is Freemium being so popular, that here we are talking about seven revenue streams while a segment of the industry is buzzing about giving stuff away for free. I suspect this new publication, titled "The Reality of Freemium in SaaS," will quickly surpass the "7 SaaS Revenue Streams" publication in views.

As always, your feedback is requested and appreciated.

UPDATE: Download the PDF of the paper directly.

The Reality of Freemium in SaaS

Author: Lincoln Murphy (You should follow me on Twitter @lincolnmurphy)

If you are a SaaS vendor, or would like to be one, you should attend SaaS University right here in the backyard of Sixteen Ventures: Dallas, Texas. The event is January 26-28, 2010 and will be packed with SaaS experts from around the world. With over 30 sessions, this event provides the best opportunity to learn, share, and more importantly network with those that are out there making it happen in the SaaS world.

SaaS University really is a fantastic event. Sixteen Ventures participated in July 2009 at the event in Chicago and we are proud to be a part of this one, too. The attendees in Chicago ranged from pre-launch startups to Fortune 100 companies repositioning legacy software, and they all had the same goal; to be successful with their Software-as-a-Service offering. At the event in Chicago, the sessions were actually educational and the attendees were very serious about learning. Dallas will not be any different!

Sign up today to receive early bird pricing (good through December 21, 2009) and get an additional $100 off with the code SIXTEEN100. We don't get anything from this (no kick backs!) except a larger crowd of folks to present to. Speaking of which, I will be presenting on the following topic:

Monetizing Multi-Tenancy - Generating Revenue through Network Effect Data and the SaaS Ecosystem

Multi-tenancy is a key element of Software-as-a-Service (SaaS); but not for the reasons you think! Achieving economies of scale, streamlining software development, maintaining one line of source code, etc. are the widest-known benefits of multi-tenancy. The real magic happens when multi-tenancy is leveraged to unlock and enhance the Network Effect created by all customers using the same system. And when the Network Effect is itself leveraged by the Ecosystem, myriad opportunities present themselves to drive growth and revenue. These are what makes being a SaaS vendor so much better than being a Legacy Software vendor!

Hope to see you in Dallas at SaaS University!

Author: Lincoln Murphy (you should follow me on Twitter)

When I find articles that I think are useful to my followers on Twitter, I always post them. Here are the ones from the time period of 11/9/2009 - 11/20/2009. To get these in real-time, you should follow me on Twitter.

SaaS

Article says credit card acquirers excited about SaaS due to recurring revenue http://j.mp/3i3Sbg #saas #revenue

New post by @eliasbiz (/via @sundelin) "The business model of APIs" http://j.mp/Iacb4 #saas #api

New post "Updated - Introducing the 7 SaaS Revenue Streams" http://j.mp/46n8qb #saas

The 7 SaaS Revenue Streams detailed report has been updated. Check your email (or sign-up here http://j.mp/sjwm8) #saas

Great post by @justinpirie about the top questions ISV’s are asking themselves about SaaS http://j.mp/1G5HtH #saas

Posted slides from "Think You're Ready For SaaS? Think Again!" http://j.mp/4ek6Fz #saas #startups

New article by @heinzmarketing & Dave Chase "10 Laws for SaaS Sales & Marketing Success" http://j.mp/2mSrbF #saas

Notes from the Goldman Sachs Cloud Computing Conference by @esimoudis http://j.mp/2kXgRI #cloud #saas

New post by Dani Shomron "SLA Management in SaaS" http://j.mp/4bcR5L #saas

Latest post by Peter Cohen: "Make Renewals Easy" http://j.mp/3E9S31 #saas #revenue

Your data is safer in the cloud than you think http://j.mp/1oG6W3 /via @infoworld @jamesurquhart @dcunni @DavidLinthicum

BVP released latest "Top 10 Laws of Cloud Computing and SaaS" http://j.mp/2mZ6ep (PDF!) /via @justinpirie #saas

Revenue Cycle Management / Pricing

New post by @StartupCFO "Usage-based billing models" http://j.mp/7lKB1A #saas #billing #pricing #revenue

RT @mimiran: cell phone pricing maximizes recurring monthly $ @NYTimesComm Method in Cellphone Madness? http://j.mp/12BOyy #pricing

Revenue model changes in legal profession "Will a new model kiss the billable hour goodbye?" http://j.mp/C3p21 #revenue

We can all learn from this: "New revenue streams help restaurateurs retain valued staff" http://j.mp/2crObk #revenue

New post by @adventurista "Measuring churn for recurring revenue businesses" http://j.mp/2ngXqC #saas #revenue

RT @pricing Remember, you are not Walmart, Target or Amazon - RT @Mimiran WalMart expands price war to DVDs. http://bit.ly/2waYpB <+1

New post by @Recurly "Preventing Chargebacks" http://j.mp/3ldJ2i #billing #saas

Product Development / Marketing

A short but sweet gem on Seth's Blog "The reason they want you to fit in..." http://j.mp/4f5ZHo

Killer post by @ashmaurya "How I am Measuring Product/Market Fit" http://j.mp/8CS3K <-- inc. A/B testing on #pricing

Great new post by @sehlhorst "Can You Write Website Requirements Without a Product Manager?" http://j.mp/3awHAG

Great post by @sundelin "Business models turning products into platforms" http://j.mp/2Ni5LI

Good post by @RichieBlueEyes "It’s all in distribution Baby" http://j.mp/42bzWn

Great post: @daniel_jacobson on @programmableweb "Content Portability: Building an API is Not Enough" http://j.mp/1WC3AN

Great post by @ashmaurya "Achieving and Measuring Product/Market Fit" http://j.mp/3sa2UL

Investment / Venture Capital / Startups

Post by @jasonmendelson "Why Don’t Venture Capitalists Tell You Why They Won’t Invest?" http://j.mp/nbfZm #vc #startups

Great post on Seth's blog "Embracing lifetime value" http://j.mp/85e0L8

New post by @fdestin: "How a great entrepreneur deals with complexity" http://j.mp/54Orzd #startups

New post by @markpeterdavis "Signs That Your Team Might Be Deterring Investors" http://j.mp/1uweRH #vc #startups

New @austinventures “Entrepreneur Hours” announced; in DFW on 2/23/2010 http://j.mp/1at3Ys #vc #dfw #startups

New post by @privateequiteer w/ some good links "The viability of bootstrapping a business" http://j.mp/16Yysd #startups

Another great post by @sgblank “Lessons Learned – A New Type of Venture Capital Pitch" http://j.mp/3hn1u5 #vc #startups

Stanford's Entrepreneurship Corner w/ @sgblank: Fall 2009 Qrtr Roundup: What Did We Learn? http://j.mp/28Wmmu #startups

New post on @venturebeat "4 MORE ways to get automatically rejected by an angel investor" http://j.mp/DiqN9 #vc #startups

Author: Lincoln Murphy

Here are the slides from the class I did last week for SoftwareCEO titled "Think You're Ready for SaaS? Think Again!" While the slides cover the 9 Misconceptions of SaaS that should be avoided, ultimately, this was a part of a 1.5 hour presentation and the slides were used simply to "support my narrative" as one reviewer said. This is true, I'm a minimalist when it come to slides that accompany a presentation. The slides help tell the story; they aren't the story themselves. 

Whenever I find articles that I think are useful to my followers on Twitter, I always post them. Here are the ones from the week of 11/2/2009 - 11/6/2009. To get these in real-time, you should follow me on Twitter.

SaaS

Fantastic new post by @devcorporate "SaaS Company Valuation Trends" http://j.mp/2pdJcU #saas

Seeing lots of folks at BIG, legacy cos. download the "Detailed Report on the 7 SaaS Revenue Streams" PDF lately: http://j.mp/sjwm8 #saas

Great post from @ashmaurya "From Minimum Viable Product to Building A Landing Page" http://bit.ly/16FoCD #saas

RT @ghaff: RT @vtri: Nice slide deck on SaaS & tenancy models by @progressSW (http://bit.ly/1cgbup). << Agreed nice overview/model < +1

Pricing

RT @pricing: [Upated] Pricing Observer Post - Network Solutions - Domain Name Purchase Process - http://post.ly/BsCZ

In-depth post by @greggerca "When Licensing Metrics Must Change" http://j.mp/cWaj9 #pricing

New post from @venturedig "Monetizing Social Networks: The Four Dominant Business Models" http://j.mp/ysMc8 #pricing

New post from @ppolsinelli "Pricing an online service" http://bit.ly/GVrTH #saas #pricing

"Will the Customer w/ High Willingness To Pay Please Step Forward" http://j.mp/3CGGcA (via @pricing & @bouldernet)

Great post by @skap5 "Discounting Madness" http://j.mp/1qwKxX #pricing

Marketing

Great post by @scottdolson1 "Yes, your product is differentiated … so what?" http://j.mp/4B9RiH

Thoughtful post on "Revenue Journal" by @KristinZhivago "The Art of Liftoff" http://j.mp/3TjobF

New post from @williamtincup "Editorial Calendars: Get Ready For The Year Ahead" http://j.mp/27OmZY <-- you must follow this guy, HR or not!

Investment / Venture Capital / Startups

New post on @pehub "VCs: Thousands Of Companies Will Exit Next Year…" http://j.mp/2vnagE #vc #saas

Great post by @albertwenger "Don't Let the Funky Math of Convertibles Bite You" http://j.mp/457Wxq #vc

Great post by @giffconstable "Free financial model for freemium tech startup business" http://j.mp/9gi8p #startups

New post from @bernardlunn "Bits of Destruction Hit the Venture Capital Business" http://j.mp/2JaFXI #vc #startups

Great new post by @msuster "Are Business Plans Still Necessary?" http://j.mp/37EAuh #startups #vc

Great VC perspective from @pjozefak: "It's Not About Paychecks. It's About Equity!" http://j.mp/yn8O6 #startups #vc

Another amazing post by @sgblank: "Raising Money Using Customer Development" http://j.mp/1h4u3u #startups #vc

Great post by @venturebeat "4 ways to get automatically rejected by an angel investor" http://j.mp/2avbAK

Starting to see the 7 Revenue Streams appear in SaaS business plans... very cool... http://j.mp/2yZ7l #saas #startups

Great post by @bijan "Exit Strategy" http://j.mp/8duFE <-- build real valuable biz; exit might not be what/when you want!

Awesome post by @sgblank "Lean Startups aren’t Cheap Startups" http://j.mp/4l9ZBQ

Author: Lincoln Murphy

After publishing our updated SaaS Business Architecture and Seven SaaS Revenue Streams slide decks, people have asked if those principals apply to other cloud services or just SaaS? The answer is, of course they do. Some clarification is required on what "cloud" is in this context:

Cloud Computing is most often comprised of three as-a-Service acronyms:

• SaaS - Software-as-a-Service
• PaaS - Platform-as-a-Service
• IaaS - Infrastructure-as-a-Service

There are others that have tried to leverage the "as-a-Service" moniker (Storage, Identity, etc.) but ultimately they fall into one of those three categories. 

The definition of the SaaS Business Architecture, in case you missed it before, is:

...a Network-Centric commingling of Marketing, Intellectual Property, Technology, and Business Model.

One key element of this definition of SaaS is found in the Technology portion of the Business Architecture: Multi-Tenancy. The inclusion of Multi-Tenancy is why this definition is specifically SaaS and not "cloud." It could, however, just as easily be the PaaS Business Architecture or the IaaS Business Architecture. 

Unfortunately, cloud is too broad and includes elements that are *not* multi-tenant (including private clouds, ASP, virtual appliances, etc.). Network-centricity without Multi-tenancy is not a scalable business architecture and the number of ways to monetize is reduced dramatically.

Its easy to see how the Seven Revenue Streams can be available to a SaaS vendor, because the context is easy to see. SaaS offerings can be very specific to a niche or vertical, they have a well-defined GUI making it easier to understand the value to the market, etc. As you move away from what we think of as SaaS applications and go "down the stack" a bit, the opportunities for additional revenue streams becomes a bit harder to discern. This is not only due to the lack of a presentation layer, but also by the widening horizontal nature of the offering.

Of particular interest to me due to my Supply Chain Management background are companies that have an offering that sits somewhere between PaaS and SaaS; pure ecosystem or proxy plays like:

• System Integration
• API proxies
• Data Aggregation
• EDI/EC

These are vendors who have a single-instance, network-centric, multi-tenant, web-native environment, but because they don't have a substantial UI, its harder to see (actually visualize) the opportunities. Yet, these plays have some of the best Ecosystem and Network Effect revenue model options of any vendors out there.

As you move down the stack to PaaS and IaaS offerings, the revenue streams are just as relevant, but even less obvious. With SaaS, for example, the data that can be aggregated anonymously and leveraged in the form of reports or benchmarking is a bit more obvious. How a PaaS or IaaS vendor can leverage these revenue opportunities ultimately depends upon where in the stack they sit and what the underlying architecture of the offering supports. For instance, a PaaS with shared data fields where a tenant application is really just an extension of the core application will have more context at the Network Effect Data level than a PaaS that is a more of an abstraction layer of the underlying infrastructure for host applications.

At the lower levels of the stack, the information that is relevant between tenants will be less coherent, but it will be there; the opportunities will present themselves when you look with the right context. Perhaps that data cannot be monetized directly, but it can certainly be leveraged to drive other revenue-generating initiatives, better customer service, etc.

Regardless of whether you are SaaS, PaaS, IaaS, or somewhere in between, if you need help with your revenue modeling or business architecture, give us a call at (972) 200-9317 or use our contact form.

Author: Lincoln Murphy (You should follow me on Twitter!)

This is updated definition of the SaaS Business Architecture. I added a key element to the one-line definition:

The SaaS Business Architecture is a Network-Centric commingling of Marketing, Intellectual Property, Technology, and Business Model.

Note the inclusion of "Network-Centric" in this update. In the presentation embedded below this theme is expanded upon as it is core to the nature of SaaS. As always, your feedback is welcome and encouraged.

UPDATE: Ultimately this is a teaser (though potentially game-changing on its own). If you want the full, in-depth version that goes into each of the revenue streams in detail, click here and all it'll cost you an email address or a tweet. Plus, we'll keep you updated whenever a new draft is released.

Do you need help applying the SaaS Business Architecture to your business? Do you want to "switch" to SaaS or enter the market with a SaaS product but are unsure how the SaaS Business Architecture applies to you? If so, give us a call at (972) 200-9317 or use our contact form.

Author: Lincoln Murphy (you should follow me on Twitter!)

First of all, lets be very clear: its not exploitation and the revenue streams are not hidden. Network Effect Data (data exhaust, aggregate application data, etc.) is based on the position of the SaaS vendor as a proxy in a multi-tenant environment and the value that is created by the network effect data can be quite significant when leveraged correctly; both for the vendor and the ecosystem.

Regarding Network Effect Data, as a SaaS vendor, you should:

1. Make sure your User Agreement is up-to-date and is clear about your intentions (see your legal department)
2. Anonymize the data before leveraging it in aggregate
3. Leverage the information as soon as it becomes actionable
4. Understand that this is part of the trade-off that you get for managing infrastructure and operational burden for the clients
5. Add value to the ecosystem when you leverage Network Effect Data

I realize that journalists or analysts that attack SaaS vendors for "exploiting" Network Effect Data get hits when they spread FUD. I do feel that I have to defend the rights of the SaaS vendor from the negative attacks. I also need to remind my clients, readers, and followers that these folks are just spreading FUD and that leveraging, not exploiting, Network Effect Data, is potentially a critical piece of the value derived from being a SaaS vendor. Finally, I need to remind the users of SaaS that a credible, trustworthy vendor will leverage the Network Effect Data in a way that provides value to you in a way you could never have expected from Legacy Software.

The problem with Network Effect Data is that, just like SaaS itself, it is mis-understood. For example, too many SaaS vendors consider the de facto revenue model in SaaS to be monthly subscriptions, which is not only untrue, but limits the potential of the SaaS vendor substantially. In that same vein, most people think of "selling aggregate data" by a SaaS vendor as some sort of nefarious dumping of client-spefiic data to the highest bidder in a back-alley transaction. That is either an antiquated view, one that exemplifies the naivete of the author, or worse...

It is not only common practice, but highly accepted, to leverage Network Effect Data in these functional areas and market verticals:

• Supply Chain Management
• Financial / Banking / Credit Reporting
• Healthcare
• Entertainment (Music, Movies, TV, etc.)
• Retail

Note the inclusion of Healthcare in there; an industry with tight privacy laws (not just industry suggestions, but laws).  All of these industries have been trading in data like this for years. The vendor needs to ensure they comply with the proper laws and industry governance and make the right ethical decisions, but anyone who makes a blanket statement that leveraging network effect data by a SaaS vendor is "exploitative" or otherwise inappropriate is simply trying to stir the pot by being "edgy" or is, even worse, incented to spread FUD.

Unfortunately, most SaaS vendors do not consider leveraging Network Effect Data as a viable revenue stream, mostly because they do not understand what they have at their fingertips. This means they often fail to build into their system adequate data capture methods which prevents them from leveraging network effect data in any meaningful way. If they don't capture data in the right way, even if they do realize what they have later, they will have missed out on all of the data up to that point and will have to re-architect the system for improved data capture. These are things that need to be considered during the early phases of product development, even if you won't be able to fully monetize for a long time.

In fact, how long it will take to get to a point where you can derive revenue from Network Effect Data is something that is 100% unique to your business. We leverage our proprietary SaaS Revenue Matrix with our clients to get past the false notion of "critical mass" for Network Effect Data value.

Do you need help "exploiting" your Network Effect Data to drive revenue or want to figure out now when it would make sense to do so? Do you need guidance on how to capture data effectively so you can leverage it in the future?  If so, give us a call at (972) 200-9317 or use our contact form.

Author: Lincoln Murphy (You should follow me on Twitter!)

For the vendor, Software-as-a-Service (SaaS) is about rules, not exceptions. Exceptions aren't scalable.  For business scalability, you must shift focus to automated, repeatable processes. For pure-play SaaS startups, this isn't as big of deal since they are likely starting with a clean slate. For those "switching" from the legacy software model or branching out from a non-software company by exposing internal processes, products, or expertise to the market via SaaS, this can be a big challenge.

Whereas much of your current revenue might come from professional services, other one-off services, customizations, etc., if you draw the line in the sand and say "we are a SaaS vendor", then you need to do whatever it takes to derive most of your revenue from the rules, and not the exceptions. The rules are the scalable revenue streams, and the exceptions are not. To do this requires you to identify and clearly delineate the revenue streams available to you (there are 7 total) and to architect your business, including the underlying software, to drive toward the scalable revenue streams.

This could also require you to completely change your business and operating environment (the technology is the easy part); are you ready? We can help you determine if you are ready for SaaS, and if so, how to execute the switch to the SaaS Business Architecture and ensure your Revenue Model is optimized once you get there. Call us today at (972) 200-9317 or contact us through other channels.

Author: Lincoln Murphy (You should follow me on Twitter!)

Network Effect Data, Data Exhaust, the side-effect of network-centric computing... who cares? Intuit, apparently, as they just agreed to pay $170M in cash for Mint.com, a company who's entire business model is built around network-effect data. I have no visibility into Mint or Intuit on this deal, but I can only imagine that the real value was found in the user base, its accumulated data and its unique use of that data, and not so much in the software that "powers" the site itself or even the team. I could be wrong, but this seems like an Aggregate Data play more than anything.

So, if you don't get the value of network effect data or don't want to acknowledge how powerful collecting, analyzing, and leveraging aggregate information from users within your Software-as-a-Service (SaaS) application can be, then avert your eyes from the Intuit/Mint deal... move along, nothing to see here. For those that want to derive as much revenue from your SaaS offering as possible, however, let the Intuit/Mint deal be your inspiration. 

I've talked to VCs that say some of their SaaS portfolio companies are worth more for the data they collect than they are for their IP, software, infrastructure, etc. Too many, however, don't know how to properly leverage it. 

If you need additional help identifying all of the ways you can optimize your revenue model, and help drive up potential valuations due to these improved revenue models, including efficiently collecting and leveraging network effect data, give us a call... (972) 200-9317 or contact us today.

Author: Lincoln Murphy (You should follow me on Twitter!)

There are some very important conversations taking place around the blogosphere on the subject of Business Continuity and SaaS. I've commented on many of the posts, often multiple times, to share my opinions and learn from others. I wanted to put together a list of the blogs maintaining these conversations (below) and encourage others to participate.

As I said in some of the comments I've made, large SaaS vendors have already solved the issue of Business Continuity. Where the problem lies is with small SaaS vendors that cannot effectively "self insure" against failure. Until a third-party steps up with something that is aligned not only with the SaaS vendors (someone who understands completely the unique SaaS Business Architecture) and even more importantly aligned with their clients, small and medium-sized SaaS vendors will have trouble with how to solve this problem.

The subject of Business Continuity, remember, is not for the SaaS Vendor, but for their clients; the end-users. For Software-as-a-Service to be taken seriously, these issues must be talked about and ultimately solved. Too often, the risks associated with SaaS are overblown by Legacy Software vendors spreading FUD (Fear, Uncertainty, and Doubt) about SaaS. Security risks, availability, etc. For the most part, the FUD they spew is just anti-SaaS rhetoric since they missed the SaaS boat and are now trying to play catch-up. In many cases, its just a stalling mechanism to keep people from adopting their competitors SaaS products until they can release their (poorly executed?) SaaS "version." When that happens, mysteriously, the SaaS FUD disappears.

The problem is, that there are some issues that need to be dealt with, and Business Continuity is one of them. We could opt not to "air our dirty laundry" and those of us in the "SaaS business" could defend to no end that anything negative about SaaS is just FUD, but the truth is somewhere in the middle. 

My motivation to continue these conversations is two-fold:

1) Get to a point where all FUD from Legacy Software vendors or other anti-SaaS folks is easily defended against by SaaS vendors of *all* sizes and stages. 

2) Stop legacy escrow companies or other legacy vendors, ASP vendors, etc. from capitalizing on either SaaS's potential problems (on the ultra-rare occasion a vendor will fail) and/or the fast growing popularity of SaaS by associating their decidedly non-SaaS products with Software-as-a-Service.

Read on, and most importantly, participate!

• Post by @benkepes on Cloud Avenue "SaaS Certainty - Escrow is the Answer"
• Post by @fscavo on his blog: "SaaS contingency plans need more than software escrow"

Author: Lincoln Murphy (you should follow me on Twitter)

This is a work in progress that sets out to define the Software-as-a-Service (SaaS) Business Architecture. I wanted to release something now, even if it is an early version without much detail just to get it out to the world. I welcome input, but caution those commenting to temper their biases. Legacy software vendors, Open Source consulting companies, Virtualization vendors, and SaaS framework vendors are more than welcome to post, in fact, I encourage it. 

However, please comment in the context of an open-minded discussion not from the angle of  "we want to call ourselves SaaS and will defend the fact that our model is SaaS to keep that right." You can call your product whatever you want, even SaaS, if you would like to. The purpose of this definition is to define publicly what we at Sixteen Ventures have put together for our clients based on what we feel to be the most scalable (at a business level) and sustainable model.

Author: Lincoln Murphy (you should follow me on Twitter!)

Please use the comments below, or reply to me on Twitter, to share companies that you know of that have made the move from Legacy Software (On-Premises, Deployed, Behind the firewall, etc.) or even ASP to pure, Multi-Tenant SaaS.

A few of the larger ones we already know, like Boomi, Ultimate Software, etc. But what I am looking for is a more comprehensive list that contains the small, niche vendors that took their product and "switched" to SaaS. Of course, large companies are welcome on the list, too.

Once we have collected enough company names, I'll put them together in a comprehensive list, publish it here and give credit to those who contributed.

UPDATE: This is obviously an opportunity for you to promote your company, and that is fine... if you have successfully moved from a Legacy Software model to SaaS... if you haven't, please don't post a comment. If you are unsure what "multi-tenant SaaS" means, please look over this website in more depth.

Alright, lets go...

Author: Lincoln Murphy (you should follow me on Twitter)

As a follow-on to my SaaS University presentation "Multi-Tenancy in SaaS: The Business Case" we have put together a webinar with some industry insiders. In addition to me representing Sixteen Ventures, Mike Dunham from Scio Consulting, and Rick Chapman of Softletter will be on the panel. Jeremy Beck of Scio will be the moderator. 

The idea behind this webinar is to dig a little deeper than I did in Chicago to get to the implementation level of Multi-Tenancy and its various incarnations. I will be speaking on the business implications of each level of tenancy. 

Specifically I will be speaking on:

- Overview of SaaS Business Architecture

- Why the level of Tenancy per Instance matters at the Business Level

- Business Scalability and Multi-Tenancy

- Missed Revenue Opportunities when not fully Multi-Tenant

With Rick from Softletter on the webinar, this should make for a very exciting and lively discussion. I hope you can join us. 

You should reserve your spot today!

Thursday, July 16, 2009

12:00 PM - 1:00 PM CDT

Multi-Tenancy Alternatives: Selecting the Best Option for Your Software Business

Software-as-a-Service (SaaS) is becoming mainstream but getting it right can be the key to survival.  From the single instance ASP-model to virtualization to pure multi-tenant SaaS, this webinar will cover the business implications and technical alternatives to multi-tenancy for your web based software products.

Who should attend: Software executives and product managers working on SaaS offerings

Overview:

The business value of Multi-Tenancy in SaaS is no longer up for debate, but the implementation methods still are. Join Scio Consulting and Sixteen Ventures as we explore the topic of Multi-Tenancy in more detail at the implementation level and learn the business implications of each implementation method.

In this informative webinar, we will cover the following Multi-Tenant implementations:

- "ASP" model - Single Instance, Single Tenant

- Virtualization Solutions

- Single Instance, Unique DB per Tenant

- Single Instance, Multi-tenant DB, Unique Schema per Tenant

- Single Instance, Multi-tenant DB (One Schema for All Tenants)

You will learn the advantages, disadvantages, and business implications of each method as well as get recommendations by the experts at Scio Consulting and Sixteen Ventures on when one is preferred over the others.

You should reserve your spot today!

Author: Lincoln Murphy

Do you have a question you would like answered regarding the Business Case for Multi-Tenancy in SaaS? Post them in the comments. I will answer the questions at SaaS University first and post the answers on this blog after the event. 

While you will see the answers in a blog post after the event, it won't be the same. You will miss out on the discussion surrounding the questions by not attending SaaS University. If you would like to attend, there is still time, and I have a discount code for you... just contact me.

Author: Lincoln Murphy

I just saw an interesting post by Phil Wainewright on the eBiz site titled "Why Bother with Multi-Tenancy?" In fact, it's great for someone like Phil, as an analyst with a great public podium, to tackle these issues that are not the most visible issues in SaaS. I welcome a public discussion on this topic as it is what we and our partners have been preaching to our clients for years. We have been consulting with our SaaS Vendor clients for a long time to take advantage of the revenue streams beyond the core application; to take full advantage of being a SaaS Vendor. In fact, quite often the network-effect data that is collected from the application is more valuable and can be monetized in more ways than the application itself.

What is disconcerting, however, is that Phil cited a story by Zoli Erdos at CloudAve (who cited a compelling post by Dennis Howlett) that talks about "The Hidden Business Model in SaaS" as if it's something Vendors are keeping from their customers. At first Zoli talks about eyebrow-raising concerns over privacy in selling anonymous, aggregate information. The reality is that many non-SaaS businesses have been doing this for years; we tell people that this is currently being done with incredibly sensitive data. From the credit reporting agencies to hospitals, anonymized, aggregated (A/A) data is leveraged from multi-tenant environments every day and is completely safe and compliant (HIPAA, etc.). You have to know your industry and your governance issues, but it can be done.

Ken Boasso, a long-time friend and Managing Director of Keychain Logic, a Sixteen Ventures partner, likes to point out other examples when he talks about this subject. For instance the Dow Jones Industrial Average is merely anonymized aggregate (and often highly personal) financial data. Credit card fees are set based on A/A data, as are anything having to do with insurance premiums; including specific health risk information that drives the costs and coverage for prescription medicines. The list goes on and on, and the key take-away is that SaaS or not, A/A information is leveraged by many types of companies to generate revenue, to make internal decisions, and to offer guidance to industry.

Zoli, in his blog post, thankfully moves quickly into the other benefits of a Multi-Tenant environment from the vendor standpoint (including improved Customer Service, which outside of our small group of colleagues, we don't hear much about). What is unfortunate throughout the article is just his use of the term "hidden." That makes it sound like SaaS Vendors are keeping this from their customers or the market as a whole. Unfortunately, for most SaaS Vendors, it isn't hidden; it is often either unknown by the vendor ("I can do what?") or it is known, but they cannot take advantage of it because they didn't architect their application properly. 

In other words, they might be "SaaS" vendors, but aren't truly multi-tenant and can't easily aggregate data. Or they are Multi-Tenant, but only included core-application functionality and didn't effectively productize their offering for the SaaS Business Architecture. For whatever myriad reasons, I can tell you that far fewer SaaS Vendors are taking advantage of their Multi-Tenant environments than there should be; for many, its simply not knowing about this early enough in the product development process to do anything about it.

I wrote a two-part article for Softletter (first-part was published on 5/31/2009; the second part comes out on 6/15/2009) about "SaaS Multi-Tenancy: The Business Case." I will be speaking on this topic at SaaS University in Chicago at the end of this month, too. The crux of the article and the presentation is not just the benefits of Multi-Tenancy, including direct monetization of network-effect data, improved customer service and retention (reduced churn = on-going revenue), etc. but to show that to truly take advantage of Multi-Tenancy, support must be built into the application. When we work with SaaS Vendors, or those migrating to SaaS, this is part of the Strategic Product Development process that we use to help Maximize Revenues. You must think about these "hidden" parts of the business early in the process so you can actually take advantage of being a SaaS Vendor.

Of course, there are other non-technical issues surrounding the use of A/A data, (data ownership, etc.) that need to be addressed by the SaaS Vendor. Since those are legal in nature, it is outside the scope of my expertise. However, SaaS Vendors do need to ensure that their terms of service or other service agreements indicate that the customer owns their data, usage data, metadata, etc. is owned by the SaaS Vendor, and that all of it will be used by the SaaS Vendor in A/A fashion to offer better service, etc. Again, this is something to take up with the legal department or your attorney, but its as simple as making those definitions clear for this to all be above board.

In fact, Boasso has stated that the SaaS industry ought to beat their critics to the punch and start including "usage data ownership" language in their contracts. I agree and would say that it is up to us in the industry to bring this to light beyond the contracts. This way, the market can see we aren't hiding anything and that the usage of this data is all about providing better service. Yes, we have ulterior motives for offering better service (increased revenue, increased customer lifetime value, lower churn, etc.) but If we can adequately indicate what is in it for them (the customers) then we (the vendors) will be fine.

So I welcome Phil, Zoli, and Dennis' public discourse on this topic. I hope others will join in. For Sixteen Ventures, Keychain Logic, and others within our ecosystem, this will help spread the message that we have been extolling for years. For SaaS Vendors, or those wanting to move into SaaS, it will open their eyes to some of the "hidden" (read: unknown, less publicized, etc.) benefits of being a SaaS Vendor. I would just urge those talking about this to switch from saying "hidden" to understanding that these advantages of Multi-Tenancy are largely unknown to SaaS Vendors and their customers. We're working to change that.

I often extol the virtues of SaaS for Vendors beyond the typical "cost savings" and "operational efficiency" that most pundits and analysts like to talk about. I see SaaS as a way to increase Revenue for Vendors, not just save money. This increase in revenue is achieved through various means, one of which is better customer service. 

Better customer service, as Mikael Blaisdell of TheHotLineMagazine.com and Customerium.com frequently emphasizes in his writing, leads to reduced churn, more upselling opportunities, and an overall growth in Customer Lifetime Value." Many SaaS pundits and analysts tell you to look at Customer Lifetime Value, but few tell you what that really means or an effective way to increase it. Here's a freebie... serve your customers better and they will stay around and buy more. That, by the way, is not SaaS-specific.

The catalyst for this post was a an entry on the 37 Signals blog about Netflix and their proactive Customer Service. In the post, the author Ian Hall indicates that he had a streaming movie on in the background and noticed a hiccup in the audio. Apparently it wasn't a big deal to him, it must have fixed itself, and they went on with their evening.

The next day, he gets an email from Netflix telling him about the problem and asking him, if he was affected, to redeem a coupon for a small discount off of his bill. There is some discussion, to put it mildly, about the amount of the discount, etc. That is missing the point. What people should gravitate to in his post is this quote:

Now while 3% of my bill isn’t really going to add up, it makes me FEEL 100x better.

Wow! Amazing what a little customer service can do. As SaaS providers (Netflix meets the criteria for SaaS, by the way), we are in a unique position to proactively respond like this. How many actually do? Few. How many could? More, but still few since this was most likely not built into their product. If that is you, fix it.

Using the Netflix streaming movie example as an analog for a B2B SaaS Vendor, consider the same analog of Blockbuster as that of a Legacy Software vendor. I'm specifically talking about the Streaming video service from Netflix, and not their DVD Rental service.  The few times in the recent past that I've actually rented a movie from Blockbuster, the experience has been horrible. Often the DVD is so chewed up that it won't mount. My only option is to return the movie, in person, and either get a refund and not watch the movie which is not ideal or get a replacement disc and try again. This is annoying for me, the customer. 

But this should be just as annoying to Blockbuster, the vendor, as they have no control or visibility into this problem. I know for a fact that I have tried to view a DVD, and when it did not work it literally sat on my coffee table for three days before I just returned it. I didn't go back and ask for a refund because it was already late and frankly, I just didn't want to. In fact, I believe I saw that the movie was available on demand from Dish Network and just bought it that way. This episode, by the way, ensured that it would be even longer until my next visit to a Blockbuster. Blockbuster doesn't know that, and they have no idea it happened. This is all news to them.

As a Legacy Software vendor, you are Blockbuster in this analogy. You don't know how your customers are using your product, or even if they are. Sure, you might be getting paid now whether they use the product, but when it comes time to renew, you're out of luck. Too many SaaS vendors operate this way, too. If you don't know how your customers operate, what they are doing, or what problems they are encountering, you can't help them.

If you do, you can help them before they even have a chance to complain which is the ultimate in customer service. Remember, its Software-as-a-Service... Service is the keyword there.

Author: Lincoln Murphy

Can a product such as supplier performance dashboards subscription be geared for SaaS set up?

Yes. There are many ways to make this happen, and I have worked with a couple of vendors that do this very thing, but for different markets. There are lots of ways of making this work, but it would take knowing more about the market from your perspective to offer even a guess at this point. I would be more than happy to chat with you about your ideas.

Author: Lincoln Murphy

Have you seen markets that reject Multi-Tenancy based on [Information Security] requirements (no matter how well founded) and how do you counter that in the sales process?

No, I’ve not seen an entire market reject SaaS, but I have seen individual companies reject it.  You should know whether this will be the case before going in and if the majority of companies you are targeting have policies in place against SaaS or will otherwise reject it, you need to find new target customers or change your product.  That said, if you sell value over the fact that the product is SaaS or Multi-Tenant, etc., you can overcome many objections by simply not bringing them up in the first place. In other words, don’t immediately draw attention to the potential objectionable items. 

First sell them on the value your product brings and the benefits they will experience. Once you have them sold on that, the other objections will play a lesser role. The reality is that HIPAA compliance, for example, is easy to follow and there are many SaaS vendors that deal with this every day quite successfully in Multi-Tenant environments. Remember, if you do run into a potential client that objects to SaaS, you will find it difficult if not impossible to change the way they think. If they are opposed to your delivery model, it might be time to move on… they will eventually come around and there are other clients to focus your time and resources on.

It is important to note that every market is different and I would be more than happy to discuss your specific situation in more detail.

Author: Lincoln Murphy

Have you seen success with revenue share models based how much money you can save the customer?

This model is very risky and while I have seen success, I have also seen failure with it. The failure I have seen comes down to Control and Opportunity Cost. Regarding control, the further you get away from fully controlling the items for which you are billing, the more likely it is that something will go wrong. Likewise, the further you get from fully controlling the entire revenue model, the higher the Opportunity Cost is. 

In your example, if you can tie directly into, or extract data directly from, the system where you are trying to save them money and be certain that what your client is reporting is accurate, then that might be okay. However, if you have to take their word for it, you lose control and therefore the risk goes up. The Opportunity Cost goes up in the latter model because now you will need to spend time and money following-up with clients, auditing your clients’ invoices, etc. 

Author: Lincoln Murphy

What are the dangers, if any, to using ASP as a transition while converting application to SaaS?

There are dangers, not the least of which is the misconception that the Application Service Provider (ASP) model is simply a phase in the migration to SaaS. ASP is not a step on the way to SaaS for a Legacy Software vendor. With that knowledge, it would seem that you might be better off simply holding off of doing anything with your legacy clients until it is time to move them to SaaS. 

If you introduce an interim step to your clients in the migration to SaaS, you will add yet another possible churn point, or a place where you could lose clients. The path to SaaS does not include ASP so unless there is serious market demand to move the software to the network level and out of their hands, my advice for the time being is to not introduce ASP to the mix and just wait until your SaaS product is ready to rollout.

That said, every market is different and I would be more than happy to sit down and discuss this with you in more detail.

Author: Lincoln Murphy

Can you breakdown the difference between Multi-Tenancy and Single-Tenancy?  

Multi-Tenancy = shared everything (application code, database, infrastructure)

Single-Tenancy = isolated anything (application code, database, infrastructure)

Many will debate the implementation details or the various “degrees” of Multi-Tenancy, but its relatively straight forward. If you isolate a tenant at any level, you are no longer truly Multi-Tenant and the further you get from true Multi-Tenancy, the less benefits you, and ultimately your clients, can derive and the harder it will be to realize those that you are able to.

Author: Lincoln Murphy

Be sure to check out the comments section on the SaaS Single-Tenancy vs. Multi-Tenancy Debate post. The discussion has really started heating up and there is some great food for thought there. What are your thoughts on this topic? Post them there and lets continue this great dialog.

You can also subscribe to the Blog Comments Feed to make sure you don't miss any of the great points your fellow readers make. I will also post updates @lincolnmurphy and @16v on Twitter when we respond to comments so be sure to follow us.

Author: Lincoln Murphy

A lot has been happening with Sixteen Ventures over the last few weeks. We have been working with some fantastic startup SaaS Vendors, some Legacy Vendors transitioning to SaaS, and a couple of Data Center-centric vendors that see an opportunity to expand their business by re-positioning their products to attract SaaS Vendors. This is truly an exciting time for us, and the SaaS Industry / Movement as a whole.

In addition to the client work we are doing, we have some Webinars, Seminars, and writing engagements coming up very soon so my "spare time" has been spent working on  those projects. The writing engagement and one Seminar, both for Softletter, were announced in an earlier blog post. We also added them to the new Events page.

Next week we will be announcing a ground-breaking Webinar with a pioneer in the Software-as-a-Service industry. I cannot wait to announce that event!

Also, I am excited to announce that Sixteen Ventures has formed partnerships with two Major Players in Software-as-a-Service; Keychain Logic and OpSource. You can read more about those companies on our Partners page.

And don't forget to follow us on Twitter @16v and @lincolnmurphy

Author: Lincoln Murphy

I am happy to announce that I will be speaking at the Softletter SaaS University in Chicago June 30 - July 2, 2009. I am also penning a two-part article for the Softletter publication leading up the SaaS University event, and those articles will come out in the May 15 and May 29, 2009 issues. My topic will be "SaaS Multi-Tenancy: The Business Case" and it seems the timing of this couldn't be better.

Over the last week, a lot of talk about Multi-Tenancy in SaaS, and more specifically the use of it as a differentiator in marketing by Salesforce.com, has sparked some interesting conversations between Jeff Kaplan, Phil Wainewright, and Bob Warfield. I agree with all of their takes, but I would say that ultimately, even within their very thoughtful posts, Multi-Tenancy becomes a red herring, especially when the discussion drops to the technology level. Kaplan's take, by the way, that  Salesforce.com is bringing this up to fend off attacks by legacy players entering the market with single-tenant products, is spot on, in my opinion.

Jeff Kaplan did, as he does every time, a great job of keeping the discussion at a high level for non-technical folks with his "condo" analogy. I think the conversation should be somewhere in between Jeff's and Bob's. This is software, there will be a tinge of technology speak involved. But, like any good technology decision, there should always be a business driver. So when I say that Multi-Tenancy is a red herring, I am referring to the technical issues of Multi-Tenancy and to a certain extent the term itself. What we as SaaS vendors need to be selling is the value of our product;, the pain-reducing, revenue-accelerating, world-changing value that our Software-as-a-Service application brings to our target market. Nothing else matters.

The fact is, customers do not care about Multi-Tenancy, just like they don't care about SaaS or Cloud... they aren't using your system because you met the buzzword quota. They are signing up because of the value you bring. In fact, many SaaS vendors have been lucky as those customers with the worst pain sought them out and were able to ascertain the value they provide even though the could not actually convey that themselves. These SaaS vendors will need to change their messaging and positioning if they want to continue to grow.

I can hear you saying "Okay, so Multi-Tenancy has a business value, we just aren't allowed to talk about it?" Correct. Extending Kaplan's "condo" example further, when a Realtor has a list of selling points for a condo, where on the list is "all you are buying is a 'cube of air' attached to other 'cubes of air'?" It is probably not on the list at all. To move units, it is critical you sell the value that the tenant gets because of the fact that they are in a high-density housing unit. In fact, if you draw too much attention to what a condo really is, a stand-alone house can start to look more attractive. A good example of this is customization. Sooner or later it is going to occur to the buyer that they cannot customize their condo the way they could a single-family residence, even if they would never want or need to.

So in my SaaS University session we will examine how SaaS vendors should use multi-tenancy to monetize beyond the application, streamline sales &  implementation, and gain and maintain competitive advantage. We will talk about the reasons to build your SaaS application in a Multi-Tenant environment, how to use that to maximize and accelerate revenue, and improve customer service, all without "selling Multi-Tenancy."

See you in Chicago!

For more updates, be sure to Follow @16v and @lincolnmurphy on Twitter!

Author: Lincoln Murphy

Too often, the only revenue stream (of the 7 available) that Software-as-a-Service (SaaS) vendors take advantage of is Subscriptions. Even more often, the pricing strategy applied to the subscription revenue stream involves tiers or packages; different subscription levels (price, features, etc.) based on a segmentation of customers. The tiers are often created after an analysis of the market with a goal of adequately addressing each segment. Sometimes they are pulled from thin air.

Regardless of the strategy, almost without fail pricing tiers are tied to an underlying usage metric (determined during Revenue Modeling) as part of the differentiation between tiers. This leads to the unwanted effect of punishing users for increased usage of your system. If you are doing this do not worry, so is your competition. Most SaaS pricing models use this type of tiering to some degree.

To really set your offering apart, consider that subscription tiers should not punish usage by making users upgrade when they reach a certain threshold. Instead, each tier up should reward the users for reaching certain milestones with the need for the additional resources or functionality available in the next level. You want to make the user feel good about moving to the next step, not bad that they "over used" the system. That could have the opposite effect you want; they could stop using the system altogether.

Do you need help figuring out which of the 7 Revenue Streams your SaaS business can leverage? Are you trying to figure out how to apply a pricing strategy to the revenue model you've developed? If so, call us at (972) 200-9317 or contact us other ways today!

Author: Lincoln Murphy (You should follow me on Twitter!)

Sixteen Ventures does not generally recommend technology to our clients. The technologies used by our clients should ultimately be determined by the delivery method (on-premises, on-demand/SaaS, etc.) dictated by the market, the resources they have available, etc. However, being in the business of software, there are some high-level recommendations we can make. Since we deal mostly with Software-as-a-Service startups these days, one of the major considerations our clients must face is whether to leverage a Platform-as-a-Service or to manage the infrastructure (or Cloud Computing resources) directly. That is not a decision that can or should be rushed into.

However, it is critical to keep in mind that choosing a platform can be a "Bet-your-business decision" and you better be on the winning side.

When choosing a platform to build, deploy, and deliver the application to your clients, the following are just a few things to very carefully consider:

• Vendor Lock-in: how open is their system? what are the barriers to entry/exit? What kind of ramp-up time will my resources need? Do they leverage open technologies? Do they have proprietary programming languages or APIs that must be used?
• Sustainability: Are they well funded? What is their burn-rate/runway? Do they have other paying customers?
• Flexibility: Will the PaaS meet your needs after version 1.0 or will you need to change? Does their roadmap match yours?
• Track record: Do they have any history to learn from? Have they learned from their past mistakes? Do they provide visibility and alerts?
• Service Level Agreements: What are their guarantees since these directly affect what guarantees you can provide your clients?
• Terms of Service: Can they kick you off if they deem you competitive?

Again, this is a “bet-your-business” decision so be diligent in your research on where to host. If you choose a company that could go away soon, be sure to avoid vendor lock-in. If you aren't worried about that, you should be since it is obvious that no business is "too big to fail" anymore!

So the catalyst of this post is that according to Techcrunch, Coghead, an early player in the Platform-as-a-Service (PaaS) industry announced on February 19, 2009 that they are shutting their doors. For the past few weeks there were rumors that they were for sale, with one possible buyer being SAP (who previously invested in the company). While it is never a good thing to see a company fail, and we wish the founding team all the best on a valiant effort, it is one of the things you as a software entrepreneur must know is possible. Nobody likes to fail, or expects to fail, but if you learn from that failure, then it was at least worth something.

What can a software entrepreneur learn from the failure of Coghead? First of all, you can see that even a company that is relatively well capitalized (around $11M over the last couple of years according to Crunchbase) from strong Venture Capital and strategic investors can still fail. Money isn't everything. You can also see that just because you leverage "cloud computing" (Coghead ran on top of Amazon Web Services), you can still burn through money quickly.

The reality is we have no real visibility into what is going on internally at Coghead so other than guessing or rumors, we can't know. So the lessons learned, until more details come out publicly, must be those that apply directly to your software startup.

What this failure does is show that choosing a platform to build and run your pure-play Web or SaaS business is a decision that should not be taken lightly. The biggest problem with Coghead is that it was proprietary, so applications built on the platform are not easily portable to other environments. You might be able to extract your data, but it is true that often the context of data is at the application level. Even if no SaaS businesses were built on the Coghead platform and it was used entirely for one-off custom or departmental applications, the fact remains that those are not easily portable. 

Most PaaS companies streamline the "on-boarding" process but, for obvious reasons, make the "off-boarding" process a bit more complex. Often this is not by design or for nefarious reasons, but rather it is not something they want to encourage or it is not a priority on which to focus their often limited resources. Additionally, it is difficult since, as mentioned above, often the "context" of the data is in the application so simply extracting it is not enough.

No matter what, just remember that there are many decisions that will be made during the early phases of your software startup that will help reduce failure and set the stage for success later. Be sure to check out the slides from the Anchorage "Start Smart" seminar as it outlines some of the other things you need to be aware of. For SaaS or pure-play Web businesses, choosing the platform to deploy and deliver your application is definitely one of the earlier "bet-your-business" decisions that must be made.

The Start Smart seminar in Anchorage on Wednesday February 11, 2009 at the University of Alaska Anchorage Small Business Development Center was a fantastic success.  The turnout included several entrepreneurs with great ideas for software ventures, all at various stages of development, and some folks from the investment side of things as well. Knowing that our seminar might be a catalyst for local investment by Alaskans in Alaskan companies and not just an educational event would be an even greater honor.

During the visit to Anchorage, we learned that software is one of the few products that can be manufactured there and exported at a reasonable cost. Other than oil, very few products are made in Alaska and exported due to the high cost of shipping. While it is true that software or other types of IP can be exported inexpensively, the fact is that local investors do not seem interested in anything "above the ground," preferring to invest in the proven Alaskan petroleum industry. 

Further, for non-petroleum companies that do land investment, it is most often from investors outside of Alaska and the founder and their companies are often forced to move to be closer to the firm that invested. This is not unique to Alaska as this happens everywhere, including here in Dallas. This will continue to be a problem in places where there are more entrepreneurs than there are people (VCs, angels, etc.) to fund them. While an entrepreneur would love to be loyal to their hometown, ultimately it comes down to money and they go where the money is.

Anchorage, luckily, has some very driven entrepreneurs and "venture catalysts" helping to bring together the local investors and the entrepreneurs. The type of seminar we did there really helps set the expectations of the entrepreneur and helps them understand what investors, whether in Alaska or not, are looking for when you come to them for investment. Knowing how to "Start Smart" is the key to having a successful venture regardless of your need for external funding. However, if you are seeking external funding, knowing the right things to do in starting your company is absolutely critical.

Hopefully we can go back to Anchorage and do this again to an even larger audience. We will also be bringing our "Start Smart" message to other cities in the very near future, including another one in Dallas later this month.

Here are the slides from the seminar: