daily articles for founders

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

Formula for elevator pitches  

A simple formula for an effective elevator pitch, via Elliot Loh:

We solve [problem] by providing [advantage], to help [target] accomplish [target's goal].

And, once it makes sense, bolt on:

We make money by charging [customers] to get [benefit].

What does the business guy do pre-launch?  

I don't quite understand why this idea keeps cropping up lately, even from reputable sources. For example, this one is from Seth Sternberg, the CEO and cofounder of Meebo - so he's hardly a nobody or a slouch. And yet, what to make of this:

For most consumer internet products, there's not a whole lot the business person can really do pre-launch. All of the company's value will come when the team builds and launches a product, so that should be the primary focus. There aren't any partnerships to be struck yet, as the product has yet to build any credibility in the market. There aren't any folks to interview, as you can't afford to hire a full team, and you're wasting your time looking for pre-launch financing—a controversial statement these days, I know, but that's a topic for another post.

The funny thing is, he answers that in the same article, as things to do "2-3 weeks before launch" - all those things can be done long before launch:

  • Get incorporated (how does that need to wait until launch?).
  • Figure out the launch strategy (I sure hope that's being done earlier than a month before launch!).
  • Find good mentors.

Here are a few other things to do if you're the business guy on a pre-launch startup:

And that's just looking through the articles in the Founder's Library.

The truth is, if you followed some kind of discipline like Hypothesis Driven Development to map out the unknowns ahead of you, you should have plenty to do before even starting to code, let alone while the coding is going on.

Peter Thiel: Founder as Victim, Founder as God  

Fascinating and quite long "lecture notes" from Peter Thiel. Upfront warning: there is very little directly actionable advice in this lecture, but it presents some very interesting ideas about Founders' place in the world, the social dynamics that surround them, how those dynamics have evolved through history, along the way drawing parallels between the evolution of human societies and the fate of the founders of technology companies.

It's fascinating stuff. Read here.

According to Aristotle, tragedy functioned so as to reduce common peoples' anger toward successful people. The lesson in all tragedy is that even the greatest people have tragic flaws. Everybody falls. It was thus cathartic for ordinary people to see terrible things happen to extraordinary people, if only on stage. Tragedies were political tools that transformed envy and anger into pity. Commoners would retreat contentedly to their small houses instead of plotting against the upper class.

Despite the fact that it doesn't really fit the "actionable advice, useful insight, or practical tools and techniques" criteria, I am including this in the Founder's Library because it is simply great.

Startup skills vs startup ideas

There's an interesting but damaging perversion in the startup world, around ideas vs execution. Even among those who believe that "ideas are worthless, execution is everything", there is a practical, observable tendency to rate theory over practice.

If you were advising someone about how to build a top quality web application, and they didn't know how to program, you'd tell them that first they need to learn to program, probably spend a year or more practicing the craft, before they have a chance to build even a mediocre quality application. Programming is a highly complex activity that takes skill (built through experience) to do well. You wouldn't simply explain to someone the technical and architectural pitfalls of the application they want to build, give them a process for how to program, and set them off.

The same is true for most technical fields. There is a skill base that takes many months or years to build, and that skill base determines the success of any non-trivial endeavour, rather than the process they follow or the idea they have. Certainly, having a great process and a great idea is a valuable plus, but without the skill base, process, ideas and theories are mostly worthless.

But somehow, despite their renowned complexity, startups seem to be exempt from this rule. A large portion of the advice given to startups focuses on ideas (you should do this, you should do that) rather than practical skill-building (you should practice that until you're good at it).

Lean startup and the scientific method

One flagrant example of that is the Lean Startup methodology. Lean Startup is a process, a plan for how to go about executing your idea. I love it, because it presents a clear approach for applying skills which I've built over the last few years. It's a great distillation of a very rational process for going about building a startup, and I commend Eric Ries for presenting it in such a clear and cohesive manner. However, by itself it is no more useful than the Scientific Method.

Wait a minute, Daniel, the Scientific Method got us all of modern science! Surely that's pretty damn useful! I don't disagree. The Scientific Method, and the Lean Startup Method, are both very useful... when applied correctly, and with the right skill set to back them up.

If you handed down the Scientific Method to someone who is not a trained scientist, in theory they should be use it to derive new laws of nature. In practice, though, what would most likely happen is that they would mis-apply this method and come up with all sorts of crackpot theories about perpetual motion machines and life-altering magnetic bracelets. There's a good reason why we force wannabe scientists through 5-10 years of training before allowing them to do anything of consequence: it takes that long to build the skills to know how to do it properly.

In some rare cases, an exceptionally brilliant genius might manage to do "real science" without formal training, but the common case for an untrained scientist trying to apply the scientific method is failure. This is not a failure of the method, it's a failure of the person, a failure of skills.

The same is true for startups. No matter how good your method is, if you don't have the core skills needed to build and run a successful business, the great likelihood is that you will fail - not because you have the wrong method, but simply because you have no idea what you're doing and applying the Lean Startup method (or any other approach to company-building) is hard and takes skills.

Core entrepreneurial skills

The good news is, skills can be learnt and practiced. You can go from zero skill, to moderate skill, to high levels of competence. If you have the right framework and support, you might even do so quite quickly. But like all skills, you will learn them more quickly if you're deliberate about it, rather than waiting for chance to teach you the skills in its world-renowned "school of hard knocks".

I'll cover these skills in more detail in another article, but my initial short-list of what the core entrepreneurial skills are is:

  • communication (written, visual, in-person)
  • programming
  • design
  • financial control
  • organisation
  • management
  • recruitment
  • negotiation
  • sales

Someone (or a cofounding team) who is competent in these 8 key areas will be much more likely to be able to successfully build a startup than someone who has major gaps in several of them. If you look at this list and see something that you have no skill in, you should consider either teaching yourself that skill, or pairing up with someone who is competent in that skill.

One final note: of course, skills vary depending on context. You might be great at giving corporate presentations, designing motorcycles or managing a department of 500 people in an international bank. That doesn't mean those skills will translate to the entrepreneurial context, and so you should be aware of that before ticking them off as "done". However, for each of these areas, there is a commonality between different contexts, which means that some of the skills will carry over, so a corporate salesperson will at least have a good head-start over someone who knows nothing about sales.

Criticism and two-way streets  

Great design approach by Des Traynor in this post:

Like Apple, Microsoft encourages their designers to create many different solutions to any given design problem. But picking an outright winner isn't easy. It can cause arguments and standstills. The quality of resolution here defines the quality of the design process. Who gets to decide? Is it the loudest shouter? The most senior? The highest paid? None of these are correct by default.

Every solution is great in some circumstances and terrible in others. Design debates are best settled by inviting everyone to present their solution, but also explain under what circumstances their solution is terrible. Finally they're asked to explain under what circumstances their colleague's solution would be better. This is what Bill Buxton refers to as walking on both sides of the street.

This can be scaled down to a small startup team. When solving a tricky design problem, ask everyone involved to come up with some solutions, then get them to explain when their solution won't work, and why the solutions they didn't come up with are better.

The article makes several other interesting points.

How to keep your sanity during launches  

Launches happen. That's true both in the startup world and in the corporate world. Sometimes they're quiet (when you sneakily release a feature and slowly apply it to your whole user population), and sometimes they're very loud (we've launched! sign up now for a first-day 50% discount today only!).

No matter what your development process, if you build cool stuff for a living, at some point you will launch something, and then all hell will break loose. Paraphrasing Michael Lopp: Launching a product isn't going to kill you, but it will try.

Here are Erin Bury's tips on how to survive:

  • Make sure all hands are on deck before, during and after.
  • Know that you will encounter technical difficulties.
  • Know that some people will attack and criticise you.
  • Make it easy for people to share their feedback and set aside time to respond.
  • Don't miss the PR opportunity.
  • Spread the word to the network of founders and customers that you know.

The last one is a great point. Don't just launch online - tell everyone else too.

Selling dirt takes skill  

Elli Kanal has some respect for a man who, without any advanced degree, can get by selling dirt from the Holy Land to religious pilgrims. Although he makes a few interesting points, I can't help but feel that this misses the mark:

My skillset: (1) I can program in five languages. (2) I'm able to interpret neural signals and tell you what you're thinking before you even know it yourself. (3) I know how to create a machine learning program that learns from it's past mistakes. (4-inf) All the other stuff I've learned along the way.

This guy's skillset: (1) Selling dirt.

In the words of the wise master Yoda, "this is why you fail." Selling dirt successfully, making a business out of it, takes a lot more skills than it seems on the surface. Sure, you can summarise it all as "selling dirt" (and even then, you're only looking at the skills that are directly used to make money), but then you could also summarise Eli's skills as: (1) doing computer stuff; and, in fact, this is how many people who know nothing about computers summarise the skills of the average technical cofounder.

The first step to learning to be a successful businessman is to realise that business creation is a technical field that must be learned and figured out just like any other. And, unlike engineering, which is taught to relatively high levels at university, there is no course that will really help you pick it up (MBAs are widely recognised as being far from effective at training entrepreneurs).

It's a common misconception of technical founders that there's nothing to "all that business stuff". But that view is as uninformed as the opposing one that "all you need is to hire a coder to implement your vision".

Startup failure and startup mediocrity  

Dharmesh Shah:

One of the great things about software startups today is that it's very possible to reach "ramen profitability". That's also one of the bad things. Once you get to "ramen profitability", running out of cash is no longer a way to know that you should be starting afresh and trying something new. You can run a startup like that indefinitely — and many entrepreneurs will do just that, instead of building the next Dropbox and becoming legendary.

I'm of the opinion that people who are really driven to build great companies will use their "mediocre" companies as springboards to bigger and better things, and only those who don't care so much about how big their company is will remain "stuck in a dead end statup", so to speak (and they will be happy about it, because they will get their sense of fulfilment from somewhere else).

Building a startup that pays your salary and enables you to spend your time on whatever you want is no mean feat. Of course, if instead you build a startup that sucks all your time and energy in exchange for a meagre amount of money and success, then that's not a great deal, but then, surely, people stuck in this situation will not be any happier with it than they would be with a job that provided the same results, and they will act accordingly.

Count me firmly on the side that's very pleased that it's cheaper than ever to build a profitable startup.

Four misconceptions about Lean startup  

The Lean Startup methodology is frequently misunderstood, unfortunately. This article by Jim Kalbach is one more attempt to clear up some of the more common misconceptions, namely:

  • Lean startup is not an engineering process, it's a method for building startup, so it won't make your developers happy.
  • Lean startup doesn't mean "let's just shoot from the hip without overanalysing things."
  • An MVP is not a lightweight version of the product, it's the answer to a question, the resolution of your next most pressing uncertainty. More on this here.
  • User testing will not "slow you down" - it's the heart of the Lean Startup method: do stuff only to learn about what your customers need before they can give you money.

Read the whole article here.

How to detect a toxic customer  

Excellent article, and vital information. The less time you spend on toxic (and unprofitable) customers, the more time you can spend on good (and profitable customers). Recognising toxic customers is a vital skill.

Warning signs (see the article for more details):

  1. Disrespectful or Abrupt
  2. Asks for a Discount (With No Reason)
  3. Multiple Contacts, Often Through Multiple Channels
  4. Unrealistic Expectations
  5. Multiple Questions that Can Be Answered from Your Website

The article also describes an amusing encounter with a toxic customer, recognised early, and, unlike many such stories, it actually finishes well.

Update: excellent response from Joel Spolsky on HN.