daily articles for founders

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

Dropping out for a startup  

Joel Gascoigne's cofounder, Leo Widrich, dropped out of university to start successful startup Buffer. Here are Joel's insights (some gleaned from Leo) about the interaction between university and startups.

My belief and experience with going through Leo dropping out is that when it is good to drop out for your startup, you will know it. That said, I think one of the biggest misconceptions is that you have to abruptly cut everything off and burn all your bridges with university.

How I've seen it play out more often than not, is that someone does many different side-projects during college and then when something begins to work, they go through a massive amount of learning and progress in an incredibly short space of time. This is very much related to Paul Graham's notion of compressing your life:

But don't be too keen to do it:

[M]y advice to anyone thinking of dropping out is to keep studying, and use every opportunity to build projects and startups on the side. When something starts to work, you'll have that same feeling that many others have, and you'll know that it's your duty to keep building it and bring it to the world. Until that happens, keep studying and keep building. When it happens, drop out slowly.

Read up on SEO and Link Building  

Kristi Hines has put together this list of (reputable) blogs, articles and tools around the topic of SEO and link building.

For many tech founders, SEO is associated with spammers, direct marketers, and other "social media experts" - i.e. fluff. But that's a one-sided view. People like Patrick McKenzie demonstrate that SEO can be an extremely powerful part of your toolset.

This list of links, along with Patrick's blog is a great starting point if you want to learn more about SEO and link building.

A simple point that shouldn't need to be made  

Chris Dixon:

It would be great to think that in the startup industry, people would realize that today's junior person could become "big time" tomorrow, and that you should therefore be meritocratic and respectful to everyone. But that's not my experience.

In my experience, people who look down on more junior people in the startup industry are either douchebags, or outsiders. Everyone in the industry understands that where someone is today is often uncorrelated to where they will be tomorrow, and acts accordingly.

Entrepreneurial sales lessons  

An article by yours truly, on the OnStartups blog, outlining three lessons from sales and dealmaking in startups:

One of the hardest things for me to get used to, as a geek/artist/writer in business, is the constant disappointment of sales. The harsh reality, however, is that many leads will not turn into clients, no matter how exciting they might seem at first. And yet each lead must be given attention, enthusiasm, dedication, and so on, if it is to have any chance at all of turning into a sale.

Some of these will be obvious to experienced entrepreneurs, but it's amazing how many new (and not so new) founders think "it doesn't apply to me, my startup is different."

Lean Startup Machine learnings  

Eric Ries, already mentioned earlier today, also posted this retrospective on Lean Startup Machine, a Boston-based "build an MVP in 48 hours" event.

He makes a few really important points:

For example, one team managed to put together a very decent looking minimum viable product, in the form of a landing page with a "click to signup button" that basically did nothing but collect data about who was clicking. And their MVP even had a reasonably high click rate. But is a 25% click rate validation of the idea? That depends on who's clicking and why. Do they understand the product? Are they eager to try it, or were they just enticed by the shiny button? Unfortunately, the team had no way of answering these questions. They weren't even collecting contact information from these first customers. They were just counting clicks.


This is a classic startup fallacy: "ship it and see what happens." Whenever you use this plan, you are guaranteed to succeed - at seeing what happens. Unfortunately, if you cannot fail, you cannot learn.

One way to organise the MVP-building process to ensure it does answer real questions is, of course, Hypothesis-Driven Development, covered here before.

Advice for a young entrepreneur  

Tony Stubblebine starts with the following (well presented) advice:

  1. Surround yourself with interesting people;
  2. Focus on the right things (which means, ironically, figuring out what the right things are);
  3. Be useful.

He ends on a little zinger:

There's basically two ways to be financially successful as a company. One, you could rely on time-tested business fundamentals. I call this the Warren Buffet model.

Two, you could rely on the greater fool theory, which is that with enough hype, smoke, and mirrors you can find a buyer who is an even greater fool than your investors.


