daily articles for founders

Here are 10 quality posts from the Founder's Library:

Don't register your idea as a company  

Me, in January 2011:

I want to start this new year with an admonition, for all those who are still working at a day job, and thinking that at some point they may want to run their own business, but who haven't decided to do so yet.

Register a business, today.

Joel Gascoigne, today::

When to incorporate is one of those topics which comes up time and time again, and there is much conflicting advice out there. I'm lucky enough to have a number of different experiences and perspectives with this, and I now believe that by far the best option in almost all cases is to delay registering a company for as long as possible.

So who's right?

Actually, both of us are, because we're talking about different things.

I advise people who are hesitating on the cusp of starting their own business to register a business right away, because this will get them over one of the biggest mental hurdles and force them into the company owner mindset.

However, there's no forced congruency between this business, which is a step towards personal freedom, and "registering a business for an idea". The business that I propose you register today, if you haven't yet, is the a business that will largely represent you. It can be used for many purposes - including as an incubator or even long-term receptacle - for ideas, but that is not its sole purposes. Registering a business for what is merely an idea with no real validation is, as Joel correctly states, not a good thing.

However, that doesn't mean you should operate without the protection of a limited company. A great many successful entrepreneurs that I know have several businesses, including one that they use for their various consulting and speaking gigs. Just because an idea starts in one business doesn't mean it needs to remain there always. As the sole shareholder, you are allowed and able to transfer the assets to a new entity as and when it makes sense - e.g. when you need to take on shareholders.

So, do register a business, but register it for you - not for an idea.

How to learn to program without going on a £1,000 training course

Most of my colleagues in GrantTree do not know how to code.

That's fine. Their job does not involve programming computers, and although there are, I believe, always tangential benefits to knowing how to tell computers what to do, programming is not essential to their jobs and they can be brilliant without knowing how to program.

However, one of the side-effects of the explosion of startups all around the world is that several of these colleagues have already expressed some interest towards various courses that claim to teach someone "the basics of programming", whatever the hell that may be, for a nice round sum like £500 or £800 or thereabouts, in a single day.

The magic wand of bollocks

I know I won't raise any eyebrows in the actual tech scene with this article. Anyone who's learned how to program knows that there's no magic wand that will miraculously teach you how to program in a day, not for £500 or for any amount of money. You can't teach someone to program in a day any more than you can teach someone to ski or write or ride horses in a day. Those things take time. Lessons might help, but at £X00 a day you'll be broke long before you know how to program.

But there are a lot of people who don't know this. This article is for them. If you know someone who's thinking of spending a large chunk of hard-earned cash on the happy-shiny promise of learning to code in a day, please send them a link to this article.

Here's the simple, friendly, warm truth (it's not cold or hard, for once):

Learning to program doesn't cost any money.

Ok, let me qualify that - you might need some kind of programmable device. Any old laptop will do, no matter how decrepit. There are many people who learned to program on calculators. Even the cheapest netbook you can find will do. There is zero correlation between how powerful the machine you're learning on is, and how quickly you will learn. In fact, there might even be an argument to be made for learning to code on an older machine, one from the early 90s with MS-DOS on it. Back then, things were a lot simpler to understand.

Beyond that one programmable device, and a way to access the internet to read up articles about stuff, you don't need to buy anything at all.

Of course, there are many people who will happily try to sell you instant-programming-knowledge-in-a-pill, but they will not be able to deliver, because learning to program is a 10-year engagement and you will not get anywhere useful down that path if you feel you need other people to teach you stuff.

Ultimately, however, no one can teach you how to program in a day. And whatever sliver of tangential, programming-related knowledge they can teach in a day is, in my opinion, absolutely not worth the vast amounts of money requested. The reason is that the only point when you're really going to start to learn to program is when you start teaching yourself to program, and you can do that for free.

How to learn to program

There are many ways that you might teach yourself to program. The paragraphs below outline just one such way, which is the way I usually suggest to people who approach me and say they want to learn to program.

