Reasoning patterns, that make unsuccessful products

[Russian version]

After a while, I'm greeting my readers again. If you haven't been one yet, I'm pleased to meet you.

During my career I've noticed, that some patterns in people's assumptions and expressions lead to negative outcome in the area of product development. I've learned these patterns, while collecting information about different businesses.

My background can clarify why I've come up with this topic. At work I'm managing the development process in a broad sense; I'm managing projects pools, and also I'm doing business analysis (2014).

Everyone, who participates in discussions of some ideas or solutions, decision makers, and managers, belong to the target audience of my article.

Today we are going to talk about how one can identify the moment, when somebody has a wrong assumption or intention in context of product development. And what the result of such a nasty situation might by. Also we are going to discuss possible solutions.

Consequences of neglected quality

“And in those days people will seek death and will not find it. They will long to die, but death will flee from them.”  Revelation 9:6

Hello everyone! I'm pleased, that you are reading these lines. I'm sorry for the excessively pompous epigraph, but I want to talk to you about the topic, which can't let me go.

Very often I hear people saying: `We shouldn't care about good code and system architecture, because we don't know whether the product will be a popular or not...`

Or something like this: `We will care about code and architecture in the next iteration, because the Sacred Agile allows us this trick...`

Yes. I want to talk to you about the “Technical debt”. And moreover, it would be great to hear your opinion about my thoughts and assumptions.

Let's assume that somebody created a product. He or she has done it with both or one of two assumptions: `agile let me not to think about architecture and code` (I still don't understated where people finds out something like that in agile), and `i think about it when the product shoots up` (But they don't usually fulfill the promise, because there is always something, that is more important).