make it free or fail.

January 2, 2011

Follow me on Twitter, if you like. Or follow my latest project, TapType.

A kind of unspoken law has established itself in the software developer community in recent years: make it free or fail. From iPhone Apps to Windows Programs to Webapps, just about every developer has bowed to the silent pressure placed upon them to release their work for free. It has become almost a self-fulfilling prophecy: developers are led to believe the only way to succeed is through making everything free, and consequently, that’s exactly what happens. The freemium business model has become commonplace, and the consumer is enjoying a period in which they can find just about any software they need without paying a cent.

The idea behind the freemium model is great: let everyone use the service or app for free, hope it goes viral, and consequently spend far less on marketing, instead putting it into building a fantastic product. And for a few businesses, this works. The entire freemium software boom, in my opinion, stems from just a few successful companies who utilized that model: Evernote, Dropbox, Pandora, Automattic, Zynga, and Skype. Perhaps even Facebook and Twitter. The idea of behind the all too frequently heard line: ‘we’ll get millions of users first, and then worry about revenue’ stems from these businesses. The problem is, just about every startup is following this mantra,  and that’s exactly the reason why a lot of them fail.

A lot of people in the industry, angel investors in particular, love to broadcast the idea that ‘you can either get 1 million users, and have 1 percent of them pay, or struggle to find 10000 paying users right off the bat’. The thing is, in the overcrowded app and webapp space, it has become harder and harder to find those million users in order to break-even – and that is what a lot of startups are relying on. The freemium model has almost turned in on itself due to its own success: Producing a self-marketing, viral product has become, and will continue to be, increasingly difficult as the market becomes over-saturated with startups all attempting to do the same thing. Consequently, startups will be forced to pay for marketing to gain the upper hand: the freemium model will crumble as there is a requirement to release the product for free, and pay for marketing. That situation is impossible to sustain.

When releasing a product for free, just about every developer simply assumes that consumers will be willing to pay for it in some way, they assume that there will be a reliable revenue stream in the next year, or two years. Conversely, quite often there isn’t, and startups go bust. If a product is released on a pay-only basis, you know in the first month if the product will succeed, rather than two years and thousands of dollars down the road. Having a revenue stream from the get-go validates your product, it confirms that users are willing to pay for the app or service and ensures a reliable revenue stream in the future. Money, in my opinion, is the only reliable way to measure the worth of your product. Pageviews, downloads or referrals mean nothing in terms of long-term profitability. Releasing a product only to paying users also provides great feedback, simply because users who have paid for the product care a lot more about its improvement: they want their money’s worth.

Is it not better to forget about the millions of users, forget the billion dollar exit and instead focus on building a fantastic product, charging for it, and offering great support?

Advertisements

deadlines keep you alive

December 31, 2010

Deadlines. The simple concept of a deadline immediately provokes negative emotions: they remind us of work, school or financial obligations. Nobody wants to work to a deadline right? We complain endlessly if our deadlines are too short or too difficult, but guess what? They work.

It’s human nature that, having the choice, we simply wouldn’t do those frustrating tasks or jobs that need doing if we didn’t have to. An extrapolation of that is our tendency to delay completing a task until it is completely necessary, or to complete a task slowly if we know the time is available. If a project needs to be completed in a few months time, we will take a few months to complete it, even if it could be done in a week. Deadlines force you to be more productive, they force you to work harder, and consequently they are an extremely useful tool.

Personal deadlines are something that I use all the time, whether in business or elsewhere. That is, deadlines which I set for myself, without necessarily telling anyone else about them. If I have some element of a project that I’ve been putting off, I set myself a deadline for it, and I inevitably end up getting it done in that time. I created this amazing diagram to illustrate what I mean, you can thank me later.

As you can no doubt now see, due to my delightfully oversimplified graph, the closer you are to a deadline, the more productive you will be. If you set a personal deadline for yourself that is shorter than the time you would otherwise have taken, your productivity will inevitably increase.

In short, setting deadlines for yourself means that you will become more productive, work harder, and get everything done faster: leaving more time for the things you love to do.

A major flaw in the mindset of a great many indie developers is the need to infinitely tweak, tinker or build upon an app or project before its release. Whether it be in making repeated interface alterations, never-ending debugging, or as a result of a desire to keep it ‘private’ to safeguard their work, many developers end up releasing the app far later than intended, or often not at all – which is never a productive result.

