21–30 of 35 posts
I'm not sure who this blog is talking to, it feels like classic straw-man argument. Ford never said the car wouldn't solve anyone's problem, in fact his pitch was that the car was better than a faster horse.
It's an argument against using the quote to suggest that you don't need to validate ideas against real users.
Cars have wheels. Okay,tell me about your problems with horses and the way they move?
Cars don't need rest. Okay, tell me about your problems with stopping to feed your horses?
Cars are faster. Okay, walk me through a time when you were late to something - why so?
It's easy for a customer to answer all three answers separately, but they'll struggle to put them all together and come up with "car". They've never seen it before. However, you can still validate because their problems are very real. When you have your concept, you can show it, and then validate the final solution.
This is also known as the XY-problem [1]. People want a solution to X, and they think Y is the way to solve it. But they’re having trouble doing Y and so they ask for help with Y. The problem is that Y is not the best way to solve X and you’re confused about why they’d ever want to do Y. Life would be much easier if they had just asked for help solving X. [1] https://meta.stackexchange.com/a/66378
Is there a name for the reverse, when Stack Overflow assumes you don't understand your constraints and propose all possible solutions to what they think is X that aren't a solution to Y?
[1] https://www.sas.upenn.edu/~haroldfs/540/handouts/french/unin...
There is a quote by Don Norman on the matter that I like very much (from "The Design of Everyday Things"): > Requirements made in the abstract are invariably wrong. Requirements produced by asking people what they need are invariably wrong. Requirements are developed by watching people in their natural environment.
You can never perfectly plan how an application or any other arbitrary convenience should be in isolation of the user. You can certainly get very close, but there is something about actually using a thing that cannot ever be fully simulated in an authentic way. The way a knob feels to a person is not a thing you can ever truly encapsulate and store in a database field.
Constant feedback and iterating on that feedback is how you arrive at ideal outcomes. The art of developing software or other high-quality user experiences is a very iterative, chicken-egg-style problem. It is a human problem. Being prepared to throw it all away and start over each time you iterate is one of the most powerful things you could ever hope to do. Just keep a copy of what you tried before as a stick to lean on. Each time you iterate, that stick should be getting stronger. Eventually you wind up with a bunch of sticks and you can start to chop them up, reorganize them, and build a proper structure.
Stated another way: Listen to your customers, but don't feel obligated to do exactly what they say. > Just ask “What is your top problem?” People will answer this question in the form of imagined solutions or improvements to existing systems, so it's not a matter of simply asking a different question, it's a matter of digging into the answers and needs.
I'm not sure who this blog is talking to, it feels like classic straw-man argument. Ford never said the car wouldn't solve anyone's problem, in fact his pitch was that the car was better than a faster horse.
Agree with you. I think this blog post is about the same. Whatever Ford said, this quote is famous (most likely he did not say that, btw)
I just took that bit at face value, but you are right... and makes this blog post even less palatable.
There is a quote by Don Norman on the matter that I like very much (from "The Design of Everyday Things"): > Requirements made in the abstract are invariably wrong. Requirements produced by asking people what they need are invariably wrong. Requirements are developed by watching people in their natural environment.
Stated another way: Listen to your customers, but don't feel obligated to do exactly what they say. > Just ask “What is your top problem?” People will answer this question in the form of imagined solutions or improvements to existing systems, so it's not a matter of simply asking a different question, it's a matter of digging into the answers and needs.
This is also known as the XY-problem [1]. People want a solution to X, and they think Y is the way to solve it. But they’re having trouble doing Y and so they ask for help with Y. The problem is that Y is not the best way to solve X and you’re confused about why they’d ever want to do Y. Life would be much easier if they had just asked for help solving X. [1] https://meta.stackexchange.com/a/66378
Is there a name for the reverse, when Stack Overflow assumes you don't understand your constraints and propose all possible solutions to what they think is X that aren't a solution to Y?
Ford Motor Company was Henry Ford's 3rd car company, and by that time there were probably 15+ car companies in Detroit alone.
As a curious aside, his second car company is still around too. He left after serious disputes with his financial backers; they decided to liquidate the company and brought another experienced Detroit engineer in to do so, but he recognized the value and convinced them to continue, renaming it the Cadillac Automobile Company.