In most companies there's an understandable reluctance to commit significant budget to new ideas unless they're very well proven, and - critically - enough people in senior positions think they're good ideas.
So in order to get sufficient momentum for an idea, it needs to be repeated and communicated many times - and thereby loses any nuance of meaning. It becomes necessary to distill the essence of it into an "executive summary" that, especially for technical ventures, often misses the point by a small but important margin.
In the company I currently work in, various technical people, including myself, have been pitching to refactor a particularly complex area of our architecture. It doesn't perform as well as it needs to, and is also the frequent source of insidious bugs in our live environment which are hard to debug since the system is hard to reason about.
We have a proposal for how it could be designed differently, but in order for this proposal to gain momentum, the point of the work has been diluted through Chinese whispers to the basic premise of "Make it go faster". The enormous benefits in future technical enablement are glossed over. (Of course, in most companies, eliminating technical debt is considered a Good Thing, but when it come to the crunch, no one wants to invest in it. Where I work now is a hundred times better than most at this, but it's still short term wins that really get people going).
Why does this matter? The message that has become fixed on is the short term performance benefit which yields greater opportunity for sales. This benefit is much smaller than the more intangible longer term advantages, and so the idea hasn't made it very high on the agenda.
What's more, ideas with no short term benefit will probably gain no momentum at all.
And when (if?) the idea comes to be engineered, the senior business stakeholders may be impatient for it to be completed, as they don't understand the nuances of how much long term benefit they will be getting. In some companies, this can lead to the project being canned before it's complete (see Death By a Thousand Incomplete Refactorings), or made more difficult by technical teams being asked to work on short term things in parallel.
If only business people could invest more time in understanding technical matters. Of course, one barrier is that us techies are often resistant to that at a subconscious level - we take pleasure in our area of expertise being impenetrable in much the same way I suspected Polish people liked seeing me struggle with their pronunciation and grammar when I lived there. (Different endings for different numbers of things - seriously?)
But the other barrier is that we make our systems too complex. Perhaps a good rule of thumb should be: If non-technical people don't understand our systems, then they're too complex.
So, returning to the topic of gaining momentum and losing nuance, what's the answer? It seems to me it's the same answer I return to again and again in IT (and many other areas):
Better to restructure your organisation to allow for small independent teams to make their own decisions and set their own direction. That way, less momentum needs to be built up and more nuanced communication can occur, using a rich shared vocabulary.