I don't think it's nearly that cut-and-dry. The most elegant code in the world is pointless if it doesn't solve a real problem (the end product), and the an unmaintainable and unscalable mess of crap that actually shipped on time is equally pointless if it's so broken that user's can't use the product or developers can't improve upon it.

Great people need to find a balance, and I don't think leaning towards one side or another shows whether someone would be a great employee and/or founder. This "ship early/ship often" and "move fast and break stuff" attitude is ok for immature products, but there's still a minimum level of quality you need to reach, and as your userbase grows and your product matures, it's almost certainly going to be important to raise the bar on quality.

Shipping prototypes is fine, but you have to keep in mind that if it catches on, your plan to rebuild a non-crap version (invariably you had this plan) will fall through because something else came up.

My rule of thumb for prototypes is to get the data models close to right, and untangle the rest later. Pulling apart spaghetti code isn't too bad as long as there's reasonably sane intent behind it. I can fix systems where people are updating state from the views and writing to the db in all sorts of unimaginable, horrible ways; however, if you're not storing the right info, you're pretty screwed and have a hell of a migration process in your future.

Just because you focus on the product does not mean you ship bad code. Nor does a focus on the code mean you ignore the product. I see it more of a philosophical thing - what excites you most? Writing a highly efficient, perfectly formed piece of code; or creating a product that others use.

Not necessarily. The first may cause you to miss deadlines, piss of clients and ultimately lose the company money because you focused on code... I think it is important to balance both. But I get (and agree) with your point.