Who knew that software developers were such athletes? My code-writing friends are all talking about "scrums," "sprints" and "extreme programming."
Though I'm sure some of these folks are spending time in the gym, I've learned that these terms actually refer to the agile development methodologies many are using to build software-as-a-service (SaaS) solutions. Agile development is "intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals."
Agile Marketing
We SaaS marketers should get on this fitness kick, too. We should follow our development colleagues with our own version of a lean & mean methodology. Call it "agile marketing."
Agile marketing refers to a process for building visibility, generating leads and supporting sales that's faster and more flexible than traditional marketing processes. It is intended to deliver more effective marketing, closely align with agile development processes, and better support a company's overall business model.
Faster
In the traditional on-premise world in which applications are developed via the "waterfall" method, new versions typically come to market every 18 - 24 months. The marketing team falls into this same rhythm, gearing up for a big launch every 18-24 months. After one of these grand launches - gala unveiling event, PR blitz, new collateral, multimedia ad campaign, etc. - the marketing folks recuperate for a couple of months... and then gear up for the next big launch.
This "marathon" pace doesn't suit most SaaS applications, and certainly not those built according to an agile development process. Instead of launching a massive new release every couple of years, marketing needs to gear up for launches every couple of months. These are more like a constant series of sprints than a marathon. It requires a faster, more agile process to keep up.
More flexible: Besides more speed, agile marketing requires more flexibility. SaaS marketers need to be eager to try new things, fearlessly measure results, be willing to pursue what works and abandon what doesn't. There's no room for dogma here.
Marketing folks ask me all the time, "What marketing programs work best?" My honest, though sometimes infuriating answer: "It depends."
What works for one company in one market with one particular solution might not work for another company in another market with a different solution. Be skeptical about "best practices."
Drew Houston of Dropbox and Adam Smith of Xobni have shared some of their experiences trying, failing, and trying something else, while building their businesses. (Presentations on their experiences are available on David Skok's For Entrepreneurs site.) Certain kinds of press outreach worked for them; others didn't. Adwords worked for one, but not the other. And certain social media campaigns were very effective, though more traditional email campaigns generated positive results as well. Their advice would make for a good tag-line for the Agile Marketing tee-shirt: "Learn early, learn often."
Also be aware that what works today may not work tomorrow. I remember marketers' fleeting love affair with "dimensional mailers." These promotions involved mailing (as in U.S. Postal mailing) odd-sized boxes to well-targeted executives. The goal was to "bust through the clutter" of over-stuffed mail boxes.
As ridiculous as cluttered U.S.P.S. mailboxes sounds today, the current infatuation with "social media marketing" may look pathetically quaint someday, too. The fact is, there's no marketing magic bullet; or if there is, it keeps changing.
SaaS solutions built with an agile development process require a faster, more flexible marketing process as well. It's time for marketers to get agile.
Tuesday, May 25, 2010
Wednesday, May 12, 2010
Pricing SaaS solutions: Beyond a "lease vs. buy" analysis
From the "Ask the SaaS Marketing Guy" mailbag, here's a question on pricing from a software-as-a-service solution vendor:
"My prospective customer is asking about the "break-even"point at which their software-as-a-service subscription payments would equal their on-premise license cost. They're asking why they should select a SaaS subscription option if they plan to use the application over a long period."
If the SaaS application is truly identical to the on-premise application, the vendor or the customer can conduct a straight-forward "lease vs. buy" analysis, accounting for the time-value of money. That will allow them to identify the break-even point - measured in months or years - after which it makes more sense to buy the on-premise license vs. lease via SaaS subscription.
If the vendor or the customer do conduct this analysis, of course, they should factor in all of the costs associated with buying and running an on-premise solution. Those would include the annual maintenance fee as well as the hardware required to run the application on-premise and the people required to deploy and maintain it. In the SaaS model, those costs are borne by the SaaS solution vendor.
Beware of this potential flaw in the straight-forward "lease vs. buy" analysis. In many cases, the SaaS application is not truly identical to the on-premise application. Or the functionality of the SaaS application may diverge from the on-premise application over the life of the subscription. The two applications may have been identical at the start, but over the subscription term, the SaaS customer has gained the benefit of product enhancements that the on-premise customer has not enjoyed. In that case, the SaaS customer is getting increasingly more value from the application than the on-premise customer. The customer should expect to pay a premium for that extra value.
Further, the SaaS version may offer the customer additional benefits beyond the product features. For example, the customer may benefit from more rapid and less expensive deployment of the application, easier configuration, the ability to quickly scale up to handle peak demand, and the flexibility to stop paying for the solution if they no longer need it (according to the terms of the contract, of course). These are benefits beyond what they'd derive from an on-premise application and customers should expect to pay for them.
The point here is that the SaaS offering and the on-premise offering typically do not offer identical benefits to the customer, so that a straight-forward lease vs. buy analysis wouldn't be appropriate. SaaS marketers should clearly articulate those additional benefits when promoting their solution.
"My prospective customer is asking about the "break-even"point at which their software-as-a-service subscription payments would equal their on-premise license cost. They're asking why they should select a SaaS subscription option if they plan to use the application over a long period."
If the SaaS application is truly identical to the on-premise application, the vendor or the customer can conduct a straight-forward "lease vs. buy" analysis, accounting for the time-value of money. That will allow them to identify the break-even point - measured in months or years - after which it makes more sense to buy the on-premise license vs. lease via SaaS subscription.
If the vendor or the customer do conduct this analysis, of course, they should factor in all of the costs associated with buying and running an on-premise solution. Those would include the annual maintenance fee as well as the hardware required to run the application on-premise and the people required to deploy and maintain it. In the SaaS model, those costs are borne by the SaaS solution vendor.
Beware of this potential flaw in the straight-forward "lease vs. buy" analysis. In many cases, the SaaS application is not truly identical to the on-premise application. Or the functionality of the SaaS application may diverge from the on-premise application over the life of the subscription. The two applications may have been identical at the start, but over the subscription term, the SaaS customer has gained the benefit of product enhancements that the on-premise customer has not enjoyed. In that case, the SaaS customer is getting increasingly more value from the application than the on-premise customer. The customer should expect to pay a premium for that extra value.
Further, the SaaS version may offer the customer additional benefits beyond the product features. For example, the customer may benefit from more rapid and less expensive deployment of the application, easier configuration, the ability to quickly scale up to handle peak demand, and the flexibility to stop paying for the solution if they no longer need it (according to the terms of the contract, of course). These are benefits beyond what they'd derive from an on-premise application and customers should expect to pay for them.
The point here is that the SaaS offering and the on-premise offering typically do not offer identical benefits to the customer, so that a straight-forward lease vs. buy analysis wouldn't be appropriate. SaaS marketers should clearly articulate those additional benefits when promoting their solution.
Subscribe to:
Posts (Atom)