> Your software, your product, is nothing more than a collection of tiny details. If you don't obsess over all those details, if you think it's OK to concentrate on the "important" parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis – you're not creating great software. Someone else is.
I think the true moral of his story contradicts his conclusion.
He and his wife had a problem: They didn't like manually feeding their cats. So they bought a couple of automatic cat feeders and enjoyed owning them—despite several small, annoying flaws. In fact, he and his wife dutifully employed those feeders for five years until he noticed (and purchased) the company's newer, improved version!
I liked the essay, but I suppose Jeff and I disagree on what the story teaches us.
This story is about a company that identified a pain point (manually feeding cats is annoying) and created a product that alleviated the pain (an automatic cat feeder) despite several flaws (a bad color, an annoying button guard, and a difficult to clean food bowl, to name a few). Over time, the company resolved those flaws, but they didn't wait until all of the flaws were resolved before initially shipping their product. Instead, they shipped a useful, albeit imperfect product, and earned themselves at least two repeat customers.
In a new market with no competitors what matters is that someone created an automatic cat feeder at all.
In a more mature market with several competitors those small details matter more.
In a very mature market maybe several competitors get the tiny details right, so maybe building a brand matters a lot...
The dancing bear analogy is on the money. It's like early computers: "OMG, word processing! I can "delete" my typos! I can reformat my paragraph!" Today's computers: "it's hard for me to figure out how to reformat the paragraph. Next app!" Also, early computers: "the computer crashed, I should've saved!" Today's computers: "the damn computer should not have lost my data no matter what happened."
So shipping is a feature, but continual improvement once you've shipped is necessary, too.
They already owned the old version, having paid for it and installed it in their home. The issues were a minor annoyance but the effort to find a new one and risk it being worse was far greater.
However software, especially web applications generally have a low switching cost. So while your application might fulfill a need if you don't fix the annoyances you make it all the easier for a competitor the sweep in a grab your business.
The history of the internet is littered with examples both large and small.
I mean, the company that made these things could have decided that the first version shouldn't include the timer. This is the imperfect first version. Time it yourself, and we'll add a timer to the next version!
After all, that's all you need to feed your cats on a schedule, isn't it? Sure! This product is adequate. Why get distracted with unnecessary timers?
Of course, the product would probably have languished because there are plenty of other bowls you can fill on a schedule. The lesson? Get the right details squared away ahead of time, and get the less important details squared away later.
Firstly there is value in solving the problem. It didn't matter that the feeder had rough edges, it did the job. That's ultimately what matters. If it didn't feed the cats it would be considered faulty.
Secondly there is value from offering a superior experience, offering better and additional features, superior design etc. If you're product doesn't offer these it isn't broken - but it does have room for improvement.
If my phone can't ring people or text it's broken. But I can spend £20 for a phone like that. A phone that lets me send email, check twitter or browse the web is a lot mor valuable. It's why Apple and Samsung can sell phones for hundreds of pounds.
Does your product solve people's problems? If it does it's valuable. That collection of details though, fix or implement those and your product is a lot more valuable.
At which point I voluntarily wrote a blog post that described how wonderful their feeders are, and how thoughtful the revised product was, to over a hundred thousand people.
So which kind of product do you want to be?
Granted, it's easier to switch cat feeders than phone OSes, but I think the point still stands—if you alleviate a pain point, you can tweak your product to make it delightful later.
Thanks for keeping up with your blog, and congrats on your three little humans! Do they make automatic feeders for those yet? Perhaps if you clean out your old cat feeders really well...
: If you enter an existing market with nothing to differentiate your product (including price), then yes—you're probably going to fail.
Not really related to the point, but should you be adjusting the time for daylight savings at all? I mean, the cats don't care about the arbitrary 24 hours we humans use to divide up the day, so wouldn't adjusting the time for daylight saving just seem like an arbitrary change for no good reason to a cat?
Besides, we have large windows.
(1) I want my cats to be fed just before I go to sleep so the cats have the maximal period of full belly when I go to bed. I go to bed at 11:00 pm. Keep in mind that I observe DST changes for myself. But if I never adjust the feeder for standard/daylight time, then either the cats will be hungry until the midnight feeding or they'll be fed an hour early at 10:00 pm. In either case, they are more likely to wake me up for food during the night.
(2) The cat feeder is in my bedroom and since I have it set to feed the cats just before bedtime, I don't want it making noise an hour after I fall asleep. That's what would happen when I've switched to daylight time but the feeder hasn't.
The point is that there can be legitimate reasons why you'd care about a DST adjustment even if your cats don't.
Arbitrary change or not, at 4 am cat on face always wins
I agree with Jeff Atwood, that it's those little details that makes makes an app enjoyable, where before it might have been merely tolerable.
The more complex the product, the more details it has, and the harder it is to get all of those details "right". Sometimes it's impossible to get all of them "right" because different market segments have different ideas of what "right" is.
That's one of the core reasons I recommend that people start with smaller, simpler products. The easiest way of avoiding getting details wrong is to not have them in the first place.
It's much easier to delight a customer with a small simple product - because there are far fewer things for you to foul up :-)
The improvements to this product were so substantial that all of Jeff's audience now has some degree of brand awareness and a positive bias towards it.
When was the last time an upgraded product -- one that you didn't even get discounted -- made you so effusive?
The details (and implementation) of an app flow from those decisions. Include or exclude a feature? That's a decision. Buttons on the left/right, top/bottom? Decision. Add a pluggable architecture? Decision.
Look at a rather successful product like the iPhone. Much of its success can be traced to getting lots of details right. But understanding what was going into the iPhone -- the decisions made about how to create it -- led to those details. Touchscreen, app store, glass cover, all of it were active decisions.
Executing details are absolutely critical, but making the decision of what to do (or not to do) is where it all starts.
I think that Jeff's point is more valid if you look at it from the customer's view.
The fact that Jeff used the same feeders for five years is a testament to how well the original designers were able to address the core problem well enough.
Edit: They also functioned well enough that he bought the updated version on faith.
I'm not sure how any of that figures into his analogy, though.
Or, your app is the fundamental philosophy it its design,
or, or, or...