The Purpose of v1.0 is to Make a Great v2.0

versions

What drove us to become the consumers we are today? We want everything right now and just the way we like it. For the most part, these expectations are met: faster this, more options in that, and everything cheaper.

Unfortunately, when we move into our work environment we also apply these same expectations to our internal projects that create new products or significantly overhaul existing ones. End users, subject matter experts, and project teams alike strive to create a perfect product right from the get go. “I need to add this” and “can we change that?” can be heard in project status reviews.

The problem this causes is that to push a product from 80% to near 100% of the wanted capabilities or desires requires a disproportionate amount or extra effort and time. Plus, the additions have a little bit of baggage that comes along with them:

  • Often they are the wants of an individual that is not necessarily shared by the larger user base.
  • They are enhancements or mitigations related to a projected reality that never materializes.
  • They require modifying newly built components, exposing them to potential problems.

A better way to create a new product or significantly overhaul an existing one is to create a version 1.0 and already have a plan for version 2.0. There are many reasons why this is the way to go. The greatest of these is that it is congruent with and efficiently leverages an end-users horizon line. End-users have a good idea of the core requirements they want for a product. However, they tend to be vague with some of the finer details and only become clear about them after they begin interacting with the core product. Creating a product with 80% of the capabilities or desires gets it in the hands of the end-users faster and thus provides value sooner than later. It also cultivates better requirements through experience for version 2.0 with less wasted effort and time.

For example, Apple’s iTunes application has the lion’s share of the market and is amazing and fun to use, but remember it started with a version 1.0 that was a rough diamond in the works. In fact, Apple purposely waited to introduce the iPod that took advantage of iTunes until version 2.0 was released. It is easy to not be aware of this as the initial version of iTunes was not as widely used as it is today today. Our expectations as consumers are a little tainted as we tend to not be early adopters and only experience products that are mature.

Of course not all products can afford to be less than the best when they are first created. Bridges, space satellites, and bullet-proof vests have to do their job well on day one. But, these are the exceptions. You may think this is also the case with conferences and training workshops. They may be one-time events for the participants, but because they do occur again in several months there is an opportunity to make a great version 2.0.

So how do you change a person’s mindset so they will accept an 80% version 1.0? You make sure they understand and experience the plan of how they will get to a great version 2.0. The plan has to involve:

  • Version 1.0 having all the core requirements built out
  • Delivering version 1.0 on time to create value right away
  • A repository of detailed enhancements to be created and tracked
  • Developing a schedule for version 2.0 before version 1.0 is started

Once people experience the full cycle of a version 1.0 followed by a great version 2.0 they will be much more open to it in the future.  It really does lead to a better product in a shorter period of time with less wasted effort. Give it a try. There is really no down side to it.