Release of new versions of the application

On Habré, if you wish (or even without it), you can find more than one post dedicated to startups. However, for a “long and happy life” a quality startup is not enough. In other words, after the release of the first version, the project should continue to evolve. So, there should be new versions.
Obviously, for commercial success, the new version should be "better" than the previous one. On the other hand, practice shows that for developers and users the term “better” does not always mean the same thing.

I was “lucky enough” to combine the work of a developer and a project manager. In other words, I not only write code, but also decide what needs to be changed / added / deleted. Moreover, the subtleties of the latter had to learn "on the go", analyzing the successes and mistakes of their colleagues. Actually, I want to devote an article to these observations.

I came to the conclusion that the new version of the project will be successful if it meets two requirements:

• The user will find in it the changes he expects.
• The user will not find changes in it that he does not expect

Changes that the user expects

They can be classified into two types:

• Error correction
• New opportunities

It would seem that everything is simple. But this simplicity collapses when there is a problem with the deadlines and the question arises: “Correct the remaining mistakes or add new features?”. An unequivocal answer can not be given. Of course, perfectionists will say that it is necessary to correct mistakes. However, the market says that people will pay for new features. As the smallest of evils, you can first fix critical errors, and then try to add new features without adding new errors. Everything else can be fixed with the help of hot fixes and patches, although it is not too "beautiful." In my case, the choice of this particular strategy gave the best result.

Changes that the user does not expect

Unfortunately, sometimes developers accidentally (or intentionally) forget about this point. The reason for this may be that they are trying to attract new users. However, you should not forget that the success of the new version of the software largely depends on whether the users of the previous versions acquired it. And it is for them that such changes may turn out to be critical.
The list of types of such changes can be very large, but I’ll focus on two:

• backward compatibility
• Design change

Backward compatibility is very important. People who have used your product for years (and why not) will be very “discouraged” upon learning that the new version is not able to work with their projects. So you can say that you lose them.
But with the change of design is not so simple. On the one hand, it must be changed. As time goes by, technology changes and the “hi from 1999” design is no longer popular. On the other hand, practice shows that many users are very conservative. They are very painful to worry about because of the “missing button right here in the corner” or even because of a change in the color scheme. Therefore, a very good solution would be to add a “old-style” checkbox somewhere in the settings.
')

Conclusion

Of course, there are actually many more problems. I just tried to describe those of them that I encountered myself. Perhaps, if more serious problems or reliable solutions - I would love to hear about them.
As a guide to action, I want to add the following. You should not consider users simpletons if you are not Steve Jobs. Personally, I chose the approach “the user knows what he wants, but cannot explain it”. At the moment, both I and the management are satisfied with the results of the approach.