What influences the value of the product?

Agile or life cycle management

At first glance, Agile and flexibility primarily imply short-term prioritization, while formal product lifecycle management is quite the opposite, namely the whole range of changes that accompany the existence of a product from the moment it is developed to the moment it becomes completely unsuitable. Then how to determine the relationship between these two categories? Just at this moment the value of the product comes to the fore.

What influences the value of the product?

')
If we approach this confusing problem from the point of view of philosophy and start asking questions, then the first and most important of them will be the question: for whom is the product made? The answer is simple: for users. What do users associate with the benefits of using the product they paid for? The answer is again simple: with the nominal value of the product. This is a basic definition of the value of a product. Over the years, this definition has moved away from its primary meaning and has become a rapidly developing category containing an understanding of the value of a product. This is because the very concept of value and its definition has undergone a number of significant changes over the past 10 years.

What is the value of my product?

In search of an answer to this question (what is the true definition of the cost of a product?), I processed a lot of different sources, where from different points of view we spoke about the assessment process and product life cycle in software production. But I did not manage to develop an integrated approach. As a result, I found the answer where I expected the least.

It all started with a non-binding dinner table conversation, when I exchanged views on the industry’s development trends with the CEO of a very well-known and reputable company that profits from production and development by more than $ 2 billion (I’m talking about so that the reader gets an idea of ​​the level of seriousness of opinions). The topic of discussion was how blurring the line between product and service at the current stage of technology development. Soon I began to connect the understanding of this phenomenon with Agile and Scrum. Everything turned out to be trivial - the border was not just erased between the product and the service on its own. Rather, the sensitivity and receptivity of a highly volatile market have been and remain the causes of tension in the technology business.

Over the past 10 years, pressure on manufacturers of products and services in this highly competitive industry has grown exponentially. Tightening of economic conditions all over the world has also contributed - large and small companies need to be much more flexible and dynamic in the production of software.

You get what you paid for!

While this motto may be relevant to other products and resources (where the premium class meets the highest requirements for the product), in the technology sector, it looks doubtful and brings up a number of funny analogies. As it turned out, research suggests that 45% of the beneficial properties of some products are never (never at all) used by most people.

So, for the production of software from the sample of the 90s, a more suitable slogan would be:
YOU PAY FOR THAT YOU DO NOT USE IN GENERAL!

Now, try to defend the persuasiveness of such a slogan at least before the salesman, not to mention the buyer!

Evidence is attached:


Source: Jim Johnson, The Standish Group International Inc. 2002

You are joking, of course, Mr. Feynman

It is probably not so obvious to the uninitiated, what this is all about and how it relates to Agile or Scrum. But a more experienced specialist would be quite understandable. If you add another parameter, namely the moment from which the Agile methodology began to be recognized as acceptable practice, it will immediately become clear that this is not just a coincidence: the flexible development methodology has been recognized in the past decade and has turned from just a “good theory” into widely used practice. And that was exactly the decade when the technological boom occurred and when the waterfall model became the main model of software development and solutions.

You do not need to be a genius to put it all into one picture and understand why, with the advent of the waterfall model, the value of products for users has decreased:

1. Product capabilities were developed specifically for the target group, which was changing faster than entering the market — the product had capabilities that were no longer in demand at the time of release.
2. Returns from the product did not meet expectations — promising technologies were marginalized because they were not flexible enough to significantly change direction in the course of development.
3. The value of the product was not only and not so much in the number of patents involved in its development, and their genius - believe me, this played a big role - but in how much of this value was added value. This meant that the requirements needed to be changed constantly, it was impossible to afford to spend half a year on honing an important solution for any problem. It was extremely important to be able to maneuver in order to lead the product through the changing conditions at each stage of its life cycle.

Technology survival curve

Y: innovators, first followers, early majority, later majority, lagging
X: Niche search, monetization, increase in profit, withdrawal and termination of support.

This graph is very clear: the process of survival of the technology is related to the key groups that apply it at different stages of the product life cycle. Innovators prepare everything for the first adherents to try the product and demonstrate its viability to the early and late majority, who will invest money in the product and which later will be replaced by lagging users who will “save” gross profit from falling due to their multiplicity. On the X-axis are the stages of the product life cycle, the initial and final points of which are niche search and withdrawal, respectively.

Mathematically-minded readers, this Gaussian curve will easily illustrate the current market situation. For those far from mathematics, I will explain: the scope of use of the product at each of the phases of its life cycle is rapidly decreasing. If earlier it was possible to spend on the development of a year and a half, then now this time frame should be reduced at least twice. This does not mean that the number of people involved in the development must be doubled, and it does not mean that it has become easier to develop and introduce new products. So the only parameter that will help restore balance is adaptability and, to a lesser extent, efficiency.

findings

If management's decision-making is focused on adaptability, and change will be perceived as something inevitable - and now it is necessary more than ever - then there will be only one way to produce working software needed by users. And all this only thanks to Agile-methodology and the use of Scrum as an aid in the process. Anyone have anything to say?