Speaker
David Heinemeier Hansson
Appearances over time
1 episodes
Episodes
1
Podcasts
Quotes & moments
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.
Promising a feature for later is a weaselly way of saying yes while avoiding the immediate consequences — a tell that it's not truly a priority.
A bullet point on a roadmap makes customers believe a future feature will solve their specific problem, when in reality the final shape of the feature may not match their expectations at all.
Microsoft was forced to remove AI features it had crammed into MS Paint and other products after customers rejected them as making the products worse.
Finding a promising AI use case is not enough — it must be fully solidified into a great final form before it's worth shipping.
Hearing the same request repeatedly is your signal — not a written list. The moment you write something down, you create an obligation. Most individual feedback reflects one person's scenario, not the product's true direction.
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.
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.
A one-line bullet on a roadmap means nothing. Customers imagine their specific version of 'calendar' or 'guest access,' while the final product takes a completely different shape. Buy software for what it is today — everything else is gravy.
37signals plans roughly one month ahead and nothing more. Launching one feature opens trails to the next — rigidly pre-planning six months out kills that optionality. Basecamp's 22-year track record is the argument: if you're worried about uncertainty, look at the longevity.
Every time 37signals made a public promise about a future feature, it ended in regret. Not always because the feature was wrong, but because the deadline crowded out everything else. Deferring a promise is a weaselly yes — if it truly mattered, you'd be building it right now.
Apple made public promises about Apple Intelligence before they had the team or technology to deliver. By setting deadlines they couldn't hit, they transformed themselves from a company iterating on AI into one that 'missed a deadline.' If even Tim Cook buckles under this pressure, you're excused — but you should still resist it.
Every company in the middle of the AI wave has uttered the phrase 'we gotta do something.' That phrase is an expression of fear, not strategy. Something almost never becomes great — Microsoft proved it by jamming AI into MS Paint and then having to pull it out.
37signals has tried many AI use cases and found glimmers — promising signals that something could work. But a glimmer isn't a product. It needs a final solid shape. You can't ship gas. When it's solidified and great, it ships.
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.
Analysis
What they talk about
- Business 50%
- Technology 50%
Connections
Shows they appear on and people they share episodes with. Drag to explore.
