Join the SaaSBlogs LinkedIn Group!

Mar 28, 2008 by Abe Sultan

 

   

Dear Readers,

We’ve established a LinkedIn group called SaaSBlogs. LinkedIn is a networking site for professionals and the purpose of this group is to extend the SaaSBlogs community and provide a place for further discussion and knowledge sharing amongst SaaS entusiasts.  We welcome you to join by following this link, and based on the comments seen here on SaaSBlogs, we’re sure we’ve got a lot of great conversation to look forward to.

 Thanks.

 

read more

A retrospective from someone familiar with the SaaS ISV trenches

Mar 24, 2008 by Matt Ammerman

This post simply serves to provide a link to a post on another site, but I felt it very appropriate to shine the spotlight on a brilliant post by Ben Yoskovitz on Instigatorblog.com entitled ‘Lessons Learned Running A SaaS Business‘. While we tend to focus on the relative “newness” of SaaS, it’s always important to remember that there are people who have been approaching, solving, re-approaching, and re-solving the challenges associated with SaaS for some time now. Ben outlines some key points from a “looking back” perspective. Give it a good read, there are tons of gems throughout – especially for those building go-to-market strategies for SaaS products.

read more

SaaS & Learning from Malcolm McLean

Mar 17, 2008 by Sinclair Schuller

For those who don’t know who Malcolm McLean is, I’ll give a brief introduction. Malcolm McLean invented the modern shipping container: you know, the ones that come in on cargo ships, are craned onto trucks and trains, and that provide a standard for transporting goods worldwide. So why are his ideas important and what does it have to do with SaaS? I think we should all pay attention to the shipping industry and how he revolutionized it. SaaS and service oriented architectures have the potential to cause a change as profound as the one experienced by the transportation world in the 1950s.

Traditionally, software is notorious for capturing functionality and locking it away in an unsharable fashion. Any other piece of software interested in tapping into some other software’s functionality generally needed access to the source code or some non-standard programmer interface. This isn’t necessarily the fault of any one piece of software, but rather a problem of lack of basic agreement. Software lacked (and still somewhat lacks) protocols, well-defined modular architectures, and an economic model allowing for subscribed functionality that can compensate producers in a producer/consumer model.

In the shipping industry, McLean recognized some significant parallels: across transport mechanisms (trucks, trains, and ships) there was no efficient protocol (everything was break bulk) and economic models in transportation reflected a heavy penalty because of lack of disintermediation (someone had to interfere at each drop point to break down shipments). By introducing shipping containers and associated support infrastructure (crane structures, roll-offs) etc., we saw those issues alleviated. McLean broke the mold by recognizing that lack of standard produced inefficiency and not competitive advantage.  This is why these days you’ll see the same shipping container on the deck of a cargo ship, on the bed of a freight train, or on the back of a trailer heading down the interstate.

In the software space, we’re starting to recognize that lack of protocol, economic models, and isolated functionality are in fact hurting us. Service oriented architectures have shown that cross-technology communication and access to non-commodity functionality is possible from a technical standpoint, that applications can in fact be very modular (just look at the mashup craze), and that software as a service has introduced an early framework for monetizing this functionality between parties. Looking back at McLean and what the shipping industry is today, we should recognize that his work and ideas led to the ability to transport goods across the globe as efficiently as possible and that we have a similar duty in the software space.

Over time, do you expect that software space to become more protocol driven and more flexible in terms of functional composition, or have we reached our peak with respect to “functionality on tap”?

 

read more

Agile Responsibilities in Your SaaS Business

Mar 7, 2008 by Sinclair Schuller

One of the much-touted benefits of single instance, multi-tenant SaaS is the ability for ISVs to respond to market demand and introduce new functionality and versions of their application to their entire customer base relatively easily. In other models, this was a nightmare and would actually dis-incentivize creativity and “staying ahead of the game.” This was understandable since the cost of distributing a new version was significant so it happened conspicuously as a major event in the lifecycle of your application. SaaS, however, encourages a continuous flow of new functionality to customers along with a “community feedback loop” to quickly absorb reactions and execute compensating actions based on that input.

One issue I have when people tout the aforementioned benefit is that it’s always from the R&D side of things. SaaS can also offer the same benefit from the pricing and business strategy side. This is true, however, only if the SaaS offering was built to support flexibility in that fashion. Let’s look at the antithesis of flexible business capabilities. Your company has architected and deployed the world’s greatest SaaS offering. It’s single instance, multi-tenant, scalable, and you can roll-out new functionality at the drop of a hat. Things are going smoothly until one day, the VP of Marketing comes in and says that their is a huge opportunity if we can reorganize the applications feature set to target certain verticals, and that the pricing strategy needs to move from monthly to quarterly in the existing segment in order for growth to continue. Oops, we didn’t think about that. The VP of Marketing has the authority to make that sort of strategy decision, but the app doesn’t care. It  was built with all the technological bells and whistles, but no one put thought into allowing the business folks in your company to independently make decisions without requiring R&D to intervene and make code changes. You’ve effectively architected an application that hampers the companies ability to “think on it’s feet” and make either reactive or proactive moves.

The key when building a SaaS offering is recognizing that it is the center of interaction and discussion at your company. How responsibilities are divided up in your organization and how the different teams and departments interact with it must come up in conversations related to implementation. You should ask yourself questions like:

1. Can we roll-out new functionality or bug fixes easily?
2. Can sales & marketing reorganize how the application is sold or marketed without intervention from R&D?
3. Can support teams gain access to normally sensitive or restricted information (such as execution logs, etc.)?

The more you can integrate your business’ concerns into your implementation decisions, the more agile and responsive you can make your business.

Do you feel that agility is under-appreciated and/or under-utilized in the SaaS model?

 

read more

A Great Video Describing a Fictitious SaaS Platform

Mar 5, 2008 by Sinclair Schuller

Eugenio Pace from Microsoft’s SaaS Architecture Team published a great webcast describing the potential relationship between ISVs and hosters and how a SaaS platform fits in. It’s worth the watch. One of the major takeaways from the video is that a good platform marginalizes an ISVs efforts involving things like multi-tenancy, onboarding of new customers, monetization, operations, revenue modeling, etc. but still gives an ISV autonomy, complete control over their offerings core definition and the interactions their customers have with the application. It’s a lengthy 30 minute video, but well worth the watch.

If you watched the video, how receptive are you to the ideas Eugenio outlined?

 

read more