Comment by danielmiller | Hacker News Reader

Comment by danielmiller | Hacker News Reader

Hold on a second, Jeff!

> 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.

I am not a marketing expert, but my reaction to this article was that it pretty much depends on what 'market phase' we are in.

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 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."

Related is 37signals' "Ignore Details Early On" [1]

So shipping is a feature, but continual improvement once you've shipped is necessary, too.

[1] http://gettingreal.37signals.com/ch04_Ignore_Details_Early_O...

Switching costs.

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.

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.

So which kind of product do you want to be?

The imperfect product that ships. Shipping is a feature, too.

Did I say it wasn't? You know what else is a feature? Being awesome!

I guess it comes down to "would you release an adequate product now and a great one later, or would you skip the adequate one completely?"

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.

It seems to me there are two parts too this.

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

Reply on news.ycombinator.com