A long time ago, I received a request to identify subconscious mapping knowledge, that is all those bits and pieces that I use to create maps and which I consider not to be important enough to even mention them. For a long time, I thought there was no such knowledge, since available materials cover mapping theory to a sufficient degree, while the rest has to be acquired by practice, practice, and again, practice.
However, Matt Edgar's testimony made me realise that things are not that simple, and that personal experiences may change the way in which a given situation is perceived.
A great example is the perspective difference between component supplier and consumer.
The typical consumer sees only two things - component output (delivered value), and sometimes, associated process (how you should interact with the component to get the value). More, the consumer can usually compare delivered value and associated processes from different providers, therefore (s)he has no problems in assessing component maturity (and related uncertainty).
The producer perspective is completely different. Focus on operational excellence and day-to-day competition causes dependencies and processes to overshadow user needs and delivered value. It becomes very tempting to determine the maturity of the component output based on characteristics of the process. For mature components, it will lead to correct results, but only by coincidence.
If new use cases are discovered, pressure to change may mount on our component; the component will have to become more efficient, and it will shift to the right on the evolution axis. It does not mean the shift will be significant. It may be as small as moving from 'Utility' to being more 'Utility'. Yet, the underlying process is likely to be devastated, as it is necessary to build value chains that can deliver better value, and to define processes in which it will happen. There will be lots of uncertainty to deal with, at least in the beginning.
The producer, that earlier drew the equation sign between process and output, sees a new process, and assumes that the component is unstable because of all those changes the producer has to deal with. While, in fact, from the customer perspective, changes to the output are subtle.
To sum up - even a small change in component evolution may cause a significant change in the underlying dependency chain and related process. However, it is output that is a base for determining evolution.