In my view, there is one factor that anyone who wants to learn how to program well must have: a sense of fascination at the idea that you can tell computers what to do.

Steve Jobs called computers a bicycle for the mind. If you can get yourself to the point where you find really awesome the idea of doing brain-work faster by telling a computer what to do, then you will learn how to program. Nothing will stop you, nothing can get in your way, not lack of hardware or lack of knowledge.

Once you have been bitten by the passion bug, you will learn how to program.

So, any early activity should be aimed at finding that bug and getting bitten.

How to get bitten

Each person will naturally be different, but here's a simple approach that should work for most people.

First, find someone in your entourage who does know how to program - ideally someone who's already quite good at it and who's reasonably people-friendly. These days, that's not so hard, as there are many of us "competent programmers" out and about.

Talk to them. Find out why they're fascinated by programming. Find out how the bug bit them. Find out more about why they care, in short. Get interested. Then, when you're starting to feel like what they say sounds pretty damn cool indeed, ask them what they'd suggest you do to get started doing that.

Chances are, whatever they just said is out of your reach, even if it's not particularly complicated for a competent programmer. But they should be able to suggest something you can work on now to get closer to being able to do that yourself. For example, if you want to build your own blog from scratch, someone might suggest that you first learn some basics of programming using one of the Learn X The Hard Way books, and then introduce you to a platform like Ruby/Rails, Python, JS/Node or some other similar thing, and then point you towards the appropriate tutorials and books about how those technologies actually end up producing a website you can deploy and then browse from any computer.

Your path will be entirely unique to you, but the starting point, the initial spark of interest, is what will propel you down that path.

That's all you need to learn to program. A spark. And it doesn't cost any money at all.

Should you turn into a hacker to do a startup?  

Nai Chng makes the point that at the early stages of a startup, if you can't help with the coding you're... less than useful. While I certainly agree that learning to code should be as essential for non-technical founders as learning business essentials is for technical founders, I think you can take it a bit too far:

... at the very early stages of a startup, what are you going to do if you can't code? There are only that much research/admin/strategy/cust. dev/misc work a non-technical person can do. (...) Right at the beginning, you got nothing but a gut feeling about something and what needs doing is the building of a prototype to validate those feelings.

That is only a problem if you see a startup as a series of things to build. You shouldn't build a prototype to validate your gut feeling - you should build a prototype when and only when it is necessary to test the next hypothesis on your startup hypotheses. Most of the time, the way to get that next critical answer won't involve much, if any, coding.

So, I don't think it's true that you need to turn into a hacker. At some points, there will be more programming to do, and at others there will be less programming to do. All founders should be multi-skiled and willing to get their hands dirty doing anything the business requires, but they don't need to all be hackers. There are plenty of examples of successful businesses started by a combination of both hackers and non-hackers.

The value of time, or not  

Here's an interesting article by Jack Groetzinger, making a relatively elaborate argument for how to value one's time.

Every person at every company has an implicit hourly rate of value they create for the business. Perhaps Bob, our traveling salesman, provides $150 of value for every hour that he's working [1]. If Bob catches the flu and is forced to spend a day hunched over a toilet rather on the road selling, then the DCF of future SeatGeek earnings decreases by $1,500 [2].

