The antithesis of this is the contract model, when a client comes to you and asks you to make something specific, rather than describing what they need. In this case they are almost always wrong. They’ll rarely admit it unless you show them some amazing alternative, though.
Requirements = a set of problems to be solved. More often you get handed a diagram of a 12” tall Stonehenge sketched on a napkin with exceeding confidence that it will be 12 feet tall.
Then they yell at you for doing what they said.
(Probably not a real quote, and probably not even accurate.)
In either case, the customers aren't stupid but instead are using the language and paradigm they are familiar with to describe their needs. Ford did indeed provide a faster/better horse, because the horse was the main means of non-human motive force in the US.
The technologist's job is to understand the universal of possible solutions and to understand the customer's needs and goals, which often includes interrogating and parsing the customer's language/worldview, and craft a product that achieves those needs/goals (and doesn't introduce negatives that overwhelm the benefits).
A lot of the times this might be wrong but I think the interesting part is how that request gets handled.
/s but maybe only half
It is correct that "Requirements = a set of problems", and therefore it does not make sense at all to repeatedly ask the client for a technical solution instead of asking for the problems to solve, and then be surprised that the client does not talk about problems anymore.
We recently got a support call from an upset client. A recent change had broken their integration, halting production.
This lead to some head scratching on our side, as we couldn't figure out what integration they were talking about.
Turned out they had paid some consultant quite a lot to script some tool similar to AutoHotkey to transfer data from their order system to our system. It would emulate copy pasting fields, tabbing along.
Our recent update had introduced a new field, thus screwing it all up.
As an aside, the "integration" used half an hour to transfer a single order due to how it did its work. An XML would have taken seconds tops.
It happens quite a bit - people solve the problem they have with what they know.
At this point, wasn't banning him in the cards?
(Humans will really adapt anything into a weapon, including human lives themselves, especially in a total war)
* Poor Japanese fighter aircraft design philosophy (weak armoring, no emphasis on pilot survival).
* Poorly trained pilots (all the veteran, experienced pilots are dead because see above).
* Poorly maintained aircraft (insufficient supplies and manpower).
* Insufficient ordnance (insufficient supplies and manpower).
* Insufficient fuel stores (so a one-way sortie out was all they could afford).
* Insufficient food and drink (a pilot going out to kamikaze is one less mouth to feed).
* Fanatical and delusional military brass.