In the software industry the term ‘MVP’ or ‘minimum viable product’ is thrown around a lot, but essentially it describes the stage when all essential features of the product are there (no more than the essentials), and they can be deployed. My philosophy in development is simple: release when you reach the MVP. Not a full-scale release, but what I refer to as an ‘EAR’ or an ‘early adopter release’. Basically this constitutes an invite-only product release, or a ‘first come first served’ limited user number release.

An EAR provides an essential component of any good software product: feedback. If you will, it gives you an ear to listen to your user’s opinion (ok, that was a terrible pun). As a developer or designer, you find yourself spending hours a day staring at the application, you know every pixel and every line of code inside out. This makes it impossible to take a fresh look at the application, and consequently it’s likely that you will miss a UI discrepancy or forget a simple feature simply because you do know it inside out. I’ll give a real-world example: I recently released a MVP of an updated version of PaintRibbon, which included an updated zoom mechanism which used a new custom slider control. This feature looked and worked beautifully, but when adding this feature, I removed the old ‘dropdown’ zoom level box. To me, this seemed a logical step, out with the old and in with the new right? As it turns out, this proved a huge problem for a variety of users who wanted to set custom zoom levels: the dropdown box allowed users to zoom in with decimal point specificity (ie 25.5% zoom), however the new slider only allowed zooming in increments of 10. Fortunately, I’d released this as an EAR, allowing this and other bugs (which may have seemed inconsequential to me) to be fixed before the large-scale release.

Other factors delaying release such as a fear of your ‘idea being stolen’ just seem ridiculous to me. I mean, you can either sit on the idea forever, and never release it, or you can release it now, get thousands of users and deal with competitors if the threat arises: the ‘we’ll cross that bridge when we come to it’ expression fits well here. From another perspective, if you intend to create revenue from the project, delaying the release is like Mark Zuckerberg hypothetically investing in MySpace: you’re just throwing money away.

In the software business, it’s vital to understand just one simple concept: when releasing a product you have a hell of a lot to gain, and very little to lose.

freemium: when it works

December 10, 2010

Freemium is an increasingly popular business model among software developers, in desktop, mobile and web apps. Popular online utilities Dropbox and Evernote use the freemium model with huge success, creating a profitable environment for users and the respective companies. Almost every popular iOS app (Angry Birds for example) offers a free or ‘lite’ version of the paid app.  There are a number of defining characteristics of every implementation which are essential for this model to succeed:

  • Great Long-Term Retention: In a freemium system, users tend to use the application or utility for a reasonably long period of time before upgrading or registering. Consequently, the app needs to maintain the user’s interest until they decide it’s time to pay for it. This means that games tend not to be very suited to the system: they’re most valuable in the first few days, and become less valuable over time. Apps such as Angry Birds have managed to work around this however, by ensuring the free version fits just within a narrow band in which users have just enough time to enjoy the app and get hooked on the gameplay, before the lite version finishes: meaning many users will upgrade to continue playing. Utility or productivity applications generally have great retention rates, but any application can create that retention simply by producing a fantastic product.
  • Increase of Perceived Value Over Time: A major motivator in the continued use of an application, and in increasing the percentage of users upgrading, is the feeling that an app gets more valuable the longer it’s used. This can be through frequent updates to the program, adding features and fixing bugs, or simply through ensuring a great lifetime service, as Evernote puts it: “we want to be the secure, trusted repository for your lifetime memories“.

A big mistake that a lot of software vendors make is trying too hard to force users into upgrading from the free version, whether through a major lack of features in that version, or from  an endless stream of popups and requests for payment. Basically, if users think that the free version is so good that they don’t have to pay, then you’ve done a great job. If the quality of the product there, users will pay.

Essentially every major mobile device vendor is trying their hardest to get into the app game, to reach the heights of Apple’s iOS platform. iOS represents, whether or not you’re a fan of the actual product, the pinnacle of mobile application distribution. It created a whole new paradigm in the industry, and just about every other company is still scrambling to catch up. Google’s Android is getting there, with many developers warming to the platform, Microsoft’s Windows Phone 7 is a great step up for Windows Phone itself, but it still has a ways to go to draw in developers, and WebOS still lags behind.

