The Catch-22 of Software Feature Releases
One of the most frustrating things with which product managers contend in the traditional software release model is the long wait between each new version. I faced this when I worked at Novell on products such as ZENworks, eDirectory, iManager, and SUSE Linux Enterprise. In managing these enterprise-focused products, it was agonizing to have researched requirements and documented specifications for a next version, and then have to languish while developers worked to create a complete, well-integrated and solid next version. But I highlight the long interim between software releases to address a common misconception and try to tear it down.Creating, and then validating and testing a release for an acceptable level of quality is hardly the most frustrating part of the enterprise software lifecycle for a product manager. Nor is it the reason why enterprise software vendors take so much time to get their next release out. If create-validate-test-release were really the root cause for the long interim between release, then the open source credo to “release early and release often” would address the issue handily. But all-too-many installations of open source products go on without being updated, just as their proprietary contemporaries do*. During my time in dealing with both open and proprietary software, I cannot count the number of customers who told me that they could not keep up to date with all the current versions from all the vendors they dealt with.
To be clear, personal applications—the kind that you install on your local system and usually serve a single person on their primary computer—are not my focus. Perhaps with the exception of an outdated OS version complicating matters, the upgrade problem has been handled well enough in the personal space. Most personal applications now notify you about new releases, and the updates are usually easy. But personal applications don’t share the intricate interdependencies that so-called “enterprise” applications do.
The product manager’s frustration that follows a release is greater by far. As a product manager, you wait through a twelve to eighteen month or longer release cycle, only to watch your customers forestall upgrades that you know would solve most of their major complaints about their deployed version. Businesses avoid the pain and turmoil of upgrades and re-deployments for as long as they possibly can.
SaaS and Feature Agility
Software as a Service significantly changes the upgrade game. When you centrally host a service, you can regularly add many new features in simple, incremental additions. The better you have architected your platform, the greater is your agility to do this.
Salesforce.com, the poster-child for special-purpose SaaS offering, is quite literally dismantling the mid-market dominance that products like SalesLogix and Goldmine once had all sewn up. The SaaS model’s suitability for Customer Relationship Management (CRM), especially in small and medium business, introduced a market disruption. By applying the SaaS model, Salesforce.com overtook the existing, traditional vendors leaving SalesLogix or Goldmine with little chance of regaining their lost marketshare—even if they were dive into SaaS themselves. I suggest that feature updates are a major component of this changeover in market dominance. So, how does the SaaS model change the traditional model for roling out new features, and why does it matter?
The 80’s and 90’s established a well-known software entrenchment strategy: get your software in, then use as many tactics as possible to lock it in place. Microsoft, with Windows and Office, is the obvious example of this, but Microsoft is hardly the only company that ever applied this tactic. (But let us not overlook the resentment that this approach ultimately fosters.) The lock-‘em-in tactic is alive and well today, but it’s now joined by a new (and probably much less evil) way to crush the competition in the SaaS space: feature release agility.
Could someone displace Salesforce.com by coming out with a competitive offering that includes some killer feature differentiator to make their product an extremely compelling alternative? It would not be long before Salesforce.com would roll out something to reduce the new entrant’s key differentiation advantage. Without the constraint of having to go through an entire release cycle, nor cajole their customers to upgrade from their old versions, a SaaS vendor can just roll new features as they are determined to be ready. Customers get the new features without any of the traditional upgrade hassle. By properly applying their SaaS advantage, Salesforce.com can discourage new competitive entrants and remain the gold standard in CRM.
Relevance to Bungee Connect
So what does the power of a SaaS vendor in the CRM space have to do with providing software development and deployment as a service? As I see it, there are two ways that this should be relevant to members of the Bungee Connect Developer Network (BCDN). First, you should be asking whether Bungee Labs intends to provide incremental updates to you in Bungee Connect. Second, you should be keenly interested in whether you can somehow extend the same potent feature update formula to the end users of the software you create with Bungee Connect.
A few of our most avid early adopters are starting to see how Bungee Labs is applying this part of the SaaS model to Bungee Connect. Since the start of our early access beta, we have rolled out several updates to introduce incremental new features. We aim to do this on a monthly basis. Additionally, we work on larger payloads of more significant features, which will release in multi-month intervals. And on a much less frequent schedule, we roll out those major platform updates—the kind that might require architectural changes. Through this means, Bungee Labs makes Bungee Connect better for our BCDN developers. (And we document these updates through the Bungee Connect Developer Network communications channels.)
But here’s what I think is the best part: BCDN developers can employ this same mechanism for their Bungee-powered applications. That is, because Bungee-powered applications are hosted applications, BCDN developers can quickly add features and make other changes to their applications while leaving their current version online. After validating that the update is adequate to roll out, they can update to the new version. The next time their users run the app, they get the new version.
I would be remiss not to mention two other things: such an update does not require users to disconnect from the current version…they just won’t see the updates until their next session. And, if you roll an update and then discover that the new version includes a critical bug, you can roll back to the previous version—or roll an even newer, fixed version—in the same way.
Postscript: Heading to DreamForce
Next week is Saleforce.com’s big conference. I’ll be there, so drop me a line if you’d like to get together and check out Bungee Connect.
*Lest I suffer many corrective slings and arrows, I should state that SaaS is a hosted model of access, and does not indicate whether the hosted service is open or proprietary. The SaaS model can be implemented with either open source and proprietary software, or a mix of both. For example, Google host their proprietary services on Linux and use many other open source technologies. To succeed as an SaaS offering, it’s much more about meeting a distinct, unfilled market need. Finally, allow me to state explicitly that I do not at all believe that the SaaS model is any kind of panacea. There remain many, many examples for which the SaaS model is wholly impractical.