So much of the startup world is arrayed around the greater fool theory that I felt like my best chance was to build a company that was independent of that system. I think of bootstrapping as a very slow form of raising money. But now that we've done it, I have a reliable stream of income and never have to raise money again. It's really just at this moment in time that we can switch from doing whatever it takes to survive to actually testing our ability to make a major impact.

To be fair, there are situations where you do need the extra money to grow extra fast, or else you lose. Groupon is a good example - had they not executed so brilliantly and quickly, they would have been eaten alive by the dozens of clones which emerged everywhere.

I'm a big fan of getting profitable early, but it is neither the only way, nor the universal best way.

Max Levchin's hiring tips  

Max Levchin's hiring tricks, put together by Bill Trenchard:

  • If there's a doubt, don't hire them
  • Hire people you know already
  • Stay away from diversity early on (controversial!)
  • Differentiate your company through its hiring process

The article is interesting. Sadly, I don't think it will help. Call me a cynic, but I think hiring is one of those things where people listen to the advice but then do their own thing anyway. Then they learn.

An interesting point from the article:

It's easy to think you can't possibly know enough good people from your network to build out an entire team. While in some ways that's true, Levchin's experience is that almost everyone actually knows more good people than they believe they know. The challenge is that most founders rule out top talent because they think they'll never be able to actually get them to join their team.

Levchin learned early on not to make this mistake. When PayPal was founded, he sat down and created a list of potential engineering hires. When he was done he had a single name written down. Levchin recounts demoralizing exercise, " Peter [Thiel] sat me down and he made me write down every smart person I knew in college personally. Turned out to be a list of about 30 people and we ended up hiring about 24 of those." You can't rule potential hires out just because you don't think you can win them. He went on to note, "We had this cascading effect where our team would be forced to write down everybody smart they knew that they were absolutely confident they could never hire. We then went after them like banshees and they would eventually crack."

Enjoy the read.

Failing faster  

Andrew Badr points out, very rightly, that:

When you're choosing between opportunities to pursue, and there is any uncertainty in their outcomes, be sure to consider how long each possible outcome would take. Opportunities that would fail fast are more likely to be worth doing.


...for some reason, many people would tend to calculate the value of each opportunity over a falsely unified four-year time frame. This totally misses the additional value that comes from failing fast, which can lead to the wrong decision.

I would add that startup development techniques (like Hypothesis Driven Development) which help you fail faster are critical to achieving this. You can spend 4 years stagnating on a startup, just as easily as you can do in a corporation.

Sometimes, failure is your best option  

Brad Feld:

I strongly believe that there are times you should call it quits on a business. Not everything works. And — even after trying incredibly hard, and for a long period of time — failure is sometimes the best option. An entrepreneur shouldn't view their entrepreneur arc as being linked to a single company, and having a lifetime perspective around entrepreneurship helps put the notion of failure into perspective.

Entrepreneurship is a career (and a safe one at that). But that doesn't mean that every startup you start has to succeed for you to be successful.

Quite the contrary. Both of my first two startups failed. My third company is now successful, highly profitable with 11 employees and growing, and so I am generally considered a successful entrepreneur now.

The only constant about declaring that your startup has failed seems to be that everyone wishes they'd done it six months earlier. It's easy to know when you're succeeding, it's much harder to know when to quit and try something different.

Start something small  

Joel Gascoigne:

What I'm starting to notice more and more, is that great things almost always start small. Most of us know that Branson started the Virgin brand with a student magazine, but Virgin is just one of many examples which shows that the reality is counterintuitive: actually, the best things we know and love started as tiny things.

I've found that if I look into my own life, I find similarly that some of the most important achievements I've made started as little projects. My startup Buffer itself is a great example: it started as a two page website and in addition the short blog post describing this process has now turned into a talk I've given more than 30 times.

This applies in other areas of life - programming, for example, has Gall's Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.