Blackberry, with the announcement of it’s Playbook tablet, seems to have finally ‘gotten it’. They seem to have finally grasped the importance of drawing in a strong bunch of developers and applications, and they’re doing some great things to make that happen:

  • Waiving Registration Fees: Registering for Blackberry App World originally cost $200: double that of Apple and eight times that of Google. This was a wildly counterproductive move by the company, why would developers be interested in even testing a platform with a far smaller user base and a much less fluid implementation when the cost of registration is so much higher than competing platforms? Recently, this fee has be waived by the company – and this will encourage huge numbers of indie developers to the platform, who otherwise wouldn’t have been interested.
  • Free Playbooks: RIM has recently announced it will be giving away free Playbook Tablets to developers who submit applications before its release. This is a very smart move by the company, it again provides the necessary incentive to attract the all-important indie developer base to the platform, and increases the likelihood of said developers distributing the application for free – a great result for consumers.

Other vendors should take a look at the approach of RIM in building up it’s Blackberry App World developer base, I have no doubt it will result in a massive increase in the uptake of the platform by developers and consequently, by consumers.

Developers often have a tendency to be feature-focused, that is, they put the majority of their time and energy into coding back-end features and functionality. Conversely, to produce a successful software product in 2010, the opposite must be done.

While it may sound counterproductive to put core features on the backburner and focus on the UI – that’s exactly what needs to be done. For me, the easiest way to think about it is this: additional features can always be coded later, functionality can be added in updates, but for any of that to be accessible to the user, and in order to make those additional features readily available, a solid UI needs to be created for the first release.

The software business in 2010 is much more a meritocracy than ever before, and consequently, the success of a product is determined more and more by consumer choice. Advertising and other overheads are much less important now than they were ten years ago: due largely to the web, and the prominence of social media (Facebook, Twitter and blogs) where consumers will freely share their opinions on products to a huge number of friends.

With the greater choice they now possess, consumers will inevitably choose the software they find easiest to use over software which claims to have more features – and consequently the product which demonstrates the simplest and most functional UI will be the one which ultimately succeeds.

One thing which never fails to frustrate me is the pointless struggle of so many to find perfection. In anything, from the most mundane tasks to the most complex ones. The simple notion itself is impossible, it’s unattainable, and consequently, it’s entirely pointless.

You’re forever taught to work on something until it’s finished. I have distinct memories of a school teacher encouraging me to work on a finger-painting until it was entirely completed, until every last piece of the paper was covered in some sort of paint. I have no doubt that my artwork was, naturally, amazing for an eight year old  –  artistic genius I’m sure, but said artwork undoubtedly reached a point about 15 minutes before I stopped where it could have been completed – where it was already the best in the class. It’s simply a matter of time vs result – those last 15 minutes of my painting could have been spent elsewhere – digging in the sandpit, perhaps. And that is the essence of my frustration. Why spend those last fifteen minutes, making something perfect, when it could be spent being truly productive elsewhere.

Dictionaries define ‘excellent’ and ‘perfect’ as being the same. In my opinion however, they are vastly different. While my finger painting may have been excellent fifteen minutes before I finished, it was still only excellent when I did eventually complete it. A state of perfection will never be reached. Those final fifteen minutes could have been spent ensuring my other paintings were excellent, or by creating another excellent painting, rather than striving for perfection in that one artwork.

Now, I’m not suggesting working on a project until it’s finished is a bad thing, in fact it’s a great thing – what is counterproductive however is the inevitable search for perfection in that project. The inevitable niggling desire to go back and check it again, to improve just a little. That time could be better spent.

I started a blog.  Being less than 25, my only source of information -other than television and the lyrics of indie-folk music – is naturally Wikipedia. Considering that, it would seem appropriate to check the opinion of Wikipedia on what a blog actually is:

A blog (a blend of the term web log) is a type of website or part of a website. Blogs are usually maintained by an individual with regular entries of commentary, descriptions of events, or other material such as graphics or video. Entries are commonly displayed in reverse-chronological order. Blog can also be used as a verb, meaning to maintain or add content to a blog.

Well there you have it. Now, this has put all of us in an awkward position: Firstly, because everyone did have to think for a moment to figure out what ‘reverse-chronological’ actually means, and secondly, because we inevitably had to pause to remember what a verb is. It’s a doing word, coincidentally.

Anyway, I’ll be writing about anything and everything here – who knows, I may even throw in some ‘other material such as graphics or video’. Never!

Check back soon for more :)