Yes, the value stream is a powerful concept; but it is often misunderstood.

A customer-facing value stream has nothing to do with how the product is built: it is about how the product is used.

The product delivery value stream is about how the product is built, validated, deployed, fixed, enhanced, etc. It is a separate value stream.

And to make things complicated, if you have multiple products, their delivery value streams probably intersect in some way; and the customer-facing value streams probably intersect as well.

Value stream mapping should not be tackled as an academic exercise, wherein one documents information flow or even flow. It should be done as a series of conversations, in which one tries to understand what the bottlenecks are - the "wastes" as Lean refers to them.

The important outcome is not the diagrams: the important outcome is the shared understanding of what the bottlenecks are, and the sources of problems.

One nit: before Agile, there were iterative methodologies like RUP. Waterfall was primarily used only on large “procurements” that were defined by people trained in PMI who did not understand software development, or by organizations that tried to institutionalize software development — which really happened during the 1990s. Before that, things were actually pretty Agile. The 90s was a huge step backward, largely as a result of the rise of PMI (https://www.linkedin.com/pulse/why-agile-creates-cognitive-dissonance-pmi-cliff-berg/).

It is no wonder that those kinds of projects usually failed. No programmer would ever propose to use waterfall — we all knew it was a terrible way to do things. In fact, if you look at some of the history of programming methods, you can see very early Agile thinking: http://valuedrivenit.blogspot.com/2014/11/history-of-agile.html