What affects product value?

Agile or lifecycle management

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

What affects product value?

If you approach this confusing problem from the point of view of philosophy and start asking questions, the first of them, and most importantly, will be the question: for whom is the product manufactured? The answer is simple: for users. And what do users associate with the benefits derived from using the product for which they paid? The answer again is simple: with a nominal value of the product. This is a basic definition of product value. Over the years, this definition has departed from its primary meaning and has turned into a rapidly developing category that contains 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 does the value of my product consist of?

In search of an answer to this question (what is the true definition of the value of a product?), I have processed many different sources, where, from different points of view, the process of evaluation and the product life cycle in the field of software production were discussed. But I was not able to develop an integrated approach. As a result, I found the answer where I least expected it.

It all started with a non-binding conversation at the dinner table, when I exchanged views on the development directions of the industry with the CEO of a very well-known and respected company that makes more than $ 2 billion in profit and production (I say this for that so that the reader gets an idea of ​​the level of seriousness of opinions). The topic of discussion was how far the border between a product and a service is being erased at the current stage of technology development. Soon, I began to associate an understanding of this phenomenon with Agile and Scrum. Everything turned out to be banal simple - the border was blurred not just between the product and the service itself. Rather, the sensitivity and susceptibility of a highly volatile market have been and remain the cause of tensions in the technology business.

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

You get what you paid for!

While this motto may be relevant for other products and resources (where the premium class meets high product requirements), in the field of technology it looks doubtful and causes a number of funny analogies. As it turned out, research suggests that 45% of the beneficial properties of certain foods are never (never ever) used by most people.

So for the production of software from the 1990s, a more appropriate slogan would be:
YOU PAY FOR WHAT YOU DO NOT USE AT ALL!

Now, try to defend the persuasiveness of such a slogan even to the seller, not to mention the buyer!

Evidence attached:


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

You are kidding, of course, Mr. Feynman

It is probably not so obvious to an uninitiated person why this is all and how it relates to Agile or Scrum. But a more experienced specialist would be quite understandable. If you add one more parameter, namely, the moment from which the Agile methodology began to be recognized as an acceptable practice, it will immediately become clear that this is not just a coincidence: the flexible development methodology has been recognized in the last 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 and solutions development.

You don’t need to be a genius to put all this into one picture and understand why the value of products for users has decreased with the advent of the waterfall model:

1. The product features were developed specifically for the target group, which was changing faster than entering the market - the product had features that were not already in demand at the time of release.
2. The return on the product did not meet expectations - promising technologies turned out to be on the sidelines, because they were not flexible enough to significantly change direction during 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, it played a big role - how much in what part 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 guide a product through changing conditions at each stage of its life cycle.

Technology Survival Curve

Y: innovators, early adopters, early majority, late majority, lagging
X: search for a niche, monetization, increase of profit, withdrawal from production and termination of support.

This graph is very clear: the process of survival of technology is correlated with key groups that apply it at various stages of the product life cycle. Innovators are preparing everything so that the first adherents try the product and demonstrate its viability to the early and late majority, who will invest money in the product and which will be replaced later by lagging users who will “save” the gross profit from falling due to their large number. On the X axis are the stages of the product life cycle, the starting and ending points of which are the search for a niche and decommissioning, respectively.

For mathematically-minded readers, this Gaussian curve will easily illustrate the current market situation. For those far from mathematics, I’ll explain: the scope of use of the product at each phase of its life cycle is rapidly decreasing. If earlier it was possible to spend one and a half years on development, now now these time frames should be reduced at least by half. This does not mean that the number of people involved in development needs to be doubled, and 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.

conclusions

If the decision-making by the management is oriented towards adaptability, and changes are perceived as something inevitable - and now it is necessary as never before - then there will be only one way to produce working software that users need. And all this is only thanks to the Agile methodology and the use of Scrum as a tool in the process. Does anyone have a thing to say?