Release early, or release right?

I really like the recent blog post by Tom Taylor, titled “you’ve either shipped or you haven’t“:

You’ve either shipped, or you haven’t. You’ve either poured weeks, months or even years of your life into bringing a product or a service into the world, or you haven’t.

If you have, you’ll know what I’m talking about. You’ll have flicked a switched, cap deploy‘d, or flipped your closed sign to open, and just waited – holding your breath for whatever happens next.

Tom makes the obvious but highly pertinent point that actually shipping something (the term ‘shipping’ is an Americanism, I think, but I can’t think of a good alternative) is a hugely important milestone. Without that step, what you’ve produced is just vapourware. Just an idea. Just something in perpetual development that nags away at you.

I’m guilty of having started tons of things that never actually got shipped. Sometimes the idea never left paper. Or my head. Many times things get started but never finished.

I’ve also had a bit experience of shipping things which have failed to have much of an impact on anybody at all. Either through lack of awareness, or because the thing wasn’t that great in the first place (or was only interesting to me and no-one else). I won’t list these things in order to save myself some embarrassment (I’m not even sure whether half of them still exist or not. I daren’t check).

Actually shipping stuff is a great feeling though.

We (Rattle) hope to be shipping one thing on Monday. It’s only a small thing. A really small thing. But it was originally my idea (though we worked on it as a team), so I feel some ownership of it. And if no-one else gets it, then it’s probably my fault. That doesn’t matter too much though, it was a fun project to work on, and hasn’t taken too much time.

We’re also putting a price on the thing we’re shipping. Not really because we hope to make tons of money from it. But because pricing something gives it some value, and makes it mean a lot more when people are willing to pay for it. The idea of actually selling something feels good (even if it’s only for nominal cost).

One dilemma we’ve faced a bit though, is picking the point at which to say “okay, that’s good enough to ship”.

There’s a mantra in software development of “release early, release often”. It’s a good argument, and feels like a truism. But it always seems to apply more strongly to stuff that’s already shipped, than stuff that hasn’t yet shipped. The initial release still feels like a bit milestone – something to be considered carefully.

Partly, I think this comes from the observation that so many things get a huge amount of initial ‘buzz’ when they first launch. And then this drops off a cliff after a few days, and often never gets discussed again. Social media makes this initial spike even more dramatic. You can see this happen with big projects like Google Buzz and Google Wave, both of which launched in a wave of publicity, and then nosedived and became pretty obscure. I’ve also informally heard from friends that this pattern has been repeated for some of their projects.

The question is, then, given the initial peak of interest might be all you ever get, how long should you wait and how much perfection should you put into your products before shipping?

Comments

  1. Ashley Moran said:

    It depends on the cost of launch issues, I think. Releasing life support software, a payroll system, or a consumer electronics device with an audience of millions before they are ready is asking for a crisis. Releasing a TextMate bundle, a media player, or a Pomodoro timer early will probably get useful feedback from people willing to try it.

    I’ve been thinking about this myself too lately. I’m working on a basic template-based checklist app (surprisingly, there don’t seem to be any already, at least nothing useful) just because I know it’s something simple I can release without consequence. The worst is it will be useful for me and no-one else.

    I also just released a Ruby gem for rebuilding databases, which has all of 86 lines of code in it. I’ve sat on it for almost two years :-/

    Incidentally, while I still don’t know what Google Buzz does, I pretty much run my business off wave. So maybe if it hangs around long enough the beta users will help refine it into something with broader appeal!

    The question to ask might be… of all the stuff you can think might be wrong with your app, how much can you obviously fix now, how much do you _need_ to fix now, and how much will be decided better by other people using it?

    • Thanks for your take Ashley. I think you’re right that the scale of the ‘thing’ matters. If it’s a small thing which aims to be useful/engaging to people in the medium/long term, then maybe releasing early is more useful. If it’s a fun/silly thing that aims to simply be a bit cool/interesting, then maybe it’s better to launch with a big bang?

  2. Ashley Moran said:

    Releasing early for things that can start small and grow makes sense. You’re probably right about cool stuff needing a big bang, anything that will have a high-profile marketing impact might fit in that. My gut feeling is that more things come into the former category than the latter… turning something into a high-profile big bang launch that needs to be right or it will fail might be a self-fulfilling prophecy. But then, I’m cynical at the best of times :)

  3. Nic Ferrier said:

    I really like your source and I really like your point, it’s tricky and I understand the temptation. But imho, release-early-release-often is about getting feedback quickly to make the execution good: release, get feedback, kill the idea or iterate; quickly moves whatever you’re doing to “ready”.

    So sometimes you release and it feels like it’s going nowhere. That’s probably a negative, review but you should keep going until your energy runs out or people definitely hate it.

    It seems like some people won’t look at it twice, and maybe they won’t. But there are always more people.

  4. Pingback: Rattle » Week #1274

Add comment