I’ve been harkening back to the good old days recently – the days when real companies made real products for real customers who paid real cold hard cash for said products. Call me old-fashioned but I still see value in that model. So that brings me to freemium….
I’ve always been more than a little dubious about a freemium model for SaaS startups. A bit of advisory work I’m doing with some companies at the moment is doing little to change my perspective. Basically my views can be summed up by the old adage about the difference between free and one dollar feeling much bigger to a consumer than the difference between one dollar and two (it’s hard to get us to bring our wallets out of our pockets, once we do, we tend to be comfortable spending more).
Recently at the Freemium summit, Lincoln Murphy warmed my heart by standing up in a crowd of freemium proponents to sounds a note of caution to those who would suggest freemium as a strategy for any startup. Murphy presented the slideshow below – the thrust of the presentation was that the best idea is to solve a real business problem and charge money for it:
I was reminded of Murphy’s post when reading something Bob Warfield, formerly (and somewhat unhappily) CEO of HelpStream wrote. Bob is writing a series looking at the learnings from the Helpstream failure and in this post he looked at their freemium model. Warfield starts by admitting that Helpstream themselves made heavy use of free software saying that “Not one single software license fee was paid in the making of that software.”
Warfield went on to describe the battles within Helpstream between marketing and sales over their freemium model. Essentially marketing saw freemium as a way of achieving bigger visibility and a greater penetration of their product. Sales however, revenue driven as they are, always saw freemium as a threat and as something that was directly taking commission out of their pockets.
The other issue that Warfield warns about is creating a freemium model for customer facing products. In Helpstream’s case theirs was a full-featured product that was limited in terms of its ability to be branded. This was naturally a barrier to adoption by customer facing departments and hence visitors tended to sign up, and kick the tyres a little but not actually deploy the application – in this case having a product with fully populated workspace would do much to give users an opportunity to really experience how a product works. I know in my experience, testing dozens of applications every month, I far prefer to have a richly content-filled sandbox to play with rather than my individual, but empty, workspace – it really gives a user a chance to try things out properly.
Looking at the opportunity to really use freemium for what it is intended, that is driving real revenue, Warfield has some great advice:
- Make sure your freemium strategy is actually targeting people who are likely to become paid users – in Helpstream’s case it wasn’t
- Put some realistic limits on the freemium model – and think of it as more of a free trial than a freemium. In Helpstream’s case Warfield set limits on their freemium model – limiting it to 50 users
- Try and lower the adoption friction – self-service, self-provisioning and the like are crucial to get people converting
I’m still very, very cautious when it comes to freemium – if something has no price, it’s difficult for prospects to assign it any value. While a number of examples exist of companies that have ground significant value based on a freemium model, there are many more example of organizations that have failed by following the strategy. Dennis Howlett takes a slightly different perspective , suggesting that free software allows an organization to be hooked to a particular platform and for vendors to make a buck via the maintenance work that goes along with this. I’m dubious about this advice for two reasons:
- One of the benefits of SaaS that many of us are talking about is the fact that the sticker price includes support and maintenance – a business strategy that relies on monetizing maintenance after the fact is problematic in my mind
- I’ll accept that SaaS products for mid to large businesses do in fact require an implementation and support offering wrapped around the product however the traditional approach, and one that SaaS vendors seem to be following in ever greater numbers, is to allow third party ISVs to do this work – if the core vendor gives up revenue from the product, and allows third parties to monetize the maintenance, that’s a very shaky foundation upon which to build a business.
My advice closely follows that of Murphy. Build a product that businesses will value and charge for it accordingly – the way things used to be done in the bricks and mortar days.