He even acknowledges the importance of code quality ("It has to be high quality code that isn't filled with bugs or is insecure.") but his point is that, as a first-time entrepreneur, you will be overwhelmed with the other aspects of a business that have to developed, and you will tempted to focus yourself in the area that you have specialized in for years prior. As a founder that has recently began the transition from programmer, I can certainly say there are times that I've failed at this, and I'm sure it happens a lot.
Your watchmaker analogy is actually a pretty close parallel to software. The mechanical functioning guts (executable code) of the watch, the gears and ratchets and springs and all, probably are about 5% of the business. But the entire watchmaking concern, from supply of materials to fashioning the face and wristband to final assembly and inspection, encompasses much more.
It also seems like he's saying that "code" as an aesthetic principle is a very small part of your business. Your code is a means to an end (for your users), and does/should not hold much of your attention as an intrinsic ideal.
Several points are hit here (some I said in a previous comment): - get to know the customer (build MVP ...), see what they want, make a product not a Software Design masterpiece - prioritize correctly (and oftentimes - especially after you built the product - the biz is more valuable)
Anyway, my experience is that even if one knows this theoretically, he will get it after the practical experience. Good luck building!
Also, this reminds me of the "nail it, then scale it" approach. Don't focus on scalability when you don't have customers.
There are in fact plenty of businesses where a quality product is not particularly necessary. I'm sure you can name some.
Even when quality is important, it is often not what a coder would identify as quality. As long as your customers receive what they perceive as quality, you've got a business.
And even when you're talking about the kind of quality your customers are seeking, that still doesn't cover all of the time and attention you will have to spend on things that aren't code.
As an entrepreneur, code isn't your product. Your product is how that code is packaged in terms of solving a customer's pain point. Finding and convincing users to use your solution is 75% of business -- that means sales and marketing. 10% is fundraising or otherwise finding capital to pay the bills if you're pre revenue. 10% is helping retain existing users (i.e. support) and 5% is the actual code writing.
The code part of the original Facebook was no big accomplishment. Getting millions of users was. Those users didn't come because Zuck and Co. wrote great code; they came because the product was something that did what they wanted and was marketed in a highly effective and viral way that drove users. Coding isn't business, it's just one of the inputs that goes into a business.
To use a watchmaker example, an anonymous watchmaker that has a fantastic watch will never grow his business despite an amazing piece of 'code' -- it takes marketing and sales to make it happen. It also takes distribution, billing and administrative support. Code is a minor part of the business.
1. Code is 5% of your business: no, it isn't. If you have a watchmaking company, is making watches 5% of the business? Marketing, sales, and operations are only important as long as you have a quality product.
2. Design is everything: it can used to great advantage, but let's keep it real. There are plenty examples of successful "gray boxes" applications, don't confuse aesthetics for usability. We are here on HN, aren't we?