Moving from programmer to entrepreneur

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.

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.

It's a huge thing to stop being a programmer, when you started out thinking it was the only path open to you career wise, and that you would be in the software business in one form or another for your entire career. But cutting that cord - as difficult as it is - can be liberating. Cause face it - if you can sell software that you wrote yourself, you can sell anything online.

What you're proposing is a little like building a house to see if a customer likes enough to buy it, without letting them pick a layout/blueprint they like, or the conversation that goes into the blueprint of ensuring the customer would want the house.

First, find a target customer. Learn what their painpoints are. See if they're willing to pay for that painpoint. Then, build something to sell to them. This allows you to explore multiple hypotheses, instead of going to them with your idea that ends in a yes or no. By involving customers from the get go, they are more engaged, invested and committed, especially if it could make their life easier.

You will find that this path will reveal to you a completely different set of priorities and pain points that would be small to do, but have a huge impact, which is a great basis for an MVP.

By doing it doing it in reverse, you're hoping you take a stab at it and it pans out, at the expense of not doing the idea development upfront before writing a single line of code. The best way to "market" is to do it as you explore what to do and build a mailing list. Share your journey through a blog focussing on the life and business problem you're solving (not your code or tech breakthroughs).

Learn about your customer instead of guessing your way through what someone might want. Having domain knowledge in a field that you build something for could be helpful but you still have to validate, first, if anyone will pay for it. That's the scary, and what makes it a real business (self sustainable and makes money for you).

Of course if it's just you and you're committed to launching your product regardless of whether you get investment or not, then you might as well code it up and see what happens!

A preferable approach is if you can test the business/app soundness before investing 5 to 6 months in programming effort. If you can test two or three app ideas in that same period you significantly increase your chances to hit gold.

That mentioned 4-5 months will, statistically, be for nought if you don't do the important marketing/prep work ahead of time.

You are wasting your time by building the product first. You have to do the inverse. Become a marketing money for the first four to five months and do minimal coding (that is why its called an MVP). Once you have people buying your product, then you focus on improving it (or refactoring to rails, for example). If you do get funding, then use the money to grow the business and software at the same time/ratio.

Reason why this may seem a bit alien to you is because it requires you to go into marketing mode from day #1. Something you may not be comfortable doing.

Plus, marketing a product is just not about adwords, blog posts, and link on hacker news. It requires you to actually talk to other people directly. This is where a lot of introvert hackers ( like me ) quit.

You have a big assumption: Product X will be valuable enough that people in group Y will pay for it. Your way of testing that assumption is to spend 5 months coding plus N months trying to sell it.

So at the end of 6-12 months, suppose you discover that Product X is in fact not valuable. All of the coding time and a substantial portion of the marketing time will be wasted.

Ask yourself: what's the cheapest possible way to test your core assumption?

Anyway best of luck!

Are you VC backed and can live without positive cash flow? Ore are you trying to build a real business?