The typical specifier does not understand the technical details and technical risks involved in building software. That's not their job. And if they did understand, engineers would become easily replaceable and their salaries would fall through the floor. For example, part of the job of marketing and sales people is to understand what the customers want, so they are able to provide great input when deciding what to build. It is not, however, part of their job to know how to build those things, which is why it's not uncommon for them to come up with ideas that are wildly expensive or literally impossible. And that's fine. Not every idea is feasible.
It's also often not specifiers' job to understand delivery risk, although it is highly desirable. Product people often don't have a good sense for whether building any given feature will be easy peasy lemon squeezy, or stressed depressed lemon zest. That's because there are knowns and unknowns that are deeply technical in nature, and only the people actually building the software have a hope of identifying where the landmines are. Product people with deep technical knowledge are incredible assets, but also exceedingly hard to find and probably outside of your price range.
So then who is actually responsible for the delivery of quality, working software? Whose job is it to deal with these deeply technical unknowns and the risks they pose? The most practical choice is engineering. Engineering is in the best position to understand and mitigate delivery risk — less so the individual engineers writing the code, and more so engineering management/leadership. Engineering management is the interface between the specifiers and the builders, and it is their job to ensure that delivery happens smoothly.
This is why I believe that non-technical engineering managers are generally a bad idea — but that's a topic for another time.
<https://www.tomdalling.com/blog/software-processes/against-must-haves-part-two/>
very respectfully,
kushal