There are several things that making the effort to new customers will give you:
1. Money. If you have more paying customers, you have more revenue. More revenue means you can pay to make problems go away. Taxes, accounting, web design (if that's not your forte), and even the sales process itself (though it's almost certain that no one can sell your product better than you can early on).
2. More feedback. You might be going the wrong way. Early adopters have a very different set of requirements from the average user (generally). So, the more mainstream your sales process becomes the more likely you are to find out that you're on the wrong path. It's very easy to keep going further and further into a niche--and if that niche is too small, you're gonna be in big trouble before you even realize it. It's entirely possible to featurize yourself out of the big markets by focusing on the tiny niches that your early adopters live in. For example, our early adopters tend to push for scalability solutions for single websites--but our mainstream customers just want to fit more customers onto the same box. If we spend all of our time building scalability solutions, we'll find ourselves only being able to serve 2% of the market extremely.
3. More users who can help you help other users, via forums or mailing lists or wikis, and can help you make more sales. It is a reinforcing cycle. We had an amazingly great sales day today, because we got mentioned by people we don't even know on Slashdot. Because we reach out to our community regularly, we support the sites and communities that would use our software, and we (or I, rather...Jamie is full-time on coding, always) try to close a deal with a new hosting provider (even small ones) every week or two.
Building a better mouse trap isn't going to make you rich. You have to "ring the cash register" sometime, or you not only won't get rich, you also won't be serving your customer as well as you should be.
But, I do think the blog post in question spends a bit too much time on checklists and making elaborate plans.
What does any of it have to do with "stop coding". If you can't juggle eggs, you should probably be someone else's employee.
I do the things you mention and I still code every single day. For a software startup, coding is like breathing. Stop and die. Only hackers understand this. Whoever downmodded my previous post is probably an MBA.
Ummm...Because most of us can't code while working on something else. I think each of us is just taking a different view of the words "stop coding". I think it means "for a few hours so you can get all of the other stuff done", while you seem to think it means "and never fire up vim/emacs again in your life". Obviously, I'm not telling anyone to stop coding forever (or even for more than a few days). If you're a tech entrepreneur you have to build things and keep building new things, or you won't be able to retain customers in the face of competitors that are always building new things.
(And I'm not among those who voted you down. I merely wanted to chime in with a bit of what I felt was important about the subject...not really in disagreement with you.)
As long as I've been doing this, 100% of the time I had problems implementing, it was always for the same reason: not enough software. Whether analysis wasn't sufficient, features were missing, testing wasn't complete, whatever, we were always deploying before we were ready. I understand that there's a school of thought that says to push like this, and naturally, I know how important the non-coding items are, but still...
I never had project difficulty because an invoice wasn't mailed, or a meeting was missed, or a prospect wasn't engaged; it was always, always, always because we simply needed more time/people/resources to have more software.
Imagine swimming the English channel and realizing you had other things to do. Would you stop swimming? Of course not. That's how I feel about coding.
For a software endeavor, coding is the critical path. Do other stuff, but don't stop coding.