Users without programming skills have a very different appreciation of value delivered by programmers then programmers themselves do. If programmers deliver lots of user interface with lots of information a typical user relates such outcome with large amount of work involved. But if the end result of programmers' work is just a single number it's very hard to understand for the user that quite often it takes a much larger amount of effort and time to deliver that single number than it would take to deliver information-laden complex user interface. And if a user is capable of coming up with that single number also himself (for example, using a spreadsheet) explaining complexity involved in delivering that single number automatically by a machine becomes impossible.
Such propensity of the users has substantial influence on product development. First, if the product engineering delivers a functionality which to the end users looks simple to implement the true cost of delivering such functionality (in terms of time and/or money) cannot be revealed to the users since they will not find it acceptable. Second, if the product engineering delivers a functionality which wows the user but is simple to implement. it is a waste to expose the true cost of delivering such functionality. It's much better to bundle such functionality with the functionality of the first type and come up with a package whose perceived value to the user is commensurate with the engineering effort. Third, product engineering shouldn't be delivering a functionality which in the eyes of the user looks difficult to implement but superfluous even if it takes very little time for developers to actually deliver it. Delivering such functionality makes users thinks that product development is disregarding real users' problems and wasting precious engineering resources.