As I read your text and think about the various projects I worked on over the past fifteen years, I realize that there is another important reason: a 1.0 is as much about learning as it is about building. Many things making up 1.0 will have to be replaced with a better solution even if, from the outside, nothing changes. It simply means that working from 1.0 onward needs to take into account fixing/improving to get the product better suited for future enhancements.

Rule #1: Even if you don't look for alternatives and just go on with business as usual you still are making a choice. Just an uninformed one.

The problem however, is that not many people understand what exactly made their product a success in the first place. People, involved from different departments, will all see their contribution as the key element. They might be so confident as to get involved in their own start-up and they will probably fail. They didn't learn from a succesfull 1.0 and assume that repeating prior a contribution [because it was the key contribution] will automatically result in similar success.

I dare say that many who today run a succesfull business would, putting back the circumstances to the original situation, just as likely fail if there would be just a small fluctuation in environment. For them, a 1.0 could even be a second product, but there is no guarantee it will be a success. As a company they might survive because of earlier success.

Rule #2: Statistically, if enough attempts are started, some will succeed. That doesn't mean that success was a direct result from the efforts put into the attempt. (In psychology, there are some fascinating experiments and how people react with regard to this rule)

Equaly bad is someone in charge who read some book and chose a methodology, but is otherwise new in a field. There is no substitute for experience, but that means that you need a person who has looked back after each milestone to check whether what was planned to happen did indeed happen. Some managers see looking back as a negative thing, but they are simply denying themselves vital information for future projects. Each involvement in a 1.0 attempt will add to the experience to make future attempts more likely to succeed.

Rule #3: A methodology is like Polaris, the star hovering the North Pole: ideal for getting your bearings, but the goal is never to actually go there. (This also goes for Rands upsidedown piramide)

Since my very first project have I always tried to get back to the origin: where did the specs come from? Who was the first customer? Who designed/build the various part and what was the motivation behind those choices? If possible, what do customers say? Asking questions will results in anekdotes and long walks down Memory Lane, but to understand where a product is and where it came from, it is essential. (Plus, listening makes more friends then talking.)

Important is that the reason that something got started might not be reason enough to continue (see rule #1)

From very early on have I been a designer/key-developer/projectleader and I have tracked many projects that I wasn't even involved in directly. Those who were involved might not have seen it as important information, but I did.

I say this as much to whoever reads this as to myself. Currently I am in the process of defining a product for a start-up that I will be creating with two partners. I will be in charge of the technical aspects and, although I've done projects many times before and I am an independent software developer at the moment, it is the first time that I am this closely involved in building a company.

I am confident that we will succeed or I would not be involved, but I will take a lot of effort. Being human (or at least closely resemble one enough to fool even myself), I am prone to the same over-confidence that repeating prior contributions will lead to success. However, my businesscard reads (my own choice ): programmer, because basically, I create programs.