We’re working with a couple of companies right now who are gearing up to shipping their products. They’re very different products in very different spaces, but there are a number of issues they have in common:
1. What exactly is it that we’re going to ship?
Technology businesses often get lost in the feature list. You don’t necessarily need to ship everything first time out of the door – especially that stuff you’ve only just crammed in at the last minute.
Make sure you know exactly what value everything brings to the end user, and be ruthless about cutting stuff that looks like bloat. You can always add it in later, but you’ll never be able to take it out again.
2. And how are people going to get it?
If your product runs in the browser, then you’ve got a relatively easy life. Because installers are hard. Really, really hard.
On the plus side, there are plenty of guidelines to follow (there’s good information here and here for the Microsoft stack). If you haven’t been planning for install (and upgrade) since the very beginning then it isn’t too late, but it is going to be more difficult.
The art of installation comes in three parts:
i. Prerequisite management (the hardest bit) ii. Getting the bits onto the disk, and letting the right users access them iii. Updating the bits when you have a change
i. Prerequisite management (the hardest bit)
ii. Getting the bits onto the disk, and letting the right users access them
iii. Updating the bits when you have a change
Make sure you’ve covered all of these in your installation process, right from the very first release – especially your update strategy. v1.1 will come frighteningly hard on the heels of v1.0.
Testing is then the key – you’re going to need a wide range of test environments (virtualized, naturally), just for installation. Every user that downloads your trial software and has a lousy installation experience is a lost customer; don’t skimp on install/uninstall testing.
3. When they’ve got it, are we sure they’re going to know what to do with it?
Have you invested in “getting started” and “how to” documentation? What about a walkthrough video? FAQs? A web forum? A web forum that you used during your soft-launch/beta testing to seed some user-generated content? Who’s looking after your web/email support? Do you need to run “getting started” webinars – like salesforce.com do?
None of that is very expensive, but it makes a massive difference to your users’ first experience of the product. Oh – and make sure it is all available to people just trying it out, too.
4. And, is it likely to work?
You can’t test enough – but you can waste an awful lot of resource testing “known good” (or “known bad”). But, whatever your process, you can’t ship-test a moving target. This may sound stupid, but until you stop changing the code, you can’t ship. Stop. Stop now.
Right. You’ve stopped. Now – you need to work out when you’re going to stop fixing bugs. Not finding bugs. Fixing them.
Every bug you fix increases the chance of you creating another bug somewhere else. And testing will find bugs – especially beta testing. Have a process for investigating, prioritizing and then deciding whether to fix.
Don’t fix a bug at this stage because it is easy to fix; fix it because it will seriously impact on your customers. Remember you’re trying to stop doing anything else to the product. Including bug fixing.
I know this all seems pretty obvious, but I think we sometimes lose sight of the obvious when we’re in throes of shipping – especially shipping for the first time. Which brings me to…
5. You have to ship
You’re not going to make money/get investment/get sold without shipping. Companies have done so in the past, but that’s not going to happen in the current climate. Well, not often…
Page rendered at Thursday, September 09, 2010 6:45:00 PM (GMT Standard Time, UTC+00:00)
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.