Where this was said
Handling feedback on the technical and open source side
At 6:43 · chapter starts 3:08
DHH opens with a wry observation: open source contributors don't pay him, so he feels zero guilt telling them they're completely wrong. That bluntness, he argues, is a pressure valve — it lets him stay measured and professional when dealing with paying Basecamp customers who deserve a more considered response. But the substance cuts deeper than just professional etiquette. [1] — David Heinemeier Hansson "Customers are software users, not software designers. They can identify what hurts, but they can't prescribe the right fix for a broad user…" 05:08 He draws a sharp distinction between the customer as pain-identifier and the customer as solution-designer, arguing these are entirely different skill sets. Most customers are software users, not software designers — they can point at what hurts but cannot prescribe the right fix for a broad audience. The real insight, he explains, is that seemingly unrelated feature requests often trace back to the same underlying wound: your job as a designer is to recognise the constellation and find the grander simplification. The worst outcome is taking customers at their word and just applying duct tape to whatever is visibly sticking out — it looks awful and leaves the structural problem untouched. [1] — David Heinemeier Hansson "Customers are software users, not software designers. They can identify what hurts, but they can't prescribe the right fix for a broad user…" 05:08
On open source projects, DHH can tell contributors they're wrong without professional consequence — because they don't pay him. That candor is a pressure valve. It lets him stay measured and professional when dealing with paying Basecamp customers, where the same bluntness would be inappropriate.
Customers are software users, not software designers. They can identify what hurts, but they can't prescribe the right fix for a broad user base. Your job is to look past the patch request and find the structural problem underneath.
Customers know what doesn't feel right but are rarely equipped to know how to fix it or what the right solution is for a broad user base.
Seemingly unrelated feature requests often stem from one underlying problem, and a designer's job is to identify and solve that core issue.
Microsoft famously prioritized features by tallying request counts, which Apple criticized as the wrong way to build great software.
Microsoft once ranked features by how many requests they received. Apple's charge against them was that this is entirely wrong. You only hear about the duct-tape fixes customers can articulate — not the structural problems, and not the people who never signed up because the product was wrong for them.
