Mark Geller

The good news: team KlickFu is close to working through all the major technology issues needed to deliver a fairly solid version of our initial product. Now comes the next challenge, especially for the product manager (i.e., me)–deciding which features are must-haves for version 1.

Part of the challenge is deciding what exactly V1.0 is and what is it going to be used for. In the past, this was pretty clear, especially for a desktop software application. V1.0 was the first version of your software, the one that had to make a big splash with the media, users, potentially software resellers and distributors, and basically everyone else. It was also the version you and your users were going to have to live with for at least 4 months, if not 6 to 8 months (not counting small bug fixes)… so it better be close to perfect, and certainly the best you could possibly make it.

These days, the role of V1.0 is harder to define. It is certainly not the first version of your product you will put in the hands of non-team-members. This we have done already with a super-early version and will do again at least one more round before launching V1.0. For us, then, V1.0 is really the first version we will send to the media for initial reviews and then also make available as part of a private beta distribution with a limited number of invites, maybe 500 total.

Then, as quickly as possible, hopefully within 4-6 weeks after launch, based on the feedback from the private beta, we will address any major usability issues, fix some bugs and add at least one major new feature to go to V1.1 and so on. So really the “V” in V1.0 should probably be a small “v”, because quickly it is going to be replaced by its successor. Without detailing the actual features, which need to stay confidential a bit longer, here are my high-level requirements for v1.0:

• Must be super easy to install and start using
• Must convey the core user experience in a way that is simple and fun, preferably with a single “cool” feature
• Must give the user a sense of what else is possible with future versions
• Must be self-updating–for the next version!
• Must not cause users any undue headaches
• Must be the absolute minimum feature set to accomplish the above

I believe the #1 job of the product manager or team leader is to define the true objective for a launch, select the smallest number of features that will lead to achieving that success, and then have the discipline to exclude everything else. There are several features we would very much like to include in the first version, but since V1.0 is really v1.0 (small “v”), they can wait, for at least a few weeks, and may even result in follow-on media coverage.

I read a quote recently, although I don’t remember who said it, that has become the mantra of our team for this launch: “If you are not at least a bit embarrassed by your first version, you probably waited too long to launch it.”  So we are shooting for something that is cool and simple for users and lays the groundwork for future updates, although also maybe a bit embarrassing when we look back on it from the near-term future.