However, Jack then rightly undermines this point later (though doesn't go far enough in getting rid of it):

The rate at which you value your time value your time is not static; it's constantly changing. If I'm stuck on a plane with no internet, the rate at which I'm creating value for SeatGeek is low. On the other hand, suppose it's 3am in the morning and I'm feverishly working on a presentation for a massive client. The presentation will take place in five hours. Here, the rate at which I'm creating value quite high. If two hours magically disappeared from the clock, it could destroy a meaningful amount of SeatGeek's enterprise value. So I feel justified in, say, asking my girlfriend to get me a Diet Coke so that I don't have to break my concentration (thankfully she's an economics student, so she understands).

Jack then continues with a comparison of the value of someone's time to the company and their wage, but I'll stop here for an important tangent to a point which I think is crucial to the discussion.

Time is worthless

Time is the most valuable thing in the world, and yet by itself it is worthless. Time well used is valuable. As John Gruber said of Jobs in this article:

Late last night, long hours after the news broke that he was gone, my thoughts returned to those grass stains on his shoes back in June. I realize only now why they caught my eye. Those grass stained sneakers were the product of limited time, well spent.

We all have limited time, and we can't buy more of it, so philosophically, we might say it's all priceless. So why do I say it's worthless? Because unless you spend it well, that time does not have any intrinsic value to your business (though it is probably still worth something to you personally).

I believe and have believed for a while that time is not the right thing to measure or preserve. Buying a $700 computer instead of spending an hour searching for an equivalent $640 computer (the example Jack uses) is a valid trade-off, but not because of the time being saved.

What makes the trade-off valid is the energy, the attention that's being saved.

We each have a limited amount of attention and energy (two sides of the same coin) to spend on a vast number of potential attention sinks each day. We can only care about so many different things each day, every day, before our very ability to give a damn gives up and we just don't care anymore and can't bring ourselves to care.

Spending energy caring about saving $60 on the purchase of a new computer is not worth Jack's limited supply of energy.

Whenever you're about to engage in chasing down some rabbit-hole distraction, think of this - if there are only 10 things that you have space to properly care about today, should this be one of them?

How to get actionable data from Google Analytics  

Another good post by Kristi Hines from the prolific KissMetrics blog. This one explains practically and in some detail how to set up Google Analytics goals and funnels and use them to learn about your website's conversion. This is quite an unexpected blog post, considering that KissMetrics sells a competing analytics solution, but the article is solid, clear and easy to follow. If you were thinking of adding funnel analysis to your Google Analytics but didn't know how, read this.

Start-up vs consulting vs corporate vs all three  

One of the great fallacies of the corporate world is that you must have a corporate job to have any kind of security in life. The corporate world is exceedingly good at brainwashing people who work there into believing that, to the extent that most people are (quite rightly) terrified of what will happen once they step out of the jumbo-jet of corporate life into what they perceive to be as free fall.

The natural reaction, once you realise that most of us are born with a solid pair of wings that will allow us to fly around the consulting and/or small business universe without anywhere near the level of risk that corporates thought was there, is to oppose the original lie. And there's some truth in that opposition. Flying in a plane is itself terrifying, because if something goes wrong with the plane, you'll be dead quickly, horrifyingly, and with no control over your destiny. Having your own wings (running your own business/consultancy) is far preferable from that point of view: you have control over your own fate. If you run out of money, it's your own fault, and was entirely predictable months in advance.

But, as I've mentioned before, one should not go too far in this direction either. The sensible, wise perspective is, as usual, in the middle. In large corporations, you can rise high up in the ranks if you work hard, are lucky, and play the careers game right. And so with startups or small businesses: if you work hard, are lucky, and play the game right, you can build something solid and rewarding. Which one you pick is really a matter of personal preferences.

So, in that context, here's an inspiring article by Vlad Lokshin, who refuses to settle for the accepted wisdom of either crowd, and carefully balances all three options. He arrives at his own conclusions of what the best fit is for him: a combination of a steady, 40 hours a week corporate (but independent) job with time on the side spent either consulting or working on his own ideas, as he sees fit. It's an appealing goal (though not so easy to achieve). Have a read for his full thinking.

I'll finish with one final piece of advice, which goes slightly contrary to one of Vlad's points:

No matter where you are, make sure you're always growing on a personal level. Never sacrifice your personal growth for some "I'll make it if I only throw everything into it" martyrdom delusion. Successful people start successful businesses, and successful people are always growing.

How to start a startup  

As I mentioned earlier, I will be posting older articles for the Founder's Library.

This classic from Paul Graham is a must-read for startup founders, and very much deserves to be the first to receive the "Library treatment".

You need three things to create a successful startup: to start with good people, to make something customers actually want, and to spend as little money as possible. Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.

Bearing in mind that Paul wrote this around the time when he started YCombinator, and so didn't have the vast amounts of experience watching over 200 startups grow, this is nevertheless an excellent pattern.

Starting with good people means to start with the right kind of obsessive, determined, smart people:

It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive.

Building what customers want means getting something out and quickly iterating it based on customer feedback:

In a startup, your initial plans are almost certain to be wrong in some way, and your first priority should be to figure out where. The only way to do that is to try implementing them.

This, however, should come with the caveat that not all product problems are revealed by coding - nor is the quickest way to check off hypotheses always to build something. See this article, or most of the Lean Startup methodology.

Paul's final point is about spending as little as possible - both in terms of hiring, and in terms of other miscellaneous expenses like Aeron chairs. This fits in with the Lean Startup methodology which is popular today, although one update from Lean is that, once you reach profitable product/market fit, i.e. once you have built a process that takes in $1 at one end and turns it into $2 at the other end, then you should invest money into scaling that process to saturation.

Startup sales: #2: Sell at every step

The first piece of advice was here. Here's the second one:

#2: Sell at every step

Until the money is in the bank, every interaction with the client is a sales interaction. When dealing with businesses, even a signed contract won't protect you from pissing off a customer. At the end of the day, if you're a startup and you piss off a company 10x your size and they demand to terminate the contract, what are you going to do? Nothing. You'll agree and let the contract slip.

With that in mind, it's important to make sure that every interaction before the money is in the bank reinforces your sales message. One classic mistake is sending a horrible looking contract. The contract is a sales document, and if your contract looks like shit, you look like shit. It imputes the value of your service or product just as much as Apple's packaging does for the goodies inside. Even your invoices should look good.

Another mistake is sending bad-looking status reports or plans of the ongoing work. Even the report that outlines how the project is slipping should look good and convey your sales message.

In this day and age, it doesn't take much to produce gorgeous-looking sales materials, so if you fail to do that, you fail at something very basic, and will rightly be penalised for it by losing sales.

So, think through every client interaction in the sales process that you mapped, and make sure every point of contact, be it a contract, email, meeting or phone call, projects the image you want to impute to your business.

Hot markets and flying turkeys  

Ameet said to me, "Ah, I've seen this many times before. See, Mark, in a booming market you can never tell the winners from the losers. In a booming market buyers aren't very discerning and companies that have weaknesses can mask them. I've seen this a few times before. Andersen Consulting always gains market share in down markets. That's where the companies who are just good at marketing tend to crumble. In a booming market you can't tell the difference."

The wisdom in the stock market is to buy when the market is down and depressed and sell when the market is high and hyped. The same is true for investing in startup ideas (whether you're a wealthy investor putting in money or a cash-strapped entrepreneur putting in their best years).

As an entrepreneur, this is even more important wisdom, because whereas an investor can invest in many startups at the same time, you can only pour your soul into one at a time.

Things change dramatically, however, if, as an individual, you can do multiple things at once for cheap. Then it might make more sense to follow the trends and monetise them as best you can. The applicable wisdom, then might be to put your eggs in many baskets that are rising with the tide, and sell them before the tide goes down.

Is your MVP really an MVP?  

Anthony Panozzo argues that most of what entrepreneurs calls "an MVP" is really a "version 1". Instead, an MVP is a tool to test assumptions. If you're not testing specific hypotheses, you're not doing an MVP.

So here are my new question for MVPs. If someone says they intend to "build an MVP" (the build part itself might be a tell), I am going to ask:

  • What are you trying to learn with this particular MVP?
  • What data are you collecting about your experiment?
  • What determines the success or failure of the experiment?

It's worth reading the article if you're unclear on this point.