> 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.
The product in the early phase was called a Dancing Bear in the book, "The Inmates are Running the Asylum". You don't need the bear to move like a professional dancer because "look at that, it's a bear ... and it's dancing!". The details start to matter when more dancing bears come on the scene.
+1. "The Inmates Are Running the Asylum" is an excellent book and a must must must read for anyone in software engineering. It will open your mind and give you a new perspective on software.
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."
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.
Both aspects are valid, but I think what you point out is also very important. I know several people who are not launching their product because they are doing yet another iteration of user tests and fine tuning. On the other hand my experience has been that if your product provides anything useful for people, they will be able to extract it. I am often surprised at the complex user interfaces people master - stuff I personally would never have the patience to put up with, but "normal people" somehow master it, even if at the same time they might not be aware what a browser is. (One example: Facebook groups, horrible interface but apparently people use it).
There's a world of difference between "imperfect" and "merely adequate". Not having all the details squared away makes your product imperfect. Not having all the important details squared away makes your product "merely adequate". The key is knowing which details are important and which aren't. Using "We can't be perfect" to dismiss the details is a cop out.
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.
umm.... i think he focuses on the merits of the new product and the fact that the company eventually paid attention on the details, otherwise he would probably go for something else
Until they delighted me, by addressing all the niggling details that I didn't like about the old version of the feeder.
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.
I'd love to have a delightful product, and I'd love for it to be given positive press to over a hundred thousand people! But like Android back in 2008, I don't think I'd get there without scrappily alleviating a pain point, getting my foot in proverbial door, and just shipping. Had Google waited and waited, they might be where Microsoft is now with WP7—an awesome product with really nice details that no one uses.
Granted, it's easier to switch cat feeders than phone OSes, but I think the point still stands—if you alleviate a pain point[1], 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...
[1]: If you enter an existing market with nothing to differentiate your product (including price), then yes—you're probably going to fail.
> We never changed the actual feed schedule, but just changing the time for daylight savings was so incredibly awkward and contorted we had to summarize the steps from the manual on a separate piece of paper as a "cheat sheet"
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?
I am not a cat either, but I do live 52.5 degrees North and quite often visit 57.5 degrees North. Daylight saving is not arbitrary for daylight liking non-cats
But daylight saving occurs during the time when you already have more daylight than the vast majority of habitable landmass does. You aren't "saving" daylight at all during the daylight poor months when you're inside at work during the entire daylight period.
In the spirit of the OP's point about tiny details, I can offer you two reasons why setting DST matters:
(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.
If your cats sit on your head at 5am to remind you to feed them, then if your auto-feeder thinks 5am is another hour off, your cats will not. they will howl and sit on your head, only now its 4am.
Arbitrary change or not, at 4 am cat on face always wins
Except the point with the 5am bit was that the cats no longer directly associate the author with food (and vice versa), so the cats don't sit on his face at all; they'll just get angry at the feeders.
Today I was designing wireframes for a web application, using a little prototyping app called Balsamiq mockups. It is a little, very focused application, and the detail level is nothing short of amazing. Typing a few letters and hitting enter will create a new control and add it to the canvas, already focused and ready for positioning. Creating a text paragraph and then writing the word lorem, will automatically create 3 lines of lorem ipsum text. There is a filterable icon gallery. One click export to PNG, and all other kinds of little nuggets.
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.
A vaguely related point to this is how the problems with getting details right are related to the simplicity or complexity of the product.
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?
I get where Jeff is going with this post, and I agree and disagree. It may seem like splitting hairs, but I find a big difference between details and decisions. My version: your app is a collection of decisions.
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.
And from the customer's point of view, the first product did the single most important thing properly. Feed the cats with minimal human input. That's still a decision on the creators' part i.e the creators could have sat down and bickered about colour options but they (presumably) took a decision to fix the customer's problem.
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.
Having owned both of those cat feeders, for all the improvements made, the new model has a fatal flaw not readily apparent from the pictures shown: The edges of the hopper are not at a steep enough slope to move all the cat food downward (depending on size/shape, I imagine). This allows significant amounts of food to pile up on the sides and not be funneled into the dispensing mechanism underneath. Worse than just causing the unit to have a much smaller usable volume that expected, it gives the appearance of still being full when, in fact, the cats are starving.
I'm not sure how any of that figures into his analogy, though.
> 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.