Most of the products in this world are created by small to medium-sized companies.

Few have the competence - or capacity - to produce a full specification up-front. Probably not even the economy of having the developers waiting for a very large staff of project managers to decide on a design.

The specification may be a rough draft where you wing it a bit, and put up the finger in the air and try to deduce how much extra time and money to spend on the details and functions that will arrive on-the-fly while the project is running.

It can be said that such a concept is wrong. But such a concept is also the reason why small companies are so productive. They have a product ready while the large companies have their staff in the conference rooms trying to make policy decisions about what the goal should be - before even starting to produce a specification.

That is also the reason why large companies tends to buy small companies. They need the working products and the RD team that made them.

The big picture must have been decided, so that a washing machine really ends up as a washing machine and not a dry tumbler.

But an important fact with projects is that when the last percent of the design isn't locked down months or years in advance, there will crop up new ideas an potential improvements as the work progresses. In a small company, such design changes can be decided upon by one or two mails or a three-part phone call. That gives a great dynamism in the project and can be the difference between taking market shares or have your products collecting dust on the shelves.

Using Bugzilla or similar not only for bugs but also for design changes can help a tech writer to catch any late changes and make sure that user manuals, installation documents etc are up-to-date with the resulting product, and not the initial design.

Sometimes you find out that you could have done the product better. Maybe by spending more time on the design requirements, but often not. Most often the missing parts are results of changed requirements in the real world while the product was developed. But that seldom represents a problem. Sell the first 500 and earn money from them. Then release a revision 2 with modified/extended features to fulfill any new requirements that may have cropped up. Maybe the two revisions can even continue to live side-by-side, making your customers see a more complete product line (even if only in their imagination).