Perfectionism
This may be hard for you to believe, but I’m something of a perfectionist. I get a special kind of joy out of tweaking every last detail until it’s just right, making sure each pixel is in its place. Unfortunately, I’ve never really been able to indulge this desire on any of my previous projects, either because my skills are too weak (no matter how much time I spend on it, I’ll never be able to craft a page like John Gruber can) or because time is too short.
At Reddit, for example, we were always rushing-rushing-rushing to get more done. In a recent post, Paul Graham suggests startups can make you rich if you simply make sure to email him once a week. At Reddit we had no such worries: Paul was sure to email us weekly, sometimes even daily, usually asking why we hadn’t added any new features to the site lately. (In fairness, it worked, I suppose.)
When you get that question once a week, you get to try out many different answers, including questioning the premise. At first I give the usual low-level excuses: we weren’t feeling well this week, we had to go to a meeting, Alexis was out of town. Then we started in on more general principles: afraid of change, distracted by day-to-day fires, dissatisfaction with the codebase. And once I sent him Slate’s suggestion that “the Eccentrics’ own egotistical indolence has resulted in self-imposed limits to their skills—at the very least it deprives the world of more of their unique cultural prognostications.” (He was not amused.)
Paul eventually became convinced that we had written lots of good code but wouldn’t release it because we were perfectionists. Knock it off, he would tell us. It’s more important to get it up than to get it right. Paul had become convinced that users love seeing new features, it gave them the impression of an exciting vibrant site.
There is something to this, of course. But I have a contrary proposal: users love perfectionism. Creating something brilliant is a process of continual refinement: adding bits where they’re needed, chipping off others that aren’t, and sanding everything smooth once it’s in place, then polishing it until it gleams. Do one thing, release it, and don’t stop releasing improvements until you do it really, really, well.
Adding features is part of this, of course, but not at all the whole thing. You can’t create a great sculpture just by tossing on more and more clay.
Meanwhile, even if users can’t immediately see all the subtle details you’ve added, they begin to add up to a feeling of — if you’re talented — delight. The software knows where you want to go and has already laid out the trail. The path is worn smooth and shiny. Everything looks beautiful along the way. And every day it gets a little bit better.
For my next startup, Jottit, that’s the plan.
You should follow me on twitter here.
August 31, 2007
The problem with perfectionism is that users can never love what they never see… if a product never reaches perfection, the danger is that the the perfectionist either ends up never releasing it, or dumps out something they know is crap when they get sick of it (regardless of how great everyone else thinks it is) and loses interest in it forthwith.
posted by Gwenhwyfaer
on August 31, 2007 #
I think Paul’s point doesn’t contradict yours—it sounds like he was just proposing that you live out loud. I think your first round of users are sort of expecting to be guinea pigs, and you need to carefully take advantage of them for their feedback. Simultaneously, you are stepping through continual refinement. Hopefully you reach a place of relative perfection by the time your next round of users come through the door, because they may not be as forgiving.
I think refinement tends to follow a series of arcs where you add features and things until you realize there’s too much, then you remove and refine more until they’re back in balance. You could say this about any creative work. The top of the arc is the point where things are at their worst and most cluttered (eg. the four-button-plus-scroll-wheel iPod).
posted by Carl Tashian
on August 31, 2007 #
I think the difference between excellence and something that has a lot of investment (time and money) is that special quality called “talent”.
Like your analogy to sculpture and the amount of clay applied: talent is knowing how much clay to apply and where to apply it.
Timeless art (Michelangelo’s sculptures and ceiling work come to mind) have both: earth-shaking talent and a limitless capacity for personal investment in the effort to make that art.
Make something that delites you and we’ll see the difference. You may not make any oney but neither did Michelangelo.
In the tech world the difference is exemplified by Bill Gates and Gary Kildall. No one remembers CPM any more so we have to use Steve Jobs to illustrate excellence in technology. I can live with that… despite the fact that Jobs drives the talent absolutely crazy at times. In the Michelangelo paradigm he’s the Pope and not the artist: the patron of great works. Gary Kildall on the other hand… genius.
posted by mcd
on August 31, 2007 #
Are you really that much of a perfectionist if you can’t properly spell “perfectionist” (ie. your title)
posted by Brash
on August 31, 2007 #
You’re totally wrong. Users could care less about perfection. Things have to sorta work most of the time, sure… anything beyond that is engineer OCD.
posted by stark fist of reality
on August 31, 2007 #
maybe we need both?
Coda was high on the perfection scale, but they’re losing my excitement because they haven’t been releasing regularly.
posted by tk
on August 31, 2007 #
You can so create a great sculpture just by tossing on more and more clay. If you do it right. OKCupid uses that method, and imho it’s pretty awesome.
posted by Ben Donley
on August 31, 2007 #
tk: Have you tried TextMate? ;)
posted by Jacob Rus
on August 31, 2007 #
Gwen…: I’m not suggesting that you only release when you’re perfect. Just that it’s what you aim for.
Rus: TextMate is the last piece of software that delighted me, but I can’t remember the last time it shipped a genuine change.
posted by Aaron Swartz
on August 31, 2007 #
There are 2 things to keep in mind:
The quality of a delivered product or feature increases logarithmically with delivery time.
The use value of a delivered product or feature decreases exponentially with delivery time.
Let’s call the point on the time graph where the two plot lines intersect “perfect ship date” (PSD). Before PSD you’re creating value by not shipping and after PSD you’re destroying value by not shipping. Since the point is unknowable you have to choose which side of the point you’d rather err on.
I think history shows that erring on the early side is a better survival strategy than erring on the late side. Worse is better: http://www.jwz.org/doc/worse-is-better.html
posted by David Mathers
on August 31, 2007 #
Another example of worse-is-better: I’m reading this on the World Wide Web, not on Xanadu.
posted by David Mathers
on August 31, 2007 #
I just read your thought again and I think I missed your point in my response.
If your point is that a product that provokes an emotional response is delivering significantly more user value than one that is merely functional, then I agree completely.
posted by David Mathers
on August 31, 2007 #
Hey Aaron,
I think you might appreciate the irony of publishing a post on your perfectionism that has a grammatical error in it.
“…Paul Graham suggests startups can make you rich if you simple be sure to email him once a week.”
Ian
posted by Ian
on August 31, 2007 #
Aaron:
TextMate is the last piece of software that delighted me, but I can’t remember the last time it shipped a genuine change.
Yeah, was just responding to tk’s comment about Coda. And yeah, Allan had better get to work on that. :)
posted by Jacob Rus
on September 1, 2007 #
David Mathers:
I think you’re on the right track, but not quite there. In my view, a product can never be “merely functional.” If it doesn’t provoke an emotional response, that’s critical missing functionality.
Well-designed products minimize mental overhead through elegant simplicity.
posted by Jacob Rus
on September 1, 2007 #
Perfection isn’t as important as is a well-adapted system. Determining which functionality best satisfies a majority of the uses for the largest sub-set(s) of your user base will prove more valuable than providing an exceedingly polished set of functions that don’t map as well to solving the problems your users are trying to solve.
posted by John Siegrist
on September 3, 2007 #
You can also send comments by email.
Comments
The problem with perfectionism is that users can never love what they never see… if a product never reaches perfection, the danger is that the the perfectionist either ends up never releasing it, or dumps out something they know is crap when they get sick of it (regardless of how great everyone else thinks it is) and loses interest in it forthwith.
posted by Gwenhwyfaer on August 31, 2007 #
I think Paul’s point doesn’t contradict yours—it sounds like he was just proposing that you live out loud. I think your first round of users are sort of expecting to be guinea pigs, and you need to carefully take advantage of them for their feedback. Simultaneously, you are stepping through continual refinement. Hopefully you reach a place of relative perfection by the time your next round of users come through the door, because they may not be as forgiving.
I think refinement tends to follow a series of arcs where you add features and things until you realize there’s too much, then you remove and refine more until they’re back in balance. You could say this about any creative work. The top of the arc is the point where things are at their worst and most cluttered (eg. the four-button-plus-scroll-wheel iPod).
posted by Carl Tashian on August 31, 2007 #
I think the difference between excellence and something that has a lot of investment (time and money) is that special quality called “talent”.
Like your analogy to sculpture and the amount of clay applied: talent is knowing how much clay to apply and where to apply it.
Timeless art (Michelangelo’s sculptures and ceiling work come to mind) have both: earth-shaking talent and a limitless capacity for personal investment in the effort to make that art.
Make something that delites you and we’ll see the difference. You may not make any oney but neither did Michelangelo.
In the tech world the difference is exemplified by Bill Gates and Gary Kildall. No one remembers CPM any more so we have to use Steve Jobs to illustrate excellence in technology. I can live with that… despite the fact that Jobs drives the talent absolutely crazy at times. In the Michelangelo paradigm he’s the Pope and not the artist: the patron of great works. Gary Kildall on the other hand… genius.
posted by mcd on August 31, 2007 #
Are you really that much of a perfectionist if you can’t properly spell “perfectionist” (ie. your title)
posted by Brash on August 31, 2007 #
You’re totally wrong. Users could care less about perfection. Things have to sorta work most of the time, sure… anything beyond that is engineer OCD.
posted by stark fist of reality on August 31, 2007 #
maybe we need both?
Coda was high on the perfection scale, but they’re losing my excitement because they haven’t been releasing regularly.
posted by tk on August 31, 2007 #
You can so create a great sculpture just by tossing on more and more clay. If you do it right. OKCupid uses that method, and imho it’s pretty awesome.
posted by Ben Donley on August 31, 2007 #
Real Artists Ship.
posted by Jacob Rus on August 31, 2007 #
tk: Have you tried TextMate? ;)
posted by Jacob Rus on August 31, 2007 #
Gwen…: I’m not suggesting that you only release when you’re perfect. Just that it’s what you aim for.
Rus: TextMate is the last piece of software that delighted me, but I can’t remember the last time it shipped a genuine change.
posted by Aaron Swartz on August 31, 2007 #
There are 2 things to keep in mind:
The quality of a delivered product or feature increases logarithmically with delivery time.
The use value of a delivered product or feature decreases exponentially with delivery time.
Let’s call the point on the time graph where the two plot lines intersect “perfect ship date” (PSD). Before PSD you’re creating value by not shipping and after PSD you’re destroying value by not shipping. Since the point is unknowable you have to choose which side of the point you’d rather err on.
I think history shows that erring on the early side is a better survival strategy than erring on the late side. Worse is better: http://www.jwz.org/doc/worse-is-better.html
posted by David Mathers on August 31, 2007 #
Another example of worse-is-better: I’m reading this on the World Wide Web, not on Xanadu.
posted by David Mathers on August 31, 2007 #
I just read your thought again and I think I missed your point in my response.
If your point is that a product that provokes an emotional response is delivering significantly more user value than one that is merely functional, then I agree completely.
posted by David Mathers on August 31, 2007 #
Hey Aaron,
I think you might appreciate the irony of publishing a post on your perfectionism that has a grammatical error in it.
“…Paul Graham suggests startups can make you rich if you simple be sure to email him once a week.”
Ian
posted by Ian on August 31, 2007 #
Aaron:
Yeah, was just responding to tk’s comment about Coda. And yeah, Allan had better get to work on that. :)
posted by Jacob Rus on September 1, 2007 #
David Mathers:
I think you’re on the right track, but not quite there. In my view, a product can never be “merely functional.” If it doesn’t provoke an emotional response, that’s critical missing functionality.
Well-designed products minimize mental overhead through elegant simplicity.
posted by Jacob Rus on September 1, 2007 #
Perfection isn’t as important as is a well-adapted system. Determining which functionality best satisfies a majority of the uses for the largest sub-set(s) of your user base will prove more valuable than providing an exceedingly polished set of functions that don’t map as well to solving the problems your users are trying to solve.
posted by John Siegrist on September 3, 2007 #
You can also send comments by email.