This entry follows on from a discussion on Hacker News around a submission of a blog post by Alex Payne entitled “Shortchanging Your Business with User-Hostile Platforms“. It started out as a comment but kind of spiralled out of control so I thought I’d write it up as a blog-post-in-reply.
I’m not particularly familiar with AIR as an application framework but I’m pretty familiar with building and releasing software. I can say that I have never released a piece of software without a very large backlog of things that I wanted to do.
So why didn’t I just finish those things all those times and release the software that I really wanted once I was done? There are 2 primary reasons.
One is time and money. I’ve never received external funding (although I have worked on projects that were funded) and so my products have always been bootstrapped using mine and my employees’ unbillable time. There’s only so much you can get done.
The other is that, being a perfectionist and an idealist, as almost every developer I’ve ever met is, I will never be happy. The backlog will never be empty because as soon as I build a new feature, that feature in itself gives me 10 more ideas of things that I want to implement.
So as far as I can tell, I have 2 choices: never release software or release software I’m not happy with. Since the only way I can ever learn about the usefulness of my product or make any money is by releasing software, I consistently choose the latter.
In my experience of releasing software I’m not happy with, I’ve found that some people use it, and some don’t. Those that don’t use it, don’t generally hate you for having released it – they just note that it doesn’t fit their requirements and move on.
There’s no risk associated with releasing software that you’re not happy with – so long as you don’t trick anyone into buying it under false pretenses and you support the users you do get fanatically enough that even when things go wrong, they still see that you care about them.
My guess is that the thought process that the guys at Hip Chat (the company which, as it turns out, was the impetus for Alex’s original post) could be approximated as follows:
Hip Guy 1: Hey let’s make a chat product – I bet we could do better than Campfire.
Hip Guy 2: Cool but we’re pretty cashstrapped and time poor so we need to release something quickly to see if there’s actually a market for it
Hip Guy 1: Well, we’re web developers – let’s build it in Adobe AIR. We won’t have to learn anything new and people seem to like Tweetdeck [or whatever] and we can probably get a version 0.1 out to market in like 2 months
Hip Guy 1: Okay. I heard AIR is kinda slow though. Let’s have a play around with some stuff that’s out there and see what’s what.
Hip Guys download a few AIR apps and play with them
Hip Guy 1: That’s not so bad. I bet we’d get some users with a really nice chat app
Hip Guy 2: Okay we’ll let’s run with that and see how we go getting something out to market in 2 months
16 months later and Hip Chat was born!!
DISCLAIMER: the above reference to the Hip Chat release schedule was a joke, I have absolutely no idea how long it took them to build it or release it.
The Exceptional Quality Matrix
A little while ago I met up with some people in Melbourne, Australia via a LinkedIn group called “UX Peers”. It was a good time, and there was a guy there (who’s name escapes me) that spoke about the idea of an Exceptional Quality Matrix. The Y-axis went from “Expected” to “Exceptional” and the X-axis was how long a feature would take to impelement.
The example analysis he used was the iPhone, which was first released with SMS bugs, no MMS, no Bluetooth and no WAP push. All these things were expected in a phone but none of them would make the product exceptional.
A kick ass web browsing experience on a phone, however, along with incredible touch screen technology and a platform that allowed developers to quickly release and commercialise thousands of applications, were all completely exceptional. People were willing to forgo several features they had always expected from their phones in exchange for some exceptional features.
So what makes your product exceptional?
More importantly, what is it that you can compromise on that people may expect, in order to deliver what you consider to be exceptional in a period of time that fits your budget and release schedule?
People may expect that an application that runs on their machine will look just like other applications that run on their machine (native applications), but they may be willing to forgo that pleasantry if you deliver them some quality in your application which they consider to be exceptional.
The key to living with mediocrity, releasing software and, hopefully, making money is to figure out which bits of the application you’re building can get away with being mediocre, then spend all your time working on the bits that will make your product exceptional.