Graham vs. Buchheit: All else being equal, should startups seek out hard problems or avoid them?
7 comments
I say down with such vague philosophical arguments:)
paul says that the way to build successful products is to avoid hard problems:
http://paulbuchheit.blogspot.com/2007/04/secret-to-making-things-easy-avoid-hard.html http://news.ycombinator.com/comments?id=16409 http://news.ycombinator.com/comments?id=17040
That made a lot of sense to me. But on the other hand, pg's "How to Make Wealth" makes a good argument for precisely the opposite view:
"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him. What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we'd always take the harder one."
http://paulgraham.com/wealth.html
Of course, no piece of general advice is right in all cases. But what should you look for, in a given situation, to know whether it's better to seek out the hard problems or better to avoid them?
http://paulbuchheit.blogspot.com/2007/04/secret-to-making-things-easy-avoid-hard.html http://news.ycombinator.com/comments?id=16409 http://news.ycombinator.com/comments?id=17040
That made a lot of sense to me. But on the other hand, pg's "How to Make Wealth" makes a good argument for precisely the opposite view:
"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him. What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we'd always take the harder one."
http://paulgraham.com/wealth.html
Of course, no piece of general advice is right in all cases. But what should you look for, in a given situation, to know whether it's better to seek out the hard problems or better to avoid them?
Don't seek problems -- seek solutions. Avoid all problems :)
One of the hardest things for a big company to do is move fast. Startups typically have very limited resources, so the only way to move fast is to not spend very long on any one problem, and that's generally going to mean avoiding problems that are hard. What I'm really advocating here is that you look for the easy 90% solution that seems almost the same to the user but only take you 1% as long to implement.
One of the hardest things for a big company to do is move fast. Startups typically have very limited resources, so the only way to move fast is to not spend very long on any one problem, and that's generally going to mean avoiding problems that are hard. What I'm really advocating here is that you look for the easy 90% solution that seems almost the same to the user but only take you 1% as long to implement.
Thanks, Paul! Between your reply and pg's, I understand your point a lot better now, I think.
advice = limited experience + overgeneralization - pb
I don't disagree with anything PB says. I say to do hard things if they benefit the user proportionately. He says not to do hard things just because they're impressive. Since in practice impressing people (including oneself) is the main reason people do hard things that don't benefit users, these two principles yield the same advice.
I suppose I took PB's post more broadly than it was intended, then. If he was only talking about solving hard problems that don't benefit the user proportionally, I see that there's no contradiction [and have a clear answer to the question of when to follow which advice ;-)].
Thanks for the clarification.
Thanks for the clarification.